Database Design

Nguyễn Văn Diêu

Ho Chi Minh City University of Transport

2024

Kiến thức - Kỹ năng - Sáng tạo - Hội nhập

Sứ mệnh - Tầm nhìn
Triết lý Giáo dục - Giá trị cốt lõi
Outline I
1. Overview of the Design Process
2. Conceptual Design
2.1 ER Conceptual Model
A Sample Database Application
Entity
Relationship
Constraints of relationships
Patterns and Relationships
Summary of the notation
Database Example
2.2 ER Design Methodology
2.3 Example
2.4 Mapping to Relational Database
Mapping Entity
Mapping Relationship
2.5 Weak Entity
Nguyễn Văn Diêu Table of Contents 2/175
Outline II

Strong Entity
Weak entity and Identifying Relationship
Weak Entity connected Weak Entity
Update Methodology
Mapping Weak Entity to Rational Database
2.6 Attributes of Relationship
2.7 Change M:N Relationship
2.8 Recursive Relationship
Structural Constraints
Multiple Relationship
2.9 Mapping Recursive Relationship
2.10 Derived or Redundant Relationship
2.11 Enhanced EntityRelationship (EER)
Generalization & Specialization
Subclasses of Subclasses

Nguyễn Văn Diêu Table of Contents 3/175

Outline III

Mapping rules
2.12 Union Types
Mapping rules

3. Logical Design
3.1 Functional Dependencies
Definition
Notation
Satisfaction
Integrity Constraint
Inference
3.2 Amstrong’s Axioms
Amstrong’s Axioms
Lemma
Proof
3.3 Closure

Nguyễn Văn Diêu Table of Contents 4/175

Outline IV

Closure of FDs Set

Closure of Attribute Set
Algorithm
Lemma
Testing Membership
Covers
Minimum Covers
Algorithm
Projected FD
Algorithm
3.4 Keys
Definition
Algorithm
Remarkable
Algorithm
FDs by Keys

Nguyễn Văn Diêu Table of Contents 5/175

Outline V

3.5 Normal Form

Definition
1NF
Fully dependent
Prime and nonprime attributes
2NF
Transitively Dependent
3NF Classic
3NF Modern
Lemma
BCNF Classic
BCNF Modern
3.6 Database Normalization
Overview
Preserve Information
Tableau Test

Nguyễn Văn Diêu Table of Contents 6/175

Outline VI

Theorem
Preserve Dependencise
Testing Preserve Dependencies
Decomposition Algorithm
Synthesis Algorithm

4. Physical Design
4.1 Overview
4.2 Conceptual to Physical
Problem
ERD
Relational Model
Normal Form
Normalization
Customize Name
Foreign Keys
SQL Script

Nguyễn Văn Diêu Table of Contents 7/175

Outline VII

4.3 Denormalization
4.4 Customized data views
4.5 Indexes

Nguyễn Văn Diêu Table of Contents 8/175

Main phases of Database design

Nguyễn Văn Diêu 1. Overview of the Design Process 9/175

Company Database sample
• The company is organized into departments. Each department has a unique
name, a unique number, and a particular employee who manages the department.
We keep track of the start date when that employee began managing the
department. A department may have several locations.
• A department controls a number of projects, each of which has a unique name, a
unique number, and a single location.
• The database will store each employee’s name, Social Security number, address,
salary, sex (gender), and birth date. An employee is assigned to one department,
but may work on several projects, which are not necessarily controlled by the same
department. It is required to keep track of the current number of hours per week
that an employee works on each project, as well as the direct supervisor of each
employee (who is another employee).
• The database will keep track of the dependents of each employee for insurance
purposes, including each dependent’s first name, sex, birth date, and relationship
to the employee.
Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: A Sample Database Application 10/175
ER Conceptual Model

• Entity: a thing or object in the real world with an independent existence.

• Attributes: Each entity has attributes — the particular properties that describe it
• Composite versus Simple (Atomic) Attributes
• Single-Valued versus Multivalued Attributes
• Stored versus Derived Attributes
• NULL Values
• Complex Attributes
• Key Attributes

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Entity 11/175

ER Conceptual Model

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Entity 12/175

ER Conceptual Model

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Entity 13/175

Relationship

• Relationship: Whenever an attribute of one entity type refers to another entity

type, some relationship exists.
• Degree of a Relationship: is the number of participating entity.
binary is degree two,
ternary is a degree three.
• Attributes of Relationship
• Recursive Relationships

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Relationship 14/175

Cardinality Ratio of a Relationship

• One-to-One (1:1) one entity is associated with one other entity and vice versa
• Many-to-One (M:1) many entity are associated with one another entity
• One-to-Many (1:M)
• Many-to-Many (M:N)
• Participation (Full/Partial)
Full (doube lines): All entity associated with another entity
Partial (single line): Not every entity associated with another entity

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Constraints of relationships 15/175
Pattern 1

1(full):1 Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 16/175
Pattern 1

M(full):1 Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 17/175
Pattern 2

1(partial):1 Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 18/175
Pattern 2

M(partial):1 Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 19/175
Pattern 3

1(full):M Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 20/175
Pattern 3

M(full):N Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 21/175
Pattern 4

1(partial):M Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 22/175
Pattern 4

M(partial):N Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Patterns and Relationships 23/175
Summary of the notation for ER diagrams

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Summary of the notation 24/175
Summary of the notation for ER diagrams

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Summary of the notation 25/175
COMPANY database - Using Tool to draw ERD

Nguyễn Văn Diêu 2. Conceptual Design :: ER Conceptual Model :: Database Example 26/175
ER Design Methodology

• Step 1. Select one primary entity from the database requirements description;
Show attributes.
• Step 2. Find out if information about attributes refer to another thing.
• Step 3. If another entity is appropriate, draw the second entity. Repeat step 2.
• Step 4. Connect entities with relationships if relationships exist.
• Step 5. Define Cardinality ratio of relationship.
• Step 6. Show some sample data.

Nguyễn Văn Diêu 2. Conceptual Design :: ER Design Methodology 27/175

Example

Consider a model for a simplified airport where PASSENGERS and FLIGHTS are to
be recorded. Suppose the attributes of PASSENGERS are name, luggage_pieces
and frequent_flier_no. Suppose the attributes for FLIGHT are flight_no,
destination, arrive_time and depart_time. Draw the ER diagram.
ER Design Methodology:

Nguyễn Văn Diêu 2. Conceptual Design :: Example 28/175

Example

Nguyễn Văn Diêu 2. Conceptual Design :: Example 29/175

Example

Nguyễn Văn Diêu 2. Conceptual Design :: Example 30/175

Mapping Entity to Relation

Mapping rule 1: Mapping strong entities to a relation with attibutes and the primary
key. If more than one candidate key is indicated on the ER diagram, choose one for the
primary key.

STUDENT(name, phone, school, address, major)

Nguyễn Văn Diêu 2. Conceptual Design :: Mapping to Relational Database :: Mapping Entity 31/175
Mapping Entity to Relation

Mapping rule 2: Mapping composite attributes.

STUDENT(name.first, name.mid, name.last, school, address)

Nguyễn Văn Diêu 2. Conceptual Design :: Mapping to Relational Database :: Mapping Entity 32/175
Mapping Entity to Relation

Mapping rule 3: Mapping multivalued attributes.

STUDENT(student_number, name.first, name.mid, name.last, address)

STUDENT_SCHOOL(student_number, school)

Nguyễn Văn Diêu 2. Conceptual Design :: Mapping to Relational Database :: Mapping Entity 33/175
Mapping Relationship to Relation

Mapping rule 4: Mapping binary M:N relationships.

STUDENT(student_number, name.first, name.mid, name.last, address)

COURSE(c_number, cname, credit_hrs)
ENROLL(student_number, c_number)

Nguyễn Văn Diêu 2. Conceptual Design :: Mapping to Relational Database :: Mapping Relationship 34/175
Mapping Relationship to Relation

Mapping rule 5: Mapping a binary 1:1 relationship when one side of the relationship
has full participation and the other has partial participation.

AUTOMOBILE(vehicle_id, make,
body_style, color, year,
student_number)
STUDENT(student_number,
name.first, name.mid,
name.last, address)

Nguyễn Văn Diêu 2. Conceptual Design :: Mapping to Relational Database :: Mapping Relationship 35/175
Mapping Relationship to Relation

