This action might not be possible to undo. Are you sure you want to continue?

# Top-Down Database Design

Mini-world Requirements

E1

R

?

Relation schemas

Conceptual schema E2

**Lecture 10: Functional Dependencies & Normalization
**

Dr. Dang Tran Khanh

Department of Information Systems Faculty of Computer Science and Engineering dtkhanh@hcmut.edu.vn

Outline

**Introduction Functional dependencies (FDs)
**

–

Definition of FD

–

– – –

**Direct, indirect, partial dependencies
**

Inference Rules for FDs Equivalence of Sets of FDs Minimal Sets of FDs

Normalization

– – – –

1NF and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

**Notes and suggestions Summary
**

Reading suggestion:

– –

[1]: Chapters 10, 11 [2]: Chapters 13, 14

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

3

Introduction

Each relation schema consists of a number of attributes and the relational database schema consists of a number of relation schemas

Attributes are grouped to form a relation schema Need some formal measure of why one grouping of attributes into a relation schema may be better than another

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

4

Introduction

“Goodness”

– – – –

measures:

Redundant information in tuples Update anomalies: modification, deletion, insertion Reducing the NULL values in tuples Disallowing the possibility of generating spurious tuples

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

5

Introduction

Redundant information in tuples: the attribute values pertaining to a particular department (DNUMBER, DNAME, DMGRSSN) are repeated for every employee who works for that department

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

6

Introduction

**Update anomalies: modification, deletion, insertion
**

–

Modification

As the manager of a dept. changes we have to update many values according to employees working for that dept. Easy to make the DB inconsistent

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

7

Introduction

Deletion: if Borg James E. leaves, we delete his tuple and lose the existing of dept. 1, the name of dept. 1, and who is the manager of dept. 1

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

8

Introduction

Insertion:

–

How can we create a department before any employees are assigned to it ??

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

9

Introduction

Reducing

– –

the NULL values in tuples

Employees not assigned to any dept.: waste the storage space Other difficulties: aggregation operations (e.g., COUNT) and joins

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

10

Introduction

**Disallowing the possibility of generating spurious tuples
**

EMP_PROJ(SSN, PNUMBER, HOURS, ENAME, PNAME, PLOCATION) EMP_LOCS(ENAME, PLOCATION) EMP_PROJ1(SSN, PNUMBER, HOURS, PNAME, PLOCATION)

Generation of invalid and spurious data during JOINS: PLOCATION is the attribute that relates EMP_LOCS and EMP_PROJ1, and PLOCATION is neither a primary key nor a foreign key in either EMP_LOCS or EMP_PROJ1 (cf. chapter 10 [1] for more details)

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

11

Introduction

“Goodness” measures:

– – – –

Redundant information in tuples Update anomalies: modification, deletion, insertion Reducing the NULL values in tuples Disallowing the possibility of generating spurious tuples

Normalization

**It helps DB designers determine the best relation schemas
**

– –

A formal framework for analyzing relation schemas based on their keys and on the functional dependencies among their attributes A series of normal form tests that can be carried out on individual relation schemas so that the relational database can be normalized to any desired degree

It is based on the concept of normal form 1NF, 2NF, 3NF, BCNF, 4NF, 5 NF It is a process which ensures that the data is structured in such a way that attributes are grouped with the PK. Attributes that do not directly depend on PK may be extracted to form a new relation

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

12

Introduction

**There are two important properties of decompositions:
**

(a) (b)

non-additive or losslessness of the corresponding join preservation of the functional dependencies

Note that property (a) is extremely important and cannot be sacrificed. Property (b) is less stringent and may be sacrificed (see chapter 11)

13

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

**Functional Dependencies (FDs)
**

Definition

of FD Direct, indirect, partial dependencies Inference Rules for FDs Equivalence of Sets of FDs Minimal Sets of FDs

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

14

**Functional Dependencies (FDs)
**

Functional dependencies (FDs) are used to specify formal measures of the "goodness" of relational designs FDs and keys are used to define normal forms for relations FDs are constraints that are derived from the meaning and interrelationships of the data attributes A set of attributes X functionally determines a set of attributes Y if the value of X determines a unique value for Y

15

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

**Functional Dependencies (FDs)
**

X -> Y holds if whenever two tuples have the same value for X, they must have the same value for Y For any two tuples t1 and t2 in any relation instance r(R): If t1[X]=t2[X], then t1[Y]=t2[Y] X -> Y in R specifies a constraint on all relation instances r(R) Examples:

– – –

social security number determines employee name: SSN -> ENAME project number determines project name and location: PNUMBER -> {PNAME, PLOCATION} employee ssn and project number determines the hours per week that the employee works on the project: {SSN, PNUMBER} -> HOURS

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

