2. 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
domain
Conceptual
model
DBMS data
model
Create
Schema
(DDL)
Load data
(DML)
ER Model
3. 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
5. 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. 6
Relationships & RelationshipRelationships & Relationship
TypesTypes
• A relationship associates 2 or more entities.
• A relationship type is a set of associations between
entity types.
COURSEstudySTUDENT
ER Model
7. 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. 8
Degree of Relationship TypeDegree of Relationship Type
A relationship of degree two (2 entity types) are binary.
COURSEstudySTUDENT
ER Model
9. 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
11. 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. 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. 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
15. 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. 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. 17
Simple & Composite AttributesSimple & Composite Attributes
Composite 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
LName
initial FName
Area_cd
no
EX
ER Model
18. 18
Single-valued & Multi-valuedSingle-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. 19
Single-valued & Multi-valuedSingle-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
LName
initial FName
Area_cd
no
EX
ER Model
20. 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. 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
24. 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. 25
Primary Key in ERDPrimary Key in ERD
ageSTUDENT
St_no
name DOB
Tel_no
LName
initial
FName
Area_cd
no
EX
ER Model
26. 26
KeysKeys
A 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. 27
Composite Key in ERDComposite Key in ERD
CLASS
crs_code
Section_no name
hours
ER Model
28. 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. 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
DOB
dep_no FName
DEPENDENThas
ER Model
30. 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. 31
One-To-One RelationshipOne-To-One Relationship
A professor chairs at most one department; and a department
is chaired by only one professor.
DEPARTMENTchairsPROFESSOR
1 1
PROFESSOR chair DEPARTMENT
P1 r1 D002
P2
P3 r2 D001
ER Model
32. 32
One-To-Many RelationshipOne-To-Many Relationship
A course is taught by at most one professor; a professor
teaches many courses.
COURSEteachPROFESSOR
1 M
PROFESSOR teach COURSE
P1 r1 C01
r2 C02
P2 r3 C03
P3 C04
ER Model
33. 33
Many-To-One RelationshipMany-To-One Relationship
A class requires one room; while a room can be scheduled
for many classes.
ROOMrequireCLASS
M 1
CLASS require ROOM
C1 r1 R001
C2 r2 R002
C3 r3 R003
R004
ER Model
35. 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
40. 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. 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
42. 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
43. 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. 44
Problems with ER ModelProblems with ER Model
Connection 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. 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. 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. 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. 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. 49
Chasm TrapChasm Trap
has oversee
STAFF
BRANCH PROPERTY
M
M
1
1
BRANCH has STAFF oversee PROPERTY
B001 r1 SG1 r4 P1
B003 r2 SG2 P14
B002 r3 SG3 r5 P5
offer
r6
r7
r8
offer
1 M
(0,*)
(0,1)
(1,1)
(1,*)
ER Model
50. 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. 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 BRANCH
1 1
(a)
(b)
ER Model
52. 52
What makes a good DB design?What makes a good DB design?
• Avoid Redundancy. Say everything only once.
Biz-name
PERSON own BUSINESS
M N
name
ER Model
53. 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 OWNER
1 1
own
BUSINESS
1
M
Example 1
ER Model
54. 54
What makes a good DB design?What makes a good DB design?
PERSON
own
run
BUSINESS
Example 2
ER Model
55. 55
What makes a good DB design?What makes a good DB design?
EMPLOYEE work COMPANY
M 1
own
PERSON
M
1
Example 3
contract
1
1
ER Model
56. 56
What makes a good DB design?What makes a good DB design?
• Pick the right kind of element.
STUDENT allocate DEPARTMENT
M 1
STUDENT
degrees
dpt_name
degreesdpt_name
Example 1
ER Model
57. 57
What makes a good DB design?What makes a good DB design?
BUSINESS contract SUPPLIER
1 M
LAWYER
1
Example 2
CONTRACT Sup-makeBiz-make
Law-make
BUSINESS
LAWYER
SUPPLIER
1 M M 1
M
1
(business, lawyer, supplier)
Biz-make (business, contract)
Sup-make (supplier, contract)
Law-make (lawyer, contract)
(a)
(b)
59. 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
61. 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
68. 68
Disjoint ConstraintsDisjoint Constraints
Disjoint constraint when an entity can be a member of only
one of the subclasses of the specialization.
STAFF
FULL-TIME
STAFF
PART-TIME
STAFF
salary Hourly-rate
d
ER Model
70. 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
72. 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. 73
Summary of ERD notations (2)Summary of ERD notations (2)
CARDINALITY
RATION
PARTICIPATION
CONSTRAINTS
1 M
(min,max)
ER Model
74. 74
Summary of EERD notations (3)Summary of EERD notations (3)
Disjoint constraintd
o Non-Disjoint constraint
Total Participation
Optional Participation
ER Model
