07 FDs Normalization

8/9/2019 07 FDs Normalization

http://slidepdf.com/reader/full/07-fds-normalization 1/86

Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke 1

Schema Refinement and

Normal FormsChapter 19




The Evils of Redundancy

Redundancy is at the root of several problemsassociated with relational schemas: redundant storage, insert/delete/update anomalies

Integrity constraints, in particular functionaldependencies, can be used to identify schemas withsuch problems and to suggest refinements.

Main refinement technique: decomposition (replacingABCD with, say, AB and BCD, or ACD and ABD).

Decomposition should be used judiciously: Is there reason to decompose a relation?

What problems (if any) does the decomposition cause?




Functional Dependencies (FDs)

A functional dependency X→Y holds over relation Rif, for every allowable instance r of R: t1 r, t2 r, (t1) = (t2) implies (t1) = (t2)

i.e., given two tuples in r , if the X values agree, then the Yvalues must also agree. (X and Y are sets of attributes.)

An FD is a statement about all allowable relations. Must be identified based on semantics of application.

Given some allowable instance r1 of R, we can check if itviolates some FD f , but we cannot tell if f holds over R!

K is a candidate key for R means that K→R

However, K→R does not require K to be minimal!




Example: Constraints on Entity Set

Consider relation obtained from Hourly_Emps: Hourly_Emps (ssn, name, lot, rating, hrly_wages, hrs_worked)

Notation: We will denote this relation schema by

listing the attributes: SNLRWH This is really the set of attributes {S,N,L,R,W,H}.

Sometimes, we will refer to all attributes of a relation byusing the relation name. (e.g., Hourly_Emps for SNLRWH)

Some FDs on Hourly_Emps: ssn is the key: S→SNLRWH

rating determines hrly_wages: R→W



Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke

Example (Contd.)

5

Problems due to R→

W : Update anomaly: Can

we change W in justthe 1st tuple of SNLRWH?

Insertion anomaly: What ifwe want to insert an

employee and don’t knowthe hourly wage for hisrating?

Deletion anomaly: If wedelete all employees withrating 5, we lose the

information about thewage for rating 5!

Hourly_Emps2

Wages

Will 2 smaller tables be better?




Reasoning About FDs

Given some FDs, we can usually infer additional FDs: ssn→did, did→lot implies ssn→lot

An FD f is implied by a set of FDs F if f holdswhenever all FDs in F hold. = closure of F is the set of all FDs that are implied by F .

Armstrong’s Axioms (X, Y, Z are sets of attributes): Reflexivity: If X⊆Y, then Y→X

Augmentation: If X→Y, then XZ→YZ for any Z

Transitivity: If X→Y and Y→Z, then X→Z

These are sound and complete inference rules for FDs!




Reasoning About FDs (Contd.)

Couple of additional rules (that follow from AA): Union: If X→Y and X→Z, then X→YZ

Decomposition: If X→YZ, then X→Y and X→Z

Example: Contracts(cid,sid,jid,did,pid,qty,value), and: C is the key: C→CSJDPQV

Project purchases each part using single contract: JP→C

Dept purchases at most one part from a supplier: SD→P

JP→

C, C→

CSJDPQV imply JP→

CSJDPQV SD→P implies SDJ→ JP

SDJ→ JP, JP→CSJDPQV imply SDJ→CSJDPQV




Reasoning About FDs (Contd.)