Mapping rule 6: Mapping a binary 1:1 relationship when both sides have partial
participation constraints.
AUTOMOBILE( vehicle_id, make,
body_style, color, year)
STUDENT(student_number,
name.first, name.mid,
name.last, address, vehicle_id)
———
AUTOMOBILE( vehicle_id, make, body_style, color,
year)
STUDENT(student_number, name.first, name.mid,
name.last, address)
STUDENT_AUTOMOBILE(student_number, vehicle_id)
Nguyễn Văn Diêu 2. Conceptual Design :: Mapping to Relational Database :: Mapping Relationship 36/175
Mapping Relationship to Relation

Mapping rule 7: Mapping a binary 1:1 relationship when both sides have full
participation constraints. Using M:N
Mapping rule 8: Mapping binary 1:N relationships when the N side has full
participation. Include the key of the entity on the 1 side of the relationship as a foreign
key on the N side. Using rule 5.

Nguyễn Văn Diêu 2. Conceptual Design :: Mapping to Relational Database :: Mapping Relationship 37/175
Strong Entity

e.g.

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Strong Entity 38/175
Strong Entity

Sample data:

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Strong Entity 39/175
Weak Entity

A weak entity clearly will be an entity but

will depend on another entity for its
existence.
A weak entity will not necessarily have a
unique identifer.
• The attribute dname is a Partial
Key.
• Underlined dname with dashes.

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Weak entity and Identifying Relationship 40/175
Weak Entity

• The automobile is identifed by the

owner.
• Double diamond on the owns
relationship and the full participation
of the AUTOMOBILE entity in the
owns relationship.
• All automobiles are driven by some
employee.

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Weak entity and Identifying Relationship 41/175
Weak Entity - Weak Entity

• Entity EMPLOYEE is the owner of

the weak entity DEPENDENT
• Weak Entity DEPENDENT is the
owner of the weak entity HOBBY

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Weak Entity connected Weak Entity 42/175
Mapping Weak Entity to Relational DB

Mapping Rule 9: Mapping weak entities.

EMPLOYEE(employee_id, fname,
minit, lname)
DEPENDENT(employee_id, dname,
insurance, birth_date)
HOBBY(employee_id, dname, type,
year_involved)

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Mapping Weak Entity to Rational Database 43/175
Attributes of Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: Attributes of Relationship 44/175

Change M:N Relationship

Change to:
• Intersection Weak Entity:
STUDENT-COURSE
• Attribute: grade
• Key: student_ID +
course_ID
• Relationship 1: Rel1
• Relationship 2: Rel2

Nguyễn Văn Diêu 2. Conceptual Design :: Change M:N Relationship 45/175

Recursive Relationship

• An employee may supervise

many other employees
• Many employees having one
supervisor

Nguyễn Văn Diêu 2. Conceptual Design :: Recursive Relationship 46/175

One to One Recursive Relationship

e.g.

Nguyễn Văn Diêu 2. Conceptual Design :: Recursive Relationship :: Structural Constraints 47/175
One to Many Recursive Relationship

e.g.

Nguyễn Văn Diêu 2. Conceptual Design :: Recursive Relationship :: Structural Constraints 48/175
Many to Many Recursive Relationship

e.g.

Nguyễn Văn Diêu 2. Conceptual Design :: Recursive Relationship :: Structural Constraints 49/175
Multiple Relationship

e.g.

Nguyễn Văn Diêu 2. Conceptual Design :: Recursive Relationship :: Multiple Relationship 50/175
Mapping Recursive Relationship

Mapping Rule 10: Mapping 1:N recursive relationships. Re-include the primary key of
the table with the recursive relationship in the same table, giving it some other role
name.
e.g.
PERSONNELL(emplye_id, fname, mname, lname, super_id)

Nguyễn Văn Diêu 2. Conceptual Design :: Mapping Recursive Relationship 51/175

Derived or Redundant Relationship

• Students take courses

• Each course is taught by an
instructor
• We do not need a taught_by
relationship

Nguyễn Văn Diêu 2. Conceptual Design :: Derived or Redundant Relationship 52/175

Generalization or Specialization

• Generalization: Super Class

• Specialization: Sub Class
Constraints: There are two types of constraints on the “Sub-class” relationship.
• Overlapping: Superclass entity may contain more than one subclass
• Disjoint: Superclass entity may be a member of only one of the subclasses

Nguyễn Văn Diêu 2. Conceptual Design :: Enhanced EntityRelationship (EER) :: Generalization & Specialization 53/175
Generalization or Specialization

Nguyễn Văn Diêu 2. Conceptual Design :: Enhanced EntityRelationship (EER) :: Generalization & Specialization 54/175
Generalization or Specialization

Nguyễn Văn Diêu 2. Conceptual Design :: Enhanced EntityRelationship (EER) :: Generalization & Specialization 55/175
Subclasses of Subclasses

Nguyễn Văn Diêu 2. Conceptual Design :: Enhanced EntityRelationship (EER) :: Subclasses of Subclasses 56/175
Subclasses of Subclasses

Nguyễn Văn Diêu 2. Conceptual Design :: Enhanced EntityRelationship (EER) :: Subclasses of Subclasses 57/175
Mapping rules to Relation

• Generalization: New Relation

• Specialization: New Relation with Primary key of Generalization

Nguyễn Văn Diêu 2. Conceptual Design :: Enhanced EntityRelationship (EER) :: Mapping rules 58/175
Union Types

Nguyễn Văn Diêu 2. Conceptual Design :: Union Types 59/175

Union Types

Nguyễn Văn Diêu 2. Conceptual Design :: Union Types 60/175

Union Types

Nguyễn Văn Diêu 2. Conceptual Design :: Union Types 61/175

Union Types

Nguyễn Văn Diêu 2. Conceptual Design :: Union Types 62/175

Union Types

Nguyễn Văn Diêu 2. Conceptual Design :: Union Types 63/175

Mapping rules to Relation

Generalizations have the same primary keys

• Generalizations: New Relations
• Specialization: New Relation with the same as the Primary key of Generalization

Generalizations have diferent primary keys

• Generalizations: New Relations with foreign key to be PK of specialization
• Specialization: New Relation with the same as the Primary key of Generalization

Nguyễn Văn Diêu 2. Conceptual Design :: Union Types :: Mapping rules 64/175
Functional Dependencies Definition

Let:
• R(A1 , · · ·, An ) be a relational scheme,
• X and Y be subsets of {A1 , · · ·, An }
We say:
• X → Y, read ”X functionally determines Y” or ”Y functionally depends on X” if:
∀(t1 , t2 ) ∈ ∀r(R) :
Not possible: t1 (X) = t2 (X) but t1 (Y) ̸= t2 (Y)
• In the FD X → Y, X is called the Left side and Y called the Right side.

Nguyễn Văn Diêu 3. Logical Design :: Functional Dependencies :: Definition 65/175

Notational Conventions

• A, B, C, · · · stand for single attributes

• U, V, · · ·, Z stand for sets of attributes
• R is used to denote a relation scheme
• r(R) relation, the current instance of scheme R
• A1 · · · An set of attributes {A1 , · · ·, An }
• XY stand for X ∪ Y
• XA or AX stand for X ∪ {A}

Nguyễn Văn Diêu 3. Logical Design :: Functional Dependencies :: Notation 66/175

e.g.
StudentGrade(StudentID, StudentName,SubjectID, SubjectName, Grades)
One current StudentGrade:
StudentGrade (StudentID StudentName SubjectID SubjectName Grades)

T01 Nam S01 Database 7

T01 Nam S02 Math 6
T02 Tuan S01 Database 9
T02 Tuan S02 Math 5
T03 Cuong S01 Database 8
T04 Quoc S02 Math 8

StudentID → StudentName
SubjectID → SubjectName
StudentID, SubjectID → Grades

Nguyễn Văn Diêu 3. Logical Design :: Functional Dependencies :: Notation 67/175

Satisfaction of Dependencies

• r satisfies FD X → Y
if ∀(t1 , t2 ) ∈ r(R) : t1 (X) = t2 (X) then t1 (Y) = t2 (Y)
• ”if ... then” statement, it can be satisfied either by:
1. t1 (X) ̸= t2 (X) or
2. t1 (Y) = t2 (Y)
• If r does not satisfy X → Y, the r violate X → Y.
• If we declared X → Y hold for R, then all instance r of scheme R will satisfy
X → Y.
• FD X → ∅ is trivially satisfied by any relation.
• FD ∅ → Y is satisfied by those relations in which every tuple has the same
Y − value.

