CS 157B Midterm 2 Revision Prof. Sin Min Lee

Q #1 (01) 1. Characterize the difference between the following pairs of terms a. Entity and entity class b. Relationship and relationship type c. Attribute value and attribute d. Strong entity class and weak entity class 2. Create an ER model for the following enterprise: Each building in an organization has a different building name and address. The meeting rooms in each building have their own room numbers and seating capacities. Rooms may be reserved for meetings, and each meeting must start on the hour. The hour and length of use are recorded. Each reservation is made by a group in the company. Each group has a group number and a contact phone.

Q#1 (01): Solutions a. Entity and entity class An entity is an object and an entity class is a collection of objects. b. Relationship and relationship type A relationship is a specific instance of two related entities. A relationship type represents the possibility that two entities are related. c. Attribute value and attribute An attribute is a characteristic shared by entities of a class. An attribute value is the particular value of the attribute for a specific entity. d. Strong entity class and weak entity class A strong entity class is one with a key and a weak entity class has no key of its own.

Q #1 (01): Solutions

Q #1 (02) 1. Consider the following E-R diagram and attributes Buyer: id, name, address Property: id, askingPrice, salePrice, address StaffMember: id, lastName, firstName, phone Branch: id, name, address, phone a. Write sentences to describe the roles of staff members in the diagram. b. Write sentences to describe the roles of property in the diagram. 2. Explain the following constraints. a. Domain constraint b. Key constraint c. Cardinality constraint d. Participation constraint

Q#1 (02) Solution 1. a. Write sentences to describe the roles of staff members in the diagram. A staff member may sell many properties. A staff member may work at a branch. A staff member may mange a branch b. Write sentences to describe the roles of property in the diagram. A property may be bought by one buyer A property may be sold by many staff members 2. a. Domain constraint : restrictions on the allowable values of attributes - the type and the range of values possible for each attribute b. Key constraint : unique value in an entity class-most entity classes have one or more attributes that form a key of the class c. Cardinality constraint : the number of relationships that may exist at a time – (to-one and to-many) d. Participation constraint : whether at least one relationship must exist for each entity of a class.

Q #2 -01 Create a relational database schema for the following ER model. Group 1 Uses Is In 1 MM contact Has Room capacitytypenumber Building name Meeting lengthhour name date number phone 1 M address

Q#2 -01 : solution Building (name, address) Room (number, capacity, type, buildingName) Meeting (name, date, hour, length, roomNo, byGroup) Group (number, contact, phone)

Q #2 (02) 1. Create a relational database schema for the following EER model. ssn firstName lastName

Q #2 (02) 2. Suppose R(A,B,C,D,E,F,G,H) is a relation. Suppose {A,B}  {C,D,E,F,G,H}, C  {B,E,F}, and G  H. a. Which sets of attributes are the keys of R? b. Identify and eliminate any 2NF violations. c. Identify and eliminate any 3NF violations.

Q #2 (02): solution 1. One of the possible solutions Vehicle (vehicleId, weight, capacity, numberWheels) Car (vehicleId, numberDoors, amenities) Truck (vehicleId, weightCapacity, numberAxles) Motorcycle (vehicleId, engineType, usage) Owner (ssn, firstName, lastName) Has (ssn, vehicleId)

Q #2 (02): solution 2. a. Which sets of attributes are the keys of R? {A, B} and {A, C} b. Identify and eliminate any 2NF violations. C  {E, F} is a 2NF violation The revised schema is R9: (A, B, C, D, G, H), {A, C} is also a key R10: (C, E, F) c. Identify and eliminate any 3NF violations. G  H is a 3NF violation The revised schema is R10, R11: (A, B, C, D, G), {A, C} is also a key R12: (G, H)

Q#3 (01) 1. Write SQL statements to create the following two tables (including key constraints and referential constraints) 2. Write a SQL select statement to find the names of Employees who work in ‘Research’ department. 3. Write a SQL statement to insert a new department with Dnumber=6 and Dname=“sales”. DepartmentDNumberDNameMgrSSN 5Research Administrator Headquarter EmployeeSSNFNameLNameSexSalar y SuperSSNDno JohnSmithM FranklinWongM AliciaZelayaF JenniferWallaceF RameshNaraynM JoyceEnglishF AhmadJabbarM JamesBorgM