16

**Functional Dependencies (FDs)
**

If

K is a key of R, then K functionally determines all attributes in R (since we never have two distinct tuples with t1[K]=t2[K])

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

17

**Functional Dependencies (FDs)
**

Definition

of FD Direct, indirect, partial dependencies Inference Rules for FDs Equivalence of Sets of FDs Minimal Sets of FDs

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

18

**Functional Dependencies (FDs)
**

Direct dependency (fully functional dependency): All attributes in a R must be fully functionally dependent on the primary key (or the PK is a determinant of all attributes in R)

Performer-id Performer-name Performer-type Performerlocation

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

19

**Functional Dependencies (FDs)
**

Indirect

**dependency (transitive dependency): Value of an attribute is not
**

determined directly by the primary key

Performer-id Performername Performertype Performerlocation

Fee

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

20

**Functional Dependencies (FDs)
**

Partial dependency

–

Composite determinant - more than one value is required to determine the value of another attribute, the combination of values is called a composite determinant

EMP_PROJ(SSN, PNUMBER, HOURS, ENAME, PNAME, PLOCATION)

**{SSN, PNUMBER} -> HOURS
**

–

Partial dependency - if the value of an attribute does not depend on an entire composite determinant, but only part of it, the relationship is known as the partial dependency SSN -> ENAME PNUMBER -> {PNAME, PLOCATION}

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

21

**Functional Dependencies (FDs)
**

Partial dependency

Performer-id

Performer-name Performer-type

Performer-location

Fee

Agent-id

Agent-name Agent-location

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

22

**Functional Dependencies (FDs)
**

Definition

of FD Direct, indirect, partial dependencies Inference Rules for FDs Equivalence of Sets of FDs Minimal Sets of FDs

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

23

**Functional Dependencies (FDs)
**

IR1. (Reflexive) If Y ⊆ X, then X -> Y IR2. (Augmentation) If X -> Y, then XZ -> YZ (Notation: XZ stands for X U Z) IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z

Given a set of FDs F, we can infer additional FDs that hold whenever the FDs in F hold Armstrong's inference rules:

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

24

**Functional Dependencies (FDs)
**

Some additional inference rules that are useful:

(Decomposition) If X -> YZ, then X -> Y and X -> Z (Union) If X -> Y and X -> Z, then X -> YZ (Psuedotransitivity)⊆ X -> Y and WY -> Z, then WX -> Z If

The last three inference rules, as well as any other inference rules, can be deduced from IR1, IR2, and IR3 (completeness property)

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

25

**Functional Dependencies (FDs)
**

Closure of a set F of FDs is the set F+ of all FDs that can be inferred from F Closure of a set of attributes X with respect to F is the set X + of all attributes that are functionally determined by X X + can be calculated by repeatedly applying IR1, IR2, IR3 using the FDs in F

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

26

**Functional Dependencies (FDs)
**

Definition

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

27

**Functional Dependencies (FDs)
**

Two sets of FDs F and G are equivalent if F+ = G+ Definition: F covers G if G+ ⊆ F+. F and ⊆G are equivalent if F covers G and G covers F There is an algorithm for checking equivalence of sets of FDs (see chapter 10 [1])

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

28

**Functional Dependencies (FDs)
**

A

**set of FDs is minimal if it satisfies the following conditions:
**

⊆

Every dependency in F has a single attribute for its RHS. We cannot remove any dependency from F and have a set of dependencies that is equivalent to F. We cannot replace any dependency X -> A in F with a dependency Y -> A, where Y proper-subset-of X ( Y subset-of X) and still have a set of dependencies that is equivalent to F

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

29

**Functional Dependencies (FDs)
**

Every set of FDs has an equivalent minimal set There can be several equivalent minimal sets ⊆ There is no simple algorithm for computing a minimal set of FDs that is equivalent to a set F of FDs To synthesize a set of relations, we assume that we start with a set of dependencies that is a minimal set (e.g., see algorithms 11.2 and 11.4)

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

30

Outline

**Introduction Functional dependencies (FDs)
**

–

Definition of FD

–

– – –

**Direct, indirect, partial dependencies
**

Inference Rules for FDs Equivalence of Sets of FDs Minimal Sets of FDs

Normalization

– – – –

1NF and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

**Notes and suggestions Summary
**

Reading suggestion:

– –

[1]: Chapters 10, 11 [2]: Chapters 13, 14

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

31

Normalization

