fundamental db system lecture note

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide - 1 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide - 2

1 Informal Design Guidelines for

Chapter Outline Relational Databases (1)
 3 Normal Forms Based on Primary Keys  What is relational database design?
 3.1 Normalization of Relations
 The grouping of attributes to form "good" relation
 3.2 Practical Use of Normal Forms
 3.3 Definitions of Keys and Attributes Participating in Keys
schemas
 3.4 First Normal Form  Two levels of relation schemas
 3.5 Second Normal Form  The logical "user view" level
 3.6 Third Normal Form
 The storage "base relation" level
 4 BCNF (Boyce-Codd Normal Form)  Design is concerned mainly with base relations
 What are the criteria for "good" base relations?

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide- 3 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

fundamental db system lecture note 1

fundamental db system lecture note

Informal Design Guidelines for Relational

Databases (2) 1.1 Semantics of the Relation Attributes
 We first discuss informal guidelines for good relational  GUIDELINE 1: Informally, each tuple in a relation should
design represent one entity or relationship instance. (Applies to
 Then we discuss formal concepts of functional individual relations and their attributes).
dependencies and normal forms  Attributes of different entities (EMPLOYEEs,
 - 1NF (First Normal Form) DEPARTMENTs, PROJECTs) should not be mixed in the
same relation
 - 2NF (Second Normal Form)
 Only foreign keys should be used to refer to other entities
 - 3NF (Third Normal Form)
 Entity and relationship attributes should be kept apart as
 - BCNF (Boyce-Codd Normal Form)
much as possible.
 Bottom Line: Design a schema that can be explained
easily relation by relation. The semantics of attributes
should be easy to interpret.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 5 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 6

Figure 10.1 A simplified COMPANY 1.2 Redundant Information in Tuples and

relational database schema Update Anomalies

 Information is stored redundantly

 Wastes storage
 Causes problems with update anomalies
 Insertion anomalies
 Deletion anomalies
 Modification anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 7 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 8

fundamental db system lecture note 2

fundamental db system lecture note