Q #3 (01): Solutions 1. Create table Department ( Dnumberintprimary key, Dnamevarchar(20), MgrSSNint references Employee ); Create table Employee ( SSNint primary key, Fnamevarchar(20), Lnamevarchar(20), Sexchar(1), Salaryint, SuperSSNintreferences Employee, Dnointreferences Department ); 2. Select Fname, Lname from Employee, Department where Dname=‘Research’ and Dnumber = Dno; 3. Insert into Department (Dnumber, Dname) values (6, “Sales”);

Q #3 (02) 1. Write a SQL select statement to find the names of all employees whose salaries are greater than Write a SQL select statement to find the names of departments for which female employees work. 3. Write a SQL statement to delete all the employees who work at Dno 4. DepartmentDNumberDNameMgrSSN 5Research Administrator Headquarter EmployeeSSNFNameLNameSexSalar y SuperSSNDno JohnSmithM FranklinWongM AliciaZelayaF JenniferWallaceF RameshNaraynM JoyceEnglishF AhmadJabbarM JamesBorgM

QUIZ #3 (02): Solution 1. Select Fname, Lname From Employee Where Salary > 30000; 2. Select Dname From Employee, Department Where Sex=‘F’ and Dno=Dnumber; 3. Delete * From Employee Where Dno=4;

Manipulating Information with the Relational Algebra [Ch. 6.1] Relation is a set of tuples and that each tuple in a relation has the same number and types of attributes. Relational algebra includes : Selection Operators Projection Operators Set Operators Join and product Operations Relation is a set of tuples and that each tuple in a relation has the same number and types of attributes. Relational algebra includes : Selection Operators Projection Operators Set Operators Join and product Operations

Selection Operators (  ) Reduce the number of tuples in a set by selecting those that satisfy some criteria. Example :  lastName = ‘Doe’ (Customer) [ Select from Customer where lastName = ‘Doe’ ]Customer Reduce the number of tuples in a set by selecting those that satisfy some criteria. Example :  lastName = ‘Doe’ (Customer) [ Select from Customer where lastName = ‘Doe’ ]Customer Account Id Last Name First Name StreetCityStateZip Code Balance 101BlockJane345 Randolph CircleApopkaFL30458-$ HamiltonCherry3230 Dade St.Dade CityFL30555-$ HarrisonKatherine103 Landis HallBrattFL30457-$ BreauxCarroll76 Main St.ApopkaFL30458-$ MorehouseAnita9501 Lafayette St.HoumaLA44099-$ DoeJane123 Main St.ApopkaFL30458-$ GreavesJoseph14325 N. Bankside St.GodfreyIL43580-$ DoeJaneCawthon Dorm, room 142TallahasseeFL32306-$10.55

Projection Operators (  ) Reduce the size of each tuple in a set by eliminating specific attributes. Example :  lastName, firstNAme (Customer) [ project customer onto (lastName, firstName) ] Customer Customer Reduce the size of each tuple in a set by eliminating specific attributes. Example :  lastName, firstNAme (Customer) [ project customer onto (lastName, firstName) ] Customer Customer Account Id Last Name First Name StreetCityStateZip Code Balance 101BlockJane345 Randolph CircleApopkaFL30458-$ HamiltonCherry3230 Dade St.Dade CityFL30555-$ HarrisonKatherine103 Landis HallBrattFL30457-$ BreauxCarroll76 Main St.ApopkaFL30458-$ MorehouseAnita9501 Lafayette St.HoumaLA44099-$ DoeJane123 Main St.ApopkaFL30458-$ GreavesJoseph14325 N. Bankside St.GodfreyIL43580-$ DoeJaneCawthon Dorm, room 142TallahasseeFL32306-$10.55

Set Operators (   -) Manipulate two similar sets of tuples by combining or comparing. Example : Rental  PreviousRental Rental PreviousRental Manipulate two similar sets of tuples by combining or comparing. Example : Rental  PreviousRental Rental PreviousRental accountIdvideoIDdateRenteddateDuecost /3/991/4/99$ /22/992/25/99$ /2/992/25/99$ /1/9812/31/98$ /14/992/16/99$ /1/991/8/99$ /1/991/4/99$3.49 accountIdvideoIddateRenteddateReturnedcost /9/9812/10/98$ /13/981/4/98$ /15/99 $ /1/9812/3/98$ /4/9812/6/98$ /1/991/4/99$ /9812/14/98$ /14/991/24/99$3.35

