1. Functional Dependencies and Normalization for RDBs
Database Systems
Chapter 10
Functional Dependencies and
Normalization for RDBs
主講人:陳建源
研究室 :法401
日期:99/9/14

2. Outline 1. Informal Guidelines for Relation Schema Design
2. Functional Dependencies
3. Normalization
4. General Normal Form Definitions

3. 1.Data Definition in SQL Schema and Catalog Concepts in SQL2
An SQL schema is identified by
A schema name
An authorization identifier to indicate the user or account who owns the schema
Descriptors for each element in the schema
Schema elements include the tables, constraints, views, domains, and other constructs (such as authorization grants) that describe the schema

4. 1. Informal Guidelines for Relation Schema Design
Four Informal Measures
Semantics of the attributes
Reducing the redundant values in tuples
Reducing the null values in tuples
Disallowing the possibility of generating spurious tuples

5. 1. Informal Guidelines for Relation Schema Design
Semantics of the Relation Attributes
Meaning of semantics: specifies how to interpret the attribute values stored in a tuple of the relation
In general, the easier it is to explain the semantics of the relation, the better the relation schema design will be

7. 1. Informal Guidelines for Relation Schema Design
Design a relation schema so that it is easy to explain its meaning
Do not combine attributes from multiple entity types and relationship types into a single relation
Intuitively, if a relation schema corresponds to one entity type or one relationship type, the meaning tends to be clear

8. 1. Informal Guidelines for Relation Schema Design
Poor design example:
EMP_DEPT mixes attributes of employees and departments
EMP_PROJ mixes attributes of employees and projects

9. 1. Informal Guidelines for Relation Schema Design
Redundant Information in Tuples and Update Anomalies
One goal of schema design is to minimize the storage space of the base relations
Example: compare Fig and 14.4
Redundancy problem
Update anomalies problem

10. 1. Informal Guidelines for Relation Schema Design
Fig 14.2

11. 1. Informal Guidelines for Relation Schema Design

12. 1. Informal Guidelines for Relation Schema Design
Fig 14.4

13. 1. Informal Guidelines for Relation Schema Design

14. 1. Informal Guidelines for Relation Schema Design
Update Anomalies
Insertion anomalies: two situations
To insert a new employee tuple into EMP_DEPT, we must include either the attribute values for the department that the employee works for, or nulls
It is difficult to insert a new department that has no employees as yet in the EMP_DEPT relation

15. 1. Informal Guidelines for Relation Schema Design
Deletion anomalies
If we delete from EMP_DEPT an employee tuple that happens to represent the last employee working for a particular department, the information concerning that department is lost
Modification anomalies
If we change the value of one of the attributes of a particular department, we must update the tuples of all employees in that department to avoid inconsistency

16. 1. Informal Guidelines for Relation Schema Design
Design the base relation schemas so that no insertion, deletion, or modification anomalies are present in the relations
If any anomalies are present, note them clearly and make sure that the programs that update the database will operate correctly

17. 1. Informal Guidelines for Relation Schema Design
Note
To improve the performance of certain queries, these guidelines may sometimes have to be violated
In general, it is advisable to use anomaly-free base relations and to specify views that include the JOINs for placing together the attributes frequently referenced in important queries
Example: Specify EMP_DEPT as a view to speedup query

18. 1. Informal Guidelines for Relation Schema Design
Null Values in Tuples
Problems with null values
Waste space at the storage level
May lead to problems with understanding the meaning of the attributes
The attribute does not apply to this tuple
The attribute value for this tuple is unknown
The value is known but absent
How to account for them when aggregate operations such as COUNT or SUM are applied

19. 1. Informal Guidelines for Relation Schema Design

20. 1. Informal Guidelines for Relation Schema Design

21. 1. Informal Guidelines for Relation Schema Design

22. 1. Informal Guidelines for Relation Schema Design
A NATURAL JOIN on EMP_PROJ1 and EMP_LOCS produces more tuples than those in EMP_PROJ

23. 1. Informal Guidelines for Relation Schema Design
Design relation schemas so that they can be JOINed with equality conditions on attributes that are either primary keys or foreign keys in a way that guarantees that no spurious tuples are generated
Do not have relations that contain matching attributes other than foreign key-primary key combinations
If such relations are unavoidable, do not join them on such attributes

24. 2. Functional Dependencies
Definition
Consider a relation schema R = {A1, A2, …, An}. A functional dependency, denoted by X  Y, for X, Y  R, specifies a constraint on a relation state r of R such that for any two tuples t1 and t2 in r,
if t1[X] = t2[X], we must have t1[Y] = t2[Y].
Note: if X is a candidate key of R, this implies that X  Y for any subset of attributes Y of R

25. 2. Functional Dependencies
Meaning
The Y component of a tuple in r depend on, or are determined by, the values of the X component
The values of the X component of a tuple uniquely (or functionally) determine the values of the Y component
We also say that there is a functional (FD) dependency from X to Y or that Y is functionally dependent on X

