Database Design

Nguyễn Văn Diêu

Ho Chi Minh City University of Transport

2023

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/248
Outline II

Strong Entity
Weak entity and Identifying Relationship
Weak Entity connected Weak Entity
Update Methodology
Mapping Weak Entity to Rational Database
2.6 Extensions with Binary Relationships
Attributes of Relationship
M:N Relationship
More Entity and Relationship
2.7 Recursive Relationship
Structural Constraints
Multiple Relationship
2.8 Mapping Recursive Relationship
2.9 Derived or Redundant Relationship
2.10 Enhanced EntityRelationship (EER) Model

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

Outline III

Generalization and Specialization

Subclasses of Subclasses
Mapping rules
2.11 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

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

Outline IV

3.3 Closure
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

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

Outline V

FDs by Keys
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

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

Outline VI

Tableau Test
Theorem
Preserve Dependencise
Testing Preserve Dependencies
Decomposition Algorithm
Synthesis Algorithm
3.7 Multivalued Dependencies
Overview
Definition
Lemma
Trivial MVDs
Theorem
Test MVDs
3.8 Axioms for MVDs
MVDs Alone
FDs and MVD

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

Outline VII

Finding X+F by Chase

Tableau Chase Test for MVDs
Projecting MVDs
Minimum Dependency Basis
Beeri Algorithm
3.9 4NF
Definition
Lemma
Decomposition into 4NF
3.10 Join Dependency
Overview
Definition
Project Join NF
Definition
3.11 Embedded Functional Dependencies
Definition

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

Outline VIII

Embedded MVDs
Embedded JD

4. Physical Design
4.1 Overview
4.2 Conceptual to Physical
Problem
ERD
Relational Model
Normal Form
Normalization
Customize Name
Foreign Keys
SQL Script
4.3 Denormalization
4.4 Customized data views

Nguyễn Văn Diêu Table of Contents 9/248

Outline IX

4.5 Indexes

Nguyễn Văn Diêu Table of Contents 10/248

Main phases of Database design

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

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 12/248
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 13/248

ER Conceptual Model

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

ER Conceptual Model

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

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 16/248

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 17/248
Pattern 1

1(full):1 Relationship

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

M(full):1 Relationship

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

1(partial):1 Relationship

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

M(partial):1 Relationship

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

1(full):M Relationship

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

M(full):N Relationship

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

1(partial):M Relationship

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

M(partial):N Relationship

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

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

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

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

• Step 1. Select one primary entity from the database requirements description and
show attributes to be recorded for that entity. Label key if appropriate, and show
some sample data.
• Step 2. Use structured English for entities, attributes, and keys to describe the
database.
• Step 3. Examine attributes in the primary entity (possibly with user assistance)
to find out if information about one of the attributes is to be recorded.
• Step 3a. If information about an attribute is needed, then make the attribute an
entity, and then
• Step 3b. Define the relationship back to the original entity.
• Step 4. If another entity is appropriate, draw the second entity with its attributes.
Repeat step 2 to see if this entity should be further split into more entities.

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

ER Design Methodology

• Step 5. Connect entities with relationships if relationships exist.

• Step 6. State the exact nature of the relationships in structured English from all
sides; for example, if a relationship is A:B::1:M, then there is a relationship from
A(1) to B(M) and from B(M) back to A(1).
• Step 7. Present the “as designed” database to the user complete with the English
for entities, attributes, keys, and relationships. Refine the diagram as necessary.
• Step 8. Show some sample data.

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

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:
Step 1. Select one primary entity from the database requirements description and
show attributes to be recorded for that entity. Label keys if appropriate and show some
sample data.
Suppose we choose PASSENGERS as our primary entity. PASSENGERS has the
following attributes: frequent_flier_no, name [frst, middle, last], luggage_pieces.

Nguyễn Văn Diêu 2. Conceptual Design :: Example 31/248

Example

Step 2. Use structured English for entities, attributes, and keys to describe the elicited
database.
Step 3. Examine attributes in the primary entity (possibly with user assistance) to find
out if information about one of the attributes is to be recorded.

Nguyễn Văn Diêu 2. Conceptual Design :: Example 32/248

Example

Step 4. If another entity is appropriate,

draw the second entity with its attributes.
Repeat step 2 to see if this entity should be
further split into more entities.
Step 5. Connect entities with relationships
if relationships exist.

Nguyễn Văn Diêu 2. Conceptual Design :: Example 33/248

Example

Step 6. State the exact nature of the relationships in structured English from all sides,
such as, if a relationship is A:B::1:M, then there is a relationship from A(1) to B(M)
and from B(M) back to A(1).
Step 7. Present the “as designed” database to the user complete with the English for
entities, attributes, keys, and relationships. Refine the diagram, as necessary.
Step 8. Show some sample data.

Nguyễn Văn Diêu 2. Conceptual Design :: Example 34/248

Example

Nguyễn Văn Diêu 2. Conceptual Design :: Example 35/248

Mapping Entity to Relation

Mapping rule 1: Mapping strong entities. Develop a new table (relation) for each
strong entity and make the indicated key of the strong entity the primary key of the
table. If more than one candidate key is indicated on the ER diagram, choose one for
the primary key. Call this table, TABLE1.
Mapping rule 2: Mapping atomic attributes. For entities with atomic attributes, map
the entities to a table and form columns for each atomic attribute. Here we’d map the
atomic attributes associated with TABLE1 into it.

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

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

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

Mapping rule 3: Mapping composite attributes. For entities with composite

attributes, map entities to a table and form columns of each elementary (atomic) part
of the composite attributes.

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

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

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