Set Operators (   -)... con’t The union of two relations is a relation that contains the set of each tuple that is in at least one of the input relations. Partial result of the Rental  PreviousRental accountIdvideoIddateRenteddateDuecost /1/991/8/99$ /1/991/4/99$ /3/991/4/99$ /1/9812/31/98$ /4/9812/6/98$ /14/991/24/99$3.35

Set Operators (   -)... con’t The intersection of two relations is the set of all tuples that occur in both input relations. The intersection of the relations Rental  PreviousRental in the previous example will return an empty set. Another example would be the intersection between the video IDs of the two tables.  videoId (Rental)   videoId (PrevioutsRental) = Videotapes that are currently rented as well as those that have been rented before. The set of all videotapes that have been rented previously but are not currently rented is expressed as follows:  videoId (PreviousRental) -  videoId (Rental) The intersection of two relations is the set of all tuples that occur in both input relations. The intersection of the relations Rental  PreviousRental in the previous example will return an empty set. Another example would be the intersection between the video IDs of the two tables.  videoId (Rental)   videoId (PrevioutsRental) = Videotapes that are currently rented as well as those that have been rented before. The set of all videotapes that have been rented previously but are not currently rented is expressed as follows:  videoId (PreviousRental) -  videoId (Rental)

Join and Product Operations (  ) Increase the size of each tuple by adding attributes The Cartesian product produces a tuple of the new realtion for each combination of one tuple from the left operand and one tuple from the right operand. Example : Employee  TimeCard Employee TimeCard Increase the size of each tuple by adding attributes The Cartesian product produces a tuple of the new realtion for each combination of one tuple from the left operand and one tuple from the right operand. Example : Employee  TimeCard Employee TimeCard ssnlastNamefirstName UnoJane ToulouseJennifer ThreatAyisha FortuneBruce FivozinskyBruce ssndatestartTimeendTimestoreIdpaid /14/998:1512:003yes /14/998:1512:003yes /23/9914:0022:005yes /16/998:1512:003yes /03/9910:0014:005yes /03/9915:0019:005yes

Join and Product Operations (  )... con’t The result of this operation has 30 tuples because there are 5 Employee and 6 TimeCard. Partial result of Cartesian product Employee  TimeCard The result of this operation has 30 tuples because there are 5 Employee and 6 TimeCard. Partial result of Cartesian product Employee  TimeCard Employee.ssnlastNamefirstNameTimeCard.ssnDatestartTimeendTimestoreIdpaid UnoJane /14/998:1512:003no ToulouseJie /14/998:1512:003no UnoJane /23/9914:0022:005no ToulouseJie /14/998:1512:003no

Join and Product Operations (  )... con’t A selection of those tuples where Employee.ssn equals TimeCard.ssn can be expressed by :  Employee.ssn = TimeCard.ssn (Employee  TimeCard) This type of product is called a join. The join operation puts together related objects from two relations. A Natural Join however is defined so that the shared attribute appears only once in the output table. Ref. textbook Table 6.6 [natural join] vs Table 6.7 [join] A selection of those tuples where Employee.ssn equals TimeCard.ssn can be expressed by :  Employee.ssn = TimeCard.ssn (Employee  TimeCard) This type of product is called a join. The join operation puts together related objects from two relations. A Natural Join however is defined so that the shared attribute appears only once in the output table. Ref. textbook Table 6.6 [natural join] vs Table 6.7 [join]

