CS 338 Functional Dependencies

Transcription

1 CS 338 Functional Dependencies Bojana Bislimovska Winter 2016

2 Outline Design Guidelines for Relation Schemas Functional Dependency Set and Attribute Closure Schema Decomposition Boyce-Codd Normal Form

3 Design Guidelines for Relation Schemas Measures to determine the quality of relation schema design: Clear semantics of attributes in the schema Reduction of redundant information in tuples Reduction of NULL values in tuples Disallowment of generating spurious tuples Above-mentioned measures are not always independent of one another

4 Design Guidelines for Relation Schemas Guideline 1: Design a relation schema so that is easy to explain its meaning. Do not combine attributes from multiple entity types and relationship types into a single relation Example of violating guideline 1 Every tuple includes employee and department data Redundant repetition of Dname and Manager Ssn for every employee (increases storage space) Potential for many NULL values (employee without department, department without employees)

5 Design Guidelines for Relation Schemas Update anomalies Deleting the last employee in a dept should not delete dept Changing the dept name/mgr requires many tuples to be updated Inserting employees requires checking for consistency of its dept name and manager Guideline 2: Design base relation schemas so that no insertion, deletion, or modification anomalies are present Consistent with guideline 1

6 Design Guidelines for Relation Schemas NULL values in tuples If some attributes do not apply to all tuples in the relation Multiple interpetation of NULL values Guideline 3: Avoid placing attributes in a base relation whose values may frequently be NULL. If NULLs are unavoidable, make sure they apply in exceptional cases, and do not apply to a majority of tuples in the relation.

7 Design Guidelines for Relation Schemas Spurious tuples Guideline 4: Design relation schemas so that they can be joined with equality conditions on appropirately related attribute pairs (primary key, foreign key) that guarantees that no spurious tuples are generated.

8 Functional Dependency Constraint between two sets of attributes from the database Expresses the fact that in a relation schema (values of) a set of attributes uniquely determine (values of) another set of attributes Definition: Given relation schema R(A 1,A 2,,A n ) and sets of attributes X {A 1,A 2,,A n }, Y {A 1,A 2,,A n }, X Y specifies the following constraint (functional dependency): for any tuples t 1 and t 2 in any valid relation state r of R, if t 1 [X] = t 2 [X] then t 1 [Y] = t 2 [Y]. A functional dependency is a property of the semantics (meaning) of the attributes Main use in the further description of a relation schema by specifying constraints on its attributes that must always hold Given a relation state Cannot determine which functional dependencies hold Can state that functional dependency does not hold if there are tuples that show violation of the dependency

9 Functional Dependency Notation: {B 1,B 2,,B i } {C 1,C 2,,C j } but can omit set braces if i=1 or j=1, respectively. Example Following functional dependencies hold Ssn Ename Pnumber {Pname, Plocation} {Ssn, Pnumber} Hours

10 Functional Dependencies and Keys Keys (as defined previously): A superkey is a set of attributes such that no two tuples (in an instance) agree on their values for those attributes. A candidate key is a minimal superkey. A primary key is a candidate key chosen by the DBA Relating keys and FDs: If K R is a superkey for relatio s he a R, the depe de K R holds on R. If depe de K R holds o R a d we assu e that R does ot o tai duplicate tuples (i.e. relational model) then K R is a superkey for relation schema R

11 Closure of FD Sets How do we know what additional FDs hold in a schema? The closure of the set of functional dependencies F (denoted F + ) is the set of all functional dependencies that are satisfied by every relational instance that satisfies F. Informally, F + includes all of the dependencies in F, plus any dependencies they imply.

12 Computing Attribute Closures If we want to derive the maximal set of attributes functionally determined by some X (called the attribute closure of X). function ComputeX + (X, F) begin X + := X; while true do if there e ists Y ) F such that (1) Y X +, and (2) Z X + then X + := X + Z else exit; return X + ; end

13 Computing Attribute Closures Let R be a relational schema and F a set of functional dependencies on R. Then Theorem: X is a superkey of R if and only if ComputeX + (X, F) = R Theorem: X Y F + if and only if Y ComputeX + (X, F)

14 Attribute Closure Example Example: F = { Ssn EName Pnum Pname, Ploc Ploc, Hours Allowa e } ComputeX + ({Pnum,Hours},F): FD X + initial Pnum Pname, Ploc Ploc, Hours Allowa e Pnum, Hours Pnum, Hours, Pname, Ploc Pnum, Hours, Pname, Ploc, Allowance