Normalization: The process of decomposing unsatisfactory "bad" relations by breaking up their attributes into smaller relations Normal form: Using keys and FDs of a relation to certify whether a relation schema is in a particular normal form Normalization is carried out in practice so that the resulting designs are of high quality and meet the desirable properties The database designers need not normalize to the highest possible normal form (3NF, BCNF or 4NF)

32

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

Normalization

Two

– –

new concepts:

A Prime attribute must be a member of some candidate key A Nonprime attribute is not a prime attribute: it is not a member of any candidate key

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

33

Normalization

1NF

and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

34

Normalization

First

normal form (1NF): there is only one value at the intersection of each row and column of a relation - no set valued attributes in 1 NF Disallows composite attributes, multivalued attributes, and nested relations To be part of the formal definition of a relation in the basic (flat) relational model

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

35

1NF

Performer-name Performer-id Performer-location Performer-type Agent-id Agent-name Agent-location Venue-name Venue-id Venue-location Event-id Event-name Event-type Booking-date Fee

1NF determinancy diagram

Normalization

1NF

and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

37

Normalization

Second

normal form (2NF) - all attributes must be fully functionally dependent on the primary key 2NF solves partial dependency problem in 1NF Method: identify primary keys and group attributes that relate to the key together to form separate new relations

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn) 38

2NF

2NF determinancy diagram

Performer-id Performername Performertype Performerlocation Fee

Relation in 2NF

P-id

101 105 108 112 118 126 129 134 138 140 141 143 147 149 150 152

P-name

Baron Steed Jones Eagles Markov Stokes Chong Brass Ng Strong Gomez Tan Qureshi Tan Pointer Peel

P- type

Singer Dancer Actor Actor Dancer Comedian Actor Singer Singer Magician Musician Singer Actor Actor Magician Dancer

Fee

75

60 85 85 60 90 85 75 75 72 92 75 85 85 72 60

P-loc’n

York Berlin Bombay Leeds Moscow Athens Beijing London Penang Rome Lisbon Chicago London Taipei Paris London

2NF

2NF determinancy diagram

Agent-name Agent-location

A-id

1295 1435 1504 1682 1460 1522 1509 1478 1377 1478 1190 1802 1076 1409 1428

A-name

Burton

A-oc’n l

Lonton Boston Taipei Beijing Rome Madrid York Leeds Sydney Leeds Hue Bristol Oxford York Cairo

Relation in 2NF

Nunn

Lee Tsang Stritch Ellis Patel Burns Webb Burns Patel Chapel Eccles Arkley Vemon

Agent-id

Venue-id

Venue-name

V-id

59 35 54

V-name

Atlas Polis Nation Silbury Royale Vostok Festive Gratton State Tower Palace Shaw

V-loc’n

Tokyo Athens Lisbon Tunis Cairo Kiev Rome Boston Kiev Lima Milan Oxford

17

Venue-location

46 75 79 28 84 82 92 62

2NF

Relation in 2NF

E-id

959 907 921

E-name

Show Time Elgar 1 Silver Shoe White Lace The Dark What Now Next Year Gold Days Angels Trick-Treat New Dawn Birdsong Quicktime Vanish Mahler 1 The Friends Chanson Card Trick Secret Tape Swift Step

E-type

Musical Concert Ballet Ballet Drama Drama Drama Drama Opera Variety show Drama Musical Musical Magic show Concert Drama Opera Magic show Drama Dance

**2NF determinancy diagram
**

Event-type Event-id Event-name

942 901 913 926 952 934 945 938 981 957 963 941 964 927 971 988 978

2NF

2NF determinancy diagram

P-id

101

Relation in 2NF

A-id

1295 1435 1504 1682 1460 1522 1504 1509 1478 1504 1509 1478 1478 1504 1076 1409 1428

Performerid Agent-id Venue-id Event-id Booking-date

V-id

59 35 54 79 17 46 75 59 79 28 84 17 84 79 17 79 59

E-id

959 921 942 901 926 952 952 945 926 981 957 963 941 927 952 988 978

Booking-date

25-Nov-99 07-Jan-02 10-Feb-02 29-Jul-03 13-Aug-00 05-May-99 16-Mar-99 02-Sept-01 22-Jun-00 18-Sept-01 18-Aug-99 18-Aug-99 21-Jul-00 21-Nov-02 30-Apr-00 17-Apr-00 01-Oct-01

105 105 108 112 112 112 126 129 134 138 140 141 143 147 147 152

**2NF determinancy diagram
**

Performer-id Performername Performertype Performerlocation

2NF

Fee

Relation in 2NF

P-id

101 105 108 112 118 126 129 134 138 140 141 143 147 149 150 152

P-name

Baron Steed Jones Eagles Markov Stokes Chong Brass Ng Strong Gomez Tan Qureshi Tan Pointer Peel

