1. Algorithm of Compute F+
F + = F
repeat
Step-1 apply reflexivity rules for each functional dependency f in F+
Step-2 augmentation rules for each functional dependency f in F+
Step-3 add the resulting functional dependencies to F +
step-4 for each pair of functional dependencies f1and f2 in F + if f1 and f2 can be combined using transitivity rule
Step-5 add the resulting functional dependency to F +
until F + does not change any further

2. R= {A,B,C,D,E}
F = {A → B, B → C, C D → E }
• Step 1: For each f in F, apply reflexivity rule
– We get: CD → C; CD → D
– Add them to F:
• F = {A → B, B → C, C D → E; CD → C; CD → D }
• Step 2: For each f in F, apply augmentation rule
– From A → B we get: AC → BC; AD→ BD; ABC →BC; ABD → BD;
– From B → C we get: AB → AC; BC → C; BD → CD;
ABC → AC; ABD → ACD, etc etc.
Step 3: Apply transitivity on pairs of f’s
• Keep repeating… You get the idea

3. Computing X+ Input F (a set of FDs), and X (a set of attributes)
Output: Result=X+ (under F)
Method:
While(changes to result)do
For each function dependency Y→ Z in F do
Begin
If Y result then result = result U Z;
End

4. Uses of Attribute Closure
There are several uses of the attribute closure
algorithm:
• Testing for superkey:
– To test if X is a superkey, we compute X+, and check if
X+ contains all attributes of R.
• Testing functional dependencies
– To check if a functional dependency X → Y holds (or,
in other words, is in F+), just check if Y ⊆ X+.
– That is, we compute X+ by using attribute closure, and
then check if it contains Y.
– Is a simple and cheap test, and very useful
• Computing closure of F

5. Example OF X+ R=(A,B,C,G,H,I) F= {A → B,A → C,CG → H,CG → I,B → H}
Step 1: Result = AG
Step -2
A → B causes us to include B in result. We know that A → B is in F, A result ( which is AG), so result=result U B
A → C causes result to become ABCG.
CG → H causes result to become ABCGH.
CG → I causes result to become ABCGHI

6. How to find List OF Candidate key
if + = R, then  is a super key for R
if we find + for all  R, we've computed F+ (except that we'd need to use decomposition to get all of it).

7. Compute the closure for relational schema R={A,B,C,D,E} A-->BC CD-->E B-->D E-->A List candidate keys of R.

8. Find the attributes that are neither on the left and right side
Find attributes that are only on the right side
Find attributes that are only on the left side
Combine the attributes on step 1 and 3

9. Canonical Cover
A canonical cover for F is a set of dependencies Fc such that
F logically implies all dependencies in Fc, and
Fc logically implies all dependencies in F, and
No functional dependency in Fc contains an extraneous attribute, and
Each left side of functional dependency in Fc is unique
Intuitively, a canonical cover of F is a “minimal” set of functional dependencies equivalent to F, having no redundant dependencies or redundant parts of dependencies

10. Extraneous Attributes
Consider F, and a functional dependency, A  B.
“Extraneous”: Are there any attributes in A or B that can be safely removed ?
Without changing the constraints implied by F

11. Every functional dependency a->b in Fc contains no extraneous attributes in a(ones that can be removed from without changing fc+ ). So A is extraneous in if
logically implies Fc

12. Every functional dependency a->b in Fc contains no extraneous attributes in b(ones that can be removed from b without changing fc+). So A is extraneous in b if and
logically implies .fc

13. Testing if an Attribute is Extraneous
Consider a set F of functional dependencies and the functional dependency    in F.
To test if attribute A   is extraneous in 
compute ({} – A)+ using the dependencies in F
check that ({} – A)+ contains A; if it does, A is extraneous
To test if attribute A   is extraneous in 
compute + using only the dependencies in F’ = (F – {  })  { ( – A)},
check that + contains A; if it does, A is extraneous