Mapping rule 4: Mapping multivalued attributes. Form a separate table for the
multivalued attribute. Record a row for each value of the multivalued attribute
together with the key from the original table. The key of the new table will be the
concatenation of the multivalued attribute plus the key of the owner entity. Remove
the multivalued attribute from the original table.

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

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 41/248
Mapping Relationship to Relation

Mapping rule 5: Mapping binary M:N relationships. For each M:N relationship,
create a new table (relation) with the primary keys of each of the two entities (owner
entities) related in the M:N relationship. The primary key of this new table will be the
concatenated keys of the owner entities. Include any attributes the M:N relationship
may have in this new table.

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

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 43/248
Mapping Relationship to Relation

Mapping rule 6: Mapping a binary 1:1 relationship when one side of the relationship
has full participation and the other has partial participation. When one of the sides of
the relationship has full participation and the other has partial participation, then store
the primary key of the side with the partial participation constraint on the side with
the full participation constraint as a foreign key. Include any attributes on the
relationship on the same side to which the key was added.

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

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 45/248
Mapping Relationship to Relation

Mapping rule 7: Mapping a binary 1:1 relationship when both sides have partial
participation constraints.
When both sides have partial participation constraints in a binary 1:1 relationship, the
relationships can be mapped in one of two ways.
Mapping rule 7A: Select either one of the relations to store the key of the other.

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

AUTOMOBILE( vehicle_id, make,

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

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

Mapping rule 7B:. Depending on the semantics of the situation, you can create a
new relation to house the relationship to contain the key of the two related entities.

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 48/248
Mapping Relationship to Relation

Mapping rule 8: Mapping a binary 1:1 relationship when both sides have full
participation constraints. Use the semantics of the relationship to select which of the
relations should contain the key of the other. If this choice is unclear, then use
mapping rule 7B.

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

Mapping rule 9: 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.

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

if we assume full participation on the

student side, we will have:
• Dorm rooms may have zero or more
students.
• Student must live in only and only
one dorm room.
STUDENT(student_number,
name.first, name.mid,
name.last, address,
dname)
DORM(dname, superviser)

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

Mapping rule 10: Mapping binary 1:N relationships when the N side has partial
participation. This situation would be handled just like a binary M:N relationship with
a separate table for the relationship. The key of the new relation would consist of a
concatenation of the keys of the related entities. Include any attributes on the
relationship on this new table.

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

Strong entities almost always have a unique identifer that is a subset of all the
attributes.
e.g.

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

Sample data:

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Strong Entity 54/248
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.
• Te 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 55/248
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 56/248
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 57/248
Methodology (+ Weak Entity)

Step 3. Examine attributes in the primary entity (possibly with user assistance) to find
out if information about one of the attributes is to be recorded.
Step 3a. If information about an attribute is needed, then make the attribute an
entity, and then
Step 3b. Define the relationship back to the original entity.
So, we add
Step 3c. If the new entity depends entirely on another entity for its existence, then
draw the entity as weak (double boxed) and show the connection to the identifying
entity as a double diamond. The participation of the weak entity in the relationship is
full. Dash underline the partial key identifier(s) in the weak entity.

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Update Methodology 58/248
Methodology (+ Weak Entity)

Step 4. If another entity is appropriate, draw the second entity with its attributes.
Repeat step 2 to see if any attributes should be further split into more entities.
Step 4a. If the additional entity or entities do not have candidate keys, then draw
them as weak entities (as explained in step 3c) and show the connection to an
identifying entity. The participation of the weak entity in the relationship is full or
mandatory. Dash or dot underline the partial key identifier(s) in the weak entity.

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Update Methodology 59/248
Mapping Weak Entity to Relational DB

Mapping Rule 11: Mapping weak entities. Develop a new table (relation) for each
weak entity. As is the case with the strong entity, include any atomic attributes from
the weak entity in the table.
If there is a composite attribute, include only the atomic parts of the composite
attribute and be sure to qualify the atomic parts in order not to lose information. To
relate the weak entity to its owner, include the primary key of the owner entity in the
weak relation. The primary key of the weak relation will be the partial key of the weak
entity concatenated to the primary key of the owner entity.
If a weak entity owns other weak entities, then the weak entity connected to the strong
entity must be mapped first. The key of the weak owner-entity has to be defined
before the “weaker” entity (the one furthest from the strong entity) can be mapped.

Nguyễn Văn Diêu 2. Conceptual Design :: Weak Entity :: Mapping Weak Entity to Rational Database 60/248
Mapping

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 61/248
Attributes of Relationship

Relationship attributes may occur

with an ER diagram containing
any cardinality, but one will most
often find relationship attributes in
the binary, M:N model.

Nguyễn Văn Diêu 2. Conceptual Design :: Extensions with Binary Relationships :: Attributes of Relationship 62/248
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 :: Extensions with Binary Relationships :: M:N Relationship 63/248
More Entity and Relationship

Update Methodology:
Step 4. If another entity is appropriate, draw the second entity with its attributes.
Repeat step 2 to see if this entity should be further split into more entities.
Step 5. Connect entities with relationships (one or more) if relationships exist.

Nguyễn Văn Diêu 2. Conceptual Design :: Extensions with Binary Relationships :: More Entity and Relationship 64/248
More Entity and Relationship

Te relationship between
INSTRUCTOR and COURSE is
teach; instructors teach many
courses, and a course is taught by
an instructor.
We add relationship teach.

Nguyễn Văn Diêu 2. Conceptual Design :: Extensions with Binary Relationships :: More Entity and Relationship 65/248
More Entity and Relationship

Nguyễn Văn Diêu 2. Conceptual Design :: Extensions with Binary Relationships :: More Entity and Relationship 66/248
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 67/248

One to One Recursive Relationship

e.g.

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

e.g.

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

e.g.

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

e.g.

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

Mapping Rule 12: 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)
Mapping Rule 13: Mapping M:N recursive relationships. Create a separate table for
the relationship (as in mapping rule 5).

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

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 73/248

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

