V. Database Design CS448/ How to obtain a good relational database schema

Transcription

1 V. How to obtain a good relational database schema Deriving new relational schema from ER-diagrams Normal forms: use of constraints in evaluating existing relational schema CS448/648 1

2 Translating an E-R Model to a Relational Schema General approach is straightforward Each entity set maps to a new table Each attribute maps to a new table column Each relationship set maps to either new table columns or to a new table CS448/648 2

3 Introduction to Database Management Representing Strong Entity Sets Entity set with attributes table with attributes Entity of type row in table Primary key of entity set primary key of table Ex. Student Major StudentNum StudentName Student StudentNum StudentName Major CS448/648 3

4 Introduction to Database Management Representing Weak Entity Sets Weak entity set table Columns of table should include Attributes of the weak entity set Attributes of the identifying relationship set Primary key attributes of entity set for dominating entities Primary key of weak entity set primary key of table CS448/648 4

5 Representing Weak Entity Sets (cont d) Ex. Balance Account 1 AccNum Log N Transaction TransNum Date Amount Account AccNum Balance Transaction TransNum AccNum Date Amount CS448/648 5

6 Introduction to Database Management Representing Relationship Sets If the relationship set is an identifying relationship set for a weak entity set then no action needed If we can deduce the general cardinality constraint (1,1) for a component entity set then add following columns to table Attributes of the relationship set Primary key attributes of remaining component entity sets Otherwise: relationship set table CS448/648 6

7 Representing Relationship Sets (cont d) Columns of table should include Attributes of the relationship set Primary key attributes of each component entity set Primary key of table determined as follows If we can deduce the general cardinality constraint (0,1) for a component entity set, then choose the primary key attributes for Otherwise, choose primary key attributes of each component entity CS448/648 7

8 Representing Relationship Sets (cont d) Ex. Score Address Team HomeTeam Visitor Match Location TeamName LocName Team TeamName Location LocName Address Match HomeTeamName VisitorTeamName LocName Score Note that the role name of a component entity set should be prepended to its primary key attributes, if supplied CS448/648 8

9 Example Translation Course CourseNum CourseName Student StudentNum StudentName Section CourseNum SectionNum ProfNum EnrolledIn CourseNum SectionNum StudentNum Mark Professor ProfNum ProfName CS448/648 9

10 Representing Aggregation Tabular representation for aggregation of relationship set tabular representation for relationship set To represent relationship set involving aggregation of, treat the aggregation like an entity set whose primary key primary key of the table for CS448/648 10

11 Representing Aggregation (cont d) Ex. CourseNum Student N EnrolledIn N Course 1 StudentNum CourseAccount ExpirationDate 1 Account UserId Student Course Account StudentNum CourseNum UserId EnrolledIn StudentNum CourseNum CourseAccount UserId StudentNum CourseNum ExpirationDate CS448/648 11

12 Representing Specialization Create table for higher-level entity set, and treat specialized entity subsets like weak entity sets Ex. StudentNumber Student StudentName Graduate N (1, 1) SupervisedBy 1 (0, N) Professor Degrees ProfessorName Student StudentNumber StudentName Professor ProfessorName Graduate StudentNumber ProfessorName Degree StudentNumber Degree CS448/648 12

13 Representing Generalization Create a table for each lower-level entity set only Columns of new tables should include Attributes of lower level entity set Attributes of the superset The higher-level entity set can be defined as a view on the tables for the lower-level entity sets CS448/648 13

14 Representing Generalization (cont d) Ex. MakeAndModel LicenceNum Vehicle Price Tonnage Truck Car MaxSpeed AxelCount PassengerCount Truck LicenceNum MakeAndModel Price Tonnage AxelCount Car LicenceNum MakeAndModel Price MaxSpeed PassengerCount CS448/648 14

15 Normal Forms What is a good relational database schema? How can we evaluate an existing relational schema? Goals: Intuitive and straightforward changes Nonredundant storage of data We review: Boyce-Codd Normal Form (BCNF) Third Normal Form (3NF) CS448/648 15

16 Change Anomalies Assume we are given the E-R diagram Sno Sname Ino Supplied_Items City Iname Price CS448/648 16