Nguyễn Văn Diêu 3. Logical Design :: Functional Dependencies :: Satisfaction 68/175

FDs is an Integrity Constraints

Let: R(ABC); FD: A → B

There is an integrity constraint of scheme R.
• Context: R
• Condition:
∀(t1 , t2 ) ∈ ∀r(R) : t1 .A = t2 .A
t1 .B = t2 .B
end.
• Influence table:
Insert Delete Update
R + - +(A/B)

Nguyễn Văn Diêu 3. Logical Design :: Functional Dependencies :: Integrity Constraint 69/175
Inference FD

Let R; A, B, C : attributes.
FD: A → B and B → C are known to hold in R.
We claim that A → C must also hold in R
Proof by Contradiction
Suppose r satisfies A → B and B → C,
but ∃(t1 , t2 ) ∈ r : t1 .A = t2 .A and t1 .C ̸= t2 .C
• if t1 .B ̸= t2 .B, then r violate A → B
• if t1 .B = t2 .B but t1 .C ̸= t2 .C then r violate B → C
Hence r must satisfy A → C ■
Direct Proof
∀(t1 , t2 ) ∈ ∀r(R) : t1 .A = t2 .A =⇒ t1 .B = t2 .B (A → B)
=⇒ t1 .C = t2 .C (B → C)
from FD definition =⇒ A → C ■
Nguyễn Văn Diêu 3. Logical Design :: Functional Dependencies :: Inference 70/175
Logically Inference

− Let F set of functional dependencies hold on R

− X → Y be a functional dependency.
• F logically inference X → Y written F |= X → Y
if ∀r(R) satisfies F also satisfies X → Y
{ }
e.g. F = A → B, B → C
then A → { C is logically inference
} by F
that is, A → B, B → C |= A → C

Nguyễn Văn Diêu 3. Logical Design :: Functional Dependencies :: Inference 71/175

Amstrong’s Inference Axioms

Giving U be a universal set of attributes. F be a FDs set involving only attributes in U.

The inference rule are:
1. Reflexivity. If Y ⊆ X ⊆ U, then X → Y is logically implied by F. This rules gives
the trivial dependencies . It hold in every relation.
{ }
2. Augmentation. X → Y, Z ⊆ U |= XZ → YZ.
{ }
3. Transitivity. X → Y, Y → Z |= X → Z.

Nguyễn Văn Diêu 3. Logical Design :: Amstrong’s Axioms :: Amstrong’s Axioms 72/175
e.g.

Let R(ABCD), F = {A → C, B → D}.

F |= AB → ABCD ?
1. A → C (given)
2. AB → ABC [augmentation of (1) by AB]
3. B → D (given)
4. ABC → ABCD [augmentation of (3) by ABC]
5. AB → ABCD [transitivity applied to (2) and (4)] ■

Nguyễn Văn Diêu 3. Logical Design :: Amstrong’s Axioms :: Amstrong’s Axioms 73/175
Lemma

Amstrong’s Axioms are sound. That is,

if X → Y is deduced from F using the axioms, then X → Y is true in any relation in
which the dependencies of F are true.
Proof:
Reflexivity. Clearly sound.
Augmentation. Suppose relation r satisfies X → Y, but
∃(t1 , t2 ) : t1 (XZ) = t2 (XZ) and t1 (YZ) ̸= t2 (YZ)
=⇒ t1 .Y ̸= t2 .Y
So t1 .X = t2 .X and t1 .Y ̸= t2 .Y, violating X → Y holds for r. ■
Transitivity. Similarly, as an exercise.

Nguyễn Văn Diêu 3. Logical Design :: Amstrong’s Axioms :: Lemma 74/175

Lemma

There are several other inference rules that follow from Amstrong’s Axioms
Lemma:
{ }
1. Union. X → Y, X → Z |= X → YZ
{ }
2. Pseudotransitivity. X → Y, WY → Z |= WX → Z
{ }
3. Decomposition. X → Y, Z ⊆ Y |= X → Z

Nguyễn Văn Diêu 3. Logical Design :: Amstrong’s Axioms :: Lemma 75/175

Proof

Proof:
Union. Given X → Y |= X → XY (augment)
Given X → Z |= XY → YZ (augment)
{ }
By transitivity X → XY, XY → YZ |= X → YZ
Pseudotransitivity. Given X → Y |= WX → WY (augment)
Since given WY → Z |= WX → Z (transitivity)
Decomposition. Given Z ⊆ Y |= Y → Z (reflexivity)
Given X → Y, by transitivity, |= X → Z ■

Nguyễn Văn Diêu 3. Logical Design :: Amstrong’s Axioms :: Proof 76/175

e.g.
{ }
F= AB → CD, C → B, A → C, BD → G, H → K
Show F |= AH → GK
AB → CD |= AB → D [decomposition] (1)
{ }
A → C, C → B |= A → B [transitivity] (2)
(2) A → B |= A → AB [augment] (3)
{ }
(3) A → AB, (1) AB → D |= A → D [transitivity] (4)
{ }
(2) A → B, (4) A → D |= A → BD [union] (5)
{ }
(5) A → BD, BD → G |= A → G [transitivity] (6)
H → K |= GH → GK [augment] (7)
{ }
(6) A → G, GH → GK |= AH → GK [pseudotransitivity] ■

Nguyễn Văn Diêu 3. Logical Design :: Amstrong’s Axioms :: Proof 77/175

Closure of FDs Set

• We define F+ , the closure of F, to be the set of functional dependencies that are

logically implied by F; i.e.,
{ }
• F+ = X → Y | F |= X → Y
{ }
e.g. F = AB → C, C → B hold on R(ABC), then:
{
F+ = A → A, AB → A, AC → A, ABC → A, B → B,
AB → B, BC → B, ABC → B, C → C, AC → C,
BC → C, ABC → C, AB → AB, ABC → AB, AC → AC,
ABC → AC, BC → BC, ABC → BC, ABC → ABC,
AB → C, AB → AC, AB → BC, AB → ABC, C → B,
}
C → BC, AC → B, AC → AB

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Closure of FDs Set 78/175
e.g.
{ }
Let R(ABC) and F = A → B, B → C . Then F+ consists of all those dependencies
X → Y such that either
1. X contains A e.g., ABC → AB, AB → BC, or A → C,
2. X contains B but not A, and Y does not contain A e.g., BC → B, B → C, or
B → ∅, and
3. X → Y is one of the three dependencies C → C, C → ∅, or ∅ → ∅.

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Closure of FDs Set 79/175
Closure of Attribute Set

Let:
• R be an attributes set.
• F be a functional dependencies set hold on R.
• X be a subset of R.
We define X+
F is the closure of X (with respect of F) is the set of attributes A such
that X → A can be logically implied from
{ F (by FD definition).
}
X+F = A | F |= X → A

e.g. { }
R(ABCD) , F = B → D, A → B, C → B
A+
F = ABD

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Closure of Attribute Set 80/175
Algorithm

Closure of a set of attributes with respect to a set of functional dependencies.

Input: R, F, X ⊆ R
Output: X+
F
(0) (1)
Method: Computing a sequence attributes sets XF , XF , ... by the rule:
(0)
1. XF ← X
(i)
2. Repeat Y → Z ∈ F : Y ⊆ XF
(i+1) (i)
XF ← XF ∪ Z
(i+1)
Until XF is not change
(0) (i)
Since X = XF ⊆ · · · ⊆ XF ⊆ · · · ⊆ R, and R is finite, we must eventually reach i such
(i) (i+1)
that XF = XF .

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Algorithm 81/175

e.g.
{
F= AB → C, D → EG, C → A, BE → C }
BC → D, CG → BD, ACD → B, CE → AG
X = BD, compute X+
F:
(0)
XF = BD
(1)
XF = BDEG
(2)
XF = BCDEG
(3)
XF = ABCDEG
(3) (4)
XF = XF = · · ·
Thus (DB)+
F = ABCDEG

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Algorithm 82/175

Lemma

Dependencies Logically Implied by Closure Set.

Let R , F , X ⊆ R, X+
F , then:

• X → X+F
• Z ⊆ X+
F , then X → Z

Proof: X → Z:
Suppose ∃(t1 , t2 ) : t1 .X = t2 .X, but t1 .Z ̸= t2 .Z
So ∃ A ∈ Z : t1 .A ̸= t2 .A. That is contradiction with closure set definition, because of
A ∈ Z ∈ X+
F ■
Similarly with X → X+
F ■

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Lemma 83/175