2. Conceptual Design :: Enhanced EntityRelationship (EER) Model :: Generalization and

Nguyễn Văn Diêu Specialization 74/248
Generalization or Specialization

2. Conceptual Design :: Enhanced EntityRelationship (EER) Model :: Generalization and

Nguyễn Văn Diêu Specialization 75/248
Generalization or Specialization

2. Conceptual Design :: Enhanced EntityRelationship (EER) Model :: Generalization and

Nguyễn Văn Diêu Specialization 76/248
Subclasses of Subclasses

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

Nguyễn Văn Diêu 2. Conceptual Design :: Enhanced EntityRelationship (EER) Model :: Subclasses of Subclasses 78/248
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) Model :: Mapping rules 79/248
Union Types

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

Union Types

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

Union Types

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

Union Types

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

Union Types

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

Union Types

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

Mapping rules to Relation

Generalizations have the same primary keys

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

Generalizations have diferent primary keys

• Generalizations: New Relations with foreign key to be PK of specialization
• Specialization: New Relation with

Nguyễn Văn Diêu 2. Conceptual Design :: Union Types :: Mapping rules 86/248
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 87/248

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 88/248

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 89/248

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 90/248

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 91/248
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 92/248
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 93/248

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 94/248
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 95/248
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 96/248

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 97/248

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 98/248

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 99/248

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 100/248
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 101/248
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 102/248
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 103/248

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 104/248

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 105/248

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 106/248

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 107/248

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 108/248
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 109/248

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 110/248

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 111/248

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 112/248

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 113/248

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 114/248

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 115/248

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 116/248
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 117/248

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 118/248

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 119/248

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 120/248

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 121/248

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 122/248
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 123/248

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 124/248

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 125/248

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 126/248

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 127/248

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 128/248

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 129/248

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 130/248

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 131/248

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 132/248

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 133/248
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 134/248
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 135/248

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 136/248

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 137/248
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 138/248
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 139/248
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 140/248
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 141/248
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 142/248

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 143/248
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 144/248
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 145/248

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 146/248
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 147/248
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 148/248
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 149/248
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 150/248
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 151/248
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 152/248
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 153/248
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 154/248
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 155/248
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 156/248
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 157/248
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 158/248
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 159/248
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 160/248
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 161/248
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 162/248
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 163/248

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 164/248

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 165/248

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 166/248

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 167/248

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 168/248
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 169/248
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 170/248
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 171/248
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 172/248
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 173/248
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 174/248
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 175/248
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 176/248
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 177/248
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 178/248
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 179/248
Overview

Supply(Name, Item, Delivery)

Supply (Name Item Delivery)

Amazon Laptop Moto
Amazon Washer Moto
Amazon Laptop Pick-Up
Amazon Washer Pick-Up
McD Hamb Drone
McD Hamb Scooter

∗ (n, i, d) ∈ Supply: supply name n supplied item i and can use delivery type t for
that item.
∗ There is no FDs Name → Item or Name → Delivery on Supply,
yet Supply decomposes losslessly onto:
(Name, Item) and (Name, Delivery).
Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Overview 180/248
Overview (cont.)

SupItem (Name Item) SupDeli (Name Delivery)

Amazon Laptop Amazon Moto
Amazon Washer Amazon Pick-Up
McD Hamb McD Drone
McD Scooter

SupItem ⋊
⋉ SupDeli (Name Item Delivery)
Amazon Laptop Moto
Amazon Laptop Pick-Up
Amazon Washer Moto
Amazon Washer Pick-Up
McD Hamb Drone
McD Hamb Scooter

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Overview 181/248

Overview (cont.)

Another instance of the relation Supply:

Supply (Name Item Delivery)
Amazon Laptop Moto
Amazon Washer Moto
Amazon Washer Pick-Up
McD Hamb Drone
McD Hamb Scooter
Like above instance, if we decompose this instance onto:
(Name, Item) and (Name, Delivery).

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Overview 182/248

Overview (cont.)

And join the two projections, we do not get back original instance.

SupItem (Name Item) SupDeli (Name Delivery)

Amazon Laptop Amazon Moto
Amazon Washer Amazon Pick-Up
McD Hamb McD Drone
McD Scooter
SupItem ⋊
⋉ SupDeli (Name Item Delivery)
Amazon Laptop Moto
Amazon Laptop Pick-Up
Amazon Washer Moto
Amazon Washer Pick-Up
McD Hamb Drone
McD Hamb Scooter
Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Overview 183/248
Multivalued Dependencies

Difference of two instance above is in the first instance:

If t1 (n, i, d), t2 (n, i’, d’), then t3 (n, i’, d).
Definition R(XYZ); X, Y be disjoint subsets of R, and
Z = R − (XY).
r(R) satisfies the multivalued dependency (MVD) X ↠ Y
if ∀(t1 , t2 ) ∈ r(R): t1 .X = t2 .X
∃ t3 ∈ r(R): t3 .X = t1 .X = t2 .X,
t3 .Y = t1 .Y, and
t3 .Z = t2 .Z.
The symmetry of t1 and t2 in this definition implies:
∃ t4 ∈ r(R): t4 .X = t1 .X = t2 .X,
t4 .Y = t2 .Y, and
t4 .Z = t1 .Z.
Notice: Dislike FD, this definition concern one r(R) not ∀r(R).
Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Definition 184/248
Definition (cont.)