26. 2. Functional Dependencies
Example: Relation schema EMP_PROJ
1. SSN  ENAME
2. PNUMBER  {PNAME, PLOCATION}
3. {SSN, PNUMBER}  HOURS

27. 2. Functional Dependencies
Notice
A functional dependency is a property of the relation schema (intension) R, not of a particular legal relation state (extension) r of R.
An FD cannot be inferred automatically from a given relation extension r but must be defined explicitly by someone who knows the semantics of the attributes of R.

28. 2. Functional Dependencies
Inference Rules for FDs
F: the set of functional dependencies specified on a relation schema R
Other dependencies can be inferred or deduced from the FDs in F
The set of all such dependencies is called the closure of F and is denoted by F+

29. 2. Functional Dependencies
Example
Let F = {SSN  {ENAME, BDATE, ADDRESS, DNUMBER}, DNUMBER  {DNAME, DMGRSSN}}
We can infer the following additional FDs
SSN  {DNAME, DMGRSSN},
SSN  SSN,
DNUMBER  DNAME

30. 2. Functional Dependencies
Inference rules
The rules that can be used to infer new dependencies from a given F
Notation F  X  Y: X  Y is inferred from the set F
For simplicity,
{X, Y}  Z is abbreviated to XY  Z
{X, Y, Z}  {U, V} is abbreviated to XYZ  UV
There are six well defined rules

31. 2. Functional Dependencies
IR1 (reflexive rule): If X  Y, then X  Y
IR2 (augmentation rule): {X  Y } XZ  YZ
IR3 (transitive rule): {X  Y, Y  Z} X  Z
IR4 (decomposition, or projective, rule):
{X  YZ} X  Y.
IR5 (union, or additive, rule):
{X  Y, X  Z} X  YZ
IR6 (pseudotransitive rule):
{X  Y, WY  Z } WX  Z

32. 2. Functional Dependencies
IR1 through IR3 are known as Armstrong’s inference rules
It has been shown by Armstrong (1974) that inference rules IR1 through IR3 are sound and complete
In other words, the set of dependencies, which we called the closure of F, can be determined from F by using only inference rules IR1 through IR3

33. 3. Normalization Introduction Normalization of data
A process of analyzing the given relation schemas based on their FDs and primary keys to achieve the desirable properties of
(1) minimizing redundancy
(2) minimizing the insertion, deletion, and update
anomalies
Unsatisfactory relation schemas that do not meet the normal form tests are decomposed into smaller relation schemas

34. 3. Normalization History
Initially, Codd (1972a) proposed three normal forms based on FD, which he called first, second, and third normal form
A stronger definition of 3NF—called Boyce-Codd normal form (BCNF)—was proposed later by Boyce and Codd
Later, a fourth normal form (4NF) and a fifth normal form (5NF) were proposed, based on the concepts of multivalued dependencies and join dependencies

35. 3. Normalization
Notice
Normal forms, when considered in isolation from other factors, do not guarantee a good database design
The lossless join or nonadditive join property, which guarantees that the spurious tuple generation problem
The dependency preservation property, which ensures that each functional dependency is represented in some individual relations resulting after decomposition

36. 3. Normalization
The database designers need not normalize to the highest possible normal form.
Relations may be left in a lower normalization status for performance reasons
The process of storing the join of higher normal form relations as a base relation—which is in a lower normal form—is known as denormalization

37. 3. Normalization Related terminology Example -- WORKS_ON relation
Prime attribute
An attribute of relation schema R is called a prime attribute of R if it is a member of some candidate key of R
Nonprime attribute
An attribute is called nonprime if it is not a prime attribute
Example -- WORKS_ON relation
prime: both SSN and PNUMBER
nonprime: others

38. 3. Normalization First Normal Form (1NF)
Historically, it was defined to disallow multivalued attributes, composite attributes, and their combinations
The domain of an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute

39. 3. Normalization Example
Not in 1NF because DLOCATIONS is not an atomic attribute

40. 3. Normalization Three main techniques to achieve 1NF
1. Decomposes the non-1NF relation into two 1NF relations

41. 3. Normalization 2. Expand the key to distinguish each tuple
Has the disadvantage of introducing redundancy
3. Divide the attribute into several atomic attributes
DLOCATIONS => DLOCATION1, DLOCATION2, and DLOCATION3
The maximum number of values needs to be known
Has the disadvantage of introducing null values

42. 3. Normalization
The first is superior because it does not suffer from redundancy and it is completely general
The first normal form also disallows multivalued, composite attributes
These are called nested relations
For example:
EMP_PROJ(SSN, ENAME, {PROJS(PNUMBER, HOURS)})
PROJS is a multivalued, composite attribute

43. 3. Normalization

44. 3. Normalization
Technique to normalize multivalued, composite attributes into 1NF
Remove the nested relation attributes into a new relation
Propagate the primary key into new relation