EXAMPLE OF AN UPDATE ANOMALY EXAMPLE OF AN INSERT ANOMALY

 Consider the relation:  Consider the relation:

 EMP_PROJ(Emp#, Proj#, Ename, Pname,  EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours) No_hours)
 Update Anomaly:  Insert Anomaly:
 Changing the name of project number P1 from  Cannot insert a project unless an employee is
“Billing” to “Customer-Accounting” may cause this assigned to it.
update to be made for all 100 employees working  Conversely
on project P1.
 Cannot insert an employee unless an he/she is
assigned to a project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 9 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 10

Two relation schemas suffering from

EXAMPLE OF AN DELETE ANOMALY update anomalies

 Consider the relation:

 EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
 Delete Anomaly:
 When a project is deleted, it will result in deleting
all the employees who work on that project.
 Alternately, if an employee is the sole employee on
a project, deleting that employee would result in
deleting the corresponding project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 11 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 12

fundamental db system lecture note 3

fundamental db system lecture note

Example States for EMP_DEPT and Guideline to Redundant Information in

EMP_PROJ Tuples and Update Anomalies

 GUIDELINE 2:
 Design a schema that does not suffer from the
insertion, deletion and update anomalies.
 If there are any anomalies present, then note them
so that applications can be made to take them into
account.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 13 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 14

1.3 Null Values in Tuples 2.1 Functional Dependencies (1)

 GUIDELINE 3:  Functional dependencies (FDs)
 Relations should be designed such that their  Are used to specify formal measures of the
tuples will have as few NULL values as possible "goodness" of relational designs
 Attributes that are NULL frequently could be  And keys are used to define normal forms for
placed in separate relations (with the primary key) relations
 Reasons for nulls:  Are constraints that are derived from the meaning
 Attribute not applicable or invalid and interrelationships of the data attributes
 Attribute value unknown (may exist)  A set of attributes X functionally determines a set
 Value known to exist, but unavailable of attributes Y if the value of X determines a
unique value for Y

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 15 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 16

fundamental db system lecture note 4

fundamental db system lecture note

Functional Dependencies (2) Examples of FD constraints (1)

 X -> Y holds if whenever two tuples have the same value  Social security number determines employee
for X, they must have the same value for Y name
 For any two tuples t1 and t2 in any relation instance r(R): If  SSN -> ENAME
t1[X]=t2[X], then t1[Y]=t2[Y]
 Project number determines project name and
 X -> Y in R specifies a constraint on all relation instances location
r(R)
 PNUMBER -> {PNAME, PLOCATION}
 Written as X -> Y; can be displayed graphically on a
relation schema as in Figures. ( denoted by the arrow: ).  Employee ssn and project number determines
the hours per week that the employee works on
 FDs are derived from the real-world constraints on the
attributes
the project
 {SSN, PNUMBER} -> HOURS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 17 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 18

Examples of FD constraints (2) 2.2 Inference Rules for FDs (1)

 An FD is a property of the attributes in the  Given a set of FDs F, we can infer additional FDs that
hold whenever the FDs in F hold
schema R
 Armstrong's inference rules:
 The constraint must hold on every relation  IR1. (Reflexive) If Y subset-of X, then X -> Y
instance r(R)  IR2. (Augmentation) If X -> Y, then XZ -> YZ
 (Notation: XZ stands for X U Z)
 If K is a key of R, then K functionally determines
 IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z
all attributes in R
 (since we never have two distinct tuples with  IR1, IR2, IR3 form a sound and complete set of
t1[K]=t2[K]) inference rules
 These are rules hold and all other rules that hold can be
deduced from these

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 19 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 20

fundamental db system lecture note 5

fundamental db system lecture note

Inference Rules for FDs (2) Inference Rules for FDs (3)
 Some additional inference rules that are useful:  Closure of a set F of FDs is the set F+ of all FDs
 Decomposition: If X -> YZ, then X -> Y and X -> that can be inferred from F
Z
 Union: If X -> Y and X -> Z, then X -> YZ
 Closure of a set of attributes X with respect to F
 Psuedotransitivity: If X -> Y and WY -> Z, then
WX -> Z is the set X+ of all attributes that are functionally
determined by X
 The last three inference rules, as well as any
other inference rules, can be deduced from IR1,  X+ can be calculated by repeatedly applying IR1,
IR2, and IR3 (completeness property) IR2, IR3 using the FDs in F

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 21 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 22

2.3 Equivalence of Sets of FDs 3 Normal Forms Based on Primary Keys

 Two sets of FDs F and G are equivalent if:  3.1 Normalization of Relations
 Every FD in F can be inferred from G, and
 3.2 Practical Use of Normal Forms
 Every FD in G can be inferred from F
 Hence, F and G are equivalent if F+ =G+
 3.3 Definitions of Keys and Attributes Participating
 Definition (Covers): in Keys
 F covers G if every FD in G can be inferred from F  3.4 First Normal Form
 (i.e., if G+ subset-of F+)  3.5 Second Normal Form
 F and G are equivalent if F covers G and G covers F
 3.6 Third Normal Form
 There is an algorithm for checking equivalence of sets of
FDs

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 23 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 24

fundamental db system lecture note 6

fundamental db system lecture note

3.1 Normalization of Relations (1) 3.2 Practical Use of Normal Forms

 Normalization:  Normalization is carried out in practice so that the
resulting designs are of high quality and meet the
 The process of decomposing unsatisfactory "bad" desirable properties
relations by breaking up their attributes into  The practical utility of these normal forms becomes
questionable when the constraints on which they are
smaller relations based are hard to understand or to detect
 The database designers need not normalize to the
highest possible normal form
 Normal form:  (usually up to 3NF, BCNF)
 Condition using keys and FDs of a relation to  Denormalization:
certify whether a relation schema is in a particular  The process of storing the join of higher normal form
relations as a base relation—which is in a lower normal
normal form form

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 25 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 26

3.3 Definitions of Keys and Attributes Definitions of Keys and Attributes

Participating in Keys (1) Participating in Keys (2)

 A superkey of a relation schema R = {A1, A2, ....,  If a relation schema has more than one key, each
An} is a set of attributes S subset-of R with the is called a candidate key.
property that no two tuples t1 and t2 in any legal  One of the candidate keys is arbitrarily
relation state r of R will have t1[S] = t2[S] designated(chosen) to be the primary key, and
the others are called secondary keys.
 A key K is a superkey with the additional  A Prime attribute must be a member of some
property that removal of any attribute from K will candidate key
cause K not to be a superkey any more.  A Nonprime attribute is not a prime attribute—
that is, it is not a member of any candidate key.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 27 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 28

fundamental db system lecture note 7

fundamental db system lecture note

3.2 First Normal Form Normalization into 1NF

 Disallows
 composite attributes
 multivalued attributes
 nested relations; attributes whose values for an
individual tuple are non-atomic

 Considered to be part of the definition of relation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 29 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 30

3.3 Second Normal Form (1) Second Normal Form (2)

 Uses the concepts of FDs, primary key  A relation schema R is in second normal form
 Definitions (2NF) if every non-prime attribute A in R is fully
 Prime attribute: An attribute that is member of the primary
key K
functionally dependent on the primary key
 Full functional dependency: a FD Y -> Z where removal
of any attribute from Y means the FD does not hold any
more  R can be decomposed into 2NF relations via the
 Examples: process of 2NF normalization
 {SSN, PNUMBER} -> HOURS is a full FD since neither SSN
-> HOURS nor PNUMBER -> HOURS hold
 {SSN, PNUMBER} -> ENAME is not a full FD (it is called a
partial dependency ) since SSN -> ENAME also holds

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 31 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 32

fundamental db system lecture note 8

fundamental db system lecture note

Figure 10.10 Normalizing into 2NF and

3NF 3.4 Third Normal Form (1)
 Definition:
 Transitive functional dependency: a FD X -> Z
that can be derived from two FDs X -> Y and Y ->
Z
 Examples:
 SSN -> DMGRSSN is a transitive FD
 Since SSN -> DNUMBER and DNUMBER ->
DMGRSSN hold
 SSN -> ENAME is non-transitive
 Since there is no set of attributes X where SSN -> X
and X -> ENAME

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 33 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 34

Third Normal Form (2) Normal Forms Defined Informally

 A relation schema R is in third normal form (3NF) if it is  1st normal form
in 2NF and no non-prime attribute A in R is transitively
dependent on the primary key  All attributes depend on the key
 R can be decomposed into 3NF relations via the process  2nd normal form
of 3NF normalization
 All attributes depend on the whole key
 NOTE:
 In X -> Y and Y -> Z, with X as the primary key, we consider  3rd normal form
this a problem only if Y is not a candidate key.  All attributes depend on nothing but the 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.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 35 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 36

fundamental db system lecture note 9

fundamental db system lecture note

4 General Normal Form Definitions (For

Multiple Keys) (1) General Normal Form Definitions (2)
 The above definitions consider the primary key  Definition:
only  Superkey of relation schema R - a set of attributes
 The following more general definitions take into S of R that contains a key of R
account relations with multiple candidate keys  A relation schema R is in third normal form (3NF)
 A relation schema R is in second normal form if whenever a FD X -> A holds in R, then either:
(2NF) if every non-prime attribute A in R is fully  (a) X is a superkey of R, or
functionally dependent on every key of R  (b) A is a prime attribute of R
 NOTE: Boyce-Codd normal form disallows
condition (b) above

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 37 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 38

5 BCNF (Boyce-Codd Normal Form) Figure 10.12 Boyce-Codd normal form

 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
 Each normal form is strictly stronger than the previous
one
 Every 2NF relation is in 1NF
 Every 3NF relation is in 2NF
 Every BCNF relation is in 3NF
 There exist relations that are in 3NF but not in BCNF
 The goal is to have each relation in BCNF (or 3NF)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 39 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 40

fundamental db system lecture note 10

fundamental db system lecture note

Figure 10.13 a relation TEACH that is in

3NF but not in BCNF Achieving the BCNF by Decomposition (1)
 Two FDs exist in the relation TEACH:
 fd1: { student, course} -> instructor
 fd2: instructor -> course
 {student, course} is a candidate key for this relation and
that the dependencies shown follow the pattern in Figure
10.12 (b).
 So this relation is in 3NF but not in BCNF
 A relation NOT in BCNF should be decomposed so as to
meet this property, while possibly forgoing the
preservation of all functional dependencies in the
decomposed relations.
 (See Algorithm 11.3)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 41 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 42

Achieving the BCNF by Decomposition (2) Chapter Outline

 Three possible decompositions for relation TEACH
 Informal Design Guidelines for Relational
 {student, instructor} and {student, course}

 {course, instructor } and {course, student}

Databases
 {instructor, course } and {instructor, student}  Functional Dependencies (FDs)
 All three decompositions will lose fd1.
 We have to settle for sacrificing the functional dependency
 Definition, Inference Rules, Equivalence of Sets of
preservation. But we cannot sacrifice the non-additivity property FDs, Minimal Sets of FDs
after decomposition.
 Out of the above three, only the 3rd decomposition will not generate  Normal Forms Based on Primary Keys
spurious tuples after join.(and hence has the non-additivity property).
 General Normal Form Definitions (For Multiple
 A test to determine whether a binary decomposition (decomposition
into two relations) is non-additive (lossless) is discussed in section Keys)
11.1.4 under Property LJ1. Verify that the third decomposition above
meets the property.  BCNF (Boyce-Codd Normal Form)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 43 Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 44

fundamental db system lecture note 11