Suppose r on R(XYZ) satisfies the MVD X ↠ Y

Representation of the definition below for easy remember:

r (R: X Y Z) r (R: X Y Z)
t1 : 1 1 1 t1 : x y z
t2 : 1 2 2 t2 : x y’ z’
t3 : 1 1 2 t3 : x y z’
t4 : 1 2 1 t4 : x y’ z

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Definition 185/248

Definition (cont.)

Note 1: The X ↠ Y says that the relationship between X and Y is independent of the
relationship between X and (R − Y).

Note 2: X ↠ Y holds in R if whenever we have:

• (t1 , t2 ) ∈ r(R): t1 (X) = t2 (X), then
• We can swap two values t1 (Y) and t2 (Y) and get new (t3 , t4 ) that are also ∈ r(R).

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Definition 186/248

Lemma

Relation r(R) satisfies the X ↠ Y:

1. Z = R − XY, then r(R) satisfies X ↠ Z.
2. If X, Y are not disjoin: Y′ = Y − X, then X ↠ Y′
3. X′ ⊆ X, then X ↠ X′ Y
Proof
1. Easy to see when we change role of Y and Z
2. Z = R − (XY) = R − (XY′ )
Since X ↠ Y
∀ (t1 , t2 ) ∈ r(R): t1 .X = t2 .X
∃t3 : t3 .X = t1 .X = t2 .X,
t3 .Y = t1 .Y and t3 .Z = t2 .Z
Since Y′ ⊆ Y, so that t3 .Y = t1 .Y ⇒ t3 .Y′ = t1 .Y′
Definition implies r(R) satisfies X ↠ Y′ ■
Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Lemma 187/248
Lemma (cont.)

Relation r(R) satisfies the X ↠ Y:

1. Z = R − XY, then r(R) satisfies X ↠ Z.
2. If X, Y are not disjoin: Y′ = Y − X, then X ↠ Y′
3. X′ ⊆ X, then X ↠ X′ Y
Proof
3. Z = R − (XX′ Y) = R − (XY)
Since X ↠ Y
∀ (t1 , t2 ) ∈ r(R): t1 .X = t2 .X
∃t3 : t3 .X = t1 .X = t2 .X,
t3 .Y = t1 .Y and t3 .Z = t2 .Z
Since X′ ⊆ X, so that t3 .X′ = t1 .X′ , then t3 .X′ Y = t1 .X′ Y
Definition implies r(R) satisfies X ↠ X′ Y ■

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Lemma 188/248

e.g.

r(R : ABCD) shown below satisfies the AB ↠ BC, hence it satisfies the AB ↠ D,
AB ↠ C and AB ↠ ABC
r (R: A B C D)
t1 : 1 1 1 1
t2 : 1 1 2 2
t3 : 1 1 1 2
t4 : 1 1 2 1
t5 : 1 2 2 1
t6 : 2 1 1 2

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Lemma 189/248

Trivial MVDs

Definition
− R and X, Y ⊆ R
− MVD X ↠ Y is trivial if any relation r(R) satisfies X ↠ Y.
− So that
• Y ⊆ X or
• XY = R

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Trivial MVDs 190/248
Theorem