Computing the closure of a set of FDs can beexpensive. (Size of closure is exponential in # attrs!)

Typically, we just want to check if a given FD X →Y is

in the closure of a set of FDs F . An efficient check: Compute attribute closure of X (denoted ) wrt F:

• Set of all attributes A such that X→A is in

• There is a linear time algorithm to compute this.

Check if Y is in

Does F = {A→B, B→C, C D→E } imply A→E? i.e, is A→E in the closure ? Equivalently, is E in ?




Normalization

“There are two rules in life:

Rule #1: Don’t sweat the small stuff.

Rule #2: Everything is small stuff.”

(Finn Taylor)

Life is as complicated as we make it—normalization

can be simplified.☻




Normal Forms

Returning to the issue of schema refinement, the firstquestion to ask is whether any refinement is needed!

If a relation is in a certain normal form (BCNF, 3NF

etc.), it is known that certain kinds of problems areavoided/minimized. This can be used to help usdecide whether decomposing the relation will help.

Role of FDs in detecting redundancy: Consider a relation R with 3 attributes, ABC.

• No FDs hold: There is no redundancy here.

• Given A→B: Several tuples could have the same Avalue, and if so, they’ll all have the same B value!




Normalization

What is normalization?

In general, normalization removesduplication and minimizes redundant chunksof data.

The result is better organization and moreeffective use of physical space, among otherfactors.

Normalization is not always the best solution!

11




1NF: First Normal Form

Eliminate repeating fields. Furthermore, allfields must contain a single value.

Define primary keys. All records must beidentified uniquely with a primary key. Aprimary key is unique and thus no duplicatevalues are allowed.

All fields other than the primary key mustdepend on the primary key, either directly orindirectly.

12





13

Table in 0thNormal Form!







apply 1NF: removerepeating fields bycreating a new table

where the originaland new table arelinked in a one-to-many relationship.

15





apply 1NF: assignprimary keys

16




2NF: Second Normal Form

The table must be in 1NF.

All non-key values must be fully functionallydependent on the primary key. In other words,non-key fields not completely and individuallydependent on the primary key are not allowed.

Partial dependencies must be removed. Apartial dependency is a special type of

functional dependency that exists when a fieldis fully dependent on a part of a compositeprimary key.

17





Full functional dependence

given: X→Y

Y depends on X and X alone therefore

in: XZ→Y

Y is not in full functional dependence

Y is partially dependent on the compositekey XZ

18





Partial Dependency

19

Key Attributes XAttribute ACase 1:

A not in Key










Table in 1NF!





2NF performs a seemingly similar function tothat of 1NF, but creates a table whererepeating values rather than repeating fields

are removed to a new table. Typically, 2NF creates one-to-many

relationships between static and dynamic,removing static data from transactional tables

into new tables.

23




separate staticdata fromdynamic data

is this in 2NFalready?

24




connect thetables with theproperrelationship

(one-to-one orone-to-many)


25




all tables musthave a primarykey (1NFrequirement!)


26














Is this in 2NF??

30





Is this in 2NF??

31

✕

✔




3NF: Third Normal Form


Eliminate transitive dependencies.

A transitive dependency is where a field isindirectly determined by the primary keybecause that field is functionally dependenton a second field, where that second field isdependent on the primary key.

In basic terms, every field in a table that isnot a key field must be directly dependenton the primary key.

32





Transitive Dependency

33

Key Attributes X Attribute A

KeyAttributes X

Attribute A

Case 1:A not in Key

Case 2:

A is in Key




many-to-many relationships! how to search for single taskassigned to a single employee?




3NF Transformation! decomposition of entities

involved in a many-to-many relationship




3NF Transformation! amalgamating duplication

into a new table




3NF Transformation! transitive dependency

removed

a transitive dependency exists because it is

assumed that:1. each employee is

assigned to a

particular department2. each department withina company is exclusivelybased in one specific city

CAUTION: too many

tables will result to slower queries having to join too

many tables




3NF Transformation! remove calculated fields




Third Normal Form (3NF)

Reln R with FDs F is in 3NF if, for all X→A in A∈X (called a trivial FD), or

X contains a key for R, or

A is part of some key for R.

Minimality of a key is crucial in third condition above!

If R is in 3NF, some redundancy is possible. It is acompromise, used when BCNF not achievable. Lossless-join, dependency-preserving decomposition of R into a

collection of 3NF relations always possible.





Is this in 2NF??

40

?





Is this in 2NF??

41

✔

all the nonkey attributes (B and C) are fully dependent on the

primary key (A)





Is this in 3NF??

42

?





Is this in 3NF??

43

✕

C, which is a nonkey attribute, is also functionally dependent on

B, which is also a nonkey attribute. Therefore, the relation R isnot in 3NF.





Is this in 3NF??

44

✕

✔




BCNF: Boyce-Codd Normal Form


A table can have only one candidate key.

A candidate key has potential for being atable’s primary key.

A table is not allowed more than oneprimary key because referential integrityrequires it as such.

45





BCNF is an odd one because it is a little like aspecial case of 3NF.

BCNF requires that every determinant in a

table is a candidate key. If there is only one candidate key, 3NF and

BCNF are the same.

Essentially, BCNF prohibits a table from having

two possible primary keys.

46




BCNF Transformation!




Boyce-Codd Normal Form (BCNF)

Reln R with FDs F is in BCNF if, for all X→A in A∈X (called a trivial FD), or

X contains a key for R.

In other words, R is in BCNF if the only non-trivialFDs that hold over R are key constraints. No dependency in R that can be predicted using FDs alone.

If we are shown two tuples that agree uponthe X value, we cannot infer the A value in

one tuple from the A value in the other. If example relation is in BCNF, the 2 tuples

must be identical (since X is a key).





Is this in 2NF??

49

?





Is this in 2NF??

50

✕

The R relation is not in 2NF because, like before, C is in a partial dependence with the primary key.





Is this in 2NF??

51

✕?





Is this in 2NF??

52

✕

✕We can’t because we lose an FD, namely D→ C. Therefore, we

need to find another decomposition.





Is this in 2NF??

53

✕?





Is this in 2NF??

54

✕✔

With this decomposition, no FDs are lost. And the resulting relations are in 2NF.







Is this in 3NF??

56

✕✔

The resulting relations are not only in 2NF, but they are also in3NF.





Is this in BCNF??

57

?





Is this in BCNF??

58

✕

B and D are determinants and are not candidate keys. Therefore,the relation R2 is not in BCNF, while the relation R1 is.





Is this in BCNF??

59

✕

✔





Normalized Form!

60

✔




Recap!

1st Normal Form (1NF)—Eliminate repeating groupssuch that all records in all tables can be identifieduniquely by a primary key in each table.

2nd Normal Form (2NF)—All non-key values must befully functionally dependent on the primary key. Nopartial dependencies are allowed.

3rd Normal Form (3NF)—Eliminate transitivedependencies.

Boyce-Codd Normal Form (BCNF)—Everydeterminant in a table is a candidate key.




Decomposition of a Relation Scheme

Suppose that relation R contains attributes A1 ... An.A decomposition of R consists of replacing R by two ormore relations such that: Each new relation scheme contains a subset of the attributes

of R (and no attributes that do not appear in R), and Every attribute of R appears as an attribute of one of the

new relations.

Intuitively, decomposing R means we will store

instances of the relation schemes produced by thedecomposition, instead of instances of R.

E.g., Can decompose SNLRWH into SNLRH and RW.




Example Decomposition

Decompositions should be used only when needed. SNLRWH has FDs S→SNLRWH and R→W

Second FD causes violation of 3NF; W values repeatedlyassociated with R values.

Easiest way to fix this is to create a relation RW to storethese associations, and to remove W from the main schema:

• i.e., we decompose SNLRWH into SNLRH and RW




Problems with Decompositions

There are three potential problems to consider:

Some queries become more expensive.

• e.g., How much did sailor Joe earn? (salary = W*H)

Given instances of the decomposed relations, we may notbe able to reconstruct the corresponding instance of theoriginal relation!

• Fortunately, not in the SNLRWH example.

Checking some dependencies may require joining the

instances of the decomposed relations.• Fortunately, not in the SNLRWH example.

Tradeoff : Must consider these issues vs. redundancy.




Problems with Decompositions

Illustration of a Lossy Decomposition




Lossless Join Decompositions

Decomposition of R into X and Y is lossless-join w.r.t. aset of FDs F if, for every instance r that satisfies F: (r ) (r ) = r

It is always true that r (r ) (r ) In general, the other direction does not hold! If it does, the

decomposition is lossless-join.

Definition extended to decomposition into 3 or morerelations in a straightforward way.

It is essential that all decompositions used to deal withredundancy be lossless! (Avoids Problem (2).)




More on Lossless Join

The decomposition of R into X and Y islossless-join wrt F if and only if the closure ofF contains: X∩Y → X, or

X∩Y → Y

in other words, the attributes common to X and Ymust contain a key for either X or Y

In particular, the decomposition of R into

R - Y and XY is lossless-join if X→ Y holdsover R.




Dependency Preserving Decomposition

Consider CSJDPQV, C is key, JP→C and SD→P. BCNF decomposition: CSJDQV and SDP

Problem: Checking JP→C requires a join!

This is NOT a dependency-preserving decomposition!!

Dependency preserving decomposition (Intuitive): If R is decomposed into X, Y and Z, and we enforce the FDs

that hold on X, on Y and on Z, then all FDs that were givento hold on R must also hold. (Avoids Problem (3).)

A dependency preserving decomposition allows us toenforce all FDs by examining a single relation instance oneach insertion and update.




Dependency Preserving Decomposition

Projection of set of FDs F : If R is decomposed into Xand Y, and let F be a set of FDs over R. The projectionof F on X (denoted FX ) is the set of FDs in the closure

of F+ (not just F) that involve only attributes of X.

U→V is in FX iff U, V are in X.

Decomposition of R into X and Y is dependency preserving if (FX ∪ FY ) + = F +




Dependency Preserving Decompositions(Contd.)

Important to consider F +, not F, in this definition: Consider relation R with attributes ABC

decomposed into AB and BC

FDs of R (F) : A→B, B→C, C→A

A→B is in FAB, B→C is in FBC

Is this dependency preserving? Is C→A preserved?????

Dependency preserving does not imply lossless join: ABC, A→B, decomposed into AB and BC.

And vice-versa! (Example?)




Decomposition into BCNF

Consider relation R with FDs F. If X→Y violatesBCNF, decompose R into R - Y and XY. Repeated application of this idea will give us a collection of

relations that are in BCNF; lossless join decomposition, andguaranteed to terminate.

e.g., CSJDPQV, key C, JP→C, SD→P, J→S

To deal with SD→P, decompose into SDP, CSJDQV.

To deal with J→S, decompose CSJDQV into JS and CJDQV





Decomposition of CSJDPQV





The decomposition of CSJDQV into SDP, JS, andCJDQV is not dependency-preserving. JP→C cannotbe enforced without a join.

One way to deal with this situation is to add a relationwith attributes CJP. In effect, this solution amounts tostoring some information redundantly in order tomake the dependency enforcement cheaper.

Problem: Redundancy across relations!!





Suppose that we choose to decompose CSJDPQVinto JS and CJDPQV instead (choose J→S first!).

The only dependencies that hold over CJDPQV are

JP→C and the key dependency C→CJDPQV. Since JPis a key, CJDPQV is in BCNF.

Thus, the schemas JS and CJDPQV represent alossless-join decomposition of Contracts into BCNF

relations too! designer must discriminate among alternatives!




BCNF and Dependency Preservation

In general, there may not be a dependency preservingdecomposition into BCNF. e.g., CSZ, CS→Z, Z→C

Can’t decompose while preserving 1st FD; not in BCNF.

Similarly, decomposition of CSJDQV into SDP, JS andCJDQV is not dependency preserving (w.r.t. the FDs

JP→C, SD→P and J→S). However, it is a lossless join decomposition.




Decomposition into 3NF

Clearly, the algorithm for lossless join decomp intoBCNF can be used to obtain a lossless join decompinto 3NF (can stop earlier).

Refinement: Instead of the given set of FDs F, use aminimal cover for F .

the resulting decomposition will be lossless join anddependency preserving!




Minimal Cover for a Set of FDs

Minimal cover G for a set of FDs F: Closure of F = closure of G.

Right hand side of each FD in G is a single attribute.

If we modify G by deleting an FD or by deleting attributes

from an FD in G, the closure changes. Intuitively, every FD in G is needed, and ``as small as

possible’’ in order to get the same closure as F.

e.g., A→B, ABCD→E, EF→GH, ACDF→EG has the

following minimal cover: A→B, ACD→E, EF→G and EF→H





Given (F): A→ B, ABCD→ E, EF→ G, EF→H, ACDF→ EG

rewrite ACDF→ EG ACDF→ E and ACDF→ G

delete ACDF→ G bec. it is implied by the ff FDs: A→ B, ABCD→ E, EF→ G

delete ACDF→ E, and so on.

Minimal Cover: A→ B, ACD→ E, EF→ G, and EF→H







What is the minimal cover of: ABCD→ E, E→ D, A→ B, and AC→ D





What is the minimal cover of: ABCD→ E, E→ D, A→ B, and AC→ D

FDs are already in standard form.

Minimize the left side of each FD: AC→ E, E→ D, A→ B, and AC→ D

Delete redundant FDs: AC→ E, E→ D implies AC→ D

Minimal Cover: AC→ E, E→ D, and A→ B





Refined algo for a 3NF decomposition which islossless join and dependency preserving :

Consider relation R with FDs G that is a minimal cover. If

X→Y violates 3NF, decompose R into R - Y and XY. For each FD X→A in G that is not preserved, create a

relation schema XA and add it to the decomposition of R





Consider the Contracts relation with attributesCSJDPQV and FDs JP→ C, SD→ P, and J→ S.

If we decompose CSJDPQV into SDP and CSJDQV, thenSDP is in BCNF, but CSJDQV is not even in 3NF.

So we decompose it further into JS and CJDQV.

The relation schemas SDP, JS, and CJDQV are in 3NF (infact, in BCNF), and the decomposition is lossless-join.However, the dependency JP→ C is not preserved.

This problem can be addressed by adding a relation schemaCJP to the decomposition.




3NF vs BCNF

It is always possible to decompose a relation intorelations in 3NF and

The decomposition is lossless

Dependencies are preserved

It is always possible to decompose a relation intorelations in BCNF and

The decomposition is lossless

It may not be possible to preserve dependencies

But a schema that is in 3NF but not in BCNF maycontain redundancy




Refining an ER Diagram

1st diagram translated:Workers(S,N,L,D,C)Departments(D,M,B) Lots associated with workers.

Suppose all workers in a

dept are assigned the samelot: D→L

Redundancy; fixed by:Workers2(S,N,D,C)Dept_Lots(D,L)

Can fine-tune this:Workers2(S,N,D,C)Departments(D,M,B,L)

lot

dname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn

lot

dname

budget

did

sincename

Works_In DepartmentsEmployees

ssn

Before:

After:



Summary of Schema Refinement

If a relation is in BCNF, it is free of redundancies thatcan be detected using FDs. Thus, trying to ensurethat all relations are in BCNF is a good heuristic.

If a relation is not in BCNF, we can try to decompose

it into a collection of BCNF relations. Must consider whether all FDs are preserved. If a lossless-

join, dependency preserving decomposition into BCNF isnot possible (or unsuitable, given typical queries), shouldconsider decomposition into 3NF.

Decompositions should be carried out and/or re-examinedwhile keeping performance requirements in mind.

Documents

07 FDs Normalization