15 Schema Decomposition Let R be a relation schema (= set of attributes). The collection {R 1,..., R n } of relation schemas is a decomposition of R if R = R 1 R 2 R n A good decomposition does not lose information complicate checking of constraints contain anomalies (or at least contains fewer anomalies)

16 Lossless-Join Decompositions We should be able to reconstruct the instance of the original table from the instances of the tables in the decomposition Example: Consider replacing By decomposing into two tables Student Assignment Group Mark Ann A1 G1 80 Ann A2 G3 60 Bob A1 G2 60 Student Group Mark Ann G1 80 Ann G3 60 Bob G2 60 Assignment Mark A1 80 A2 60 A1 60

17 Lossless-Join Decompositions Computing natural join of SGM and AM produces Student Assignment Group Mark Ann A1 G1 80 Ann A2 G3 60 Ann A1 G3 60 Bob A2 G2 60 Bob A1 G and we get extra data (spurious tuples). We would therefore lose information if we were to replace the first table, Marks, by SGM and AM. If re-joining SGM and AM would always produce exactly the tuples in Marks, then we call SGM and AM a lossless-join decomposition

18 Lossless-Join Decompositions A decomposition {R1, R2} of R is lossless if and only if the common attributes of R1 and R2 form a superkey for either s he a, that is R R R or R R R2 Example: In the previous example we had R = {Student, Assignment, Group, Mark}, F = { tude t, Assig e t Group, Mark }, R1 = {Student, Group, Mark}, R2 = {Assignment, Mark} Decomposition {R1, R2} is lossy e ause R R = {Mark} is ot a superkey of either {Student, Group, Mark} or {Assignment, Mark}

19 Normal Forms What is a good relatio al data ase s he a? Rule of thumb: Independent facts in separate tables: Each relation schema should consist of a primary key and a set of mutually independent attri utes This is achieved by transforming a schema into a normal form. Goals: Intuitive and straightforward transformation Anomaly-free/Nonredundant representation of data

20 Boyce-Codd Normal Form (BCNF) - Informal BCNF formalizes the goal that in a good database schema, independent relationships are stored in separate tables. Given a database schema and a set of functional dependencies for the attributes in the schema, we can determine whether the schema is in BCNF. A database schema is in BCNF if each of its relation schemas is in BCNF. Informally, a relation schema is in BCNF if and only if any group of its attributes that functionally determines any others of its attributes functionally determines all others, i.e., that group of attributes is a superkey of the relation.

21 Formal Definition of BCNF Let R be a relation schema and F a set of functional dependencies. Schema R is in BCNF (w.r.t. F) if and only if whenever (X Y ) F + and XY R, then either (X Y ) is trivial (i.e., Y X), or X is a superkey of R A database schema {R 1,..., R n } is in BCNF if each relation schema R i is in BCNF.

22 BCNF and Redundancy Why does BCNF avoid redundancy? Consider: Supplied_Items Sno Sname City Pno Pname Price The following functional dependency holds: Sno Sname, City Therefore, supplier name ith a d it Aja ust e repeated for ea h ite supplied supplier S1. Assume the above FD holds over a schema R that is in BCNF. This implies that: Sno is a superkey for R each Sno value appears on one row only no need to repeat Sname and City values

23 Lossless-Join BCNF Decomposition function DecomposeBCNF(R, F) begin Result := {R}; while some R i Result a d X Y F + violate the BCNF condition do begin Replace R i by R i Y X ; Add {X, Y } to Result; end; return Result; end

24 Lossless-Join BCNF Decomposition No efficient procedure to do this exists. Results depend on sequence of FDs used to decompose the relations. It is possible that no lossless join dependency preserving BCNF decomposition exists

25 Lossless-Join BCNF Decomposition Example R = {Sno,Sname,City,Pno,Pname,Price} functional dependencies: Sno Sname,City Pno Pname Sno,Pno Pri e This schema is not in BCNF because, for example, Sno determines Sname and City, but is not a superkey of R.

26 Lossless-Join BCNF Decomposition Example The complete schema is now R 1 = {Sno,Sname,City} R 2 = {Sno,Pno,Price} R 3 = {Pno,Pname} This schema is a losslessjoin, BCNF decomposition of the original schema R.