Testing Membership in F+

Let X → Y and F
Determine F |= X → Y ? We have three methods:
1. Using FD definition
2. Using Amstrong’s axioms
3. Test if X → Y ∈ F+
In the 3th method, F+ can be very lager
How to show X → Y ∈ F+ without generating all of F+
Algorithm:
1. X+
F
2. if Y ⊆ X+
F then F |= X → Y
if Y ⊈ XF then F |=
+


X → Y

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Testing Membership 84/175

e.g.
{ }
F= A → D, AB → E, BI → E, CD → I, E → C
Proofing items below by using Amstrong’s axioms as an exercise.
1. AE → AI ∈ F+ ?
AE+
F = ACDEI contain the right side of the FD, so
AE −→ AI ∈ F+ or F |= AE → AI ■
2. DB → C ∈ F+ ?
DB+
F = DB not contain the right side of the FD, so
/ F+ or F |=
DB → C ∈

DB → C ■

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Testing Membership 85/175

Covers and Equivalence of Dependencies Sets

Definition:
• Two FDs F and G over R are equivalent if F+ = G+
• Denote F ≡ G
• If F ≡ G, then F is a cover for G
Test whether F and G are equivalent:
• Step 1: F |= G
− Test every g : X → Y ∈ G is g ∈ F+
− g : X → Y ∈ G, compute X+
F
− If Y ⊆ X+
F , then g ∈ F , if not: g ∈
+ / F+
− If ∃ g ∈ G, ∈
/ F+ , then surely F+ ̸= G+
• Step 2: G |= F
Analogous manner Step 1:, test every f ∈ F is f ∈ G+
Nguyễn Văn Diêu 3. Logical Design :: Closure :: Covers 86/175
e.g.
{ }
F = { A → BC, A → D, CD → E }
G = A → BCE, A → ABD, CD → E
F≡G?
Step 1: F |= G.
A → BCE: A+ F = ABCDE ⇒ F |= A → BCE
A → ABD: A+ F = ABCDE ⇒ F |= A → ABD
CD → E: CD+ F = CDE ⇒ F |= CD → E
Step 2: G |= F.
A → BC: A+ G = ABCED ⇒ G |= A → BC
A → D: AG = ABCED ⇒ G |= A → D
+

CD → E: CD+ G = CDE ⇒ G |= CD → E
F≡G■

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Covers 87/175

Minimum Covers

Definition
• F have many cover sets, its equivalent to F
• We define a set Fc is a minimal cover of F if:

1. Every right side of FD in Fc is a single attribute

{ }
2. ∄ X → A ∈ Fc : Fc − { X → A } ≡ Fc
3. ∄ X{→ A ∈ Fc and Z}⊆ X :
Fc − {X → A} ∪ {Z → A} ≡ Fc
One dependencies G maybe there are many minimum covers.

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Minimum Covers 88/175

Algorithm

Find one minimum cover of dependencies set.

Input: Dependencies F.
Output: One minimum cover.
Method: Compute a sequence steps:

1. Decompose right side FDs in F to one attribute.

2. For each X → A in F:
if F − {X → A} ≡ F then
F = F − {X → A}
3. For each X → A{in F: }
if Z ⊂ X {and F − {X →}A} ∪ {Z → A} ≡ F then
F = F − {X → A} ∪ {Z → A}.
Easy proofing three steps, we see as an exercise ■

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Algorithm 89/175

e.g.
{
F= AB → C, D → EG, C → A, BE → C, BC → D
}
CG → BD, ACD → B, CE → AG
Step 1, split right side FDs:
AB → C, D → E, D → G, C → A, BE → C, BC → D
CG → B, CG → D, ACD → B, CE → A, CE → G
Step 2, remove CE → A, CG → B
Step 3, ACD → B replaced by CD → B
One minimum cover
{
Fc = AB → C, D → E, D → G, C → A, BE → C,
}
BC → D, CG → D, CD → B, CE → G

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Algorithm 90/175

Projected Functional Dependencies

R, F ; R1 : Attributes Set.
F1 = projected FDs of F on R1 ,
denote F1 = π R1 (F):
• F1 follow from F and
• Involve only attributes of R1 .

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Projected FD 91/175

Algorithm

Input: R, F ; R1 : Attributes Set

Output: F1 = π R1 (F)
Method: Compute a sequence steps
1. F1 ← ∅
2. For each X ⊂ R1
• Compute X+ F
• If X+
F ∩ R1 ̸= ∅ :
{ }
F1 = F1 + X → X+
F ∩ R1
3. F1 ← a minimal cover of F1

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Algorithm 92/175

e.g.
{ }
R(ABCD) ,F = A → B, B → C, C → D
Find F1 = π R1 (ACD) (F)
{ }
• First, A+
F = ABCD ⇒ F1 = A → C, A → D
{ }
• Next, C+F = CD ⇒ F1 = A → C, A → D, C → D
• Since A+
F = R1 , no any superset of A can find new FDs.
Thus, the only CD can be compute, but CD+ = CD, add nothing.
• Done F1 = {A → C, A → D, C → D}
• Find a minimum cover of F1 ,
{ }
Thus, F1 = A → C, C → D ■

Nguyễn Văn Diêu 3. Logical Design :: Closure :: Algorithm 93/175

Keys by Functional Dependencies

R(A1 , · · · , An ) and F; subset K ⊆ A1 A2 · · · An

K is a key of R if:
1. K → A1 A2 · · · An is in F+ , and
2. ∄ Y ⊊ K : Y → A1 A2 · · · An in F+
• May be more than one key, one call primary key
• The keys not chose primary key is called candidate key
• Set consists key is called super key
• One key show in relation scheme by an underline
{ }
e.g. R(ABC), F = A → B, B → C .
Only one key A, since A → ABC is in F+ (F |= A → ABC),
and no set X dose not contain A, is also X → ABC.
R(ABC)
Nguyễn Văn Diêu 3. Logical Design :: Keys :: Definition 94/175
e.g.
{ }
− R1 (ABCD) , F1 = AB → CD, C → A, D → BC
R1 have two keys: AB and D
R1 (AB C D)
− R2 (ABC) , F2 = ∅
R2 have one key, it all attributes.
R2 (ABC)
{ }
− R3 (ABC) , F3 = A → B, B → C, C → A
R3 have three keys: A, B and C
R3 (A B C)

Nguyễn Văn Diêu 3. Logical Design :: Keys :: Definition 95/175

Algorithm

Input: R , F.
Output: All keys of R.
Method: Computing a sequence steps:
1. Generate all subsets of R, not ∅ set. Sorting it by ascending.
2. Computing closure those sets.
3. Only keep the sets, such that its closure equal R.
4. Remove the sets, it contains any other sets in list.
5. All sets remain are the all keys of relation scheme R.

Nguyễn Văn Diêu 3. Logical Design :: Keys :: Algorithm 96/175

e.g.
{ }
R(ABC) , F = A → B, B → C, B → A
Find all keys.
Step 1, Step 2:
A+ = ABC, B+ = ABC, C+ = C, AB+ = ABC,
AC+ = ABC, BC+ = ABC, ABC+ = ABC
Step 3:
A+ = ABC, B+ = ABC, AB+ = ABC
AC+ = ABC, BC+ = ABC, ABC+ = ABC
Step 4:
A
B
Step 5:
R(A B C)

Nguyễn Văn Diêu 3. Logical Design :: Keys :: Algorithm 97/175

Remarkable

We note some thing about keys algorithm above:

1. Attributes do not in FDs, must in every keys.
2. Attributes do only in left side FDs, then it must in every keys.
3. Attributes do only in right side FDs, then it must do not in any key.
4. Attributes do both in left side and right side FDs, then it either in or not in any
key.

Nguyễn Văn Diêu 3. Logical Design :: Keys :: Remarkable 98/175

Algorithm

Input: Q , F.
Output: All keys on Q.
Method: Computing a sequence steps:
1. L : attributes in the left side of FDs
R : attributes in the right side of FDs
NF = Q − (L + R) : attributes do not in FDs
OL = L − R : attributes only in left side of FDs
LR = L ∩ R : att. both in the left side and right side of FDs
2. Generate all subsets of LR including ∅.
Sorting it by ascending.
3. Add NF and OL into subsets above.
4. Computing closure for all subsets.
Decide the keys like general algorithm.

Nguyễn Văn Diêu 3. Logical Design :: Keys :: Algorithm 99/175

