Chap 4 E-R Model

7/29/2019 Chap 4 E-R Model

1/99

Designing of DatabaseEntity-Relationship Model

By

Parteek Bhatia

FacultyThapar University

Patiala


2/99

How to design the database?


3/99

How to design the database?

There are two approaches

E-R Modeling: Identifying entity and relations

Normalization: Refinement of database

designing


4/99


5/99

Entity-Relation Model


6/99

E-R Model

The Entity-Relationship (ER) model wasoriginally proposed by Peter in 1976

The ER model is a conceptual data model

that views the real world as entities andrelationships.

A basic component of the model is the Entity-Relationship diagram, which is used to

visually represent data objects.


7/99


8/99

Basic Constructs of E-R Modeling

A database can be modeled as:

a collection of entities,

relationship among entities. An entity is an object that exists and is distinguishable from

other objects. Example: specific person, company, event, plant

Entities have attributes

Example: people have names and addresses

An entity set is a set of entities of the same type that share thesame properties.

Example: set of all persons, companies, trees,holidays


9/99

Basic Constructs of E-R Modeling

Entities

Entities are the principal data object about which

information is to be collected. Entities are usually

recognizable concepts, either concrete or abstract,such as person, places, things, or events, which

have relevance to the database. Some specific

examples of entities are EMPLOYEES, PROJECTS,

and INVOICES. An entity is analogous to a table inthe relational model.


10/99

Relationships

A Relationship represents an association between two or more

entities. Relationships are classified in terms of degree,

connectivity, cardinality, and existence. An example of a

relationship would be:

Employees are assigned to projects

Projects have subtasks

Departments manage one or more projects


11/99

Entity Sets customerand loan


12/99

Relationship Set borrower


13/99

AttributesAttributes describe the properties of the entity

of which they are associated. We can classify

attributes as following:

Simple

Composite

Single-values

Multi-values

Derived


14/99


15/99


16/99


17/99

Example


18/99

Degree of a RelationshipThe degree of a relationship is the number of

entities associated with the relationship. The

n-ary relationship is the general form fordegree n. Special cases are the binary, and

ternary, where the degree is 2, and 3,

respectively.


19/99

Connectivity and CardinalityThe connectivity of a relationship describes themapping of associated entity instances in therelationship. The values of connectivity are "one" or"many". The cardinality of a relationship is the actual

number of related occurrences for each of the twoentities.

The basic types of connectivity for relations are:

One to One (1:1)

One to Many (1:M) Many to One (M:1)

Many to Many (M:M)


20/99


21/99


22/99


23/99


24/99

DirectionThe direction of a relationship indicates the originating entity of arelationship. The entity from which a relationship originates is theparent entity; the entity where the relationship terminates is thechild entity.

The type of the relation is determined by the direction of line

connecting relationship component and the entity. To distinguishdifferent types of relation, we draw either a directed line or anundirected line between the relationship set and the entity set.Directed line is used to indicate one occurrence and undirectedline is used to indicate many occurrences in a relation as shown

in next case.


25/99


26/99


27/99


28/99

E-R Notation

Entities are represented by labeled rectangles. The label is thename of the entity. Entity names should be singular nouns.

Attributes are represented by Ellipses.

A solid line connecting two entities represents relationships. Thename of the relationship is written above the line. Relationshipnames should be verbs and diamonds sign is used to representrelationship sets.

Attributes, when included, are listed inside the entity rectangle.Attributes, which are identifiers, are underlined. Attribute namesshould be singular nouns.

Multi-valued attributes are represented by double ellipses. Directed line is used to indicate one occurrence and undirected

line is used to indicate many occurrences in a relation.


29/99


30/99

E-R Notation


31/99

Example


32/99


33/99

Customer-Loan Relationship


34/99

Exercise Consider the following database: S (S#, SSNAME, STATUS,

CITY)