P- type

Singer Dancer Actor Actor Dancer Comedian Actor Singer Singer Magician Musician Singer Actor Actor Magician Dancer

Fee

75

60 85 85 60 90 85 75 75 72 92 75 85 85 72 60

P-loc’n

York Berlin Bombay Leeds Moscow Athens Beijing London Penang Rome Lisbon Chicago London Taipei Paris London

Problem with 2NF: - Insertion - Modification - Deletion

Normalization

1NF

and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

44

Normalization

A

relation schema R is in third normal form (3NF) if it is in 2NF and no non-prime attribute A in R is transitively dependent on the primary key

NOTE: In X -> Y and Y -> Z, with X as the primary key, we consider this a problem only if Y is not a candidate key. When Y is a candidate key, there is no problem with the transitive dependency . E.g., Consider EMP (SSN, Emp#, Salary ). Here, SSN -> Emp# -> Salary and Emp# is a candidate key

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn) 45

Normalization

3NF

solves indirect (transitive) dependencies problem in 1NF and 2NF Method: identify all transitive dependencies and each transitive dependency will form a new relation, with non-prime attributes participating in the transitive dependency and the attribute which determines others as the attributes for the new relation

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn) 46

3NF

3NF determinancy diagram

P-id

Performer-id Performername Performertype

101 105 108 112 118 126 129 134 138 140 141 143 147 149 150 152

Relation in 3NF

P-name P- type

Baron Steed Jones Eagles Markov Stokes Chong Brass Ng Strong Gomez Tan Qureshi Tan Pointer Peel Singer Dancer Actor Actor Dancer Comedian Actor Singer Singer Magician Musician Singer Actor Actor Magician Dancer

P-loc’n

York Berlin Bombay Leeds Moscow Athens Beijing London Penang Rome Lisbon Chicago London Taipei Paris London

Performerlocation

P- type Fee

Performertype Fee

Singer Dancer Actor Comedian Magician Musician

75

60 85 90 72 92

3NF

3NF determinancy diagram

Agent-name Agent-location Agentlocation

Event-type Event-id Event-name

Agent-id

Venue-id

Venue-name

Performerid Agent-id Booking-date

Venue-location

Venue-id Event-id

Normalization

1NF

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

49

**General Normal Form Definitions
**

The

above definitions consider the primary key only The following more general definitions take into account relations with multiple candidate keys

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

50

**General Normal Form Definitions
**

A relation schema R is in second normal form (2NF) if every non-prime attribute A in R is fully functionally dependent on every key of R A relation schema R is in third normal form (3NF) if whenever a FD X -> A holds in R, then either: (a) X is a superkey of R, or (b) A is a prime attribute of R

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

51

Normalization

1NF

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

52

Normalization

A

relation schema R is in Boyce-Codd Normal Form (BCNF) if whenever an FD X -> A holds in R, then X is a superkey of R

More

**details: [1] -> chapters 10, 11 The goal is to have each relation in BCNF (or 3NF)
**

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn) 53

BCNF

Boyce-Codd normal form. (a) BCNF normalization of LOTS1A with the functional dependency FD2 being lost in the decomposition. (b) A schematic relation with FDs; it is in 3NF, but not in BCNF.

Outline

**Introduction Functional dependencies (FDs)
**

–

Definition of FD

–

– – –

**Direct, indirect, partial dependencies
**

Inference Rules for FDs Equivalence of Sets of FDs Minimal Sets of FDs

Normalization

– – – –

1NF and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

**Notes and suggestions Summary
**

Reading suggestion:

– –

[1]: Chapters 10, 11 [2]: Chapters 13, 14

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

55

Notes & Suggestions

[1]: chapter 11

– –

**4NF: based on multivalued dependency (MVD) 5NF: based on join dependency
**

Such

a dependency is very difficult to detect in practice and therefore, normalization into 5NF is considered very rarely in practice

–

–

**Other normal forms & algorithms
**

ER modeling: top-down database design

Bottom-up

database design ??

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

56

Summary

**Introduction: “goodness” measures for relations Functional dependencies (FDs)
**

– – – – –

Definition of FD Direct, indirect, partial dependencies Inference Rules for FDs Equivalence of Sets of FDs Minimal Sets of FDs 1NF and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

Normalization

– – – –

**Notes and suggestions: 4NF, 5NF, other normal forms, and bottom-up DB design Next Lecture:
**

–

– –

Database Security (KSTN): [1] - chapter 23 http://www.oracle.com Emerging DB research directions (KSTN) Revision

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

57

Q&A

Dr. Dang Tran Khanh (dtkhanh@hcmut.edu.vn)

58