14. Example
we need to compute ({ACD} – A)+ using the dependencies in F and check if
the result contains A; if it does, attribute A is extraneous.
Computing CD+, we get ACDEGB which contains A and therefore, A is extraneous. Also the
closure contains B, which tells us that CD -> B holds.

15. To compute a canonical cover for F:
repeat Use the union rule to replace any dependencies in F 1  1 and 1  2 with 1  1 2 Find a functional dependency    with an extraneous attribute either in  or in  If an extraneous attribute is found, delete it from    until F does not change
Note: Union rule may become applicable after some extraneous attributes have been deleted, so it has to be re-applied

16. {ACB, DEG, BCD, CGD, CEA}
No more extraneous attributes
FC = {ACB, DEG, BCD, CGD, CEA}
* Different order of considering the extraneous attributes can result in different FC

17. R = (A, B, C) F = {A  BC B  C A  B AB  C}
Combine A  BC and A  B into A  BC
Set is now {A  BC, B  C, AB  C}
A is extraneous in AB  C
Check if the result of deleting A from AB  C is implied by the other dependencies
Yes: in fact, B  C is already present!
Set is now {A  BC, B  C}
C is extraneous in A  BC
Check if A  C is logically implied by A  B and the other dependencies
Yes: using transitivity on A  B and B  C.
Can use attribute closure of A in more complex cases
The canonical cover is: A  B B  C

18. Given F = {A  C, AB  C } Given F = {A  C, AB  CD}
B is extraneous in AB  C because {A  C, AB  C} is equivalent to {A  C, A  C } = {A  C}
Given F = {A  C, AB  CD}
C is extraneous in AB  CD because {A  C, AB  CD} is equivalent to {A  C, AB  D}

19. A canonical cover might not be UNIQUE
R= A,B,C,D,E
f= AB→CD, A→E , E→C  
To check if C is extraneous in AB→CD we compute (AB)+
under F’ = AB→ D
A→ E
E→ C
AB+ = ABCDE which includes C so we can say that C is extraneous.
To check if D is extraneous in AB→CD we compute (AB)+
under F’ = AB→ C
E→ C 
AB+ = ABCE which does not include D so we can say that D is not extraneous.
Now we have
AB→ D
S0 Fc = {AB->,A->E,E->C}

20. Normalization Formal technique for analyzing a relation
Based on primary key and functional dependencies
Series of Steps
With each successive step the relation gets more restricted

21. The process of normalization was developed by Dr. E. F. Codd
The process of normalization was developed by Dr. E.F.Codd. Three normal forms were initially proposed.
It is a formal process for deciding which attributes should be grouped together. The database design flow is from logical design to physical design.
In the process of normalization, the designers analyze and decompose the complex relation and transform them into smaller, simpler and well structured relations.
With the help of normalization a record structure is replaced with a new record structure which is more simper and more manageable.

22. Goals Of Normalization
To eliminate the redundant data.
To Eliminate Reaping Groups
To provide simple retrieval of data in response of query.
To simplify various operations like update, deletion, and insertions.
To Eliminate Columns Not Dependent on key.
Isolate Independent Multi Relationships
Isolate semantically related multiple relationship

23. 1NF(First Normal Form)
A domain is atomic if elements of the domain are considered to be individual unit. This means there are no multivalve attributes (repeating groups). We eliminate the substructure of attribute.
We say that a relation schema R is in First Normal Form if the domains of all attributes of R are atomic. Composite attribute such as address with components street and city have non atomic domains. The set of integer is atomic domain. The set of all sets of integers is a non atomic domain.
We remove the repeating group and creating a separate relation containing repeating group.
Here the original record and new records are interrelated by a common data item
All relational tables must satisfy the 1NF requirements.

24. 1NF(First Normal Form)
A relation in which intersection of each row and column contains one and only one value.
(Each Data Value Stored in relation is single – valued) 1NF – a relation that contains no repeating groups