17 Change Anomalies (cont d) This maps to Supplied Items Sno Sname City Ino Iname Price S1 Magna Ajax I1 Bolt 0.50 S1 Magna Ajax I2 Nut 0.25 S1 Magna Ajax I3 Screw 0.30 S2 Budd Hull I3 Screw 0.40 Problems 1. Update problems (e.g. changing name of supplier) 2. Insert problems (e.g. add a new item) 3. Delete problems (e.g. Budd no longer supplies screws) 4. Likely increase in space requirements CS448/648 17

18 Change Anomalies (cont d) Now compare to Supplier Sno Sname City S1 Magna Ajax S2 Budd Hull Item Ino I1 I2 I3 Iname Bolt Nut Screw Supplies Sno Ino Price S1 I S1 I S1 I S2 I CS448/648 18

19 Change Anomalies (cont d) But other extreme is also undesirable (information about relationships is lost) Snos Sno S1 S2 Inums Inum I1 I2 I3 Snames Sname Magna Budd Inames Iname Bolt Nut Screw Cities City Ajax Hull Prices Price CS448/648 19

20 Good What is a good relational database schema? Rule of thumb: Independent facts in separate tables or: Each relation schema should consist of a primary key and a set of mutually independent attributes CS448/648 20

21 Functional Dependencies Generalizes notion of superkey Used to characterize BCNF and 3NF Some notation: Allow projection operation on tuples Ex. when is the first tuple in Supplier, [Sno] = (S1) [Sname, City] = (Magna, Ajax) CS448/648 21

22 Examples of Functional Dependencies Consider EmpProj SIN PNum Hours EName PName PLoc Allowance Key constraint forbids two different rows and in EmpProj with [SIN, PNum] = [SIN, PNum] Also disallowed one SIN with two employee names one project number with two project names or two locations different allowances for the same number of hours at the same location Notation SIN EName PNum PName, Ploc PLoc, Hours Allowance CS448/648 22

23 Introduction to Database Management Formal Definitions Let be a relation schema, and. The functional dependency holds on if no legal instance of contains two tuples and with and functionally determines, is functionally dependent on Keys again: is a superkey for relation schema if dependency holds on Functional dependencies are constraints on all instances of a schema; they are design decisions based on the semantics of the attributes A relation can confirm that a functional dependency does not hold; the relation cannot confirm that a functional dependency must always hold. CS448/648 23

24 Formal Definitions (cont d) Ex. TEACH Teacher Course Text Smith Data Structures Bartram Smith Data Management Al-Nour Hall Compilers Hoffman Brown Data Structures Augenthaler Let denote a set of functional dependencies over. The closure of, denoted by is the set of all functional dependencies that are satisfied by every relation instance that satisfies (= logical implications of ) Note: CS448/648 24

25 Introduction to Database Management Reasoning About Functional Dependencies Need to be able to find superkeys decide membership in find minimal covers There are different sets of functional dependencies that have the same logical implications. Small simples sets are desirable, and are called minimal covers. CS448/648 25

26 Introduction to Database Management Reasoning About Functional Dependencies (cont d) Logical implications can be derived by using inference rules called Armstrong s axioms (reflexivity) (augmentation) (transitivity), Additional rules can be derived (union), (decomposition) The axioms are sound (anything derived from is in ) complete (anything in can be derived) CS448/648 26

27 Reasoning (cont d) Ex. Let consist of SIN, PNum Hours SIN EName PNum PName, PLoc PLoc, Hours Allowance A derivation of: SIN, PNum Allowance 1. SIN, PNum Hours ( ) 2. PNum PName, PLoc ( ) 3. PLoc, Hours Allowance ( ) 4. SIN, PNum PNum (reflexivity) 5. SIN, PNum PName, PLoc (transitivity, 4 and 2) 6. SIN, PNum PLoc (decomposition, 5) 7. SIN, PNum PLoc, Hours (union, 6, 1) 8. SIN, PNum Allowance (transitivity, 7 and 3) CS448/648 27

28 Introduction to Database Management Reasoning (cont d) There is a more efficient way of using Armstrong s axioms function begin := ; while true do if there exists (1) (2) then := else exit; return ; end, and such that Let be a relational schema and a set of functional dependencies on. Then Theorem: is a superkey of if and only if Theorem: if and only if CS448/648 28

29 Introduction to Database Management Finding Minimal Covers A minimal cover for can be computed in four steps. Note that each step must be repeated until it no longer succeeds in updating. Step 1. Replace with the pair and. Step 2. Remove. from if Step 3. Remove in from the left-hand-side of. in if is Step 4. Replace and in by. CS448/648 29

