Entity-Relationship Modeland
Enhanced Entity-Relation Model
Outline
• Data Models• Notation basics• Understanding types of relationship• Generalization/Specialization hierarchies
Data Models
Data Models : a collection of conceptual tools for describing data, data relationships, data semantics, and consistency constraints.
The Entity-Relationship ModelThe Relational Model
Entity-Relationship Model (ER Model)
เป็�นโมเดลที่�ช่ วยในการออกแบบระบบฐานข้�อม�ลโดยรวม (Overall Logical Structure) ให้�ก�บองค์!กร
E-R Model เป็�นโมเดลที่�มป็ระโยช่น! และมค์วามสำ#าค์�ญมาก เพราะสำามารถแสำดงค์วามห้มาย และค์วามสำ�มพ�นธ์!ข้องข้�อม�ลตามสำภาพที่�เป็�นจร+ง (real world) ข้ององค์!กรห้น,�งได�อย างช่�ดเจน สำ#าห้ร�บการออกแบบในระด�บห้ล�กการ (Conceptual Level)
Entity-Relationship Model (ER Model)
Entity-Relationship Model (ER Model): perceives the real world as consisting of basic objects, called entities, and relationships among these objects.
E-R Model was developed to facilitate database design by allowing specification of an enterprise schema, which represents the overall logical structure of a database.
E-R Model is very useful because it can represent the meaning and relationship between objects of real world enterprise onto conceptual schema.
Components of ER Model
1. Entity set is a set of entities of the same type that share the same properties, or attributes. An entity is a thing or object in the real world that is distinguishable from all other objects.
2. Relationship set is a set of relationships of the same type. Each relation is a row which represents the relations among several entities from n entity sets (n >= 2).
1. Entity set : เป็�นเซ็/ตข้อง entities ที่�มโค์รงสำร�างข้�อม�ลแบบเดยวก�น (บางค์ร�0งเราเรยกแต ละ entity ว า object ห้ร1อ thing)
2. Relationship set : เป็�นเซ็/ตข้องค์วามสำ�มพ�นธ์! (relationships) ระห้ว าง Entity sets ที่�มโค์รงสำร�างข้�อม�ลแบบเดยวก�น โดยที่�แต ละrelationship ค์1อแต ละแถวที่�แสำดงค์วามสำ�มพ�นธ์!ระห้ว าง entities ที่�มาจาก n entity sets (n >= 2).
องค์�ประกอบของ ER Model
An entity is represented by a set of Attributes
Attributes are descriptive properties possessed by each member of an entity set. Attribute ค์1อข้�อม�ลที่�แสำดงล�กษณะ และค์4ณสำมบ�ต+ข้อง entity เช่ น เลข้ป็ระจ#าต�ว ช่1�อ-นามสำก4ล สำ วนสำ�ง ห้ม� เล1อด ว�นเด1อนป็6เก+ด …. เป็�นต�น
Student
Std_ID Name
Height
BloodDoB
Std_ID Name Height
Blood DoB
50100200
xxxxxx 175 A 12/2/33
50100422
yyyyy 165 AB 25/10/33
ER Model Relational Model
Attribute value : ค์�าของ attribute
Each entity has a value for each of its attributes. For instance, a particular student entity may have the value 50051044 for Std_ID, the value Kanchana Boonmak for Std_Name, and the value 3.12 for GPA.
For each attribute, there is a set of permitted values, called the domain, or value set of that attribute. For instance, the domain of attribute GPA might be the set of real number whose value is not greater than 4.0
Attribute Type
An attribute, as used in the E-R model, can be characterized by the following attribute types :
Simple and composite :
Simple : The attribute is a simple attribute if its value can not be divided into subparts. For example Std_ID, Std_Name, GPA.
Composite : The attribute is a composite attribute if its value can be divided into subparts. For example Name, Address.
Attribute Type (cont..)
Single-valued and Multivalued :
Single-valued : The attribute is a single-valued attribute if it has only one value for a particular entity.
Multivalued : The attribute is multivalued attribute if it has a set of values for a particular entity.
Derived:
The attribute is a derived attribute if its value can be derived from the values of other related attributes or entities.
Entity-Relationship Diagrams
Lecturer
Lec_ID
FirstName
LastName
Dept
Add_No Stree
CityZipcod
e
Sec
Age
Sub_name
Sub_type
Sub_code
Specialization
Address
TTeach Subject
Relationship type
M M
Relationship type
Credit
Compositeattribute
Multivaluedattribute
Derivedattribute
Key attribute
Descriptive
attribute
Constraints
An E-R schema may define certain constraints to which the contents of a database must conform. Such constraints are as following :
Mapping cardinalities constraintsKey constraints
Mapping Cardinalities
Mapping cardinalities or cardinality ratios, express the number of entities to which another entity can be associated via a relationship set.
Degree of relationship : The number of participating in a relationship.
• A relationship of degree two is called binary relationship.• A relationship of degree three is called ternary relationship.• A relationship of degree four is called Quarternary relationship
Degree of relationship : The number of participating in a relationship.
A relationship of degree two is called binary relationship.
person carowns
A relationship of degree three is called ternary relationship.
P-ID
FirstName
LastName
Addr
Person
License
Car
Year
Model
participated
Accident
Rept_no
Location
Date
Damage_cost
A relationship of degree four is called Quarternary relationship.
P-ID
FirstName
LastName
Addr
License
Car
Person
Model
Tparticipated
Accident
Rept-NoLocation
Date
Policy-NoAmount
Start_Date
Year
Insurance
Mapping cardinalities are most useful in describing binary relationship sets, (although they can contribute to the description of relationship sets that involve more than two entity sets as mentioned above 2 slides.)
Now, only binary relationship sets must be concentrated. For a binary relationship set R between entity sets A and B, the mapping cardinality must be one of the following:
One-to-oneOne-to-many (or many-to-one)Many-to-many
Binary Relationship
One-to-one mapping
An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A.
Std_ID
FirstName
LastName
GPA
Proj_name
Proj_No
Twork Project1 1
Budget
Student
One-to-many mapping
An entity in A is associated with any number (zero or more) of entities in B. However, An entity in B can be associated with at most one entity in A.
L_ID
FirstName
LastName
Dept
Firstname
Std_ID
Tadvise Student1 M
GPA
Lecturer
Lastname
Many-to-many mapping
An entity in A is associated with any number (zero or more) of entities in B and an entity in B is associated with any number (zero or more) of entities in A.
L_ID
FirstName
LastName
Dept
Sub_name
Sub_code
TTeach SubjectM M
Lecturer
Credit
sec
Crow’s Foot notation for ERD
Crow’s Foot is a useful notation to become familiar with, as it is easy to understand and is supported by many of the CASE tools students may encounter in their database career
Basic Symbols
Entity Typesymbol Relationship
symbol
Primary Key
AttributesRelationship
name
Entity Typename
CourseNoCrsDescCrsUnits
Course
OfferNoOffLocationOffTime
Offering
Has
CardinalitiesCardinalities
Course Offering
Course1 Offering1
Course2
Course3
Offering2
Offering3
Offering4
Cardinality NotationCardinality Notation
Inside symbol:minimum cardinality
CourseNoCrsDescCrsUnits
Course
OfferNoOffLocationOffTime
Offering
Has
Perpendicular line:one cardinality
Outside symbol:maximum cardinality
Circle: zerocardinality
Crow's foot: manycardinality
Comparison to Access NotationComparison to Access Notation
CourseNoCrsDescCrsUnits
Course
OfferNoOffLocationOffTime
Offering
Has
ERD (Crow's Foot)
CourseCoursenoCrsDescCrsUnits
1 8OfferingOfferNoCourseNoOffLocationOffTime...
Access Relationship Diagram
Key in Database System
We must have a way to specify how entities within a given entity set are distinguished. Conceptually, individual entities are distinct, however, the difference among them must be expressed in terms of their attributes.
Therefore, the value of the attribute must be such that it can uniquely identify the entity. In other words, no two entities in an entity set are allowed to have exactly the same value for all attributes.
A key allows us to identify a set of attributes that enough to distinguish entities from each other. Keys also help uniquely identify relationships, and thus distinguish relationships from each other.
Key type in Database System
Candidate Key : In each entity set, there can be more than one attribute whose value can distinguish one entity from all other entities in the same entity sets. These attributes are known as candidate key.
Primary Key : PK denotes a candidate key that is chosen.
Foreign Key : FK is an attribute which is used to reference from one relation to another relation.
Candidate key
Prov_ID and ProvName are candidate keys because they can uniquely identify a specific entity.
A candidate key, which is chosen, is primary key. Therefore, Prov_ID is primary key.
Primary key
Province
Prov_ID
ProvName Region
Area
Conversion of ER Diagram to Relational Model
One-to-one mapping
Std_ID
FirstName
LastName
GPA
Proj_name
Proj_No
Twork Project1 1
Budget
Student
Year
Std_ID FirstName
LastName
GPA Proj_No Proj_Name Budget Year
Std_ID FirstName
LastName
GPA Proj_No Proj_No Proj_Name Budget Year
Std_ID FirstName
LastName
GPA Proj_No Proj_Name
Budget
Year Std_ID
Conversion of ER Diagram to Relational Model
One-to-many mapping
L_ID
FirstName
LastName
Dept
Firstname
Std_ID
Tadvise Student1 M
GPA
Lecturer
Lastname
Case 1: No descriptive attributes associated with relationship.
L_ID FirstName LastName Dept
L1 Yuen Poovaravan
CPE
L2 Kietiyuth Kaveeyan EE
Primary key
Std_ID FirstName LastName GPA L_ID
S1 Panita Komolpat 5.4 L2
S2 Pranom Sangswang
2.2 L2
S3 Kasom Chaleerat 1.8 L1
….. ….. ….. …..
Primary key
Foreign key
Conversion of ER Diagram to Relational Model
One-to-many mapping
Case 2: Descriptive attributes associated with relationship.
accountID
firstName lastName
addr
title
videotapeID
Trents Videotape1 M
rating
Customer
genre
costdateRented
dateDue
length
accountID
firstName
LastName
addr
acct1 Napat Chusang xxxxx
acct2 Ittikorn Meemak yyyy
acct3 Varaporn Mektavorn
zzzz
accountID
videotapeID
Title genre rating length dateRented
dateDue
Cost
acct1 V01 Xmen Part I
action R 2 12 Jan 2010
20 Jan 2010
70
V02 Star War I
Sci Fi PG 13 2.5
V05 Harry Potter I
fantasi PG 13 3
acct2 V04 Ghost Ryder
action R 2 7 Mar 2010
27 Mar 2010
70
Schema I
Case 2: Descriptive attributes associated with relationship.
accountID
firstName
addr
title
videotapeID
Videotape1 M
rating
Customer
genre
costdateRented
dateDue
length
LastName
Change relationship to Weak Entity Set
Rentalhas
has
1 1
Participation contraint
Weak entity class
Identifying relationship
type
accountID
firstName
LastName
addr
acct1 Napat Chusang xxxxx
acct2 Ittikorn Meemak yyyy
acct3 Varaporn Mektavorn zzzz
videotapeID
Title genre rating length
V01 Xmen Part I
action R 2
V02 Star War I
Sci Fi PG 13 2.5
V04 Harry Potter I
fantasi PG 13 3
Schema II
accountID
videotapeID
dateRented
dateDue
Cost
acct1 V01 12 Jan 2010
20 Jan 2010
70
acct2 V04 7 Mar 2010
27 Mar 2010
70
acct3 V02 1 Apr 2010
7 Apr 2010
40
acct4 V06 5 Jun 2010 5 Jun 2010
40
Conversion of ER Diagram to Relational Model
Many-to-many mapping
L_ID
FirstNameLastNam
e
Dept
Sub_name
Sub_code
TTeach SubjectM MLecturer
Credit
secL_ID firstNam
eLastNam
eDept
L1 Yuen Poovaravan
CPE
L2 Kietiyuth Kaveeyan EE
…….. ……. …… ……
Sub_code
Sub_Name Credit
01204211
Discrete Math
3
01204212
Abstract Data
3
01205201
ElectroMecha
2
….. ….. …..L_ID Sub_code
sec
L1 01204211
1
L3 01204211
2
L2 01205201
1
…… ….. …..
Primary keyFK
FK
Weak and Strong Entity Sets
An entity set may not have sufficient attributes to form a primary key. Such an entity set is termed a weak entity set. An entity set that has a primary key is termed a strong entity set.
For a weak entity set to be meaningful, it must be associated with another entity set, called the identifying or owner entity set. Every weak entity must be associated with and identifying entity; that is, the weak entity set is said to be existence dependent on the identifying entity set. The identifying entity set is said to own the weak entity set that it identifies. The relationship associating the weak entity set with the identifying entity set is called the identifying relationship. The identifying relationship is many to one from the weak entity set to the identifying entity set, and the participation of the weak entity set in the relationship is total.
Videotape1 M
Customer
costdateRented
dateDue
Rentalhas
has
1 1
Participation contraint
Weak entity class
Identifying relationship
type
Videotape1 M
Customer
costdateRented
dateDue
Rentalhas
has
1 1
Participation contraint
Weak entity class
Identifying relationship
type
A customer may have many rentals.A rental must have one customer.A videotape may have one rental.A rental must have one videotape.
A Rental object cannot exist without being related to a Customer and a Videotape, and no combination of attributes of class Rental is unique. Rental must be an example of a weak entity class.
A rental is identified by its relationship to a videotape. The related videotape is considered the owner of the rental. Without that relationship, the rental cannot exist. The key for a Rental entity is the VideotapeID attribute, which is the key of the owner videotape.
Problems with ER Models
The problems normally occur due to a misinterpretation of the meaning of certain relationships. These problems are referred to as Connection traps which are divided into 2 subtypes :
• Fan traps• Chasm traps
To identify connection traps, we must ensure that the meaning of a relationship is fully understood and clearly defined. If we do not understand the relationships we may create a model that is not a true representation on the real world.
BranchStaff
Division
SG37
SA9
SL21
r1
r2
r3
D1
D2
r4
r5
r6
B3
B7
B5
IsAllocated
relationship
Staffentities
Divisionentities
Operatesrelationsh
ip
Branchentities
IsAllocated
operates
1
M M
1
Fan Traps: Where a model represents a relationship between entity types, but the pathway between certain entity occurrences is ambiguous.
r4
r5
r6
StaffDivision
Branch
r1
r2
r3
D1
D2
SG37
SA9
SL21
B3
B7
B5
IsAllocated
relationship
Staffentities
Divisionentities
Operatesrelationsh
ip
Branchentities
OperatesIsAllocate
d
1
M
M
1
How to correct Fan Traps problem:
r4
r5
Property_for_rentBranch
Staff
r1
r2
r3
PG36
PG14
PL94
SG37
SA9
SL21
B3
B7
B5
IsAllocatedrelationshi
p
Staffentities
Property_for_rententities
Overseesrelationshi
p
Branchentities
IsAllocated
Oversees
1
M
M
1
Chasm Traps : Where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences
r4
r5
Property_for_rentBranch
Staff
R1
R2
r3
PG36
PG14
PL94
SG37
SA9
SL21
B3
B7
B5
IsAllocatedrelationshi
p
Staffentities
Property_for_rententities
Overseesrelationshi
p
Branchentities
IsAllocated
Oversees
1
M
M
1
How to solve the Chasm Traps problem:
Has1 M
r6
r7
r8
Hasrelationship
The Enhanced Entity-Relationship Model
The basic concepts of ER modeling are not sufficient to represent the requirements of the newer, more complex applications. The stimulated the need to develop additional semantic model concepts.
The ER model supported with additional semantic concepts is called the Enhanced Entity-Relationship (EER) model.
The EER model includes all the concepts of the original ER model together with the additional concepts of specialization/generalization.
The concepts of specialization/generalization
Specialization : (Top-Down Approach) The process of finding and specifying differences among objects of a single class. A single class is divided into one or more specialized subclasses. The set of subclasses is defined on the basis of some distinguishing characteristics of the entities in the superclass. When we identify a set of subclasses, we then associated attributes specific to each subclass.
Generalization : (Bottom-up Approach) The process of minimizing differences between entities by identifying their common features. The process of generalization can be viewed as the reverse of the specialization process.
ISA
Standard
Min_balance
Account-number
Senior
Num_checks
balance
Account
Checking_ccount
Saving_account
ISA Interest_rate
Overdraft-amount
Gold
Interest_payment
Date-of-birth
The concepts of specialization/generalization
The concepts of ER specialization/generalization are associated with the related concepts of entity sets described as superclass and subclass and the process of attribute inheritance.
Superclass : An entity set that included distinct subclasses that require to be represented in a data model.
Subclass : A subclass is also an entity set that has a distinct role and is also a member of a superclass.
ISA
Officer
Hours_worked
ID
Secretary
Office_number
name
address
Person
Employee Customer
ISA Credit_rating
Salary
Teller
Station_number
Wage
Attribute Inheritance
A crucial property of the higher and lower level entities created by specialization and generalization is attribute inheritance. The attributes of the higher-level entity sets are said to be inherited by the lower-level entity sets.
Whether a given portion of an E-R model was arrived by specialization or generalization, the outcome is basically the same :
• A high-level entity set with attributes and relationships that apply to all of its lower-level entity sets.
• Lower-level entity sets with distinctive features that apply only within a particular lower-level entity set.
There are 2 important reasons for introducing the concepts of Superclasses and Subclasses into an ER Model
1. To avoid describing different types of entities with possibly different
attributes within a single entity set.2. To avoid describing similar concepts more than once,
thereby saving time for designer and making the ER diagram more readable.
3. To add more semantic information to design in a form that is familiar to many people.
Constraints on Specialization and Generalization
A second type of constraint relates to whether or not entities may belong to more than one lower-level entity set within a single generalization. The lower-level entity sets may be one of the following:
• Disjoint : A disjointness constraint requires that an entity belong to no more than one lower-level entity set. e readable.
• Overlapping : The same entity may belong to more than one lower-level entity set within a single generalization.
Officer
commision-_rate
ID
Account
Teller
Daily_saleBonus
name
address
O
Personemployee
SiteA
Customer
A final constraint, the completeness constraint on a generalization or specialization, specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within the generalization/specialization. This constraint may be one the following
• Total generalization or specialization : Each higher-level entity must belong to a lower-level entity set.
• Partial generalization or specialization : Some higher-level entities may not belong to any lower-level entity set.
SiteA
commission-_rate
ID
Account
SiteB
Daily_saleBonus
name
address
O
Staff
Manager
IsAllocated
Typing_speed
O
Fname
Lname
Name
Address
Secretary Sales_Personnel
Staff
Bonus
Manages
Branch
Sales_area
Car_allowance
M
1
1
1
Staff-No
Manager
IsAllocated
Typing_speed
O
Fname
Lname
Name
Address
Sales_Personnel
Staff
Bonus
Manages
Branch
Salary_
Scale
Car_allowance
M
1
1
Staff-No
Part_Time_Temporary
Holiday_allowance
d
Secretary
Sales_area
Full_Time_Permanen
t
Hourly_rate
Example 1:
homeidstreetcitystatezipnobedrmsnobathssqftownoccupied
home
ssnownnamespousenameprofessionspouseprofess
owner
owns
owner (ssn , ownname, spousename, ……. );home (homeid, street, city, ……. , ssn);
foreign key (ssn) references owner
Example 2: homeid
streetcitystatezipnobedrmsnobathssqftownoccupiedcommissionsalesprice
home
ssnownnamespousenameprofessionspouseprofess
owner
owns
agentidagentnameofficeidphone
agent
lists
owner (ssn , ownname, spousename, ……. );home (homeid, street, city, ……. , ssn, agentid);
foreign key (ssn) references ownerforeign key (agentid) refences agent
agent (agentid, agentname, phone);
phone
homeidstreetcitystatezipnobedrmsnobathssqftownoccupiedcommissionsalesprice
home
ssnownnamespousenameprofessionspouseprofess
owner
owns
agentidagentnamephone
agent
lists
officeidaddressmgrnamephone
office
worksat
Example 3:
owner (ssn , ownname, spousename, ……. );home (homeid, street, city, ……. , ssn, agentid);
foreign key (ssn) references ownerforeign key (agentid) refences agent
agent (agentID, agentname, officeid, phone);foreign key (officeid) refences office
office(officeid, address, mrgname, phone)
ContrNoContrName
Contractor
SpecNoSpecName
SpecialtyProjNoProjName
Project ProjectNeeds
FulFillsHas
ProvidedBy
Supplies
proiect(projno, …) specialty(specno, …) contractor(contrno, specno, …)
FOREIGN KEY(specno) REFERENCES specialty projectneeds(projno, specno)
FOREIGN KEY(projno) REFERENCES project FOREIGN KEY(specno) REFERENCES specialty providedby(contrno, projno, specno)
FOREIGN KEY(projno, specno) REFERENCES projectneeds FOREIGN KEY(contrno) REFERENCES contractor
Example 4:
AcctidAcctNameBalance
Account DecomposedPartNoPartDescColor
Part Contains
part(partno, partdesc, color) account(acctid, acctname, balance) decomposed(acctid, parent_acctid)
FOREIGN KEY(acctid) REFERENCES accountFOREIGN KEY(parent_acctid) REFERENCES account
contains(super_partno, sub_partno)
FOREIGN KEY(super_partno) REFERENCES part FOREIGN KEY(sub_partno) REFERENCES part
Example 5:
Patient
PatNoPatFirstNamePatLastNamePatCityPatStatePatZipPatHealthPlan
Visit
VisitNoVisitDateVisitPayMethodVisitCharge
Attends
Physician
PhyEMailPhyHospitalPhyCertification
Treats
Nurse
NursePayGradeNurseTitle
Item
ItemNoItemDescItemTypeItemPrice
VisitDetail
VisitDetailNoDetailChargeContains
Provides
UsedIn
Provider
ProvNoProvFirstNameProvLastNameProvPhoneProvSpecialty
D,C
patient(patno, …) provider(provno, …) physician(provno, …)
FOREIGN KEY(provno) REFERENCES provider ON DELETE CASCADE nurse(provno, …)
FOREIGN KEY(provno) REFERENCES provider ON DELETE CASCADE item(itemno, …) visit(visitno, patno, provno, …)
FOREIGN KEY(patno) REFERENCES patientFOREIGN KEY(provno) REFERENCES physician
visitdetail(visitno, visitdetailno, provno, itemno)
FOREIGN KEY(visitno) REFERENCES visitFOREIGN KEY(provno) REFERENCES nurseFOREIGN KEY(itemno) REFERENCES item
provides(visitno, visitdetailno, provno)
FOREIGN KEY(visitno, visitdetailno) REFERENCES visitdetail FOREIGN KEY(provno) REFERENCES nurse