25. UNF to 1NF
Nominate an attribute or group of attributes to act as the key for the Unnormalized table.
Identify repeating group(s) in unnormalized table which repeats for the key attribute(s). Remove repeating group by:
entering appropriate data into the empty columns of rows containing repeating data

26. Second Normal Form (2NF)
Based on concept of full functional dependency:
A and B are attributes of a relation,
B is fully dependent on A if
B is functionally dependent on A but not on any proper subset of A.
2NF - A relation that is in 1NF and every non-primary-key attribute is fully functionally dependent on the primary key.
Relations with a simple key are automatically in 2NF
Need to concentrate on relations with composite keys

27. 1NF to 2NF Identify primary key for the 1NF relation.
Identify functional dependencies in the relation.
If partial dependencies exist on the primary key remove them by placing them in a new relation along with copy of their determinant.

28. 3NF(Third Normal Form) Based on concept of transitive dependency:
A, B and C are attributes of a relation such that if A  B and B  C,
then C is transitively dependent on A through B. (Provided that A is not functionally dependent on B or C).
3NF - A relation that is in 1NF and 2NF and in which no non-primary-key attribute is transitively dependent on the primary key.
No non-key attribute is a determinant for another non-key attribute

29. 2NF to 3NF Identify the primary key in the 2NF relation.
Identify functional dependencies in the relation.
If transitive dependencies exist on the primary key remove them by placing them in a new relation along with copy of their determinant.

30. Definition of Decomposition
Let R be a relation schema
A set of relation schemas { R1, R2,…, Rn } is a decomposition of R if R = R1 U R2 U …..U Rn
each Ri is a subset of R ( for i = 1,2…,n)

31. Example of Decomposition
For relation R(x,y,z) there can be 2 subsets:
R1(x,z) and R2(y,z)
If we union R1 and R2, we get R
R = R1 U R2

32. Goal of Decomposition
Eliminate redundancy by decomposing a relation into several relations in a higher normal form.
It is important to check that a decomposition does not lead to bad design

33. Example : Problem with Decomposition
Model Name
Price
Category
a11
100
Canon
s20
200
Nikon
a70
150 R1 R2
Model Name
Category
a11
Canon
s20
Nikon
a70
Price
Category
100
Canon
200
Nikon
150

34. Example : Problem with Decomposition
Model Name
Price
Category
a11
100
Canon
150
s20
200
Nikon
a70
R1 U R2
Model Name
Price
Category
a11
100
Canon
s20
200
Nikon
a70
150 R

35. Lossy decomposition
In previous example, additional tuples are obtained along with original tuples Although there are more tuples, this leads to less information Due to the loss of information, decomposition for previous example is called lossy decomposition or lossy-join decomposition

36. Lossless Decomposition
A decomposition {R1, R2,…, Rn} of a relation R is called a lossless decomposition for R if the natural join of R1, R2,…, Rn produces exactly the relation R.

37. Lossless Decomposition Property
R : relation
F : set of functional dependencies on R
X,Y : decomposition of R
Decomposition is lossles if :
X ∩ Y  X, that is: all attributes common to both X and Y functionally determine ALL the attributes in X OR
X ∩ Y  Y, that is: all attributes common to both X and Y functionally determine ALL the attributes in Y

38. Lossless Decomposition Property
In other words, if X ∩ Y forms a superkey of either X or Y, the decomposition of R is a lossless decomposition

39. Example : Lossless Decomposition
Given:
Lending-schema = (branch-name, branch-city, assets, customer-name, loan-number, amount)
Required FD’s:
branch-name -> branch-city assets
loan-number -> amount branch-name
Decompose Lending-schema into two schemas:
Branch-schema = (branch-name, branch-city, assets)
Loan-info-schema = (branch-name, customer-name, loan-number, amount)

40. Since Branch-schema ∩ Loan-info-schema = {branch-name}
branch-name -> branch-city assets
Thus, this decomposition is Lossless decomposition