45. 3. Normalization Second Normal Form (2NF)
2NF is based on the concept of full functional dependency
X  Y is a full functional dependency if removal of any attribute A from X invalidates the dependency
X  Y is a partial dependency if some attribute A  X can be removed and the dependency still holds

46. 3. Normalization Example {SSN, PNUMBER}  HOURS is a full dependency
{SSN, PNUMBER}  ENAME is partial

47. 3. Normalization Testing for 2NF
The test for 2NF involves testing for functional dependencies whose left-hand side attributes are part of the primary key
If the primary key contains a single attribute, the test need not be applied at all
A relation schema R is in 2NF if every nonprime attribute A in R is fully functionally dependent on the primary key of R

48. 3. Normalization Method for normalizing a non-2NF relation Example
EMP_PROJ is in 1NF but not in 2NF
The nonprime attribute ENAME violates 2NF because FD2 is partial
The nonprime attributes PNAME and PLOCATION also violates 2NF because FD3 is partial
Method for normalizing a non-2NF relation
Divide the relation into several relations in which nonprime attributes are associated only with the part of the primary key on which they are fully functionally dependent

49. 3. Normalization

50. 3. Normalization Third Normal Form (3NF)
3NF is based on the concept of transitive dependency
X  Y in a relation schema R is a transitive dependency if there is a set of attributes Z that is neither a candidate key nor a subset of any key of R, and both X  Z and Z  Y hold

51. 3. Normalization Example Both SSN  DNUMBER and DNUMBER  DMGRSSN hold
DNUMBER is neither a key nor a subset of the key of EMP_DEPT
SSN  DMGRSSN is a transitive dependency

52. 3. Normalization Testing for 3NF
A relation schema R is in 3NF if it satisfies 2NF and no nonprime attribute of R is transitively dependent on the primary key
Example: the EMP_DEPT relation
Method for normalizing a non-3NF relation
Decompose and set up a relation that includes the nonkey attribute(s) that functionally determine(s) other nonkey attribute(s)

53. 3. Normalization
Example

54. 4. General Normal Form Definitions
Preliminary
The above definitions consider the primary key only
We have to consider more general definitions that take into account relations with multiple candidate keys
General definition of prime attribute
An attribute that is part of any candidate key will be considered as prime

55. 4. General Normal Form Definitions
General Definition of 2NF
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
Example: relation schema LOTS
Two candidate keys: PROPERTY_ID# and {COUNTY_NAME, LOT#}
FD1 and FD2 hold
Assume FD3 and FD4 also hold

56. 4. General Normal Form Definitions
TAX_RATE is partially dependent on the candidate key {COUNTY_NAME, LOT#}, due to FD3
LOTS not in general 2NF

57. 4. General Normal Form Definitions
Normalization to general 2NF
Decompose it into the two relations LOTS1 and LOTS2

58. 4. General Normal Form Definitions
General Definition of 3NF
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
Superkey of relation schema R
A set of attributes S of R that contains a key of R

59. 4. General Normal Form Definitions
Example
LOTS2 is in general 3NF
FD4 in LOTS1 violates 3NF
AREA is not a superkey
PRICE is not a prime attribute in LOTS1

60. 4. General Normal Form Definitions
Normalization LOTS1 to general 3NF
Decompose it into the relation schemas LOTS1A and LOTS1B

61. 4. General Normal Form Definitions
Boyce-Codd Normal Form
Definition
A relation schema R is in Boyce-Codd Normal Form (BCNF) if whenever a nontrivial FD X  A holds in R, then X is a superkey of R
BCNF is stronger than 3NF
Every relation in BCNF is also in 3NF; however, a relation in 3NF is not necessarily in BCNF
The only difference is that condition (b) of 3NF

62. 4. General Normal Form Definitions
Example -- LOTS1A
Suppose that
There are only two counties: Dekalb and Fulton
Lot sizes in Dekalb: restricted to 0.5, 0.6, ...,1.0 acres
Lot sizes in Fulton: restricted to 1.1, 1.2, ..., 2.0 acres
There is an additional FD in relation LOTS1A
FD5: AREA  COUNTY_NAME

63. 4. General Normal Form Definitions
It is still is in 3NF because COUNTY_NAME is a prime attribute
FD5 violates BCNF in LOTS1A because AREA is not a superkey of LOTS1A
We can decompose LOTS1A into two BCNF relations LOTS1AX and LOTS1AY
In LOTS1AY, there are only 16 possible AREA values
This reduces the redundancy in LOTS1A tuples
But it loses the functional dependency FD2

64. 4. General Normal Form Definitions

65. 4. General Normal Form Definitions
Summary
Most relation 3NF schemas are also in BCNF
Only if FD X  A holds in R with X not being a superkey and A being a prime attribute will R be in 3NF but not in BCNF
General form

66. 4. General Normal Form Definitions
Example -- TEACH
FD1: {STUDENT, COURSE}  INSTRUCTOR
FD2: INSTRUCTOR  COURSE

67. 4. General Normal Form Definitions
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