0% found this document useful (0 votes)
160 views80 pages

Relational Database Design

The document discusses relational database design and normalization. It covers pitfalls in relational design like repetition of data, decomposition to reduce redundancy, functional dependencies and normal forms to achieve lossless joins and avoid update anomalies. Normalization is the process of organizing data to avoid inconsistencies caused by redundant or irrelevant data.

Uploaded by

Sayantan Jana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
160 views80 pages

Relational Database Design

The document discusses relational database design and normalization. It covers pitfalls in relational design like repetition of data, decomposition to reduce redundancy, functional dependencies and normal forms to achieve lossless joins and avoid update anomalies. Normalization is the process of organizing data to avoid inconsistencies caused by redundant or irrelevant data.

Uploaded by

Sayantan Jana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 80

Relational Database Design

Pitfalls in Relational-Database Design


Decomposition
Functional Dependency
Normalization: Normal Forms
Higher Order Normal Form

1 [email protected]
Relational Database Design

Goal: To generate a set of relation schemas that allows


us to store information without unnecessary
redundancy through the concept of normalization.

2 [email protected]
Pitfalls in Relational-Database Design

① Repetition of information
② Inability to represent certain information

Lending-schema=(branch-name, branch-city, assets,


customer-name, loan-number, amount)

3 [email protected]
Pitfalls in Relational-Database Design

branch- branch-city assets customer loan- amount


name -name number
Downtown Brooklyn 9000000 Jones L-17 1000
Redwood Palo Alto 2100000 Smith L-23 2000
Perryridge Horseneck 1700000 Hayes L-15 1500
Downtown Brooklyn 9000000 Jackson L-14 1500
Mianus Horseneck 400000 Jones L-93 500
Round Hill Horseneck 8000000 Turner L-11 900

4 [email protected]
Pitfalls in Relational-Database Design

① Add a new loan


The loan is sanctioned by the Perryridge branch to
Adams and the amount is $1500. Let the loan-number be
L-31.

(Perryridge, Horseneck, 1700000,Adams, L-31, 1500)


Repeating information wastes space.
Repeating information complicates the updation.

5 [email protected]
Pitfalls in Relational-Database Design

② We cannot represent directly the information


concerning a branch(branch-name, branch-city, assets)
unless there exists at least one loan at the branch. The
problem is that tuples in the lending relation require
values for loan-number, amount and customer-name.

Solution:
Introduce null values to handle updates through
views.(difficult)

6 [email protected]
Decomposition

Decompose into smaller relations (tables) with


fewer attributes to solve the said problem. But
careless decomposition, however, many lead to another
form of bad design.

7 [email protected]
Decomposition

:
Consider an alternative design in which Lending-schema is
decomposed into the following two schemas:

Branch-customer-schema=(branch-name, branch-city,
assets,customer-name)
Customer-loan-schema=(customer-name,loan-number,
amount)

8 [email protected]
Decomposition

branch- branch-city assets customer customer loan- amount


name -name -name number
Downtown Brooklyn 9000000 Jones Jones L-17 1000
Redwood Palo Alto 2100000 Smith Smith L-23 2000
Perryridge Horseneck 1700000 Hayes Hayes L-15 1500
Downtown Brooklyn 9000000 Jackson Jackson L-14 1500
Mianus Horseneck 400000 Jones Jones L-93 500
Round Hill Horseneck 8000000 Turner Turner L-11 900

Branch-customer B Customer-loan C

9 [email protected]
Decomposition
Find all branches that have loans with amount less than $1000.
branch- branch-city assets customer loan- amount
name -name number
Downtown Brooklyn 9000000 Jones L-17 1000
Downtown Brooklyn 9000000 Jones L-93 500
Redwood Palo Alto 2100000 Smith L-23 2000
Perryridge Horseneck 1700000 Hayes L-15 1500
Downtown Brooklyn 9000000 Jackson L-14 1500
Mianus Horseneck 400000 Jones L-17 1000
Mianus Horseneck 400000 Jones L-93 500
Round Hill Horseneck 8000000 Turner L-11 900