R= ( A, B, C ) F = {A  B, B  C } F + = {A  A, B  B, C  C, AB  AB, BC  BC, AC  AC, ABC  ABC, AB  A, AB  B, BC  B, BC  C, AC  A, AC  C, ABC  AB, ABC  BC, ABC  AC, ABC  A, ABC  B, ABC  C, A  B, … (1) ( given ) B  C, … (2) ( given ) A  C, … (3) ( transitivity on (1) and (2) ) AC  BC, … (4) ( augmentation on (1) ) AC  B,… (5) ( decomposition on (4) ) A  AB,… (6) ( augmentation on (1) ) AB  AC, AB  C, B  BC, A  AC, AB  BC, AB  ABC, AC  ABC, A  BC, A  ABC } R= ( A, B, C ) F = {A  B, B  C } F + = {A  A, B  B, C  C, AB  AB, BC  BC, AC  AC, ABC  ABC, AB  A, AB  B, BC  B, BC  C, AC  A, AC  C, ABC  AB, ABC  BC, ABC  AC, ABC  A, ABC  B, ABC  C, A  B, … (1) ( given ) B  C, … (2) ( given ) A  C, … (3) ( transitivity on (1) and (2) ) AC  BC, … (4) ( augmentation on (1) ) AC  B,… (5) ( decomposition on (4) ) A  AB,… (6) ( augmentation on (1) ) AB  AC, AB  C, B  BC, A  AC, AB  BC, AB  ABC, AC  ABC, A  BC, A  ABC } Using reflexivity, we can generate all trivial dependencies

Example: F= { A  B, B  C } A + = ABC B + = BC C + = C AB + = ABC

R= ( A, B, C, G, H, I ) F= {A  B, A  C, CG  H, CG  I, B  H } To compute AG + closure = AG closure = ABG ( A  B ) closure = ABCG ( A  C ) closure = ABCGH ( CG  H ) closure = ABCGHI ( CG  I ) Is AG a candidate key? AG  R A +  R ? G +  R ?

In general, suppose X  A violates BCNF, then one of the following holds X is a subset of some key K: we store ( X, A ) pairs redundantly. X is not a subset of any key: there is a chain K  X  A ( transitive dependency ) In general, suppose X  A violates BCNF, then one of the following holds X is a subset of some key K: we store ( X, A ) pairs redundantly. X is not a subset of any key: there is a chain K  X  A ( transitive dependency )

Third Normal Form The definition of 3NF is similar to that of BCNF, with the only difference being the third condition. Recall that a key for a relation is a minimal set of attributes that uniquely determines all other attributes. A must be part of a key (any key, if there are several). It is not enough for A to be part of a superkey, because this condition is satisfied by every attribute. The definition of 3NF is similar to that of BCNF, with the only difference being the third condition. Recall that a key for a relation is a minimal set of attributes that uniquely determines all other attributes. A must be part of a key (any key, if there are several). It is not enough for A to be part of a superkey, because this condition is satisfied by every attribute. A relation R is in 3NF if, for all X  A that holds over R A  X ( i.e., X  A is a trivial FD ), or X is a superkey, or A is part of some key for R If R is in BCNF, obviously it is in 3NF.

Suppose that a dependency X  A causes a violation of 3NF. There are two cases: X is a proper subset of some key K. Such a dependency is sometimes called a partial dependency. In this case, we store (X,A) pairs redundantly. X is not a proper subset of any key. Such a dependency is sometimes called a transitive dependency, because it means we have a chain of dependencies K  X  A. Suppose that a dependency X  A causes a violation of 3NF. There are two cases: X is a proper subset of some key K. Such a dependency is sometimes called a partial dependency. In this case, we store (X,A) pairs redundantly. X is not a proper subset of any key. Such a dependency is sometimes called a transitive dependency, because it means we have a chain of dependencies K  X  A.

Key Attributes XAttributes A Key Attributes AAttributes X Key Attributes AAttributes X Partial Dependencies Transitive Dependencies A not in a key A in a key

Motivation of 3NF By making an exception for certain dependencies involving key attributes, we can ensure that every relation schema can be decomposed into a collection of 3NF relations using only decompositions. Such a guarantee does not exist for BCNF relations. It weaken the BCNF requirements just enough to make this guarantee possible. Unlike BCNF, some redundancy is possible with 3NF. The problems associate with partial and transitive dependencies persist if there is a nontrivial dependency X  A and X is not a superkey, even if the relation is in 3NF because A is part of a key. Motivation of 3NF By making an exception for certain dependencies involving key attributes, we can ensure that every relation schema can be decomposed into a collection of 3NF relations using only decompositions. Such a guarantee does not exist for BCNF relations. It weaken the BCNF requirements just enough to make this guarantee possible. Unlike BCNF, some redundancy is possible with 3NF. The problems associate with partial and transitive dependencies persist if there is a nontrivial dependency X  A and X is not a superkey, even if the relation is in 3NF because A is part of a key.