e.g.
{ }
Q(ABCDEG) , F = B → CD, D → C, C → EG .
Find all keys.
Step 1: L = BCD, R = CDEG
NF = A, OL = B, LR = CD
Step 2: ∅, C, D, CD
Step 3: AB, CAB, DAB, CDAB
Step 4: AB+ = ABCDEG
 

CAB
 

DAB


CDAB
One key result: AB
Q(ABCDEG)
{ }
e.g. Q(ABCD) , F = B → CD, A → C , find all keys.
Nguyễn Văn Diêu 3. Logical Design :: Keys :: Algorithm 100/175
e.g.
{ }
Q(ABCD) , F = AB → CD, CD → AB, B → C .
Find all keys.
Step 1: L = ABCD , R = ABCD , NF = ∅, OL = ∅, LR = ABCD
Step 2: ∅, D, BC, ABD, A, AB, BD, ACD
B, AC, CD, BCD, C, AD, ABC, ABCD
Step 3: Nothing change
Step 4: ∅, AB+ = ABCD, CD+ = CDAB,  
ACD,
A+ = A, AC+ = AC,  

ABC,  

BCD,
+ +   
B = BC, AD = AD, ABD, 
ABCD,
+ +
C = C, BC = BC,
D+ = D, BD+ = BDCA
Three keys result: (AB), (BD), (CD)

Nguyễn Văn Diêu 3. Logical Design :: Keys :: Algorithm 101/175

FDs logically implied by Keys

R , F,
K1 , K2 , · · · Kn : keys of R, then we have FDs:
K1 → R, or K1 → (R − K1 )
···
Kn → R, or Kn → (R − Kn )
e.g. { }
R(ABCDE) , F = AB → CD, D → E, BC → A
Two keys: K1 = AB, K2 = BC
Then, there are FDs logically implied by keys:
AB → CDE
BC → ADE

Nguyễn Văn Diêu 3. Logical Design :: Keys :: FDs by Keys 102/175

Normal Form

• Base on Keys checking system of DBMS, we have a concept to check all FDs on
relation.
• This concept is call Normal Form.

A good Normal form has mainly two purposes:

• Removing duplicated data, redundancy (repetition) data.
• Ensuring data is logically stored.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: Definition 103/175

First Normal Form (1NF)

• Relation scheme R is in first normal form (1NF) if every attribute A in R, Dom(A)

are atomic.
• That is, the values in the domain are not lists or sets of values or composite
values.
• Database scheme D is in 1NF if every relation scheme in D is in 1NF.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 1NF 104/175

e.g.

Relation Gender, shown below, is not in 1NF because it contains values that are sets
of atomic values.
Gender(Name, Sex)

Gender (Name Sex)

{Tuan, Nam, Cuong} male
{Nhung, Hang} female

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 1NF 105/175

e.g.

To be in lNF, gender should be stored like this:

Gender(Name, Sex)

Gender (Name Sex)

Tuan male
Nam male
Cuong male
Nhung female
Hang female

Specially DateTime data type is a type with atomic domain.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 1NF 106/175

e.g.

Assign(Flight, Day, Pilot, Gate)

{ }
with F = Flight, Day → Pilot; Flight → Gate
Key: {Flight, Day}

Assign (Flight Day Pilot Gate)

VN123 20/10/2018 Cuong 7
VN123 27/10/2018 Nhan 7
VN456 28/10/2018 Tuan 8
We would like to update the first tuple:
ssign(VN123, 20/10/2018, Cuong; Gate = 9)

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 1NF 107/175

e.g.

Assign (Flight Day Pilot Gate)

VN123 20/10/2018 Cuong 9
VN123 27/10/2018 Nhan 7
Assign will violate the FD Flight → Gate.
To avoid violating the FD, every time an update is made, we have to scan the relation
and update the gate number every place the flight number appears.
The flight number and gate number information is duplicated, thus making the data
redundant.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 1NF 108/175

e.g.

We can represent the same information as a database of two relations, PilotAssign

and GateAssign:

PilotAssign (Flight Day Pilot)

VN123 20/10/2018 Cuong
VN123 27/10/2018 Nhan
VN456 28/10/2018 Tuan

GateAssign (Flight Gate)

VN123 7
VN456 8

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 1NF 109/175

e.g.

To reconstruct the original relation Assign, taking

⋉GateAssign
PilotAssign⋊

To update anomaly in Assign, altering to change in GateAssign.

We have also removed data redundancy of Gate attribute.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 1NF 110/175

Fully dependent

• Given R , F;
X, Y ⊆ R
• Y is called fully dependent upon X if:
1. X → Y ∈ F+
′ ′
2. ∄ X ⊊ X : X → Y ∈ F+
{ }
e.g. F = Flight, Day → Pilot, Gate; Flight → Gate
Gate is not fully dependent upon {Flight, Day}.
Pilot is fully dependent upon {Flight, Day}.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: Fully dependent 111/175
Prime and nonprime attributes

• Given R , F
• A is an attribute in R
• A is prime in R with respect to F if A is contained in some key of R.
• Otherwise A is nonprime in R.
e.g. Assign(Flight, Day, Pilot, Gate)
with F = {Flight, Day → Pilot; Flight → Gate}
Key: {Flight, Day}
Prime: Flight and Day.
Nonprime: Pilot and Gate.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: Prime and nonprime attributes 112/175
Second normal form (2NF)

• R is in second normal form (2NF) respect to FDs F

• if it is in 1NF and every nonprime attribute is fully dependent on every key of R.
• A database scheme D is in second normal form if every relation scheme in 2NF.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 2NF 113/175

e.g.

Assign(Flight, Day, Pilot, Gate)

{ }
with F = Flight, Day → Pilot; Flight → Gate
Key: {Flight, Day}
Assign is not in 2NF, because Gate is not fully dependent on key {Flight, Day}.
{ }
If we let D = R1 (Flight, Day, Pilot); R2 (Flight, Gate) ,
then both R1 and R2 are in 2NF,
so D is in 2NF.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 2NF 114/175

Transitively Dependent

• R,F
• X ⊆ R, A ∈ R
• A : transitively dependent upon X in R if there is a Y ⊆ R with:
• X → Y ∈ F+
• Y ↛ X ∈ F+
• Y → A ∈ F+
• A∈/ XY

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: Transitively Dependent 115/175
e.g.

Conference(Room, Day, Reporter, Name)

{ }
F = Room, Day → Reporter, Name; Reporter → Name
• Room, Day → Reporter
• Reporter ↛ Room, Day
• Reporter → Name
• Name ∈/ {Room, Day} ∪ {Reporter}
Name is transitively dependent

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: Transitively Dependent 116/175
Third Normal Form (3NF)

Classic Definition
R is in third normal form (3NF) if:
• It is in 1NF, and
• no nonprime attribute in R is transitively dependent upon a key of R.

Database scheme D is in third normal form if every relation scheme R in D is in third

normal form.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 3NF Classic 117/175
e.g.

Conference(Room, Day, Reporter, Name)

{ }
F = Room, Day → Reporter, Name; Reporter → Name
It is not in 3NF because of the transitive dependency of Name upon {Room, Day}.
{ }
If D = R1 (Room, Day, Reporter); R2 (Reporter, Name) , then
D is in 3NF because both R1 and R2 are in 3NF.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 3NF Classic 118/175
Third Normal Form (3NF)

Modern Definition
R is in third normal form (3NF) if:
• It is in 1NF, and
• Whenever X → Y is a nontrivial FD in F+ , either
• X is a superkey, or
• Each B ∈ Y is a member of some key of R

Database scheme D is in third normal form if every relation scheme R in D is in third

normal form.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: 3NF Modern 119/175
Lemma 3NF ⇒ 2NF

Any relation scheme R in 3NF is in 2NF.

Proof Using method:
• (X ⇒ Y) ⇔ (¬Y ⇒ ¬X )
• (3NF ⇒ 2NF) ⇔ (¬2NF ⇒ ¬3NF)
• Partial dependency ⇒ Transitive dependency.

R is not in 2NF ⇒ exists non-prime attribute A is not fully dependent upon key
′
K ⊆ R. So that ∃ K ⊊ K:
′
• K → A ∈ F+ and because of
′
• K ↛ K ∈ F+
′
• A∈/ K=K ∪K
Therefore A is transitively dependent upon key K, so that R is not in 3NF. ■

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: Lemma 120/175

Boyce-Codd Normal Form (BCNF)