P (P#, PNAME, COLOR,

WEIGHT, CITY) J ( J#, JNAME, CITY)

SPJ( S#, P#, J#, QTY)

Here, S indicates information of

suppliers, P Parts, J Projectsand SPJ indicates the suppliedquantity details.


35/99


36/99

Total participation (indicated by double line): every entity in the entity setparticipates in at least one relationship in the relationship set

E.g. participation of loan in borrower is total

every loan must have a customer associated to it via borrower

Partial participation: some entities may not participate in any relationship in therelationship set

Example: participation of customer in borrower is partial

Total Participation


37/99


38/99


39/99

Some More Examples


40/99

Representation of Cardinality in the

E-R Diagram The cardinality of a relationship is the actual number of related

occurrences for each of the two entities. E-R diagrams alsoprovide a way to indicate cardinality of the relationship. An edgebetween an entity set and a relationship set can have anassociated minimum and maximum cardinality, shown in the form

l..h, where lis the minimum and h the maximum cardinality. Aminimum value of 1 indicates total participation of the entity set inthe relationship set. A maximum value of 1 indicates that theentity participates in at most one relationship, while a maximumvalue *indicates no limit. The label 1..*on an edge is equivalentto a double line.


41/99

It is easy to misinterpret the 0..*on the edgebetween customerand Cust_Loan, and think

that the relationship Cust_Loan is many toone from customerto loan, this is exactly thereverse of the correct interpretation.

Customer Loan

C_name

Address

Phone_no

City amountLoan_No

Cust_

Loan0..* 1..1


42/99

For example,the edge between loan and Cust_Loan

has a cardinality constraint of 1..1, meaning the

minimum and the maximum cardinality are both 1.

That is, each loan must have exactly one associated

customer. The limit 0..*on the edge from customer

to Cust_Loan indicates that a customer can have

zero or more loans. Thus, the relationship

Cust_Loan is one to many from customerto loan,

and further the participation ofloan in Cust_Loan is

total.


43/99

Customer Loan

C_name

Address

Phone_no

City amountLoan_No

Cust_

Loan0..* 1..1


44/99

If both edges from a binary relationship have

a maximum value of 1, the relationship is one

to one. If we had specified a cardinality limit

of 1..*on the edge between customerandCust_Loan, we would be saying that each

customer must have at least one loan.


45/99

Some More Examples


46/99

Some More Examples


47/99

Some More Examples


48/99

Consider the following database:

S (S#, SSNAME, STATUS, CITY)

P (P#, PNAME, COLOR, WEIGHT, CITY)

J ( J#, JNAME, CITY)

SPJ( S#, P#, J#, QTY)

Here S indicates information of suppliers, P Parts, J Projects

and SPJ indicates the supplied quantity details.


49/99


50/99

Car-insurance company

It has a set of customers, each of who owns one or more cars.

Car may have any number of customers.

Each car has associated with it zero to any number of recorded

accidents. System should store date and location of accident.

Car insurance company will pay damage amount for the

accidental cars to concerned driver.


51/99


52/99

Case Study of University Management

System

Consider, a university contains many departments.

Each department can offer any number of courses.

Many teachers can work in a department. A teacher

can work only in one department. For each

department there is a Head. A teacher can be head

of only one department. Each teacher can take any

number of courses. A course can be taken by only

one instructor. A student can enroll for any number

of courses. Each course can have any number ofstudents.


53/99

Steps to design E-R diagram

First Step to Identify the Entities

Second Step to find relationships among

these entities

Step 3 to identify the key attributes

Step 4 to identify other relevant attributes

Step 5 to draw the complete e-r diagram


54/99

First Step to Identify the Entities

In order to identify the entities collect all the noun inthe requirement sheet which has some propertiesand are important for the system.

We can identify the following nouns:

University, Department, Course, Teacher, Student. Here, the database is of only one university. If an

entity has a single instance then that entity isignored. Thus, the final entities are:

DEPARTMENT

COURSE TEACHER

STUDENT

d d


55/99

Second Step to find relationships

among these entities Each department can offer any number of courses and we can

assume that each course belongs to only one department. Thenthe connectivity of the relation ship among DEPARTMENT andCOURSE is One to Many. If a course can run in more than onedepartment then it is Many to Many.

Many teachers can work in a department and a teacher can work

only in one department. Thus the connectivity amongDEPARTMENT and TEACHER is one to many.

For each department there is a Head and a teacher can be headof only one department. Hence, the connectivity is one to one.

Each teacher can take any number of courses and a course canbe taken by only one instructor. Thus, the connectivity betweenTEACHER and COURSE is one to many.

A student can enroll for any number of courses and each coursecan have any number of students. Thus, the connectivitybetween STUDENT and COURSE is many to many.

S 3 id if h k ib


56/99

Step 3 to identify the key attributes

Following are the primary key attributes for each

entity set:

Dno (Department number) is the key attribute for the

Entity DEPARTMENT.

C_code (Course number) is the key attribute for

COURSE Entity.

Roll_no (Roll number) is the key attribute for

STUDENT Entity. T_code (Teacher code) is the key attribute for

TEACHER Entity.

S 4 id if h l


57/99

Step 4 to identify other relevant

attributes

Following are the other relevant attributes for

each entity set:

DEPARTMENT entity will have other relevant

attributes as dname, loc. For COURSE entity, c_name, credits.

For TEACHER entity, name, mob_no

For STUDENT entity, name, address

S 5 d h l


58/99

Step 5 to draw the complete e-r

diagram

DEPARTMENT

TEACHER STUDENT

COURSEoffers

has enroll

teach

head

s

dno dname loc c_code credits

roll_no addressnamet_code mob_noname

c_name


59/99

Strong and Weak Entity Sets

The entity set which does not has sufficient attributes to form a primary key is

called as weak entity set. An entity set that has a primary key is called as Strong

entity set. Consider an entity set Payment which has three attributes:

payment_number, payment_date and payment_amount. Although each payment

entity is distinct but payment for different loans may share the same payment

number. Thus, this entity set does not have a primary key and it is a weak entity

set. Each weak set must be a part of one-to-many relationship set.

A member of a strong entity set is called dominant entity and member of weak

entity set is called as subordinate entity. A weak entity set does not have a

primary key but we need a means of distinguishing among all those entries in

the entity set that depend on one particular strong entity set. The discriminator

of a weak entity set is a set of attributes that allows this distinction to be made.

For example, payment_number is acts as discriminator for payment entity set. It

is also called as the Partial key of the entity set.


60/99

The primary key of a weak entity set is formed by the primary

key of the strong entity set on which the weak entity set is

existence dependent, plus the weak entity sets discriminator. Inthe above example {loan_number, payment_number} acts as

primary key for payment entity set.


61/99

The relationship between weak entity and strong entity set is

called as Identifying Relationship. In example, loan-payment is

the identifying relationship for payment entity. A weak entity

set is represented by doubly outlined box and corresponding

identifying relation by a doubly outlined diamond


62/99


63/99

C S d


64/99

Case Study

Represent each of the following requirements with an ER diagram: A regional council requires the design of a database system that can provide

information on all schools in the region. The requirements collection andanalysis phase of the database design process has provided the followingdata requirements for the schools database system.

(a) Every school has many pupils and many teachers. Each pupil is assignedto one school and each teacher works for one school only.

(b) Each teacher teaches more than one subject but a subject may be taughtby more than one teacher. The database should store the number of hours ateacher spent teaching a subject. Data held on each teacher includes his/hernational Insurance Number (NIN), name (first and last), sex, andqualifications. The data held on each subject includes subject title and type.

(c) Each pupil can study more than one subject and a subject may be studiedby more than one pupil. Data held on each pupil includes the pupil's code,

name (first and last), sex, and date of birth.(d) Each school is managed by one of its teachers. The database shouldkeep track of the date he/she started managing the school. Data stored oneach school includes the school's code, name, address (town, street, andpost code) and phone.

D i I


65/99

Design IssuesUse of Entity Sets versus Attributes

Consider the entity set employee with attributesemployee-name and telephone-number.

It can easily be argued that a telephone is an entity in itsown right with attributes telephone-numberand location(the office where the telephone is located). If we take this

point of view, we must redefine the employee entity setas: The employee entity set with attribute employee-name The telephone entity set with attributes telephone-numberand location The relationship set emp-telephone, which denotes theassociation between employees and the telephones thatthey have

What then is the main difference bet een


66/99

What, then, is the main difference betweenthese two definitions of an employee? Treating a telephone as an attribute telephone-

numberimplies that employees have precisely one

telephone number each.

Treating a telephone as an entity telephone permits

employees to have several telephone numbers

(including zero) associated with them

However, we could instead easily define telephone-

numberas a multivalued attribute to allow multipletelephones per employee.


67/99

The main difference then is that treating a

telephone as an entity better models a situation

where one may want to keep extra information

about a telephone, such asits location, or its type

(mobile, video phone, or plain old telephone), or

who all share the telephone. Thus, treating

telephone as an entity is more general than

treating it as an attribute and is appropriate whenthe generality may be useful.


68/99


69/99

In contrast, it would not be appropriate to

treat the attribute employee-name as an

entity; it is difficult to argue that employee-

name is an entity in its own right (in contrastto the telephone). Thus, it is appropriate to

have employee-name as an attribute of theemployee entity set.


70/99

Two natural questions thus arise: What

constitutes an attribute, and what constitutes

an entity set?

Unfortunately, there are no simple answers.The distinctions mainly depend on the

structure of the real-world enterprise being

modeled, and on the semantics associatedwith the attribute in question.

Some common mistakes we make during


71/99

Some common mistakes we make duringdesigning of E-R diagram A common mistake is to use the primary key of an entity set as

an attribute of another entity set, instead of using a relationship.For example, it is incorrect to model customer-idas an attributeofloan even if each loan had only one customer. The relationshipborroweris the correct way to represent the connection between

loans and customers, since it makes their connection explicit,rather than implicit via an attribute. Another related mistake that people sometimes make is to

designate the primary key attributes of the related entity sets asattributes of the relationship set. This should not be done, sincethe primary key attributes are already implicit in the relationship.

Use of Entity Sets versus Relationship


72/99

Use of Entity Sets versus Relationship

Sets It is not always clear whether an object is best

expressed by an entity set or a relationship set. Weassumed that a bank loan is modeled as an entity.

An alternative is to model a loan not as an entity, but

rather as a relationship betwee customers and

branches, with loan-numberand amountas

descriptive attributes. Each loan is represented by arelationship between a customer and a branch.


73/99

If every loan is held by exactly one customerand is associated with exactly one branch,

we may find satisfactory the design where a

loan is represented as a relationship.

Problems


74/99

Problems However, with this design, we cannot represent

conveniently a situation in which several customers

hold a loan jointly. To handle such a situation, we

must define a separate relationship for each holder

of the joint loan. Then, we must replicate the valuesfor the descriptive attributes loan-numberand

amountin each such relationship. Each such

relationship must, of course, have the same value

for the descriptive attributes loan-numberandamount.


75/99


76/99

Two problems arise as a result of thereplication: (1) the data are stored multipletimes, wasting storage space, and (2)updates potentially leave the data in aninconsistent state, where the values differ intwo relationships for attributes that aresupposed to have the same value. The issueof how to avoid such replication is treatedformally by normalization theory


77/99

The problem of replication of the attributes loan-numberand amountis absent in the original design

because there loan is an entity set.

One possible guideline in determining whether to

use an entity set or a relationship set is to designate

a relationship set to describe an action that occurs

between entities. This approach can also be useful

in deciding whether certain attributes may be moreappropriately expressed as relationships.


78/99

Generalization: A bottom-up design process

A generalization hierarchy is a form of abstraction that specifies

that two or more entities that share common attributes can be

generalized into a higher-level entity type called a supertype or

generic entity. The lower level of entities becomes the subtype,or categories, to the super type. Subtypes are dependent entities.

Generalization is used to emphasize the similarities among

lower-level entity sets and to hide differences. It makes ER

diagram simpler because shared attributes are not repeated.Generalization is denoted through a triangle component labeled

IS A,


79/99


80/99

Specialization: Top-down design process

Specialization is the process of taking subsets of a higher-level

entity set to form lower level entity sets. It is a process of

defining a set of subclasses of an entity type, which is called as

superclas of the specialization. The process of defining subclass

is based on the basis of some distinguish characteristics of the

entities in the super class.

For example, specialization of the Employee entity type may

yield the set of subclasses namely Salaried_Employee and

Hourly_Employee on the method of pay


81/99


82/99

Diff b t S i li ti d G li ti


83/99

Difference between Specialization and Generalization

Specialization is the process of taking subsets of a higher-level

entity set to form lower level entity sets. Specialization

emphasizes differences among entities within the set by creating

distinct lower-level entity sets. These lower-level entity sets may

have attributes, or may participate in relationships, that do notapply to all entities in the higher-level entity set.

Generalization proceeds from the recognition that a number of

entities set share some common features, which are described by

the same, attributes and participate in the same relationship sets.Generalization is used to emphasize the similarities among lower-

level entity sets and to hide differences.

Design Constraints on a


84/99

Design Constraints on aSpecialization/Generalization Constraint on which entities can be members of a given lower-level entity set.

condition-defined OR Attribute Defined Example: all customers over 65 years are members ofsenior-citizen entity set; senior-citizen

ISA person.

All accountentities are evaluated on the defining account-type attribute. Only those entities thatsatisfy the condition account-type = savings account are allowed to belong to the lower-levelentity setperson. All entities that satisfy the condition account-type = checking account areincluded in checking account. Since all the lower-level entities are evaluated on the basis of thesame attribute (in this case, on account-type), this type of generalization is said to be attribute-

defined. user-defined

User-defined lower-level entity sets are not constrained by a membership condition;rather, the database user assigns entities to a given entity set. For instance, let usassume that, after 3 months of employment, bank employees are assigned to one offour work teams.We therefore represent the teams as four lower-level entity sets of thehigher-level employee entity set. A given employee is not assigned to a specific teamentity automatically on the basis of an explicit defining condition. Instead, the user incharge of this decision makes the team assignment on an individual basis. Theassignment is implemented by an operation that adds an entity to an entity set.


85/99

Constraint on whether or not entities may belongto more than one lower-level entity set within asingle generalization.

Disjoint

A disjointness constraintrequires that an entity belong tono more than one lower-level entity set. In our example,an accountentity can satisfy only one condition for theaccount-type attribute; an entity can be either a savingsaccount or a checking account, but cannot be both.

Overlapping an entity can belong to more than one lower-level entity

set


86/99

Overlapping. In overlapping generalizations, the same entitymay belong to more than one lower-level entity set within a singlegeneralization. For an illustration, consider the employee workteam example, and assume that certain managers participate inmore than one work team.A given employee may thereforeappear in more than one of the team entity sets that are lower-level entity sets ofemployee. Thus, the generalization isoverlapping.

As another example, suppose generalization applied to entitysets customerand employee leads to a higher-level entity set

person. The generalization is overlapping if an employee can

also be a customer.

Design Constraints on a


87/99

DesignConstraintson aSpecialization/Generalization (Cont.) Completeness constraint -- specifies

whether or not an entity in the higher-levelentity set must belong to at least one of thelower-level entity sets within a generalization. total : an entity must belong to one of the lower-

level entity sets

partial: an entity need not belong to one of thelower-level entity sets


88/99

Partial generalization is the default.We can specify total generalization in an E-Rdiagram by using a double line to connect the box representing the higher-levelentity set to the triangle symbol. (This notation is similar to the notation for totalparticipation in a relationship.) The accountgeneralization is total: All accountentities must be either a savings account or a checking account. Because thehigher-level entity set arrived at through generalization is generally composed ofonly those entities in the lower-level entity sets, the completeness constraint fora generalized higher-level entity set is usually total. When the generalization is

partial, a higher-level entity is not constrained to appear in a lower-level entityset. The work team entity sets illustrate a partial specialization. Since employeesare assigned to a team only after 3 months on the job, some employee entitiesmay not be members of any of the lower-level team entity sets. We maycharacterize the team entity sets more fully as a partial, overlappingspecialization ofemployee.


89/99

The generalization ofchecking-accountand savings-accountintoaccountis a total, disjoint generalization. The completeness anddisjointness constraints, however, do not depend on each other.Constraint patterns may also be partial-disjoint and total-overlapping. We can see that certain insertion and deletionrequirements follow from the constraints that apply to a givengeneralization or specialization. For instance, when a totalcompleteness constraint is in place, an entity inserted into ahigher-level entity set must also be inserted into at least one ofthe lower-level entity sets. With a condition-defined constraint, allhigher-level entities that satisfy the condition must be inserted

into that lower-level entity set. Finally, an entity that is deletedfrom a higher-level entity set also is deleted from all theassociated lower-level entity sets to which it belongs.


90/99

Aggregation

One limitation of the E-R model is that it cannot express

relationships among relationships.

The best way to model a situation like this is by the use of

aggregation. Thus, the relationship set work_on relating the

entity sets Employee, Branch and Job is a higher-level entity set.

Such an entity set is treated in the same manner, as is any other

entity set. We can then create a binary relationship Managesbetween work_on and Manager to represent who manages what

tasks.


91/99


92/99

Suppose a customer loan pair may have a bank emp Who is a

l ffi f th t ti l i


93/99

loan officer for that particular pair.

CUST LOANBORROWER

LOAN-

OFFICER

EMP

The best way to model the situation is to use aggregation.


94/99

The best way to model the situation is to use aggregation.

Aggregation is asn abstraction through which relationship are treated

as higher level entities

CUST LOANBORROWER

LOAN-OFFICER

EMP


95/99

E-R Diagram ofBaking System

Case Study: Database Design for


96/99

y gBanking Enterprise Here are the major characteristics of the

banking enterprise. The bank is organized into branches. Each

branch is located in a particular city and isidentified by a unique name. The bankmonitors the assets of each branch.


97/99


98/99


99/99

ReferencesSimplified Approach To DBMS

By

Parteek BhatiaKalyani Publishers

Chap 4 E-R Model

Documents

Transcript of Chap 4 E-R Model