ITEC 3220A
Using and Designing Database Systems
Instructor: Gordon Turpin
Course Website:
www.cse.yorku.ca/~gordon/itec3220S07
Office: CSEB3020
Supertypes and Subtypes
• Generalization hierarchy: depicts
relationships between higher-level supertype
and lower-level subtype entities
• Supertype: contains the shared attributes
• Subtype: contains the unique attributes
• Inheritance:
– Subtype entities inherit values of all attributes of
the supertype
– An instance of a subtype is also an instance of
the supertype
2
Supertypes and Subtypes (Cont’d)
Supertype/
subtype
relationships
Attributes shared by
all entities
General
entity type
SUPERTYPE
And so forth
SUBTYPE1
Attributes unique
to subtype1
SUBTYPE2
Specialized
version of
supertype
Attributes unique
to subtype2
3
Supertypes and Subtypes (Cont’d)
• Disjoint relationships
– Unique subtypes
– Non-overlapping
– Indicated with a ‘G’
• Overlapping subtypes
– An instance of the supertype could be more
than one of the subtypes
– Indicated with a ‘Gs’
4
Generalization Hierarchy with
Overlapping Subtypes
5
Chapter 5
Logical Database Design and
Normalization of Database Tables
In this chapter, you will learn:
• How to transform ERD into relations
• What normalization is and what role it plays in database
design
• About the normal forms 1NF, 2NF, 3NF, BCNF, and 4NF
• How normal forms can be transformed from lower normal
forms to higher normal forms
• Normalization and E-R modeling are used concurrently to
produce a good database design
• Some situations require denormalization to generate
information efficiently
7
Transforming ERD into Relations
• Step one: Map regular entities
– Each regular entity type in an ER diagram is
transformed into a relation
– The name given to the relation is generally the
same as the entity type
– Each simple attribute of the entity type becomes
an attribute of the relation and the identifier of
entity becomes the primary key of the
corresponding relation
8
Example
STUDENT
Student_ID Student_Name Other_Attributes
9
Transforming ERD into Relations
(Cont’d)
• Step two: Map weak entities
– Create a new relation and include all of the
simple attributes as the attributes of this
relation. Then include the primary key of
the identifying relation as a foreign key
attribute in this new relation. The primary
key of the new relation is the combination
of this primary key of the identifying
relation and the partial identifier of the
weak entity type.
10
Example
Employee_ID
Date_of_birth
Employee_Name
Dependent_Name
EMPLOYEE
Has
DEPENDENT
Gender
EMPLOYEE
Employee_ID
Employee_Name
DEPENDENT
Dependent_Name
Employee_ID
Date_of_birth
Gender
11
Transforming ERD into Relations
(Cont’d)
• Step three: Map binary relationship
– Map Binary one-to-many relations
•First create a relation for each of the two entity
types participating in the relationship, using the
procedure described in step one.
•Next, include the primary key attribute of the
entity on the one-side of the relationship as a
foreign key in the relation that is on the many-side
of the relationship.
12
Example
Customer_ID
Customer_Name
Order_ID
1
Order_Date
M
Customer
Submits
(0,N)
Order
(1,1)
Customer
Customer_ID
Customer_Name
Order
Order_ID
Order_Date
Customer_ID
13
Transforming ERD into Relations
(Cont’d)
• Step three: Map binary relationship
(Cont’d)
– Map binary one-to-one relationships
•First, two relationships are created one for each
of the participating entity types.
•Second, the primary key of one of the relations is
included as a foreign key in the other relation.
14
Example
Nurse_ID
Nurse_Name
Centre_Name
1
1
In_charge
Nurse
Location
(0,1)
(1,1)
Nurse
Nurse_ID
Nurse_Name
Care
Centre
Centre_Name
Location
Care
Centre
Nurse_in_c
harge
15
Transforming ERD into Relations
(Cont’d)
• Step Four: Map composite Entities
– First step
• Create three relations: one for each of the two
participating entities, and the third for the composite
entity. We refer to the relation formed from the
composite entity as the composite relation
– Second step
• Identifier not assigned: The default primary key for the
composite relation consists of the two primary key
attributes from the other two relations.
• Identifier assigned: The primary key for the composite
relation is the identifier. The primary keys for the two
participating entity types are included as foreign keys in
the composite relation.
16
Example
Order_ID
Order
Order_Date
1
(1,N)
(1,1)
M
Order
Line
Product_ID
M
(1,1)
1
(0,N)
Product
Description
Quantity
Price
17
Example
Order
Order_ID
Order_Date
Order Line
Product_ID
Order_ID
Quantity
Description
Standard_Price
Product
Product_ID
18
Example
Customer_ID
Vendor_ID
Name
Customer
1
Date
M
Shipment
Shipment_No
Customer Customer_ID
Vendor_ID
M 1
Vendor
Amount
Customer_Name
Shipment Shipment_N Vendor_I
o
D
Vendor
Address
Address
Customer_I Date
D
Amount
19
Transforming ERD into Relations
(Cont’d)
• Step Five: Map unary relationship
– Map unary one-to-many relationship
•The entity type in the unary relationship is
mapped to a relation using the procedure
described in Step one. Then a foreign key
attribute is added within the same relation that
references the primary key values. A recursive
foreign key is a foreign key in a relation that
references the primary key values of that same
relation.
20
Example
Name
Employee_ID
Employee
Birthdate
M (1,1)
1 (0,N)
Employee
Employee_ID
Manages
Name
Birthdate
Manager_ID
21
Transforming ERD into Relations
(Cont’d)
• Step six: Map ternary relationship
– Convert a ternary relationship to a composite
entity
– To map a composite entity that links three regular
entities, we create a new composite relation. The
default primary key of their relation consists of
the three primary key attributes for the
participating entities. Any attributes of the
composite entity become attributes of the new
relation
22
Example
Patient_ID
Patient_Name
Patient
1
M
Results
(0,N)
(1,1)
Physician_ID
(0,N)
(1,1) M
Physician_Name
Physician
1
Date
Patient
Treatment
Time
Treatment_
Code
M
(1,1)
1
(0,N)
Treatment
Description
23
Example
Patient
Patient_ID
Patient_Name
Physician
Physician_ID
Physician_Name
Patient Treatment
Patient_ Physician_I Treatment_C Date
ID
D
ode
Treatment
Treatment_Code
Time
Result
Description
24
Transforming ERD into Relations
(Cont’d)
• Step seven: Map supertype/subtype
relationships
1. Create a separate relation for the supertype and
for each of its subtype
2. Assign to the relation created for the supertype
the attributes that are common to all members
of the supertype, including the primary key
3. Assign to the relation for each subtype the
primary key of the supertype, and only those
attributes that are unique to that subtype
4. Assign one attribute of the supertype to function
as the subtype discriminator
25
Example
Address
Employee_Name
Employee_Number
Employee_Type
Employee
Date_Hired
Gs
Hourly
Employee
Hourly_Rate
Salaried
Employee
Annual_Salary
Stock_Option
26
Example
Employee
Employee_Nu Employee_N Address
mber
ame
Hourly_Employee
H_Employee_Number
Employee_Ty Date_Hi
pe
red
Hourly_Rate
Salaried_Employee
S_Employee_Number
Annual_Salary
Stock_Option
27
Database Tables and
Normalization
• Table is the basic building block in database design
• Normalization is the process for assigning attributes
to entities
– Reduces data redundancies
– Helps eliminate data anomalies
– Produces controlled redundancies to link tables
• Normalization stages
–
–
–
–
1NF - First normal form
2NF - Second normal form
3NF - Third normal form
4NF - Fourth normal form
28
Need for Normalization
29
Anomalies In the Table
• PRO_NUM intended to be primary key
• Table displays data anomalies
– Update
• Modifying JOB_CLASS
– Insertion
• New employee must be assigned project
– Deletion
• If employee deleted, other vital data lost
30
Conversion to 1NF
• Step 1: Eliminate the Repeating Groups
– Present data in a tabular format, where each cell
has a single value and there are no repeating
groups
– Eliminate repeating groups by eliminating nulls,
making sure that each repeating group attribute
contains an appropriate data value
• Step 2: Identify the Primary Key
– Primary key must uniquely identify attribute value
31
Dependency Diagram (1NF)
32
1NF Summarized
• All key attributes defined
• No repeating groups in table
• All attributes dependent on primary key
• All relational tables satisfy 1NF
requirements
33
Conversion to 2NF
• Start with 1NF form:
• Write each key component on separate line
• Write original key on last line
• Each component is new table
• Write dependent attributes after each key
PROJECT (PROJ_NUM, PROJ_NAME)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS,
CHG_HOUR)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
34
2NF Conversion Results
35
2NF Summarized
• In 1NF
• Includes no partial dependencies
– No attribute dependent on a portion of
primary key
• Still possible to exhibit transitive
dependency
– Attributes may be functionally dependent
on nonkey attributes
36
Conversion to 3NF
• Create separate table(s) to eliminate transitive
functional dependencies
– For every transitive dependency, write its
determinant as a PK for a new table
– Identify the Dependent Attributes
PROJECT (PROJ_NUM, PROJ_NAME)
ASSIGN (PROJ_NUM, EMP_NUM, HOURS)
EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
JOB (JOB_CLASS, CHG_HOUR)
37
3NF Summarized
• In 2NF
• Contains no transitive
dependencies
38
Boyce-Codd Normal Form (BCNF)
• Every determinant in the table is a
candidate key
– Determinant is an attribute whose value
determines other values within a row
– 3NF table with one candidate key is
already in BCNF
39
3NF Table Not in BCNF
40
Decomposition of Table
Structure to Meet BCNF
41
Decomposition into BCNF
42
An Example
GRADE( Student_ID, Student_Name, Address, Major,
Course_ID, Course_Title, Instructor_Name,
Instructor_Office, Grade)
43
Normalization and Database
Design
• Normalization should be part of the design
process
• E-R Diagram provides macro view
• Normalization provides micro view of entities
– Focuses on characteristics of specific entities
– May yield additional entities
• Difficult to separate normalization from E-R
diagramming
• Business rules must be determined
44
Higher-Level Normal Forms
• Fourth Normal Form (4NF)
– Table is in 3NF
– Has no multiple sets of multivalued
dependencies
45
Conversion to 4NF
Stud-ID
Course
Service
Stud-ID
Course
1126
1212F
Red Cross
1126
1212F
1126
1620F
United Way
1126
1620F
1126
1320F
1126
1320F
Stud-ID
Service
1126
Red Cross
1126
United Way
Stud-ID
Course
1126
1212F
1126
1620F
1126
1320F
Service
1126
Red Cross
1126
United Way
Stud-ID
Course
Service
1126
1212F
Red Cross
1126
1620F
United Way
1126
1320F
Multivalued Dependencies
Set of Tables in 4NF
46
Denormalization
• Normalization is one of many database
design goals
• Normalized table requires
– Additional processing
– Loss of system speed
• Normalization purity is difficult to sustain
due to conflict in:
– Design efficiency
– Information requirements
– Processing
47
Exercise
Part Supplier Data
Part_
Description
No
1234
Logic Chips
5678
Memory Chips
Vendor_Nam
e
Fast Chips
Smart Chips
Address
Unit_C
ost
Cupertino 10.00
Phoenix
8.00
Fast Chips
Cupertino
Quality Chips
Austin
Smart Chips
Phoenix
3.00
2.00
5.00
48
Exercise(Cont’d)
• Convert the table to a relation in first normal form
(Named Part Supplier)
• List the functional dependency in the Part Supplier
and identify a candidate key
• For the relation Part Supplier, identify the
followings: an insert anomaly, a delete anomaly, and
a modification anomaly.
• Draw a relation schema and show the functional
dependencies
• Develop a set of 3NF relations from Part Supplier
49
Chapter 5 Review
• How to transform ERD into relations
• Definitions: 1NF, 2NF, 3NF, BCNF, and
4NF
• How normal forms can be
transformed from lower normal forms
to higher normal forms
50