R, X ⊆ R, Y ⊆ R, Z = R − (XY)
r(R) satisfies the X ↠ Y {
r1 : R1 (XY)
⇔ r(R) reserve information decomposition into Proof
r2 : R2 (XZ)

r(XYZ), r1 = π XY (r), r2 = π XZ (r)

r: X ↠ Y ⇔ r = r1 ⋊
⋉ r2

1 ”⇒”: r : X ↠ Y ⇒ r = r1 ⋊ ⋉ r2
{
r ⊆ r1 ⋊
⋉ r2 ,
i.e. r : X ↠ Y ⇒
r1 ⋊
⋉ r2 ⊆ r

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Theorem 191/248

Theorem (cont.)

1.a r ⊆ r1 ⋊⋉ r2
i.e. ∀t ∈ r ⇒ t ∈ r1 ⋊⋉ r2 . This is evident without to MVD:
∀t ∈ r 
t1 = t.XY ⇒ t1 ∈ π XY (r) 
⇒ t1 ⋊ ⋉ t2 ∈ π XY (r) ⋊
⋉ π XZ (r)
t2 = t.XZ ⇒ t2 ∈ π XZ (r) 
Since t = t1 ⋊⋉ t2 ⇒ t ∈ r1 ⋊ ⋉ r2 .
1.b r1 ⋊⋉ r2 ⊆ r
i.e ∀t ∈ r1 ⋊
⋉ r2 ⇒{ t ∈ r.
∃t1 ∈ r1 ,
∀t ∈ r1 ⋊⋉ r2 ⇒ : t = t1 ⋊
⋉ t2
∃t2 ∈ r2



 t.XY = t1 ,
i.e. t.XZ = t2 ,


 t1 .X = t2 .X
Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Theorem 192/248
Theorem (cont.)

So we have:


 t.X = t1 .X = t2 .X, (1)

t.Y = t1 .Y, (2)


 t.Z = t2 .Z (3)

t1 ∈ π XY (r) ⇒ ∃t′1 ∈ r : t′1 .XY = t1 (4)

t2 ∈ π XZ (r) ⇒ ∃t′2 ∈ r : t′2 .XZ = t2 (5)
(4,1,5) ⇒ t′1 .X = t1 .X = t2 .X = t′2 .X
⇒ t′1 .X = t′2 .X
}
(4) ⇒ t′1 .Y = t1 .Y
⇒ t.Y = t′1 .Y
(2)

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Theorem 193/248

Theorem (cont.)
}
(5) ⇒ t′2 .Z = t2 .Z
⇒ t.Z = t′2 .Z
(3)
We have:


 ∃(t′1 , t′2 ) ∈ r, t′1 .X = t′2 .X


 ∃t ∈ r, t.X = t′ .X = t′ .X
1 2

 t.Y = ′
t1 .Y


 t.Z = t′2 .Z

This is the definition of MVD X ↠ Y holds on r : R(XYZ).

t satisfied all requirements above so that t ∈ r.

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Theorem 194/248

Theorem (cont.)

2 ”⇐”: r = r1 ⋊
⋉ r2 ⇒ r : X ↠ Y
∀(t1 , t2 ) ∈ r : t1 .X = t2 .X
∃t′1 ∈ (r1 = π XY (r)) : t′1 = t1 .XY (1)
∃t′2 ∈ (r2 = π XZ (r)) : t′2 = t2 .XZ (2)
Since r = r1 ⋊
⋉ r2 , so:
∃t ∈ r : t = t′1 ⋊
⋉ t′2
So that,
since (1): t.XY = t′1 = t1 .XY (3)
since (2): t.XZ = t′2 = t2 .XZ (4)
(3) ⇒ t.X = t1 .X, t.Y = t1 .Y (5)
(4) ⇒ t.X = t2 .X, t.Z = t2 .Z (6)
Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Theorem 195/248
Theorem (cont.)

All above we have:



 ∀(t1 , t2 ) ∈ r : t1 .X = t2 .X


 ∃t : t.X = t .X = t .X
1 2

 (5) ⇒ t.Y = t1 .Y


 (6) ⇒ t.Z = t .Z
2

Follow definition r satisfied X ↠ Y on r : R(XYZ) ■

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Theorem 196/248

Test MVDs

r : R(XYZ):
1. Theorem 3.6 gives us a method to test if a relation r(R) satisfies X ↠ Y:
1. r1 = π XY (r), r2 = π XZ (r)
2. Test if r = r1 ⋊
⋉ r2 ?
2. Another method: Use only some sorting and counting.
1. Given X-value x:
2. n1 : tuples in r1 with X-value x
3. n2 : tuples in r2 with X-value x
4. n: tuples in r with X-value x
5. If n = n1 × n2 for any X-value x, then r = r1 ⋊
⋉ r2

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Test MVDs 197/248
Test MVDs (cont.)

Define the function counts the number of different W-values associated with a given
X-value in r.

CW [X = x](r) = |π W (σ X=x (r))|

The condition for X ↠ Y can be stated as:

For any X-value x in r:

CR [X = x](r) = CXY [X = x](r) × CXZ [X = x](r)

Since CWX [X = x](r) = CW [X = x](r), we can simplify to:

CR [X = x](r) = CY [X = x](r) × CZ [X = x](r)

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Test MVDs 198/248
e.g.

R(ABCD) , Test AB ↠ C

r (R: A B C D)
t1 : 1 1 1 1
t2 : 1 1 2 2
t3 : 1 1 1 2
t4 : 1 1 2 1
t5 : 1 2 2 1
t6 : 2 1 1 2

CABCD [AB = 11](r) = 4; CC [AB = 11](r) = 2; CD [AB = 11](r) = 2

CABCD [AB = 12](r) = 1; CC [AB = 12](r) = 1; CD [AB = 12](r) = 1
CABCD [AB = 21](r) = 1; CC [AB = 21](r) = 1; CD [AB = 21](r) = 1

Nguyễn Văn Diêu 3. Logical Design :: Multivalued Dependencies :: Test MVDs 199/248
Inference Axioms MVDs Alone

r(R) ; W, X, Y, Z be subsets of R.
M3. Transitivity
M1. Reflexivity }
X↠Y
Y ⊆ X |= X ↠ Y |= X ↠ Z − Y
Y↠Z
M2. Augmentation
} M4. Additivity
X↠Y }
|= XZ ↠ YW X↠Y
W⊆Z |= X ↠ YZ
X↠Z

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: MVDs Alone 200/248
Inference Axioms MVDs Alone (cont.)

M5. Decomposition

}  
X↠Y  X↠Y∩Z
|= X↠Y−Z
X↠Z 

 X↠Z−Y

M6. Pseudo Transitivity

}
X↠Y
|= XW ↠ Z − (YW)
WY ↠ Z
M7. Complementation
}
X↠Y
|= X ↠ Z
Z = R − (XY)

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: MVDs Alone 201/248
Inference Axioms FDs and MVDs

r(R) ; W, X, Y, Z be subsets of R.
C1. Replication
X → Y |= X ↠ Y
C2. Coalescence

X↠Y 


∃W, W ∩ Y = ∅ 
|= X → Z
W→Z 


Z⊆Y

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: FDs and MVD 202/248
e.g.
{ }
R(ABCDE) , D = A → BC, DE ↠ C
D |= A ↠ BDE ?
A → BC |= A ↠ BC (C1)
A ↠ BC |= A ↠ DE (M7)
}
A ↠ DE
|= A ↠ C (M3)
DE ↠ C
A ↠ C |= A ↠ BDE (M7) ■

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: FDs and MVD 203/248
Finding X+
F by Chase

R , F , X ⊆ R;
Compute X+ F all attributes that functionally depend on X.

1 Start with a tableau having two rows that agree only on X.

2 Chase the tableau using the FDs of F.
3 The columns in final tableau agrees two rows is X+
F.
e.g. { }
R(ABCDEH), F = AB → C, BC → AD, D → E, CH → B
F |= AB → D ?
Start with the tableau:
A B C D E H
0 0 1 1 1 1
0 0 2 2 2 2

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Finding X+