41. Dependency Preservation
A decomposition D = {R1, R2, ..., Rn} of R is dependency-preserving with respect to F if the union of the projections of F on each Ri in D is equivalent to F; that is if (F1  F2  …  Fn )+ = F +

42. Dependency preservation is another important requirement since Dependency is constrain on the database
If constrain is split over more than one relation then constrain would difficult to meet (Dependency is not Preserved )

43. Example of Dependency Preservation
R(A B C D)
FD1: A  B
FD2: B  C
FD3: C  D
Decomposition: R1(A B C) R2(C D)

44. FD1: A  B
FD2: B  C
FD3: C  D
R1( A B C )
FD1
FD2

45. FD1: A  B FD2: B  C FD3: C  D R1( A B C ) R2( C D ) FD1 FD3 FD2
Has all 3 functional dependencies!
Therefore, it’s preserving the dependencies

46. Example of Non-Dependency Preservation
R(A B C D)
FD1: A  B
FD2: B  C
FD3: C  D
Decomposition: R1(A C D) R2(B C)

47. FD1: A  B FD2: B  C FD3: C  D R1( A C D ) R2( B C ) FD3 FD2
Does not support FD1: A => B
Therefore, it does not preserve the dependencies

48. Dependency preservation is another important requirement since Dependency is constrain on the database
If constrain is split over more than one relation then constrain would difficult to meet (Dependency is not Preserved )

49. Checking Dependency Preservation
If All the attribute appearing on the left and right side of dependency appear in the same relation then a dependency is considered preserved

50. Algorithm for Checking Dependency Preservation
Test each X  Y in F for dependency preservation
result = X
while (changes to result) do
for each Ri in decomposition
t = (result  Ri)+  Ri
result = result  t
if Y  result, return true;
else, return false;
[Note: If any false is returned for algorithm, whole decomposition is not dependency preserving.]

51. Choose a functional dependency in set F, say you choose X  Y.
2. Let set Z to the “left hand side” of the functional dependency, X such Z = X
Starting with R1 in the decomposed set {R1, R2,…Rn)
3. Intersect Z with R1, Z  R1
4. Find the closure of the result from step 3 (Z  R1) using original set F
5. Intersect the result from step 4 ((Z  R1)+) with R1 again.

52. . Updated Z with new attribute in the result from step 5.
7. Repeat step 3-6 from R2, R3, …, Rn.
8. If there’s any changes between original Z before step 3 and after step 7, repeat step 3-7.
9. Check whether Y is a proper subset of current Z. If it is not, this decomposition is a violation of dependency preservation. You can stop now.
10. If Y is a proper subset of current Z, repeat 1-9 until you check ALL functional dependencies in set F.

53. Example using Algorithm
Given the following:
R(A,B,C,D,E)
F = {ABC, CE, BD, EA}
R1(B,C,D) R2(A,C,E)
Is this decomposition dependency preserving?

54. Update Z = AB  BD = ABD, continue
R(A,B,C,D,E) F = {ABC, CE, BD, EA}
Decomposition: R1(B,C,D) R2(A,C,E)
Z=AB
For Z  R1 = AB  BCD = B
{B}+ = BD
{B}+  R1 = BD  BCD = BD
Update Z = AB  BD = ABD, continue

55. Z=ABD
For Z  R2 = ABD  ACE = A
{A}+ = A
{A}+  R2 = A  ACE = A
Update Z, Z is still ABD
Since Z changed, repeat checking R1 to R2.

56. Z=ABD
For Z  R1 = ABD  BCD = BD
{BD}+ = BD
{BD}+  R1 = BD  BCD = BD
Update Z = ABD  BD = ABD, so Z hasn’t changed but you still have to continue.