Reserves Assume: sid  cardno (a sailor uses a unique credit card to pay for reservations). Reserves is not in 3NF sid is not a key and cardno is not part of a key In fact, (sid, bid, day) is the only key. (sid, cardno) pairs are redundantly.

Reserves Assume: sid  cardno, and cardno  sid (we know that credit cards also uniquely identify the owner). Reserves is in 3NF (cardno, sid, bid) is also a key for Reserves. sid  cardno does not violate 3NF.

Decomposition Decomposition is a tool that allows us to eliminate redundancy. It is important to check that a decomposition does not introduce new problems. A decomposition allows us to recover the original relation? Can we check integrity constraints efficiently? Decomposition is a tool that allows us to eliminate redundancy. It is important to check that a decomposition does not introduce new problems. A decomposition allows us to recover the original relation? Can we check integrity constraints efficiently?

A set of relation schemas { R 1, R 2, …, R n }, with n  2 is a decomposition of R if R 1  R 2  …  R n = R sid Supply status city part_id qty Supplier SP sid status city sid part_id qty and

Problems with decomposition 1. Some queries become more expensive. 2. Given instances of the decomposed relations, we may not be able to reconstruct the corresponding instance of the original relation – information loss. 3. Checking some dependencies may require joining the instances of the decomposed relations.

Lossless Join Decomposition The relation schemas { R 1, R 2, …, R n } is a lossless-join decomposition of R if: for all possible relations r on schema R, r =  R1 ( r )  R2 ( r ) …  Rn ( r ) The relation schemas { R 1, R 2, …, R n } is a lossless-join decomposition of R if: for all possible relations r on schema R, r =  R1 ( r )  R2 ( r ) …  Rn ( r )

Example: a lossless join decomposition sid sname major IN sid sname IM sid major Student IN IM ‘Student’ can be recovered by joining the instances of IN and IM

Example: a non-lossless join decomposition sid sname major IN IM Student IN IM sid major sname Student = IN  IM????

IN IM IN  IM The instance of ‘Student’ cannot be recovered by joining the instances of IM and NM. Therefore, such a decomposition is not a lossless join decomposition. Student

R- a relation schema F- set of functional dependencies on R The decomposition of R into relations with attribute sets R 1, R 2 is a lossless-join decomposition iff ( R 1  R 2 )  R 1  F + OR ( R 1  R 2 )  R 2  F + Theorem: i.e., R 1  R 2 is a superkey for R 1 or R 2. (the attributes common to R 1 and R 2 must contain a key for either R 1 or R 2 ).

Example R = ( A, B, C ) F = { A  B } R = { A, B } + { A, C } is a lossless join decomposition R = { A, B } + { B, C } is not a lossless join decomposition Example R = ( A, B, C ) F = { A  B } R = { A, B } + { A, C } is a lossless join decomposition R = { A, B } + { B, C } is not a lossless join decomposition

N = 5 R(A 1, A 2, A 3, A 4, A 5 ) M=3 R1(A 1, A 3 ) R2(A 2, A 4 ) R3(A 1, A 2, A 5 ) # of FD P=5 FD1, A 1 -> A 2 FD2, A 2, A 3 -> A 4 FD3, A 5 ->A 1 FD4, A 2, A 4 -> A 1, A 3 FD5, A 3 -> A 2, A 4

S-matrix 5x3-matrix A 1 A 2 A 3 A 4 A 5 R1a1 b(1,2) a3 b(1,4) b(1,5) R2b(2,1) a2 b(2,3) a4 b(2,5) R3a1 a2 b(3,3) b(3,4) a5

FD1. A 1 ->A 2 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5 FD2 A 2,A 3 -> A 4 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5

FD3 A 5 -> A 1 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5 FD4 A 2,A 4 -> A 1,A 3 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5

FD5 A 3 -> A 2, A 4 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5 // check if any single row has all “a” value // if not it is not a good decomposition

FD1, A 1 -> A 2 FD2, A 1, A 3 -> A 4, A 5 FD3, A 5 -> A 1, A 3 FD4, A 2, A 4 -> A 1, A 3 FD5, A 3 -> A 2, A 4 FD1. A1->A2 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5