F
by Chase 204/248
Finding X+
F by Chase (cont.)

Apply AB → C to infer 1 = 2; say both become 1. The resulting tableau is:

A B C D E H
0 0 1 1 1 1
0 0 1 2 2 2
Next, apply BC → AD to infer that 1 = 2, and apply D → E to infer 1 = 2. At this
point, the tableau is:
A B C D E H
0 0 1 1 1 1
0 0 1 1 1 2
Since the two tuples agree in the D column implies F |= AB → D.
Other hand: AB+ F = (ABCDE).
In this tableau, only one AB+
F not other attributes.
Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Finding X+
F
by Chase 205/248
Tableau Chase Test for MVDs

X ↠ Y holds in r : R(XYZ) if only if:

r(XYZ) = r1 (XY) ⋊
⋉ r2 (XZ)
So we can use Tableau to check r1 (XY) and r2 (XZ) reserve information with r(XYZ)
whether implies X ↠ Y.
e.g. { }
R(ABCD) , D = A → B, B ↠ C
D |= A ↠ C holds in r(R) ?
Start with tableau:
R A B C D
r1 (AC) 0 1 0 1
r2 (ABD) 0 0 2 0

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Tableau Chase Test for MVDs 206/248
Tableau Chase Test for MVDs (cont.)

Apply A → B to infer that 1 = 0.

The tableau becomes:
R A B C D
r1 (AC) 0 0 0 1
r2 (ABD) 0 0 2 0
Apply the B ↠ C, since two rows agree in the B column. We swap C columns to get
two more rows which we add to the tableau, which becomes:
R A B C D
r1 (AC) 0 0 0 1
r2 (ABD) 0 0 2 0
0 0 2 1
0 0 0 0
A row with all 0, so that F |= A ↠ C ■
Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Tableau Chase Test for MVDs 207/248
e.g.
{ }
R(ABCGHI) , D = A ↠ B, B ↠ HI, CG ↠ H
D |= AB ↠ BH
Using Tableau Chase Test:
R A B C G H I
r1 (AGBH) 0 0 1 0 0 1 t1
r2 (AGCI) 0 2 0 0 2 0 t2
A↠B 0 0 0 0 2 0 t3
using (t1 , t2 ) 0 2 0 0 2 0 t4
B ↠ HI 0 0 1 0 2 0 t5
using (t1 , t3 ) 0 0 0 0 0 1 t6
CG ↠ H 0 0 0 0 0 0 t7
using (t3 , t6 ) 0 0 0 0 2 1 t8

There is a row with all 0, so that D |= AB ↠ BH ■

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Tableau Chase Test for MVDs 208/248
Projecting MVDs
{ }
R(ABCDE), D = A ↠ CD ;
Decomposition S(ABC). Finding MVDs imply in S(ABC)?
MVDs maybe have left side are A or B or C, since orther trivial MVDs.
Furthermore, we claim A ↠ C holds in S, as does A ↠ B (by the complementation
rule).
Start with the tableau:
R A B C D E
r1 (AC) 0 1 0 1 1
r2 (ABDE) 0 0 2 0 0

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Projecting MVDs 209/248
Projecting MVDs (cont.)

Use A ↠ CD to swap the C and D components of these two rows to get two new rows:
R A B C D E
r1 (AC) 0 1 0 1 1
r2 (ABDE) 0 0 2 0 0
0 1 2 0 1
0 0 0 1 0

Notice: The last row has 0 in all the attributes of S, that is, A, B, and C. That is
enough to conclude that A ↠ C holds in S ■

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Projecting MVDs 210/248
Minimum Dependency Basis

Algorithm 1 David Maier (The Theory of Relational Databases)

{ }
Input: R, D = FDs, MVDs , X ⊆ R
Output: Minimum dependency basis for X base on D
Denote: X++
D
Method:
1 − Change all FDs in D to MVDs
{ }
− X++
D ← A1 , A2 , . . . Ak , Ai ∈ X
− ∀X′ ↠ Y′ ∈ D : X′ ⊆ X

D ← XD
X++ ++
+ {Y′ } + {R − X′ Y′ }
2 ∀{Y1 , Y2 } ∈ X++
D : Y1 ∩ Y2 =
̸ ∅:

D ← XD
X++ − {Y1 , Y2 } + {Y1 ∩ Y2 } + {Y1 − Y2 } + {Y2 − Y1 }
++

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Minimum Dependency Basis 211/248
Minimum Dependency Basis (cont.)

3 ∀W ↠ Z ∈ D : W ⊆ Y = Y1 Y2 . . . Yk , Yi ∈ X++
D
• D |= Y ↠ Z (augmentation)
{ }
• D |= X ↠ Z − Y (transitivity)
{ }
• If Z − Y is NOT the union of some sets in X++
D :
{ }
XD ← XD + Z − Y
++ ++

4 If no MVD in D can be used to change X++

D , stop.
If not, turn to step 2
Like X+ ++
F for FDs, with XD we can implies all MVDs with which left side is X and right
++
side is subset of XD

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Minimum Dependency Basis 212/248
e.g.
{ }
R(ABCDE), D = A → BC, DE ↠ C
Find A++
D .
{ }
1. − Change to MVDs:
{ } D = A ↠ BC, DE ↠ C
− Initial A++
D = A
− A ↠ BC :{ }
A++D = A, BC, DE
2. None
3. DE ↠ C with
{ Y = DE : }
A++
D = A, BC, DE, C
2. Y1 = BC, Y{2 = C : }
A++
D = A, B, C, DE
3. None 2. None 3. None
{ }
Result: A++
D = A, B, C, DE
Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Minimum Dependency Basis 213/248
e.g.
{ }
R(ABCDE), D = A → BC, DE ↠ C
Find AD++
D .
{ }
1. − Change to MVDs: { D =
} A ↠ BC, DE ↠ C
− Initial AD++
D = A, D
− A ↠ BC : { }
AD++ D = A, D, BC, DE
2. Y1 = D, Y2 ={ DE : }
AD++
D = A, D, E, BC
3. DE ↠ C with{Y = DE : }
AD++
D = A, D, E, BC, C