Classic Definition
R : Boyce-Codd normal form (BCNF) if:
• It is in 1NF, and
• No attribute in R is transitively dependent upon a key of R.

Database scheme D is in Boyce-Codd normal form if every relation scheme R in D is in

Boyce-Codd normal form.
• Because of (attribute in R) ⊇ (nonprime attribute in R)
• So if R is in BCNF, then in 3NF .

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: BCNF Classic 121/175
Boyce-Codd Normal Form (BCNF)

Modern Definition
R : Boyce-Codd normal form (BCNF) if:
• It is in 1NF, and
• for every Y ⊆ R and for every attribute A ∈ (R − Y)
• if Y → A, then Y → R
• That is, if Y non-trivially determines any attribute of R, then Y is a superkey for R.

Database scheme D is in Boyce-Codd normal form if every relation scheme R in D is in

Boyce-Codd normal form.

Nguyễn Văn Diêu 3. Logical Design :: Normal Form :: BCNF Modern 122/175
Overview

Student(Id, Name, Addr, Hobby)

{ }
with F = Id → Name, Addr
Key: {Id, Hobby}
Student is in 1NF, not in 2NF, 3NF or BCNF.
e.g. Assign(Manager, Project, Branch), with F:
Manager → Branch: Each manager works in a particular branch.
Project, Branch → Manager: Each project has several managers, and runs on several
branches; however, a project has a unique manager for each branch.
Key: {Manager, Project}, {Project, Branch}
Assign is in 3NF, not in BCNF.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Overview 123/175

Preserve Information from a Decomposition ?

SuppInfo(Name, Addr, Item, Price), with

{ }
F = Name, Item → Price; Name → Addr
SuppInfo is in 1NF. We can replace it into:
{
ρ = Supp(Name, Addr) in BCNF,
}
SuppDetail(Name, Item, Price) in BCNF
• r is a relation of SuppInfo.
• Instead of store it in SuppInfo, we store it by two relation:
1. r(Supp) = π Name,Addr (r), and
2. r(SuppDetail) = π Name,Item,Price (r)
Question: r(Supp) and r(SuppDetail) contain the same data as r.
Only way to recover r is by taking r(Supp) ⋊
⋉ r(SuppDetail).
It is right if: r = r(Supp) ⋊
⋉ r(SuppDetail)
Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Preserve Information 124/175
Preserve Information Decomposition

Decomposition of {R, F} is its replacement:

{ }
• ρ = R1 , R2 , · · · , Rk
• R = R1 ∪ R2 ∪ · · · ∪ Rk
• Ri is no requirement to be disjoin.

This decomposition is Preserve information if for every r(R) satisfying F:

r = π R1 (r) ⋊
⋉ π R2 (r) ⋊
⋉ ··· ⋊
⋉ π Rk (r)
In general:

r ⊆ π R1 (r) ⋊
⋉ π R2 (r) ⋊
⋉ ··· ⋊
⋉ π Rk (r)

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Preserve Information 125/175
Tableau Test for Preserve Information

Tableau, Chase Algorithm.

{ }
n , F,
Input: R = A1 , A2 , · · · , A
{ }
decomposition ρ = R1 , R2 · · · , Rk
Ouput: Whether ρ is Recovering information.
Method:
1. Construct a tableau T: n columns, k rows.
• Column Aj corresponds to attribute Aj
• Row i corresponds to Ri
• For all (i, j) cell:
If Aj ∈ Ri :
(i, j) ← 0
else
(i, j) ← i (the same Row no.)
Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 126/175
Tableau Test (cont.)

2. Repeatedly until no more change tableau T:

For each X → Y ∈ F
if ∃ (t1 , t2 ) ∈ T : t1 .X = t2 .X ∧ t1 .Y ̸= t2 .Y
if t1 .Y = 0 make t2 .Y ← 0
if t2 .Y = 0 make t1 .Y ← 0
if t1 .Y = t1 , t2 .Y = t2 make them both t1 or t2
3. If exits a row has become all 0 then
ρ is Preserve information.
If not, ρ is Not Preserve information. ■

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 127/175
e.g.
{ }
R(ABCD) , F = {A → B, B → C, CD → A }
Decomposed into R1 (AD), R2 (AC), R3 (BCD)
Preserve information testing.
The initial tableau:
A B C D
R1 (AD) 0 1 1 0
R2 (AC) 0 2 0 2
R3 (BCD) 3 0 0 0

Apply A → B to equate 1, 2. Chosing 1 as the representative symbol (Figure below).

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 128/175
e.g. (cont.)

A B C D
R1 (AD) 0 1 1 0
R2 (AC) 0 1 0 2
R3 (BCD) 3 0 0 0
{ }
F = A → B, B → C, CD → A
Apply B → C to equate 1, 0. Chosing 0 as the representative symbol (Figure below).

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 129/175
e.g. (cont.)

A B C D
R1 (AD) 0 1 0 0
R2 (AC) 0 1 0 2
R3 (BCD) 3 0 0 0
{ }
F = A → B, B → C, CD → A
Apply CD → A for row 1 and row 3, to equate 0, 3. Chosing 0 as the representative
symbol (Figure below).

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 130/175
e.g. (cont.)

A B C D
R1 (AD) 0 1 0 0
R2 (AC) 0 1 0 2
R3 (BCD) 0 0 0 0

The third row has all 0. Preserve information decomposition ■

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 131/175
e.g.

SuppInfo(Name, Addr, Item, Price),

{ }
F = Name, Item → Price; Name → Addr
Decompose:
R1 = Supp(Name, Addr),
R2 = SuppDetail(Name, Item, Price)

Name Addr Item Price

R1 0 0 1 1
R2 0 2 0 0

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 132/175
e.g. (cont.)

Since Name → Addr and two rows agree on Name,

we may equate their symbols for Addr, making 2 become 0.
The resulting table is:
Name Addr Item Price
R1 0 0 1 1
R2 0 0 0 0
The second row has all 0. Preserve information decomposition ■

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 133/175
e.g.
{ }
R(ABCDE), F = A → C, B → C, C → D, DE → C, CE → A ,
R1 (AD), R2 (AB), R3 (BE), R4 (CDE), R5 (AE)
The initial tableau:
A B C D E
R1 (AD) 0 1 1 0 1
R2 (AB) 0 0 2 2 2
R3 (BE) 3 0 3 3 0
R4 (CDE) 4 4 0 0 0
R5 (AE) 0 5 5 5 0
Apply A → C for rows: 1, 2, 5 to equate 1, 2, 5. Choosing 1 as the representative
symbol (Figure below).

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 134/175
e.g. (cont.)

A B C D E
R1 (AD) 0 1 1 0 1
R2 (AB) 0 0 1 2 2
R3 (BE) 3 0 3 3 0
R4 (CDE) 4 4 0 0 0
R5 (AE) 0 5 1 5 0
{ }
F= A → C, B → C, C → D, DE → C, CE → A
Apply B → C for rows: 2, 3 to equate 1, 3. Choosing 1 as the representative symbol.
(Figure below)

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 135/175
e.g. (cont.)

A B C D E
R1 (AD) 0 1 1 0 1
R2 (AB) 0 0 1 2 2
R3 (BE) 3 0 1 3 0
R4 (CDE) 4 4 0 0 0
R5 (AE) 0 5 1 5 0
{ }
F= A → C, B → C, C → D, DE → C, CE → A
Apply C → D for roes: 1, 2, 3, 5 to equate 0, 2, 3, 5. The result symbol must be 0.
(Figure below)

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 136/175
e.g. (cont.)

A B C D E
R1 (AD) 0 1 1 0 1
R2 (AB) 0 0 1 0 2
R3 (BE) 3 0 1 0 0
R4 (CDE) 4 4 0 0 0
R5 (AE) 0 5 1 0 0
{ }
F= A → C, B → C, C → D, DE → C, CE → A
Apply DE → C for rows: 3, 4, 5 to equate 1 with 0.
(Figure below)

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 137/175
e.g. (cont.)

A B C D E
R1 (AD) 0 1 1 0 1
R2 (AB) 0 0 1 0 2
R3 (BE) 3 0 0 0 0
R4 (CDE) 4 4 0 0 0
R5 (AE) 0 5 0 0 0
{ }
F= A → C, B → C, C → D, DE → C, CE → A
Apply CE → A for rows: 3, 4, 5 to equate 3, 4, 0 must be with 0.
(Figure below)

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 138/175
e.g. (cont.)