57. R(A,B,C,D,E) F = {ABC, CE, BD, EA}
Decomposition: R1(B,C,D) R2(A,C,E)
Z=ABD and checking R2 was done 2 slides ago
Z will still be ABD.
Since Z hasn’t change, you can conclude ABC is not preserved.
Let’s practice with other functional dependencies.

58. R(A,B,C,D,E) F = {ABC, CE, BD, EA}
Decomposition: R1(B,C,D) R2(A,C,E)
Z=X=B
For Z  R1 = B  BCD = B
{B}+ = BD
{B}+  R1 = BD  BCD = BD
Update Z = B  BD = BD
Since Y=D is proper subset of BD, BD is preserved.

59. R(A,B,C,D,E) F = {ABC, CE, BD, EA}
Decomposition: R1(B,C,D) R2(A,C,E)
Z=X=C
For Z  R2 = C  ACE = C
{C}+ = CEA
{C}+  R1 = CEA  ACE = ACE
Update Z = C ACE= ACE
Since Y=E is proper subset of ACE, CE is preserved.

60. R(A,B,C,D,E) F = {ABC, CE, BD, EA}
Decomposition: R1(B,C,D) R2(A,C,E)
Z=X=E
For Z  R1 = E  ACE = E
{E}+ = EA
{E}+  R1 = EA  ACE = EA
Update Z = E  EA= EA
Since Y=A is proper subset of EA, EA is preserved.

61. R(A,B,C,D,E) F = {ABC, CE, BD, EA}
Decomposition: R1(B,C,D) R2(A,C,E)
Shortcut:
For any functional dependency, if both LHS and RHS collectively are within any of the sub scheme Ri. Then this functional dependency is preserved.

62. Example = 2 Let R{A,B,C,D} and F={AB, BC, CD, DA}
Let’s decomposed R into
R1 = AB, R2 = BC, and R3 = CD
Is this a dependency preserving decomposition?

63. Example = 2
R{A,B,C,D} F={AB, BC, CD, DA}
Decomposition: R1 = AB, R2 = BC, and R3 = CD
Yes it is.
You can immediately see that AB, BC, CD are preserved for R1, R2, R3
The key is to check whether DA is preserved.
Let’s walk through the algorithm.

64. For Z  R1 = D  AB = empty set For Z  R2 = D  BC = empty set
R{A,B,C,D} F={AB, BC, CD, DA}
Decomposition: R1 = AB, R2 = BC, and R3 = CD
Z = X = D
For Z  R1 = D  AB = empty set
For Z  R2 = D  BC = empty set
For Z  R3 = D  CD = D
Find {D}+ = DABC
Find {D}+  R3 = DABC  CD = CD
Update Z to CD. Since Z changed, repeat.

65. Z = BCD
For Z  R1 = BCD  AB = B
Find {B}+ = BCDA
Find {B}+  R1 = BCDA  AB = AB
Update Z = BCD  AB = ABCD.
Since Y = A is a subset of ABCD, function DA is preserved.

66. Example = 3 R{A,B,C,D,E) F={ABD, BE} Decomposition:
R1{A,B,C} R2{A,D} R3{B,D,E}
Is this a dependency preserving decomposition?

67. Let’s start with ABD: Z = A Z  R1 = A  ABC = A {A}+ = ABDE
R{A,B,C,D,E) F={ABD, BE}
Decomposition: R1{A,B,C} R2{A,D} R3{B,D,E}
Let’s start with ABD:
Z = A
Z  R1 = A  ABC = A
{A}+ = ABDE
{A}+  R1 = ABDE  ABC = AB
Update Z = A  AB = AB

68. Z = AB
Z  R2 = A  AD = A
{A}+ = ABDE
{A}+  R1 = ABDE  AD = AD
Update Z = AB  AD = ABD
Thus A BD preserved

69. Based on R3, BE is preserved. Check B  E: Z = B Z  R1 = B  ABC = B
R{A,B,C,D,E) F={ABD, BE}
Decomposition: R1{A,B,C} R2{A,D} R3{B,D,E}
Based on R3, BE is preserved.
Check B  E:
Z = B
Z  R1 = B  ABC = B
{B}+ = BE
{B}+  R1 = BE  ABC = B
Update Z = B still the same