2. Y1 = BC, Y2 {= C : }
AD++
D = A, D, E, B, C

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Minimum Dependency Basis 214/248
e.g. (cont.)

3. None
2. None
3. None
{ }
Result: AD++
D = A, B, C, D, E
So that: D |= AD ↠ BE
We can test this MVD by use the Axioms or Tableau and Chase.

Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Minimum Dependency Basis 215/248
Another Algorithm

Minimum Dependency Basis, Beeri [1980]

{ }
Input: R, D = FDs, MVDs , X ⊆ R
Output: Minimum dependency basis for X base on D
Denote: X++
D
Method:
1 Change all FDs in D to MVDs
{ }
D ←
X++ R−X
++
2 While (No more change XD ) Do

For each V ↠ W ∈ D
If ( ∃Y ∈ X++
D : Y ∩ W ̸= ∅ , Y ∩ V = ∅ ) then

D ← XD
X++ − {Y} + {Y ∩ W} + {Y − W}
++

3 X++
D is dependency basis of X
Nguyễn Văn Diêu 3. Logical Design :: Axioms for MVDs :: Beeri Algorithm 216/248
Fourth Normal Form

Definition
{ }
R , D = FDs, MVDs
R is in fourth normal form (4NF) if for every X ↠ Y :
• X ↠ Y is a trivial MVD or
• X is a superkey for R

e.g. { }
R(ABCDE) , D = A → BC, C ↠ DE .
R is not in 4NF because of the C ↠ DE.
R consisting of the two R1 (ABC) and R2 (CDE) is in 4NF with respect to D,
even though A ↠ B is implied by D and applies to R1 .
A ↠ B is not trivial, but A is a key for R1 .

Nguyễn Văn Diêu 3. Logical Design :: 4NF :: Definition 217/248

Lemma
{ }
R , D = FDs, MVD . If R is in 4NF, then R is in BCNF.
Proof (use C1 ⇒ C2 ⇔ ¬C2 ⇒ ¬C1 )
Suppose R is not in BCNF. Then we must have subsets K, Y, and A of R such that K
is a key for R and:
1. K → Y,
2. Y ↛ K,
3. Y → A,
4. A ∈/ (KY)
We try to prove Y ↠ A is not trivial and Y is not a superkey.
− Y → A |= Y ↠ A
Since A ∈
/ Y and YA ̸= R, so Y ↠ A is not trivial.
− Y ↛ K, so Y is not a key ⇒ Y not a superkey
Therefore, R is not in 4NF ■
Nguyễn Văn Diêu 3. Logical Design :: 4NF :: Lemma 218/248
Decomposition into 4NF

Quite analogous to the BCNF decomposition algorithm.

Algorithm Decomposition into 4NF.
{ }
Input: R0 with{ D0 = FDs, MVDs }
Output: ρ = R1 , R2 , . . . , Rk in 4NF, conserve information
Method: Do the following steps, with R = R0 and D = D0
1. Find a 4NF violation in R; X ↠ Y in R, X is not a superkey.
If none, return True; R by itself is a suitable decomposition.
2. If have a 4NF violation, break R into two:
• R1 (XY)
• R2 (X(R − XY))

Nguyễn Văn Diêu 3. Logical Design :: 4NF :: Decomposition into 4NF 219/248
Decomposition into 4NF (cont.)

3. Find the FD’s and MVD’s: D1 = π R1 (D) and D2 = π R2 (D).

{ } { }
4. Recursively decompose R1 , D1 and R2 , D2
e.g. { }
R(ABCDEI), D = A ↠ BCD, B → AC, C → D .
• Key = (BEI). R is not in 4NF because of A ↠ BCD is a nontrival MVD and A is
not a key for R
• Decompose R into:
{ }
R1 (ABCD), D1 = B → AC, C → D , key = B, 2NF
R2 (AEI), D2 = ∅, 4NF
• Use C ↠ D for R1 (ABCD):
{ }
R11 (CD), D11 = C { → D , key
} = C, 4NF
R12 (ABC), D12 = B → AC , key = B, 4NF
Result: ρ = {R11 , R12 , R2 } is thus in 4NF rescpect to D.
Nguyễn Văn Diêu 3. Logical Design :: 4NF :: Decomposition into 4NF 220/248
Overview

For example, we have r(ABC) decomposes conserve information onto AB, AC and BC.

r (A B C)
1 1 1
1 2 2
3 3 3
4 3 4
5 5 5
6 6 5

r = π AB (r) ⋊
⋉ π AC (r) ⋊
⋉ π BC (r)

Nguyễn Văn Diêu 3. Logical Design :: Join Dependency :: Overview 221/248

e.g. (cont.)

π AB (r) = (A B) π AC (r) = (A C) π BC (r) = (B C)

1 1 1 1 1 1
1 2 1 2 2 2
3 3 3 3 3 3
4 3 4 4 3 4
5 5 5 5 5 5
6 6 6 5 6 5

However, r satisfies no nontrivial MVDs, so it has no conserve information

decomposition onto any pair of R1 and R2 such that R1 ̸= ABC and R1 ̸= ABC.

Nguyễn Văn Diêu 3. Logical Design :: Join Dependency :: Overview 222/248