A B C D E
R1 (AD) 0 1 1 0 1
R2 (AB) 0 0 1 0 2
R3 (BE) 0 0 0 0 0
R4 (CDE) 0 4 0 0 0
R5 (AE) 0 5 0 0 0

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 139/175
e.g. (cont.)

A B C D E
R1 (AD) 0 1 1 0 1
R2 (AB) 0 0 1 0 2
R3 (BE) 0 0 0 0 0
R4 (CDE) 0 4 0 0 0
R5 (AE) 0 5 0 0 0
The third row has all 0. Preserve information decomposition ■

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Tableau Test 140/175
Preserve Information Decomposition Theorem

Lossless Join Decomposition.

R , F;
{ }
ρ = R1 , R2 : Decomposition.
ρ has a recovered information decomposition if and only if:
• (R1 ∩ R2 ) → (R1 − R2 ) ∈ F+ , or
• (R1 ∩ R2 ) → (R2 − R1 ) ∈ F+
Note: Two FDs need not be in F; it can be in F+
Proof: The initial table is shown in below:
R1 ∩ R2 R1 − R2 R2 − R1
row for R1 0···0 0···0 1···1
row for R2 0···0 2···2 0···0

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Theorem 141/175

Theorem (cont.)

If (R1 ∩ R2 ) → (R1 − R2 ) ∈ F+ .
Result has the second row to be all 0.
R1 ∩ R2 R1 − R2 R2 − R1
row for R1 0···0 0···0 1···1
row for R2 0···0 0···0 0···0

If (R1 ∩ R2 ) → (R2 − R1 ) ∈ F+ .
Result has the first row to be all 0.
R1 ∩ R2 R1 − R2 R2 − R1
row for R1 0···0 0···0 0···0
row for R2 0···0 2···2 0···0
We has ρ Preserve information decomposition ■

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Theorem 142/175

e.g.
{ }
R(ABC) , F = A→B
1. R into R1 (AB) and R2 (AC): Preserve information.
Since R1 ∩ R2 = A ; R1 − R2 = B and A → B

2. R into R1 (AB) and R2 (BC): Not Preserve information.

Since R1 ∩ R2 = B , and:
• R1 − R2 = A and F ⊭ B → A
• R2 − R1 = C and F ⊭ B → C

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Theorem 143/175

e.g. (cont.)

R into R1 (AB) and R2 (BC): Not Preserve information.

Considering r(R) = {(1, 1, 1), (2, 1, 2)}

A B C
1 1 1
2 1 2

π AB (r) π BC (r)
A B B C
1 1 1 1
2 1 1 2

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Theorem 144/175

e.g. (cont.)
{ }
π AB (r) ⋊
⋉ π BC (r) = (1, 1, 1), (1, 1, 2), (2, 1, 1), (2, 1, 2)

A B C
1 1 1
1 1 2
2 1 1
2 1 2
This natural join is proper superset of r.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Theorem 145/175

Preserve Dependencise Decoposition

Preserve Dependencies
R , F.
{ }
R decomposed into ρ = R1 , R2 , · · · , Rn .
Decomposition ρ preserve F if the union of all the dependencies in π Ri (F), for i = 1..n
logically implies all the dependencies in F:
{ }
π R1 (F) ∪ π R2 (F) ∪ · · · ∪ π Rn (F) |= F, aka
∪
n
π Ri (F) |= F
i=1
Note: The converse is always true; F always implies all its projections, and therefore
implies their union.
∪
n
F |= π Ri (F)
i=1

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Preserve Dependencise 146/175
e.g.

Store(Category, Warehouse, Product), with

{ }
F = Product → Category; Category, Warehouse → Product
{ }
Key: K1 = {Category, Warehouse} ,
K2 = Warehouse, Product
Decopose Store into:
• R1 (Category, Product),
{ }
F1 = Product → Category , K = {Product}
• R2 (Product, Warehouse),
{ }
F2 = ∅, K = Product, Warehouse

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Preserve Dependencise 147/175
e.g. (cont.)

This is a reserve information, since: F |= (R1 ∩ R2 ) → (R1 − R2 )

But this decomposition does not preserve dependencies, since
F1 ∪ F2 ̸≡ F

R1 (Category Product) R2 (Product Warehouse)

1 1 1 1
1 2 2 1

However, this join violates FD:

Category, Warehouse → Product
Store (Category Warehouse Product)
1 1 1
1 1 2

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Preserve Dependencise 148/175
Testing Preserve Dependencies

R , F , ρ = {R1 , · · · , Rn }.
Easy to test ρ preserves F by:
1. Computing Fi = π Ri (F+ ).
∪
n
2. Test whether: Fi |= F ?
i=1

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Testing Preserve Dependencies 149/175
e.g.
{ }
R(ABCD) , F = A → B, B → C, C → D, D → A . Decomposition
{ }
ρ = R1 (AB), R2 (BC), R3 (CD)
Project F+ onto Ri , we get result:
{ }
F1 = A → B, B → A ,
{ }
F2 = B → C, C → B ,
{ }
F3 = C → D, D → C
∪
3
So Fi |= F
i=1

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Testing Preserve Dependencies 150/175
Preserve Information Decomposition into BCNF

Decomposition Algorithm
Input: R0 , F0 .
Output: A decomposition of R0 into a collection of relations, all of which are in BCNF.
Method: R = R0 and F = F0 .
Apply recursively < R, F >.
1. If R is in BCNF, return R. Done.
2. If R violated BCNF by X → Y (X is not a super key), decomposition R into
R1 (X+F ) and R2 (X ∪ (R − XF )).
+

3. Compute F1 = π R1 (F+ ), F2 = π R2 (F+ ).

4. Recursively decompose < R1 , F1 > and < R2 , F2 > using this algorithm.
5. Return the union of the results of these decompositions.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Decomposition Algorithm 151/175
e.g.

Instock(Product,
{ Category, Supply, Date, Quantity), with
F = Product → Category; Category
} → Supply;
Product, Date → Quantity
Key = {Product, Date} and Instock is in 1NF.
1. R = Instock
R violated BCNF
{ by Product → Category}
+
Product = Product, Category, Supply
R1 (Product,
{ Category, Supply), }
F1 = Product
{ → } Category; Category → Supply
Key = Product , violated BCNF by Category → Supply
R2 (Product
{ ∪ (R − Product+ )), R}2 (Product, Date, Quantity)
F2 = Product,
{ Date →} Quantity
Key = Product, Date , it is in BCNF.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Decomposition Algorithm 152/175
e.g. (cont.)

2. R1 (Product,
{ Category, Supply) }
F1 = Product
{ →} Category; Category → Supply
Key = Product { , violated BCNF } by Category → Supply
Category+ = Category, Supply
R11 (Category,
{ Supply) }
F11 = {Category → } Supply
Key = Category , it is in BCNF.
R12 (Product,
{ Category) }
F12 = {Product → } Category
Key = Product , it is in BCNF.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Decomposition Algorithm 153/175
e.g. (cont.)

Renumber relation in BCNF result:

R1 (Category,
{ Supply), in BCNF
}
F1 = Category
{ →} Supply
Key = Category
R2 (Product,
{ Category), in BCNF
}
F2 = Product
{ →} Category
Key = Product
R3 (Product,
{ Date, Quantity), in BCNF
}
F3 = Product,
{ Date →} Quantity
Key = Product, Date
This result can be show by tree below.
With Product = P; Category = C; Supply = S; Date = D; Quantity = Q.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Decomposition Algorithm 154/175
e.g. (cont.)

R({
PCSDQ); Key = PD; 1NF }
F = P → C; C → S; PD → Q
P→C

R1 (PCS
{ ); Key = P; 2NF
} R2 (PDQ); Key
F1 = P → C; C → S { = PD;}BCNF
F2 = PD → Q
C→S

R11 (CS); Key

{ = C; }BCNF R12 (PC); Key
{ = P; }BCNF
F11 = C → S F12 = P → C

Notice: This algorithm decomposition into BCNF, its preserve information but not
sure about preserve FDs.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Decomposition Algorithm 155/175
Preserve Information Decomposition into 3NF