70. Z = B Z  R2 = B  AD = empty set Z  R3 = B  BDE = B {B}+ = BE
R{A,B,C,D,E) F={ABD, BE}
Decomposition: R1{A,B,C} R2{A,D} R3{B,D,E}
Z = B
Z  R2 = B  AD = empty set
Z  R3 = B  BDE = B
{B}+ = BE
{B}+  R3 = BE  BDE = BE
Update Z = B  BE = BE
Thus BE preserved

71. non trivial dependency means X-->Y that is if Y is not proper subset of X table or relation with X then it said to be non trivial functional dependency
A trivial functional dependency occurs when you describe a functional dependency of an attribute on a collection of attributes that includes the original attribute. This type of functional dependency is called trivial
{A, B} -> B

72. Definition BCNF
A relation schema R is in BCNF with respect to a set F if:
For all functional dependencies of F of the form , where R and R
 is a trivial functional dependency()
 is a superkey for schema R
A database design is in BCNF if each member of the set of relational schemas that constitute the design is in BCNF

73. BCNF
When a relation has more than one candidate key, anomalies may result even though the relation is in 3NF.
3NF does not deal satisfactorily with the case of a relation with overlapping candidate keys
i.e. composite candidate keys with at least one attribute in common.
BCNF is based on the concept of a determinant.

74. A determinant is any attribute (simple or composite) on which some other attribute is fully functionally dependent.
A relation is in BCNF is, and only if, every determinant is a candidate key.
A table is in Boyce-Codd normal form (BCNF) if and only if it is in 3NF and every determinant is a candidate key.
It is a slightly stronger version of the third normal form (3NF)

75. BCNF Decomposition Algorithm
If R is not in BCNF, we can decompose R into a collection of BCNF schemas R1 , R2, …, Rn
Result := {R};
done := false;
computer F+
while(not done) do
if(there is a schema Ri in result that is not in BCNF)
then begin
 be a nontrivial functional dependency that holds
on Ri such that -> Ri is not in F+, and  = ;
result :=(result – Ri)  (Ri - )  (,);
end
else done := true;

76. BCNF_Decompose(R)
find X .: X ≠X+ ≠ [all attributes]
if (not found) then “R is in BCNF”
let Y = X+ - X
let Z = [all attributes] - X+
decompose R into R1(X U Y) and R2(X U Z)
continue to decompose recursively R1 and R2

77. R(A;B;C;D;E)
A ->B
CD ->E
Iteration 1: R
A+ = AB Decompose into R1 = AB, R2 = ACDE.
Continue to decompose R2 since R1 is in BCNF form already.
Iteration 2: R2
CD+ = CDE
Decompose R2 into R3 = CDE and R4 = CDA

78. Conditions for BCNF The candidate keys in relations are composite key
There is more than one overlapping candidate key in relations and some attributes in keys are overlapping and some are nor overlapping .
There is a FD from non overlapping attribute of one candidate key to non overlapping attribute of other key

79. title
year
length
filmType
studioName
star Name
Star Wars
1977
124
color
Fox
Fisher
Hamill
Ford
Mighty Ducks
1991
104
Disney
Esteves
Wayne’s World
1992 95
Paramount
Carvey
Meyers

80. {title, year, starName} as candidate key
title, year  length, filmType, studioName
The above FD (Functional Dependency) violates the BCNF condition because title and year do not determine the sixth attribute, starName

81. We solve this BCNF violation by decomposing relation Movies into
1. The schema with all the attributes of the FD
{title, year, length, filmType, studioName}
2. The schema with all attributes of Movies except the three that appear on the right of the FD
{title, year, starName}