Join Dependency
{ }
R = R1 , R2 , ..., Rp be a set of relation schemes over U = R1 R2 ...Rp . A relation r(U)
satisfies
Join Dependency: (JD) ∗ [R1 , R2 , ..., Rp ]
if r decomposes conserve information onto R1 , R2 , · · · , Rp . That is,

r = π R1 (r) ⋊
⋉ π R2 (r) ⋊
⋉ ··· ⋊
⋉ π Rp (r)
We also write ∗[R1 , R2 , · · · , Rp ] as ∗[R]
e.g.
In example 11.1, r satisfies the JD ∗[AB, AC, BC]

Nguyễn Văn Diêu 3. Logical Design :: Join Dependency :: Definition 223/248

Join Dependency (cont.)

We know:
1. r(R) satisfies X ↠ Y ⇔ r decomposes conserve information onto XY and XZ,
where Z = R − (XY).
2. This condition is just JD ∗[XY, XZ].
3. JD ∗[R1 , R2 ] is the same as the R1 ∩ R2 ↠ R1 .
4. We can also define JDs in a manner similar to the definition of MVDs.
5. Let r satisfy ∗[R1 , R2 , · · · , Rp ]. If r contains tuples t1 , t2 , · · · , tp such that
ti (Ri ∩ Rj ) = tj (Ri ∩ Rj )
for all i, j,
r must contain t such that t(Ri ) = ti (Ri ), 1 ⩽ i ⩽ p.

Nguyễn Văn Diêu 3. Logical Design :: Join Dependency :: Definition 224/248

e.g.

Suppose relation r(ABCDE) satisfies the JD ∗[ABC, BD, CDE] and contains the three
tuples shown below.
r (A B C D E)
t1 1 1 1 1 1
t2 2 1 2 2 3
t3 3 2 1 2 2

r must also contain tuple t = (1, 1, 1, 2, 2)

JD ∗[R1 , R2 , · · · , Rp ] over R is trivial if R = R1 for some i.
JD ∗[R1 , R2 , · · · , Rp ] applies to R if R = R1 R2 · · · Rp .

Nguyễn Văn Diêu 3. Logical Design :: Join Dependency :: Definition 225/248

Project Join Normal Form
{ }
R, F = FDs, JDs over R.
R is in project join normal form (PJNF) with respect to F
if for every JD ∗[R1 , R2 , · · · , Rp ] implied by F, that implies to R, and:
• JD is trivial or,
• Every Ri is a superkey for R.
e.g. {Let R(ABCDEI), }
F = ∗ [ABCD, CDE, BDI], ∗[AB, BCD, AD], A → BCDE, BC → AI .
Key = (A), (BC)
R is not PJNF because
{ of JD ∗[ABCD, CDE, BDI].}
If decompose ρ = R1 (ABCD), R2 (CDE), R3 (BDI)

Nguyễn Văn Diêu 3. Logical Design :: Join Dependency :: Definition 226/248

Project Join Normal Form (cont.)
{ }
ρ = R1 (ABCD), R2 (CDE), R3 (BDI)
{ }
R1 (ABCD), F1 = ∗ [AB, BCD, AD], A → BCD, BC → A
Key = (A), BC. So R1 is in PJNF.
R2 (CDE), F2 = ∅, PJNF.
R3 (BDI), F3 = ∅, PJNF.

Nguyễn Văn Diêu 3. Logical Design :: Join Dependency :: Definition 227/248

Embedded Functional Dependencies

Given R, X → Y holds on R.
If any S ⊇ R. Whether X → Y holds on S ?
This is evident for FDs because the definition of FDs did not concert to other XY set.
r (R: X Y) r (S: X Y Z W)
1 2 1 2 © §
1 2 1 2 x y
3 4 3 4 þ ÿ
3 4 3 4 Y §

Nguyễn Văn Diêu 3. Logical Design :: Embedded Functional Dependencies :: Definition 228/248
Embedded Multivalued Dependencies

Consider the relation r(ABCD). The projection π ABC (r) satisfies A ↠ B, but r itself
does not.
r (A B C) r (A B C D)
1 1 1 1 1 1 1
1 2 1 1 2 1 1
1 1 2 1 1 2 2
1 2 2 1 2 2 1
2 2 2 2 2 2 2
Definition: Relation r(R) satisfies the embedded multivalued dependency X ↠ Y|Z if
the X ↠ Y is satisfied by the π X∪Y∪Z (r).
Read: ’X multivalued determines Y in the context of Z’.

Nguyễn Văn Diêu 3. Logical Design :: Embedded Functional Dependencies :: Embedded MVDs 229/248
Embedded Join Dependencies

Multivalued dependencies is spectial of Join dependencies.

r(R), X ↠ Y.
Another description is JD ∗[XY, XZ] with Z = R − XY.
Definition
• Relation r(R) satisfies the embedded join dependency (EJD) ∗[R1 , R2 , ..., Rp ] if:
π S (r) satisfies ∗[R1 , R2 , ..., Rp ] as a regular JD, where S = R1 R2 ...Rp .
• Allow R = S. That is, every JD is an EJD.
• Also write the embedded multivalued dependency (EMVD) ∗[XY, XZ] as X ↠ Y|Z.

Nguyễn Văn Diêu 3. Logical Design :: Embedded Functional Dependencies :: Embedded JD 230/248
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 231/248

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 232/248

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 233/248

ERD

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

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 235/248
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 236/248
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 237/248
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 238/248

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 239/248

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 240/248
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 241/248
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 242/248
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 243/248
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 244/248
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 245/248

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 246/248
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 247/248

e.g.

MySQL: CREATE INDEX Statement

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