2
Database Design
Steps in building a database for an application:
1. Understand 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
Conceptualmodel
DBMS data model
Create Schema
(DDL)
Load data(DML)
ER Model
3
Entity-Relationship Model (E/R)A 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 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 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
Relationships & RelationshipTypes
• A relationship associates 2 or more entities.
• A relationship type is a set of associations between entity types.
COURSEstudySTUDENT
ER Model
STUDENT study COURSE
S001 r1 CO1
S002 r2 CO2
S003 r3
7
Degree 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 Type
A relationship of degree two (2 entity types) are binary.
COURSEstudySTUDENT
ER Model
9
Degree 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 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
STUDENT
lead
11
Roles
Role indicates the purpose that each participating entity type plays in a relationship. (e.g. prerequisite, requester)
COURSE
require
requester prerequisite
ER Model
STUDENT
lead
leader member
12
Roles
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
Attributes
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
Attributes 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 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 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 Attributes
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 Attributes
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 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
Keys
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
Choice of PK
Choice of Primary Key (PK) is based on:
• Attribute length• Number of attributes required• Certainty of uniqueness
ER Model
26
Keys
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
28
Strong & 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 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
Cardinalities
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 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 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 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 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
Multiplicity
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
Multiplicity
BRANCHmanageSTAFF1 1
(0,1) (1,1)
STAFF manage BRANCH
SG1 r1 B002
SG2
SG3 r2 B001
ER Model
37
Multiplicity
PROPERTYoverseeSTAFF1 M
(0,10) (0,*)
(0,1)
STAFF oversee PROPERTY
SG1 r1 P1
r2 P2
SG2 r3 P14
SG3 P6
ER Model
38
Multiplicity
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 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 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 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 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
Customer
Account
Branch
Bank has
allocate
has
own
name
name
Bno
address
phone
street
city
num
Acct_no type balance
name
SSN
address
phone
P.O.box
city
zipcountry
1
M
M
1
1
N
M M
(1,1)
(1,1)(1,1)
(1,*)
(1,*)
(0,*) (0,*)
(0,5)
ER 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.
45
Problems with ER ModelConnection 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
46
Fan 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
47
Fan 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
48
Fan 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
49
Chasm 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
50
Chasm 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
51
Chasm 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
52
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
53
What makes a good DB design?
• Avoid Redundancy. Say everything only once.
Biz-name
PERSON own BUSINESSM N
name
ER Model
54
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
56
What makes a good DB design?
EMPLOYEE work COMPANYM 1
own
PERSON
M
1
Example 3
contract
1
1
ER Model
57
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
58
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)
59
Enhanced Entity-Relationship Model (EER)
EER is an ER model supported with additional semantic concepts.
Semantic concepts supported:
- Specialization
- Generalization
- Aggregation
ER Model
60
Specialization
• 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
Specialization/Generalization
STAFF
MANAGER SECRETARYSALES
PERSONNELSubclass
Superclass
IS_A relationship 1:1
ER Model
62
Generalization
• 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
63
Inheritance
A subclass entity type inherits all the attributes and relationship participation of the superclass entity type to which it is linked.
ER Model
64
Inheritance
STAFF
SALESPERSONNEL
Unsharedattributes
Superclass
addressDOBname
SalesareaCar
allowance
sharedattributes
Subclass require CAR
Unsharedrelationship
contract COMPANY
Sharedrelationship
ER Model
65
Constraints on Specialization/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
66
Participation 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
67
Participation Constraints
Optional (partial) participation where a member in the superclass need not belong to any of its subclasses.
STAFF
MANAGER SECRETARYSALES
PERSONNEL
ER Model
68
Constraints on Specialization/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
69
Disjoint 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
70
Disjoint Constraints
Non-disjoint constraints: a subclass is a member of more than one subclass of specialization. Entity types may overlap.
STAFF
MANAGER SECRETARYSALES
PERSONNEL
o
ER Model
71
Aggregation
• 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
73
Summary of ERD notations (1)
ENTITY
WEAK ENTITY
RELATIONSHIP
IDENTIFYING RELATIONSHIP
ATTRIBUTE
KEY ATTRIBUTE
MULTI-VALUED
COMPOSITE
DERIVED
ER Model