FD2 A 1, A 3 -> A 4, A 5 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5 FD3 A 5 -> A 1, A 3 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5

FD4 A 2, A 4 -> A 1, A 3 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5 FD5 A 3 -> A 2, A 4 a1a2a3b(1,4)b(1,5) b(2,1)a2b(2,3) a4b(3,5) a1a2b(3,3)b(3,4) a5

R ( A1, A2, A3, A4, A5 ) S-Matrix 5x3 Because m = 3 and P = 5 A1 A2 A3 A4 A5 R1 a1 b(1,2) a3 b(1,4) b(1,5) R2 b(2,1) a2 b(2,3) a4 b(2,5) R3 a1 a2 b(3,3) b(3,4) a5 # of FD P = 5 FD 1 A1 A2 FD 2 A1, A3 A4, A5 FD 3 A5 A1 FD 4 A2, A4 A1, A3 FD 5 A3 A2, A4 n = 5 R( A1, A2, A3, A4, A5 ) m = 3 R1 ( A1, A3 ) R2 ( A2, A4 ) R3 ( A1, A2, A5 ) In Class Examples 02

FD1. A1 A2 A1 A2 A3 A4 A5 R1a1 a2 a3 b(1,4) b(1,5) R2 b(2,1) a2 b(2,3) a4 b(2,5) R3 a1 a2 b(3,3) b(3,4) a5 FD1. A1 A2 A1 A2 A3 A4 A5 R1a1 a2 a3 b(1,4) b(1,5) R2 b(2,1) a2 b(2,3) a4 b(2,5) R3 a1 a2 b(3,3) b(3,4) a5 FD2. A1, A3 A4, A5 A1 A2 A3 A4 A5 R1a1 a2 a3 b(1,4) b(1,5) R2 b(2,1) a2 b(2,3) a4 b(2,5) R3 a1 a2 b(3,3) b(3,4) a5 FD3. A5 A1 A1 A2 A3 A4 A5 R1a1 a2 a3 b(1,4) b(1,5) R2 b(2,1) a2 b(2,3) a4 b(2,5) R3 a1 a2 b(3,3) b(3,4) a5 FD4. A2, A4 A1, A3 A1 A2 A3 A4 A5 R1a1 a2 a3 b(1,4) b(1,5) R2 b(2,1) a2 b(2,3) a4 b(2,5) R3 a1 a2 b(3,3) b(3,4) a5 FD5. A3 A2, A4 A1 A2 A3 A4 A5 R1a1 a2 a3 b(1,4) b(1,5) R2 b(2,1) a2 b(2,3) a4 b(2,5) R3 a1 a2 b(3,3) b(3,4) a5

Normalization Consider algorithms for converting relations to BCNF or 3NF. If a relation schema is not in BCNF it is possible to obtain a lossless-join decomposition into a collection of BCNF relation schemas. Dependency-preserving is not guaranteed. 3NF There is always a dependency-preserving, lossless-join decomposition into a collection of 3NF relation schemas. Consider algorithms for converting relations to BCNF or 3NF. If a relation schema is not in BCNF it is possible to obtain a lossless-join decomposition into a collection of BCNF relation schemas. Dependency-preserving is not guaranteed. 3NF There is always a dependency-preserving, lossless-join decomposition into a collection of 3NF relation schemas.

BCNF Decomposition It is a lossless join decomposition. But not necessary dependency preserving It is a lossless join decomposition. But not necessary dependency preserving Suppose R is not in BCNF, A is an attribute, and X  A is a FD that violates the BCNF condition. 1. Remove A from R 2. Decompose R into XA and R-A 3. Repeat this process until all the relations become BCNF

3NF Synthesis Algorithm Note: result is lossless-join and dependency preserving Find a canonical cover F c for F ; result =  ; for each    in F c do if no schema in result contains  then add schema  to result; if no schema in result contains a candidate key for R then begin choose any candidate key  for R; add schema  to the result end

Design Goals Goal for a relational database design is: BCNF lossless join Dependency preservation If we cannot achieve this, we accept: 3NF lossless join Dependency preservation Goal for a relational database design is: BCNF lossless join Dependency preservation If we cannot achieve this, we accept: 3NF lossless join Dependency preservation