Synthesis Algorithm
It decompose into 3NF Relations With preserve information and dependency.
Input: R , F
Output: Decomposition ρ, each of which is in 3NF. It has preserve information and
dependency.
Method: Perform the following steps:
1. Find a minimum cover of F, say Fc .
2. For each X → A ∈ Fc , use XA as the scheme of one of the relations in the
decomposition.
3. If none of the relation schemes from Step 2 is a superkey of R, add another
relation whose scheme is a key of R.

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Synthesis Algorithm 156/175
e.g.
{ }
R(ABCDE) , F = AB → C, C → B, A → D
F is also a minimum cover. So we have:
R1 (ABC) , R2 (BC) , R3 (AD).
Not to use a relation whose is a proper subset of another relation, so we can drop R2 .
R has two keys: K1 = ABE and K2 = ACE.
Neither of these keys is a subset of the schemes chosen so far. Thus, we must add one
of them, say R4 (ABE).
The final decomposition of R is thus:
{ }
R1 (ABC); F1 = { AB → C, } C→B ; 3NF
R2 (BC); F2 = { C → B }; BCNF
R3 (AD); F3 = A → D ; BCNF
R4 (ABE); F4 = ∅; BCNF

Nguyễn Văn Diêu 3. Logical Design :: Database Normalization :: Synthesis Algorithm 157/175
Overview

Objectives of physical design:

• How to translate entities into physical tables
• What attributes to use for columns of the physical tables
• Which columns of the tables to define as keys
• What indexes to define on the tables
• What views to define on the tables
• How to denormalize the tables
• How to resolve many-to-many relationships
• What designs can take advantage of hash access

Nguyễn Văn Diêu 4. Physical Design :: Overview 158/175

Conceptual to Physical

The following steps convert from conceptual model to physical model:

1. ERD to Relational model
2. Conceptual to Functional dependencies
3. Normorlization

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical 159/175

Problem

• A construction materials store wants to manage Product including names and unit
prices.
• List of ordering customers or potential customers with customer name and
address information.
• Every time an order is placed by a customer, the order needs to store the order
date, pick-up date, and customer. Order along with a list of products ordered and
quantity ordered.
• When delivery is due, issue a delivery invoice knowing that each order can be
delivered in multiple deliveries with different delivery quantities and each Order
there is an invoice for billing.
• The unit price at delivery may be different from the reference price in stock at the
time of ordering.

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Problem 160/175

ERD

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: ERD 161/175

Relational Model

• Customer(Customer ID, Customer Name, Address)

• Order(Order ID, Order Date, Required Date, Customer ID)
• Product(Product ID, Product Name, Product Unit Price)
• Order Detail(Order ID, Product ID, Order Quantity)
• Invoice(Invoice ID, Invoice Date)
• Invoice Detail(Invoice ID, Order ID, Product ID, Invoice Unit Price,
Invoice Quantity)

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Relational Model 162/175
Functional Dependencies

• Custemer ID → Customer Name, Address

• Order ID → Order Date, Required Date
• Order ID → Customer ID
• Product ID → Product Name, Product Unit Price
• Order ID, Product ID → Order Quantity
• Invoice ID → Invoice Date
• Invoice ID → Order ID
• Invoice ID, Order ID, Product ID → Invoice Unit Price, Invoice Quantity
• Invoice ID, Product ID → Invoice Unit Price, Invoice Quantity

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Relational Model 163/175
Normal Form

• Customer(Customer ID, Customer Name, Address) BCNF

• Order(Order ID, Order Date, Required Date, Customer ID) BCNF
• Product(Product ID, Product Name, Product Unit Price) BCNF
• Order Detail(Order ID, Product ID, Order Quantity) BCNF
• Invoice(Invoice ID, Invoice Date) BCNF
• Invoice Detail(Invoice ID, Order ID, Product ID, Invoice Unit Price,
Invoice Quantity) 1NF

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Normal Form 164/175
Normalization

Normalization for:
• Invoice Detail(Invoice ID, Order ID, Product ID, Invoice Unit Price,
Invoice Quantity) 1NF
Result:
• R1 (Invoice ID, Order ID) BCNF
• R2 (Invoice ID, Product ID, Invoice Unit Price, Invoice Quantity) BCNF

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Normalization 165/175

Result of Normalization

• Customer(Customer ID, Customer Name, Address) BCNF

• Order(Order ID, Order Date, Required Date, Customer ID) BCNF
• Product(Product ID, Product Name, Product Unit Price) BCNF
• Order Detail(Order ID, Product ID, Order Quantity) BCNF
• Invoice(Invoice ID, Invoice Date, Order ID) BCNF
• Invoice Detail(Invoice ID, Product ID, Invoice Unit Price, Invoice
Quantity) BCNF

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Normalization 166/175

Customize Name for SQL

• Customer(CustomerID, CustomerName, Address)

• Order(OrderID, OrderDate, RequiredDate, CustomeID)
• Product(ProductID, ProductName, ProductUnit Price)
• Order Detail(Order ID, Product ID, Order Quantity)
• Invoice(InvoiceID, InvoiceDate, OrderID)
• InvoiceDetail(InvoiceID, ProductID, InvoiceUnitPrice, InvoiceQuantity)

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Customize Name 167/175
Foreign Keys

• Customer(CustomerID, CustomerName, Address)

• Order(OrderID, OrderDate, RequiredDate, CustomeID)
• Product(ProductID, ProductName, ProductUnitPrice)
• OrderDetail(OrderID, ProductID, OrderQuantity)
• Invoice(InvoiceID, InvoiceDate, OrderID)
• InvoiceDetail(InvoiceID, ProductID, InvoiceUnitPrice, InvoiceQuantity)

Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: Foreign Keys 168/175
SQL Script

Create table Customer

(
CustomerID char(3) primary key,
CustomerName varchar(30),
Address varchar(30)
);
Create table Order
(
OrderID char(3) primary key,
OrderDate date,
RequiredDate date,
CustomerID char(3) not null,
foreign key (CustomerID) references Customer(CustomerID)
);
Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: SQL Script 169/175
SQL Script

Create table Product

(
ProductID char(3) primary key,
ProductName varchar(30),
ProductUnitPrice float
);
Create table OrderDetail
(
OrderID char(3), ProductID char(3),
OrderQuantity float,
primary key (OrderID, ProductID),
foreign key (OrderID) references Order(OrderID),
foreign key (ProductID) references Product(ProductID),
);
Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: SQL Script 170/175
SQL Script

Create table Invoice

(
InvoiceID char(3) primary key,
InvoiceDate date,
OrderID char(3) not null,
foreign key (OrderID) references Order(OrderID),
);
Create table InvoiceDetail
(
InvoiceID char(3), ProductID char(3), InvoiceUnitPrice float, InvoiceQuantity float,
primary key (InvoiceID, ProductID),
foreign key (InvoiceID) references Invoice(InvoiceID),
foreign key (ProductID) references Product(ProductID),
);
Nguyễn Văn Diêu 4. Physical Design :: Conceptual to Physical :: SQL Script 171/175
Denormalization

• The rules of normalization do not consider performance.

• In some cases, you need to consider denormalization to improve performance.
e.g.
• Customer(CustomerID, CustomerName, Address)
• Order(OrderID, OrderDate, RequiredDate, CustomeID)
Change:
• Customer(CustomerID, CustomerName, Address)
• Order(OrderID, OrderDate, RequiredDate, CustomeID, Address)
Pros: Don’t waste time connecting, quickly retrieve customer addresses
Cons: Order: 2NF ⇒ Check: CustomerID → Address;
data redundancy and inconsistency

Nguyễn Văn Diêu 4. Physical Design :: Denormalization 172/175

Customized data views

• No single table contains all the data that we need.

• Data might be scattered among several tables.
• One table might contain more data than users want to see or more than you want
to authorize them to see. For those situations, you can create views.
Using views for a variety of reasons:
• To limit access to certain kinds of data
• To combine data from multiple tables
e.g.
CREATE VIEW OrderIncome AS
SELECT OrderID, CustomerName, SUM(OrderQuantity * ProductUnitPrice) Total
FROM OrderDetails INNER JOIN Orders USING (OrderID)
INNER JOIN Customer USING (CustomerID)
GROUP BY OrderID ;
Nguyễn Văn Diêu 4. Physical Design :: Customized data views 173/175
Indexes

Using indexes:
• To optimize data access
Accessing to data is faster with an index than without an index.
• To ensure uniqueness
A table with a unique index cannot have two rows with the same values in the
column or columns that form the index key.
• To enable clustering
When indexing, similar values will partition, optimizing page access for data.

Nguyễn Văn Diêu 4. Physical Design :: Indexes 174/175

e.g.

MySQL: CREATE INDEX Statement

Nguyễn Văn Diêu 4. Physical Design :: Indexes 175/175