10 [email protected]
Decomposition
Problems:
Additional tuples:
(Downtown, Brooklyn, 9000000,Jones, L-93, 500)
(Mianus, Horsereck, 400000,Jones, L-17, 1000)
Consider the query, “Find all branches that have made
a loan in an amount less than $1000”.
From the un-decomposed table: Mianus Round Hill
∏branch-name(amount<1000(branch-customer
customer-loan))
Through join between decomposed table:
11 [email protected]
Mianus Round Hill Downtown
Lossy Decomposition
We have more tuples (Spurious tuples) in the joined tables
but actually have less information.

We are no longer able, in general, to represent which


customers are borrowers from which branch.

We call the decomposition of Lending-schema into Branch-


customer-schema and customer-loan-schema as a lossy
decomposition or a lossy-join decomposition.

12 [email protected]
Lossless Decomposition

Lossless-join decomposition: A decomposition that is


not a lossy-join decomposition is a lossless-join
decomposition.
 Let R be a relation schema and let F be a set of FDs over R.
A decomposition of R into two schemas with attribute sets X
and Y is said to be a lossless-join decomposition with
respect to F if for every instance r of R that satisfies the
dependencies in F,
 All decompositions used to eliminate redundancy must be
lossless.
13 [email protected]
Functional Dependency

14 [email protected]
Functional Dependency

15 [email protected]
Trivial Dependency

 The Set of FDs need to be reduced.


 Trivial dependencies should be eliminated.
 A dependency is said to be trivial iff the RHS