82. Diffence between BCNF and 3NF
In a table that is in the BCNF normal form, for every non-trivial functional dependency of the form A → B, A is a super-key whereas, a table that complies with 3NF should be in the 2NF, and every non-prime attribute should directly depend on every candidate key of that table.
BCNF is considered as a stronger normal form than the 3NF and it was developed to capture some of the anomalies that could not be captured by 3NF.

83. A decomposition into 3NF is lossless and dependency preservation whereas A decomposition into BCNF lossless but may or may not be dependency preservation

84. What is the relationship between 3NF and BCNF?
3NF = BCNF 3NF≠ BCNF
3NF is subset of BCNF
BCNF is subset of 3NF

85. Example Grade_report (StudNo,StudName,Major, Adviser,
CourseNo,Ctitle,InstrucName,InstructLocn,Grade)
• Functional dependencies
– StudNo -> StudName
– CourseNo -> Ctitle, InstrucName
– InstrucName -> InstrucLocn
– StudNo , Major, CourseNo-> Grade
– StudNo, Major -> Advisor
– Advisor -> Major

86. 1NF Remove repeating groups
Student (StudNo, StudName) [studno => studname]
– StudMajor (StudNo, Major, Advisor) [studno, major => advisor]
– StudCourse (StudNo, Major, CourseNo,
Ctitle, InstrucName, InstructLocn, Grade)

87. 2NF Remove Functional dependencies
Student (StudNo, StudName)
StudMajor (StudNo, Major, Advisor)
StudCourse (StudNo, Major, CourseNo, Grade)
Course (CourseNo, Ctitle, InstrucName, InstructLocn)

88. 3NF Remove transitive dependencies
Student (StudNo,StudName)
StudMajor (StudNo,Major,Advisor)
StudCourse (StudNo,Major,CourseNo,Grade)
Course (CourseNo, Ctitle, InstrucName)
Instructor (InstructName, InstructLocn)

89. BCNF Every determinant must be a candidate key
– Student : only determinant is StudNo
– StudCourse: only determinant is
StudNo, Major, CourseNo
– Course: only determinant is CourseNo
– Instructor: only determinant is InstrucName
– StudMajor: the determinants are
• StudNo,Major [StudNo, Major -> advisor]
• Advisor [Advisor -> Major]
Only StudNo,Major is a candidate key. I.e.
Stud Major (StudNo,Major,Advisor)

90. BCNF BCNF remove non-candidate determinants
• Student (StudNo,StudName)
StudCourse (StudNo,Major,CourseNo,Grade)
Course (CourseNo,Ctitle,InstrucName)
Instructor (InstructName,InstructLocn)
StudMajor (StudNo,Major,Advisor)
Advisor -> Major
• StudMajor (StudNo, Advisor)
Advisor (Advisor, Major)

91. Problems that BCNF overcomes
StudMajor (StudNo,Major,Advisor)
StudNo
Major
Advisor
123
.net
Kirti roshania
Java
MitalVora
456
789
Sql server
Anriod
Jelam vora
Vimal Parmar

92. In BCNF we get two tables: Stud Major (StudNo, Advisor) & Advisor (Advisor, Major)

93. Testing for BCNF
To check if a nontrivial dependency  causes a violation of BCNF, compute a+(attribute closure of ), and verify that it includes all attributes of R; that is, is is the super key of R
If we can show that none of the dependencies in F causes a violation of BCNF, then none of the dependencies in F+ will cause a violation of BCNF either For every subset  of attributes in Ri check that a+(the attribute closer of  under F ) either includes no attribute of Ri - , or includes all attributes of Ri

94. lossless-join dependency-preserving decomposition into 3NF.
Find the Fc be canonical cover for F
i=0
For each FD a->b in fc do
If none of schemas Rj J= 1,2…iContains ab
Then begin
i = i+1;
Ri= ab
End
If none of schemas Rj, J= 1,2…i contains candidate key for R
i=i+1
Ri = any candidate key for R
Return (R1,R2….Rn)