30 Introduction to Database Management Boyce-Codd Normal Form (BCNF) Formalization of the goal that independent relationships are stored in separate tables Let be a relation schema and a set of functional dependencies. A functional dependency is trivial if. Schema is in BCNF if and only if whenever, then either and is trivial, or is a superkey of A database schema is in BCNF is in BCNF if each relation schema CS448/648 30

31 BCNF (cont d) Why does BCNF avoid redundancy? For schema Supplied Items we had FD: Sno Sname, City Implies: supplier name Magna and city Ajax must be repeated for each item supplied by supplier S1. Assume FD holds over a schema that is in BCNF. This implies Sno is a superkey for each Sno value appears on one row only no need to repeat Sname and City values (Cf. the original Supplier table) CS448/648 31

32 Introduction to Database Management Computing a Normal Form What to do if a given relational schema is not in BCNF? Strategy: identify undesirable dependencies, decompose schema Let be a relation schema (= set of attributes). Collection of relation schemas is a decomposition of if A good decomposition does not lose information complicate checking of constraints CS448/648 32

33 Lossless-Join Decompositions We should be able to construct the original table from its decomposition Ex. Consider replacing Marks Student Assignment Group Mark Ann A1 G1 80 Ann A2 G3 60 Bob A1 G2 60 by decomposing (i.e. projecting) into two tables SGM Student Group Mark Ann G1 80 Ann G3 60 Bob G2 60 AM Assignment Mark A1 80 A2 60 A1 60 CS448/648 33

34 Lossless-Join Decompositions (cont d) But computing the 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 G2 60 We get extra data, spurious tuples, and would therefore lose information if we were to replace Marks by SGM and AM. If converse is true, if re-joining SGM and AM would always produce exactly the tuples in Marks, then we call SGM and AM a losslessjoin decomposition. CS448/648 34

35 Introduction to Database Management Identifying Lossless-Join Decompositions A decomposition of is lossless if and only if the common attributes of and form a superkey for either schema, that is or Ex. In the previous example we had = Student, Assignment, Group, Mark, = (Student, Assignment Group, Mark), = Student, Group, Mark, = Assignment, Mark Decomposition is lossy because a superkey of either SGM or AM is not CS448/648 35

36 Dependency Preservation Goal: efficient testing of constraints on the decomposed schema Ex. A table for a company database could be R Proj Dept Div with functional dependencies FD1: Proj FD2: Dept FD3: Proj Dept, Div, and Div Consider two decompositions = R1[Proj, Dept], R2[Dept, Div] = R1[Proj, Dept], R3[Proj, Div] Both are lossless. (Why?) CS448/648 36

37 Introduction to Database Management Dependency Preservation (cont d) Decomposition lets us test FD1 on table R1 and FD2 on table R2; if they are both satisfied, FD3 is automatically satisfied In decomposition we can test FD1 on table R1 and FD3 on table R3. Dependency FD2 is an interrelational constraint: testing it requires joining tables R1 and R3 Let be a relation schema and a set of functional dependencies on. A decomposition of is dependency preserving if there is an equivalent set of functional dependencies, none of which is interrelational in CS448/648 37

38 Introduction to Database Management Computing a Lossless-Join BCNF Decomposition function begin Result := ; while some Result and violate the BCNF condition do begin Replace by ; Add to Result; end; return Result; end No efficient procedure to do this exists. It is possible that no dependency preserving BCNF decomposition exists. Ex. Consider A, B, C and AB C, C B. CS448/648 38

39 Introduction to Database Management Third Normal Form (3NF) Let be a relation schema and a set of functional dependencies. Schema is in 3NF if and only if whenever, then either is trivial, or is a superkey of, or each attribute of A database schema is in 3NF is contained in a candidate key of and is in 3NF if each relation schema Because 3NF is looser than BCNF, it allows more redundancy A lossless-join, dependency preserving decomposition into 3NF relation schemas always exists. CS448/648 39

40 Introduction to Database Management Computing a 3NF Decomposition A lossless-join 3NF decomposition that is dependency preserving can be efficiently computed function begin Result := ; := a minimal cover for ; for each do Result := Result ; if there is no Result such that contains a candidate key for then begin compute a candidate key for ; Result := Result ; end; return Result; end CS448/648 40