is a subset (not necessarily proper subset) of
the LHS. [S#, P#]------> S#....trivial
 We should be concern on non-trivial
dependencies.

16 [email protected]
Functional Dependency

 The set of all FDs that are implied by a given


set S of FD, is called the closure of S. [S+]
 Reflexivity: If B is a subset of A; then A  B.
 Augmentation: If A  B; Then ACBC.
 Transitivity: If AB & BC; then ABC.
 Self Determination: AA.
 Decomposition: If ABC, Then AB & AC.
 Union: If AB & AC; then ABC.
 Composition: If AB & CD; then ACBD.

17 [email protected]
An example

18 [email protected]
Closure of a Set

19 [email protected]
Closure of a set of attributes

 How to compute a certain subset of the


closure?
 Given: a relation R, a set of attribute Z, a set of
FD,S holds in R; How to compute a set of all
attributes of R that is functionally dependent on
Z under S? [Closure of Z+ of Z under S]

20 [email protected]
Computation: Closure of a set of attributes

21 [email protected]
Attribute Closure: Uses

22 [email protected]
Closure: Findings

 Given a set S of FDs, we can tell whether a


given FD xy follows from S or not.
 The FD will follow iff y is a subset of the
closure x+ of x under S.
 We can say a given FD is in the closure of S+
of S without computing S+ .

23 [email protected]
Irreducible Set of Dependencies

 Let S1 & S2 be two sets of FD in a relation R. If S1+ is


a subset of S2+ , then we can say S2 is a cover of S1.
 A set S of FD will be irreducible iff the following
properties are hold.
– The right side of every FD is a singleton set.
– No attribute can be discarded without changing the closure of
S.
– No FD can be discarded without changing the closure of S.
– For every set of FD, there exists at least one equivalent set
that is irreducible but may not be unique.

24 [email protected]
A typical example

25 [email protected]
A typical example

26 [email protected]
Lossless Join Decomposition

Lossless-join Decomposition:
Criterion for detecting lossy decomposition

Let R be a relation schema and F be a set of functional


dependencies on R. The decomposition of R into (R1, R2) is
a lossless-join decomposition of R if at least one of the
following functional dependencies are in F+.
① R1∩R2→R1

② R1∩R2→R2
27 [email protected]
Example

branch- branch-city assets customer loan- amount


name -name number
Downtown Brooklyn 9000000 Jones L-17 1000
Redwood Palo Alto 2100000 Smith L-23 2000
Perryridge Horseneck 1700000 Hayes L-15 1500
Downtown Brooklyn 9000000 Jackson L-14 1500
Mianus Horseneck 400000 Jones L-93 500
Round Hill Horseneck 8000000 Turner L-11 900

28 [email protected]
Example: Decomposition

branch- branch-city assets customer customer loan- amount


name -name -name number
Downtown Brooklyn 9000000 Jones Jones L-17 1000
Redwood Palo Alto 2100000 Smith Smith L-23 2000
Perryridge Horseneck 1700000 Hayes Hayes L-15 1500
Downtown Brooklyn 9000000 Jackson Jackson L-14 1500
Mianus Horseneck 400000 Jones Jones L-93 500
Round Hill Horseneck 8000000 Turner Turner L-11 900

Branch-customer B Customer-loan C

29 [email protected]
Lossless Decomposition

 In the previous example B intersection C


implies Customer name but it not functionally
determines the whole B or C. Thus the
decomposition is lossy.

30 [email protected]
Lossless Decomposition

Example:
Let us consider an alternative decomposition on the same
relation.

① Branch-schema=(branch-name,branch-city, assets)
Loan-info-schema=(branch-name,customer-
name,loan-number, amount)
Branch-schema∩Loan-info-schema={branch-name}
branch-name→{branch-name,branch-city,assets}
31 [email protected]
Lossless Decomposition

② Loan-info-schema
Loan-schema=(branch-name, loan-number, amount)
Borrower-schema=(customer-name, loan-number)
Loan-schema∩Borrower-schema={loan-number}
loan-number→{loan-number,branch-name,amount}

This step results in a lossless-join decomposition.

32 [email protected]
First Normal Form

33 [email protected]
Anomalies

 The city value for a specific customer occurs many


times that creates problem in updation. (Updation
anomaly)
 We can’t insert the fact that a probable supplier resides
in a city until the supplier supplies at least one part.
(Insertion anomaly)
 After deletion of the sole tuple for a specific supplier,
we delete not only the shipment operation but also
eliminates the corresponding city of the supplier.
(Deletion Anomaly)
34 [email protected]
Second Normal Form

35 [email protected]
Second Normal Form

 A relation is in 2 NF iff it is in 1NF and all non-key


attributes are irreducibly dependent on the primary key.
 The Status for a given city appears many times that
creates problem in updation. (Updation Anomaly)
 We can’t insert the fact that a supplier in Rome must
have status 50 till we have some supplier actually
located in the city. (Insertion Anomaly)
 After deletion of the tuple related to S5 from Second,
we lose the information that the status of Athens is 30.
(Deletion Anomaly)
36 [email protected]
Third Normal Form

37 [email protected]
Boyce-Codd Normal Form

 The 3NF did not adequately deal with the case of a


relation that (a) had two or more candidate keys & (b)
the candidate keys are composite and overlapped.
 BCNF is the solution.
 A relation will be in BCNF iff every non-trivial left-
irreducuble FD has a candidate key as it’s determinant
or less formally every determinants will be a candidate
key.
 This combination may not occur often in practice.

38 [email protected]
BCNF…

 First (S#, Status, City, P#, Qty) can be


decomposed into SP (S#, P#, Qty), SC (S#,
City), CS (City, Status).
 SP, SC & CS are in BCNF. [as well as in 3NF]

39 [email protected]
BCNF

 Consider S (S#, Sname, Status, City) with the


assumption that Sname are also distinct; it can be
used as candidate key. Status are City are not
mutually dependent i.e. FD City Status is not
true.
 Here two candidate keys are there but no
overlapping.
 All determinants are candidate key, S is in BCNF.

40 [email protected]
BCNF..

 Consider SSP (S#, Sname, P#, Qty); Overlapping


Candidate Keys (S#, P#) & (Sname, P#)
 FD s are (S#, P#) Qty, (Sname, P#) Qty, S#
Sname, Sname S#. All determinants are not
candidate keys. The tables are in 3 NF; still
anomalies are there.
 Decomposition in SS (S#, Sname) & SP (S#, P#,
Qty) is the solution and these are in BCNF.

41 [email protected]
Dependency Preservation

 One of the desirable properties


 An update should not create any illegal relation i.e. one
that does not satisfy all the given FDs.
 Let F be a set of functional dependencies on a schema
R, and let R1,R2……Rn be a decomposition of R. The
restriction of F to Ri is the set Fi of all functional
dependencies in F+ that includes only attributes of Ri.
 F0 may be union of F1, F2, F3…Fn. Here F0 may not
be equal to F but F0+ must be equal to F+ .

42 [email protected]
Algorithm: Dependency Preservation

43 [email protected]
Dependency Preservation

Let F’=F1∪ F2∪…… ∪ Fn. F’ is a set of functional


dependencies on schema R. if F’+= F+ is true, then
every dependency in F is logically implied by F’, and, if
we verify that F’ is satisfied, we have verified that F is
satisfied. We say that a decomposition having the
property F’+= F+ is a dependency-preserving
decomposition.

44 [email protected]
Lossless Decomposition

Example:
Suppose a schema R=(A,B,C,D,E,F) is decomposed into R1
(A,B,E) and R2 = (CDEF). Is the decomposition is lossless? The
following set F of functional dependencies holds.

F={A→B,C→F,E→A,CE→D}
{ABE }∩{ CDEF}= {E}
E→A A→B E→B
E→A E→B E→AB E→ABE
It’s a lossless-join decomposition
45 [email protected]
Examples: BCNF

Examples:
① customer-schema=(customer-name,customer- street,
customer-city)
customer-name→{customer-street,customer-city}
customer-name is a candidate key
customer-schema is in BCNF
② branch-schema=(branch-name,assets,branch-city)

branch-name→ {assets,branch-city}
branch-schema is a candidate key
46 branch-schema is in BCNF
[email protected]
Examples: BCNF

③ loan-info-schema=(branch-name, customer-name,
loan-number, amount)
loan-number→{amount, branch-name}
loan-number is not a candidate key based on following facts

(Downtown,John Bell,L-44,1000)
(Downtown,Jane Bell,L-44,1000)
{Customer name, Roll no} is candidate key; thus each determinant
Is not considered as candidate keys.
Thus loan-info-schema is not in BCNF
47 [email protected]
Examples: BCNF

loan-info-schema=(branch-name, customer- name,


loan-number, amount)
loan-info-schema is not in BCNF. Redundancy exist,
so we should decompose it.
loan-schema=(loan-number, branch-name, amount)
borrower-schema=(customer-name,loan-number)
loan-number→{amount,branch-name}
loan-number is a candidate key of loan-schema
loan-schema and borrower-schema are both in BCNF
48 [email protected]
BCNF Decomposition

If R is not in BCNF, one can decompose R into a


collection of BCNF schemas R1,R2……Rn
maintaining lossless-join property.

49 [email protected]
BCNF Decomposition
Algorithm:Input a rel. R; output: Ri s in BCNF
result:={R};
done:=false;
compute F+;
while (not done) do
if (there is a schema Ri in result that is not in BCNF)
then begin
let   be a nontrivial functional dependency that
holds on Ri such that  Ri is not in F+ ,and ∩ = ;
result:=(result-Ri) ∪(Ri- ) ∪( ,);
end
50 else done:=true;[email protected]
BCNF Decomposition

Example:
Lending-schema={branch-name,branch-city, assets,customer-
name,loan-number,amount}
branch-name→{branch-city,assets}
F=
loan-number→{amount,branch-name}
A candidate key for this schema is:
{loan-number,customer-name}
BCNF decomposition :
Each determinant (branch-name & loan-number) is not a
candidate key. Thus ,Lending-schema is not in BCNF, so
51 decompose it.
[email protected]
BCNF Decomposition

branch-name→{branch-city,assets}
{branch-name,branch-city, assets,customer-
name,loan-number,amount}{branch-name}+
① branch-name→ {branch-name,branch-city,
assets,customer-name,loan-number,amount} is not in F+
② branch-name∩{branch-city,assets}= 

R1=branch-name∪{branch-city assets}
R2={branch-name,branch-city, assets,customer-
name,loan-number,amount}-{branch-city,assets}
52 [email protected]
BCNF Decomposition

Branch-schema={branch-name,branch-city, assets}
Loan-info-schema={branch-name,customer-name,loan-
number,amount}

branch-name is a key for Branch-schema,


Thus ,Branch-schema is in BCNF.
F’ = loan-number→{amount,branch-name}
loan-number is not a key for Loan-info-schema.
Thus,Loan-info-schema is not in BCNF
Decompose Loan-info-schema
53 [email protected]
BCNF Decomposition

loan-number→{amount,branch-name}
{branch-name,customer-name,loan-
number,amount}{loan-number}+
① branch-name→{branch-name,customer-name,loan-
number,amount} is not in F’+
② loan-number∩{amount,branch-name}= 

R2= loan-number ∪{amount,branch-name}


R3= {branch-name,customer-name,loan-
number,amount}-{amount,branch-name}
54 [email protected]
BCNF Decomposition

Loan-schema={branch-name,loan-number,amount}
Borrower-schema={customer-name,loan-number}
Branch-schema and Borrower-schema are in BCNF.
Lending-schema=(branch-name,branch-city,
assets,customer-name,loan-number,amount)

Branch-schema={branch-name,branch-city, assets}
Loan-schema={branch-name,loan-number,amount}
Borrower-schema={customer-name,loan-number}
55 [email protected]
BCNF Decomposition: Algo

Algorithm:
Input: a schema R and R satisfied the FDs F.
Output: R is a lossless-join decomposition which
satisfies the FDs F and for each subschemas Ri is a
BCNF decomposition which satisfies Fi=∏Ri(F)

56 [email protected]
BCNF Decomposition: Algo

① initialize the result closure  to {R}, ={R}

② if all subschemas in  are BCNF then turn to ④. Let us


find a subschemas S in  that is not in BCNF. According
to the definition of BCNF, there must has a FD X→A and
A-X=, X do not include any candidate key of S, S-X-A≠
.
③ Let S={S1,S2}, S1 is XA, S2 is S-A∪(A∩X), replace the S
with {S1,S2} turn to ②
④ Stop decomposing and output 
57 [email protected]
BCNF Decomposition
Compute candidate key:
If x+=u and y+ is a proper subset of x+ ( y+ ≠u). then the
attributes in R can be classified into four groups:

L: the attributes appear only on the left-hand side of FD

R: the attributes appear only on the right-hand side of FD

LR: the attributes appear both on the left-hand side and


Right-hand side of FD
N: the attributes do not appear on the FD
58 [email protected]
BCNF Decomposition

① the classification of R are not candidate key

② the classification of (L+N) must appear in candidate


key
③ L+N unknown:

ⅰ L+N =x1 x1+=u then have only one candidate key


ⅱ L+N =x1 x1+≠u find an attribute in R and add it to
the x1.repeat!

59 [email protected]
BCNF Decomposition

Example:
Relvar R=(O,I,S,Q,B,D) satisfies the following FDs.
F={S→D, I →B, IS →Q, B →O}
Give a lossless-join decomposition into BCNF of the schema R
L: S, I R: D, Q, O LR: B
(SI)+=SIDBQO=U have only one candidate key.
S→D ISS not in BCNF
S→D D-S≠  S do not include IS
Decompose: R1=SD R2=OISQB
60 [email protected]
BCNF Decomposition

FR2={I→B, IS →Q, B →O}


L: S, I R: Q, O LR: B
(SI)+=SIBOQ=U have only one candidate key.
I→B ISI B-I≠  not in BCNF
Decompose: R21=IB R22=OISQ
F R21={I→B}
F R22 ={IS →Q}
=(R1, R21, R22)
61 [email protected]
BCNF Decomposition

Example:
Relvar R=(A,B,C,D) satisfies the following FDs.
F={A→D, C→D, D →B}
Give a lossless-join decomposition into BCNF of the schema R
L: A,C R: B LR: D
(AC)+=ACDB=U have only one candidate key.
Decompose: R1=AD R2=ACB
FR2={C→B, A →B}
……
62 [email protected]
BCNF Decomposition
Every BCNF decomposition is not dependency preserving.

Example:
Banker-schema={branch-name,customer-name,banker-name}

banker-name→{branch-name}
F=
{branch-name,customer-name}→banker-name
banker-name is not a key for Banker-schema.
Thus, Banker-schema is not in BCNF. Decompose it.
63 [email protected]
BCNF Decomposition

Banker-branch-schema={banker-name,branch-name}
Customer-banker-schema={customer-name,banker-name}
F1={banker-name→branch-name}
F2= 
{branch-name,customer-name}→banker-name in F+
{branch-name,customer-name}→banker-name not in
{F1∪F2}+
{F1∪F2}+<>F+ and the decomposition is not dependency
preserving
64 [email protected]
BCNF Decomposition

The example demonstrates that not every BCNF


decomposition is dependency preserving. Moreover, it
demonstrates that we cannot always satisfy all three
design goals:
① BCNF
② Lossless join
③ Dependency preservation

65 [email protected]
3NF Decomposition

Example:
Banker-schema={branch-name,customer-name,banker-name}
banker-name→ {branch-name}
F=
{branch-name,customer-name}→banker-name
banker-name is not a key for Banker-schema.
Thus, Banker-schema is not in BCNF.
{branch-name,customer-name} is a candidate key
for Banker-schema. Banker-schema is in 3NF.
66 [email protected]
3NF Decomposition

If R is not in 3NF, we can decompose R into a


collection of 3NF schemas R1,R2……Rn, which is not
only a lossless-join decomposition, but also a
dependency-preserving decomposition.

67 [email protected]
3NF Decomposition
Algorithm:
let Fc be a canonical cover for F’;
i:=0;
for each functional dependency   in Fc do
if none of the schemas Rj, j=1,2……,i contains  
then begin
i:=i+1;
Ri:=   ;
end
If none of the schemas Rj, j=1,2……,i contains a candidate key for R
then begin
i:=i+1;
Ri:= any candidate key for R ;
end
68 Return(R1,R2,……,Ri) [email protected]
3NF Decomposition

Example:
Relvar R=(O,I,S,Q,B,D) satisfies the following FDs.

F={S→D, I→B, IS →Q, B →O}


Give a lossless-join, dependency-preserving decomposition into
3NF of the schema R.
F=FC
L: S,I R: D,Q,O LR: B
(IS)+=ISDBQO=U have only one candidate key.
={SD,IB,ISQ,BO}
69 [email protected]
3NF Decomposition

Example:
Banker-info-schema={branch-name,customer-name,banker-
name,office-number}
Banker-name→{branch-name,office-number}
{customer-name,branch-name}→banker-name

3NF decomposition:
R1= banker-name∪{branch-name,office-number}
R2= {customer-name,branch-name}∪banker-name

70 [email protected]
3NF decomposition
Banker-office-schema={banker-name,branch-name,office-number}
Banker-schema={customer-name,branch-name,banker-name}

banker-schema contains a candidate key for banker-info-schema

Banker-info-schema={branch-name,customer-name,banker-
name,office-number}

Banker-office-schema={banker-name,branch-name,office-number}
Banker-schema={customer-name,branch-name,banker-name}

71 [email protected]
Comparison: 3 NF & BCNF

Advantage of 3NF:
It is always possible to obtain a 3NF design without sacrificing a
lossless join or dependency preservation.

Disadvantage of 3NF:
If we do not eliminate all transitive dependencies, we may have to
use null values to represent some of the possible meaningful
relationships among data items, and there is the problem of
repetition of information.

If a schema is in 3NF but not in BCNF, then redundancy may occur.

72 [email protected]
Higher Order Normal Form

73 [email protected]
Converted Table: CTB
Course TEACHER TEXT

PHYSICS PROF GREEN BASIC MECHANICS

PHYSICS PROF GREEN OPTICS

PHYSICS PROF. BROWN BASIC MECHANICS

PHYSICS PROF. BROWN OPTICS

MATHS PROF GREEN BASIC MECHANICS

MATHS PROF GREEN VECTOR ANALYSIS

MATHS PROF GREEN TRIGONOMETRY

74 [email protected]
Higher order Normal Form

 CTB is in BCNF….but still there is redundancy.


 Green can teach Physics is recorded once per
recommended text.
 You will be unable to add that a teacher can teach
physics until the corresponding text is not known.
 This is due to the factor that Teacher and Texts are
completely independent of each other.
 Redundancy can be eliminated by the decomposition
in CT (Course, Teacher) & CB (Course, Text)

75 [email protected]
Multi Valued Dependency

 MVD is a generalization of FD; every FD is an MVD but


the reverse is not true.
 Let R be a relation; x and y are two subsets of the
attributes of R, the Multi valued Dependency x y is
said to be hold on R, if each x value is associated with
a set of y values and this set is independent of the
values of other attributes. [If x   y, then x   (R-
xy).]

76 [email protected]
Multi Valued Dependency

 Course   Teacher implies though there is not a


unique corresponding teacher for a course but for a
given course c and a given text x, the set of teachers t
matching the pair (c,x) depends on the value of c alone
and it makes no difference which particular value of x
be chosen.
 Let R(A,B,C) be a relation, then R is equal to the join of
the projections on {A,B} & {A,C} iff R satisfies the MVD
AB/C.

77 [email protected]
MVD and 4 NF

 A relation R is in 4 NF iff, whenever there exists


AB; all the attributes are also functionally
dependent on A.
 Fourth Normal Form (4 NF) can solve these
redundancy i.e. a relation R is said to be in 4 NF if for
every MVD x   y; one of the following statement is
true. (a) xy = R or (b) x is a superkey.
 CTX is not in 4NF but CT & CX are in 4NF as
xy = R holds for each MVD.

78 [email protected]
Exercise:

① Suppose that we decompose the schema R=(U,V,W,X,Y,Z) into


1={WZ,VY,WXY,UVY}; 2={UVY,WXYZ} determine which
decomposition is a lossless-join decomposition if the following set F
of functional dependencies holds
F={U→V, W →Z, Y →U, WY →X}
② Suppose that we decompose the schema ={R1(A1A4), R2(A1A2),
R3(A2A3), R4(A3A4A5),R5(A1A5)} determine whether this
decomposition is a lossless-join decomposition. If the following set
F of functional dependencies holds

F={A1→A3, A3→A4, A2→A3, A4A5→A3, A3A5→A1}


79 [email protected]
Exercise:

③ Relvar R=(A,B,C,D,E) satisfies the following FDs:


F={A→C,C →D,B →C,DE →C,CE →A}
ⅰFind an irreducible equivalent for this set of FDs
ⅱFind all candidate keys of the schema R.
ⅲDetermine whether the decomposition ={AD,AB,BC,CDE,AE} is a
lossless-join decomposition or not.
ⅳGive a lossless-join decomposition into BCNF of the schema R.
ⅴGive a lossless-join, dependency-preserving decomposition into
3NF of the schema R.

80 [email protected]

You might also like