Upload
lang
View
29
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Chapter 2. Entity-Relationship Model. Chapter 12 & 13 in Textbook. Database Design. Steps in building a database for an application: 1. Understand the real-world domain being captured. 2. Specify it using a database conceptual model (E/R,OO). - PowerPoint PPT Presentation
Citation preview
Chapter 2
Entity-Relationship Entity-Relationship ModelModel
Chapter 12 & 13 in Textbook
2
Database DesignDatabase Design
Steps in building a database for an application:
1. Understand the real-world domain being captured.
2. Specify it using a database conceptual model (E/R,OO).
3. Translate specification to model of DBMS (relational).
4. Create schema using DBMS commands (DDL).
5. Load data (DML).
Real-world
domainConceptual
modelDBMS data
model
Create Schema
(DDL)
Load data(DML)
ER Model
3
Entity-Relationship Model (E/R)Entity-Relationship Model (E/R)A picture is worth a thousand wordsA picture is worth a thousand words
The Entity-Relationship model (ER) is a high-level description of the structure of the DB.
The Entity-Relationship Diagram (ERD) is a graphical model for representing the conceptual model for the data.
A E/R models the DB using three element types:- Entities- Attributes- Relationships
ER Model
ERD ExampleERD Example
enroll-in
SCHOOL
DEPARTMENT
COURSECLASSSTUDENT
PROFESSOR
advise
offer
operate
chairs
teach
belong-to
has
dean of
1 1
1
1
M
1
M
M
1
1
M1MMN
1
M
(0,*)
(0,*)
(1,1)
(1,*)
(1,1)(0,1)(0,4)
(1,1)
(0,1)
(1,1)
(0,*)
(1,1) (0,*)(0,*)
(1,1)
name
number
DOB
hrscode
(1,*)
(1,1)
1
(1,*)
(1,1)
5
Entities & Entity TypeEntities & Entity Type
Entity is an object that exists and is distinguishable from other objects.
e.g. person, company, course, university
Entity Type is a set of entities of the same type that share the same properties.
e.g. set of all persons, companies, trees, courses
COURSESTUDENT
ER Model
6
Relationships & RelationshipRelationships & RelationshipTypesTypes
• A relationship associates 2 or more entities.
• A relationship type is a set of associations between entity types.
COURSEstudySTUDENT
ER Model
7
Degree of Relationship TypeDegree of Relationship Type
Degree of relationship refers to number of participating entity types in a relationship.
• A relationship of degree two (2 entity types) are binary.
• A relationship of degree three (3 entity types) are ternary.
ER Model
8
Degree of Relationship TypeDegree of Relationship Type
A relationship of degree two (2 entity types) are binary.
COURSEstudySTUDENT
ER Model
9
Degree of Relationship TypeDegree of Relationship Type
A relationship of degree three (3 entity types) are ternary.
e.g. registration of a student in a course by a staff.
COURSEregisterSTUDENT
STAFF
ER Model
10
Recursive RelationshipRecursive Relationship
Recursive relationship is a relationship type where the same entity type participates more than once in a different role. It is a unary relationship.
COURSE
require
ER Model
11
RolesRoles
Role indicates the purpose that each participating entity type plays in a relationship. (e.g. prerequisite, requester)
COURSE
require
requester prerequisite
ER Model
12
RolesRoles
Role can be used when two entities are associated through more than one relationship to classify the purpose of each relationship.
STAFF
allocated
Manager
Staff member
BRANCH
Branch office
Branch office
manages
ER Model
13
AttributesAttributes
Attributes are descriptive properties for an entity type or a relationship type.
All entities in one entity type have the same attributes.
STUDENT
St_no
name DOB
Tel_no
ER Model
14
Attributes of EntitiesAttributes of Entities
COURSEstudySTUDENT
St_no
name DOB
Tel_no number
namehours
ER Model
15
Attributes of RelationshipsAttributes of Relationships
All relationships in one relationship type have the same attributes.
Relationships can be distinguished not only by their attributes but also by their participating entities.
contract
Start EndObject
ER Model
CompanyEmployee
16
Simple & Composite AttributesSimple & Composite Attributes
Simple attribute is an attribute that have a single value with an independent existence.
e.g. salary, age, gender,...
ER Model
17
Simple & Composite AttributesSimple & Composite AttributesComposite attribute is an attribute composed of multiple distinct components, each with an independent existence.
e.g. address (street, area, city, post code)
name (First name, initial, Last name)
phone no. (area code, number, exchange no)
STUDENT
St_no
name DOB
Tel_no
LNameinitial FName
Area_cdno
EX
ER Model
18
Single-valued & Multi-valued Single-valued & Multi-valued AttributesAttributes
Single-valued attribute is an attribute that holds a single value for a single entity. It is not necessarily a simple attribute.
e.g. student_no, age, gender,...
ER Model
19
Single-valued & Multi-valued Single-valued & Multi-valued AttributesAttributes
Multi-valued attribute is an attribute that may hold multiple values, of the same type, for a single entity.
e.g. tel_no, degrees,…
STUDENT
St_no
name DOB
Tel_no
LNameinitial FName
Area_cdno
EX
ER Model
20
Derived AttributesDerived Attributes
Derived attribute is an attribute that represents a value that is derived from the value of a related attribute,not necessarily in the same entity type.
e.g. age is derived from date_of_birth
total_cost is derived from quantity*unit_price
STUDENT
St_no
name DOB
Tel_no
age
ER Model
21
KeysKeys
Candidate key (CK) is the minimal set of attributes that uniquely identifies an entity. It cannot contain null.
e.g. student_no, social_security_no, branch_no…
Primary Key (PK) is a candidate key that is selected to uniquely identify each entity.
Alternate Key (AK) is a candidate key that is NOT selected to be the primary key.
ER Model
22
Keys ExampleKeys Example
ELEMENT(symbol, name, atomic_no)
ER Model
23
Keys ExampleKeys Example
ELEMENT(symbol, name, atomic_no)
Primary Key Alternate Keys
Candidate Key
ER Model
24
Choice of PKChoice of PK
Choice of Primary Key (PK) is based on:
• Attribute length• Number of attributes required• Certainty of uniqueness
ER Model
25
Primary Key in ERDPrimary Key in ERD
ageSTUDENT
St_no
name DOB
Tel_no
LNameinitial
FNameArea_cd
no
EX
ER Model
26
KeysKeysA key can be:
- simple key is a candidate key of one attribute.
e.g. student_no, branch_no…
- composite key is a candidate key that consists of two or more attributes.
e.g. STUDENT (Lname, Fname, Init)
CLASS (crs_code, section_no)
ADVERT (property_no, newspaperName, dateAdvert)
ER Model
27
Composite Key in ERDComposite Key in ERD
CLASS
crs_code
Section_no name
hours
ER Model
28
Strong & Weak Entity TypesStrong & Weak Entity Types
A strong entity type is NOT existence-dependent on some other entity type. It has a PK.
A weak entity type is an entity type that is existence-dependent on some other entity type. It does not have a PK.
ER Model
29
Weak Entity TypeWeak Entity Type
• The existence of a weak entity type depends on the existence of a strong entity set; it must relate to the strong entity type via a relationship type called identifying relationship.
• The PK of a weak entity set is formed by the PK of its strong entity type, plus a weak entity type discriminator attribute.
EMPLOYEE
emp_no
LName FName
DOBdep_no FName
DEPENDENThas
ER Model
30
CardinalitiesCardinalities
Cardinality ratio expresses the number of relationships an entity can participate in.
Most useful in describing binary relationship types.
For a binary relationship type the mapping cardinality must be one of the following types:
– One to one (1:1) – One to many(1:M)
– Many to one (M:1) – Many to many (M:N)
ER Model
31
One-To-One RelationshipOne-To-One Relationship
A professor chairs at most one department; and a department is chaired by only one professor.
DEPARTMENTchairsPROFESSOR1 1
PROFESSOR chair DEPARTMENT
P1 r1 D002 P2 P3 r2 D001
ER Model
32
One-To-Many RelationshipOne-To-Many Relationship
A course is taught by at most one professor; a professor teaches many courses.
COURSEteachPROFESSOR1 M
PROFESSOR teach COURSE P1 r1 C01
r2 C02 P2 r3 C03 P3 C04
ER Model
33
Many-To-One RelationshipMany-To-One Relationship
A class requires one room; while a room can be scheduled for many classes.
ROOMrequireCLASSM 1
CLASS require ROOM C1 r1 R001
C2 r2 R002 C3 r3 R003 R004
ER Model
34
Many-To-Many RelationshipMany-To-Many Relationship
A class enrolls many students; and each student is enrolled in many classes.
STUDENTenrollCLASSM N
CLASS enroll STUDENT C1 r1 S1
C2 r2 S3 C3 r3 S4 r5 S5
ER Model
35
MultiplicityMultiplicity
Multiplicity is the number (range) of possible entities that may relate to a single association through a particular relationship.
It is best determined using sample data.
Takes the form (min#, max#)
ER Model
36
MultiplicityMultiplicity
BRANCHmanageSTAFF1 1
(0,1) (1,1)
STAFF manage BRANCH
SG1 r1 B002
SG2
SG3 r2 B001
ER Model
37
MultiplicityMultiplicity
PROPERTYoverseeSTAFF1 M
(0,10) (0,*)
(0,1)
STAFF oversee PROPERTY
SG1 r1 P1
r2 P2
SG2 r3 P14
SG3 P6
ER Model
38
MultiplicityMultiplicity
PROPERTYadvertiseNEWSPAPERM N
(0,*) (0,*)
Newspaper advertise PROPERTY
Al-Riyadh r1 P1
r2 P13
Al-Bilad r3
Al-Madinah r4 P6
Al-Sharq P4
ER Model
39
Participation ConstraintsParticipation Constraints
Participation constraints determine whether all or only some entities participate in a relationship.
Two types of participation:
- Mandatory (total)
- Optional (partial)
ER Model
40
Participation ConstraintsParticipation Constraints
• Mandatory (total) (1:*): if an entity’s existence requires the existence of an associated entity in a particular relationship (existence-dependent).
e.g. CLASS taught-by PROFESSOR
i.e. CLASS is a total participator in the relation.
A weak entity always has a mandatory participation constraints but the opposite not always true.
ER Model
41
Participation ConstraintsParticipation Constraints
• Optional (partial) (0:*): if an entity’s existence does not require a corresponding entity in a particular relationship. (Not existence-dependent).
e.g. PROFESSOR teach CLASS i.e. PROFESSOR is a partial participator in the relation.
ER Model
ER Case StudyER Case Study
Each bank has a unique name.
Each branch has a number, name, address (number, street, city), and set of phones.
Customer includes their name, set of address (P.O. Box, city, zip code, country), set of phones, and social security number.
Accounts have numbers, types (e.g. saving, checking) and balance. Other branches might use the same designation for accounts. So to name an account uniquely, we need to give both the branch number to which this account belongs to and the account number.
Not all bank customers must own accounts and a customer may have at most 5 accounts in the bank.
An account must have only one customer.
A customer may have many accounts in different branches.
Class exercise: Banks Database
ER Case StudyER Case Study
Homework: Television Series Database
A Television network wishes to create a database to keep track of its TV series. A television series has one or more episode. Television series identified by name and season number, and includes their production company name and Num_of_Episodes ( i.e. total number of episodes in a specific season of a series ).
Episode of a specific season of a series is identified by episode number and has a title and a length. No episode can exist without a corresponding television series. Also each episode has only one writer. A writer is identified by name, and also has birth date and a literary agency that represents him or her.
An actor appears as a performer in a television series or a guest star on an episode. An actor is identified by name and also has a nationality and birth date. An actor plays a particular character in a television series or episode.
44
Problems with ER ModelProblems with ER ModelConnection TrapsConnection Traps
Connection traps are problems that occur due to misinterpretation of the meaning of certain relationships.
Types of connection traps:– Fan Trap– Chasm Trap
ER Model
45
Fan TrapFan Trap
has operateDIVISION
STAFF BRANCH
1
M
1
M
STAFF has DIVISION operate BRANCH
SG1 r1 D1 r4 B002
SG3 r2 r5 B003
SG2 r3 D2 r6 B004
ER Model
46
Fan TrapFan Trap
operate hasBRANCH
DIVISION STAFF
M
M
1
1
DIVISION operate BRANCH has STAFF
D1 r1 B002 r4 SG1
r2 B003 r5 SG3
D2 r3 B004 r6 SG2
ER Model
47
Fan TrapFan Trap
Fan trap where a model represents a relationship between entity types, but the pathway between certain entity occurrence is ambiguous.
Exists where 2 or more 1:M relationships fan out from the same entity.
ER Model
48
Chasm TrapChasm Trap
has overseeSTAFF
BRANCH PROPERTY
M
M
1
1
BRANCH has STAFF oversee PROPERTY
B001 r1 SG1 r4 P1
B003 r2 SG2 P14
B002 r3 SG3 r6 P5
(1,*)
(1,1) (0,*)
(0,1)
ER Model
49
Chasm TrapChasm Trap
has overseeSTAFF
BRANCH PROPERTY
M
M
1
1
BRANCH has STAFF oversee PROPERTY
B001 r1 SG1 r4 P1B003 r2 SG2 P14
B002 r3 SG3 r5 P5
offer r6 r7 r8
offer1 M
(0,*)
(0,1)
(1,1)
(1,*)
ER Model
50
Chasm TrapChasm Trap
Chasm trap where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entities.
Exists when partial participating entity is part of the pathway between related entities.
ER Model
51
What makes a good DB design?What makes a good DB design?
• Faithfulness. Entity types, attributes & relationship types should reflect reality.
BRANCH
Hourly-rate
EMPLOYEE managers-in BRANCH1 1
(a)
(b)
ER Model
52
What makes a good DB design?What makes a good DB design?
• Avoid Redundancy. Say everything only once.
Biz-name
PERSON own BUSINESSM N
name
ER Model
53
What makes a good DB design?What makes a good DB design?
• Simplicity. Avoid introducing more elements into your design than is absolutely necessary.
PERSON represent OWNER1 1
own
BUSINESS
1
M
Example 1
ER Model
54
What makes a good DB design?What makes a good DB design?
PERSON
own
run
BUSINESS
Example 2
ER Model
55
What makes a good DB design?What makes a good DB design?
EMPLOYEE work COMPANYM 1
own
PERSON
M
1
Example 3
contract
1
1
ER Model
56
What makes a good DB design?What makes a good DB design?
• Pick the right kind of element.
STUDENT allocate DEPARTMENTM 1
STUDENTdegrees
dpt_name
degreesdpt_name
Example 1
ER Model
57
What makes a good DB design?What makes a good DB design?
BUSINESS contract SUPPLIER1 M
LAWYER
1
Example 2
CONTRACT Sup-makeBiz-make
Law-make
BUSINESS
LAWYER
SUPPLIER1 M M 1
M
1
(business, lawyer, supplier)
Biz-make (business, contract)
Sup-make (supplier, contract)
Law-make (lawyer, contract)
(a)
(b)
58
Enhanced Entity-Relationship Enhanced Entity-Relationship Model (EER)Model (EER)
EER is an ER model supported with additional semantic concepts.
Semantic concepts supported:
- Specialization
- Generalization
- Aggregation
ER Model
59
SpecializationSpecialization
• Top-down design process; we designate sub-groupings within an entity type that are distinctive from other entities in the set.
• These sub-groupings (subclasses) become lower-level entity types that have attributes or participate in relationships that do not apply to the higher-level entity set (superclass).
ER Model
60
Specialization/GeneralizationSpecialization/Generalization
STAFF
MANAGER SECRETARYSALES
PERSONNELSubclass
Superclass
IS_A relationship 1:1
ER Model
61
GeneralizationGeneralization
• A bottom-up design process – combine a number of entity types that share the same features into a higher-level (superclass) entity type.
• Specialization and generalization are simple inversions of each other; they are represented in an EER diagram in the same way.
ER Model
62
InheritanceInheritance
A subclass entity type inherits all the attributes and relationship participation of the superclass entity type to which it is linked.
ER Model
63
InheritanceInheritance
STAFF
SALESPERSONNEL
Unsharedattributes
Superclass
addressDOBname
SalesareaCar
allowance
sharedattributes
Subclass require CAR
Unsharedrelationship
contract COMPANY
Sharedrelationship
ER Model
64
Constraints on Constraints on Specialization/GeneralizationSpecialization/Generalization
Participation constraint determines whether every member in the superclass must participate as a member of a subclass.
Two types of participation constraints:
- Mandatory (total)
- Optional (partial)
ER Model
65
Participation ConstraintsParticipation Constraints
Mandatory (total) participation where every member in the superclass must also be a member of a subclass.
STAFF
FULL-TIMESTAFF
PART-TIMESTAFF
salary Hourly-rate
ER Model
66
Participation ConstraintsParticipation Constraints
Optional (partial) participation where a member in the superclass need not belong to any of its subclasses.
STAFF
MANAGER SECRETARYSALES
PERSONNEL
ER Model
67
Constraints on Constraints on Specialization/GeneralizationSpecialization/Generalization
Disjoint constraint describes the relationship between members of the subclasses & indicates whether it is possible for a member of a subclass to be a member of one or more subclasses.
Two types of disjoint constraints:
- Disjoint
- Non-Disjoint
ER Model
68
Disjoint ConstraintsDisjoint Constraints
Disjoint constraint when an entity can be a member of only one of the subclasses of the specialization.
STAFF
FULL-TIMESTAFF
PART-TIMESTAFF
salary Hourly-rate
d
ER Model
69
Disjoint ConstraintsDisjoint Constraints
Non-disjoint constraints: an entity is a member of more than one subclass of specialization. Entity types may overlap.
STAFF
MANAGER SECRETARYSALES
PERSONNEL
o
ER Model
70
AggregationAggregation
• Represents a “part-of” relationship between entity types, where one represents the ‘whole’ and the other the ‘part’.
• No inherited attributes; each entity has its own unique set of attributes.
ER Model
71
AggregationAggregation
TEAM
MEMBER
ER Model
72
Summary of ERD notations (1)Summary of ERD notations (1)
ENTITY
WEAK ENTITY
RELATIONSHIP
IDENTIFYING RELATIONSHIP
ATTRIBUTE
KEY ATTRIBUTE
MULTI-VALUED
COMPOSITE
DERIVED
ER Model
73
Summary of ERD notations (2)Summary of ERD notations (2)
CARDINALITYRATION
PARTICIPATIONCONSTRAINTS
1 M
(min,max)
ER Model
74
Summary of EERD notations (3)Summary of EERD notations (3)
Disjoint constraintd
o Non-Disjoint constraint
Total Participation
Optional Participation
ER Model