95. 1) Construct a canonical cover of F. In our case FC = F.
2) Initially we have an empty set of Rj (j = 0). Therefore, none of Rj contains ABC
(we take a dependency from the canonical cover A ® B). So R1 = (A, B, C).
Consider CD ® E. CDE is not in R1, hence we add R2 = (C, D, E).
Similarly, we add R3 = (B, D), and R4 = (E, A).
3) R1 contains a candidate key for R, therefore we do not need to add a relation
consisting of a candidate key.
Finally, the received decomposition is (A, B, C), (C, D, E), (B, D), (E, A).

97. ClientInterview
ClientNo
interviewDate
interviewTime
staffNo
roomNo
CR76
13-May-02
10.30
SG5
G101
12.00
CR74
SG37
G102
CR56
1-Jul-02
FD1 clientNo, interviewDate  interviewTime, staffNo, roomNo (Primary Key)
FD2 staffNo, interviewDate, interviewTime clientNo (Candidate key)
FD3 roomNo, interviewDate, interviewTime  clientNo, staffNo (Candidate key)
FD4 staffNo, interviewDate  roomNo (not a candidate key)
As a consequece the ClientInterview relation may suffer from update anmalies.
For example, two tuples have to be updated if the roomNo need be changed for staffNo SG5 on the 13-May-02.

98. 4th Normal Form (4 NF) A relation is a 4 NF if it is BCNF and
There is no multivalued dependency in the relation or
There are multivalued dependency but the attributes, which are multivalued dependent on a specific attribute, are dependent between themselves

99. The redundancy that comes from MVD’s is not
removable by putting the database schema in
BCNF.
There is a stronger normal form, called 4NF,
that (intuitively) treats MVD’s as FD’s when it
comes to decomposition, but not when
determining keys of the relation.
That mean No Relation may contain two or more 1:n and N:M relationship that are not directly related.

100. Definition A relation R is in 4NF if whenever X ‐>‐>Y is
a nontrivial MVD, then X is a superkey.
– Nontrivial means that:
1. Y is not a subset of X, and
2. X and Y are not, together, all the attributes.
– Note that the definition of “superkey” still
depends on FD’s only. 17

101. If relation in 4NF then is also in BCNF
IF relation in BCNF then is also in 3NF

102. What is a multi valued dependency (MVD)?
Multi valued dependencies (MVD’s) express a
condition among tuples of a relation that
exists when the relation is trying to represent
more than one many‐many relationship.
Multi-valued Dependency (MVD)
Dependency between attributes (for example, A, B, and C) in a relation, such that for each value of A there is a set of values for B and a set of values for C. However, the set of values for B and C are independent of each other.

103. Drinkers(name, addr, phones, beersLiked)
• A drinker’s phones are independent of the beers
they like.
• Thus, each of a drinker’s phones appears with each
of the beers they like in all combinations.
– If a drinker has 3 phones and likes 10 beers, then the
drinker has 30 tuples
– where each phone is repeated 10 times and each beer 3
times
• This repetition is unlike redundancy due to FD’s, of
hi h dd i h l 3
which name‐>addr is the only one.

104. Definition of MVD A multivalued dependency (MVD) X ‐>‐>Y
is an assertion that if two tuples of a relation
agree on all the attributes of X, then their
components in the set of attributes Y may be
swapped, and the result will be two tuples
that are also in the relation.

105. MVD Rules Every FD is an MVD
– If X ‐>Y, then swapping Y ’s between two tuples that
agree on X doesn’t change the tuples.
– Therefore, the “new” tuples are surely in the
relation, and we know X ‐>‐>Y.
• Definition of keys depend on FDs and not MDs

106. 3NF TO 4NF Relation Must Be in 3NF.
Identify Multi valued dependencies in the relation.
If multiple set of Multi valued dependencies exist remove them by placing them in a new relation along with copy of their determinant.