Presentation is loading. Please wait.

Presentation is loading. Please wait.

Defined by Edgar Codd in 1970 Defined by Edgar Codd in 1970 Considered ingenious but impractical Considered ingenious but impractical Conceptually simple.

Similar presentations


Presentation on theme: "Defined by Edgar Codd in 1970 Defined by Edgar Codd in 1970 Considered ingenious but impractical Considered ingenious but impractical Conceptually simple."— Presentation transcript:

1 Defined by Edgar Codd in 1970 Defined by Edgar Codd in 1970 Considered ingenious but impractical Considered ingenious but impractical Conceptually simple Conceptually simple Relational DB is percieved as a collection of tables Relational DB is percieved as a collection of tables Provides SQL, a 4GL Provides SQL, a 4GL Relational Data Model

2 Terminology Terminology  Relation  Tuple  Attribute Attribute values Attribute values  Domains  Simple (value is atomic) and complex (value is a relation per se) Some properties of relations Some properties of relations  Order of attributes and tuples has no significance  There are no duplicate tuples

3 Relation Keys The key is the set of attributes that uniquely indentifies tuples in a relation The key is the set of attributes that uniquely indentifies tuples in a relation Properties of a (candidate) key: Properties of a (candidate) key: –Uniqueness –Nonredundancy Relation may have more than one candidate key Relation may have more than one candidate key Primary key is the chosen candidate key Primary key is the chosen candidate key Key attribute, non-key attribute Key attribute, non-key attribute

4 Primary and Foreign Key FName MInit LName SSN BDate Address Sex Salary SuperSSN * DNo * EMPLOYEE DNumber * DLocation DName DNumber MgrSSN * MgrStartDate DEPARTMENT DEPT_LOCATIONS PName PNumber PLocation DNum * PROJECT ESSN * PNo * Hours WORKS_ON ESSN * DependentName Sex BDate Relationship DEPENDENT Legend: XXXXXXprimary key * foreign key

5

6

7 Update Anomalies PersonProjectProjectTimeSpentBy IdBudgetIdPersonOnProject S7532P17 S7540P23 S7932P14 S7927P31 S8040P25 17P4 Anomalies: budgets 32 and 40 appear twice udesired null values Add a new person to P1: Add Tupple (ASSIGN, S85, 35, P1, 9) ASSIGN

8 Update Anomalies (cont.) PersonProjectProjectTimeSpentBy IdBudgetIdPersonOnProject S7532P17 S7540P23 S7932P14 S7927P31 S8040P25 17P4 S8535P19 Anomaly: conflicting budgets for P1 Remove a person from P3: Delete Tupple (ASSIGN, S79, 27, P3, 1) ASSIGN

9 Update Anomalies (cont.) PersonProjectProjectTimeSpentBy IdBudgetIdPersonOnProject S7532P17 S7540P23 S7932P14 S8040P25 17P4 S8535P19 Anomaly: deletes also project budget Change P1’s budget: Update Tupple (ASSIGN, S75, 32, P1, 7; S75, 35, P1, 7) ASSIGN

10 Update Anomalies (cont.) PersonProjectProjectTimeSpentBy IdBudgetIdPersonOnProject S7535P17 S7540P23 S7932P14 S7927P31 S8040P25 17P4 S8535P19 Anomaly: different values for P1’s budget ASSIGN

11 Updating Anomalies Avoided No null values No anomalies after adding person’s assignment: Add Tuple (ASSIGNMENT, S85, P1, 3) No anomalies after deleting person’s assignment: Delete Tuple (ASSIGNMENT, S79, P3, 1) No anomalies after updating budget: Update Tuple (PROJECT, P1, 32; P1, 35) Project IdBudget P132 P240 P327 P417 PROJECT PersonProjectTimeSpentBy IdIdPersonOnProject S75P17 S75P23 S79P14 S79P31 S80P25 ASSIGNMENT

12 Functional Dependency Definition: Definition: Attribute B is functionally dependent on attribute A if each value in column A determines one and only one value in column B. Functional dependency is a property of the meaning of attributes Functional dependency is a property of the meaning of attributes A relation is made up of attributes and functional dependencies among them A relation is made up of attributes and functional dependencies among them Notation: Notation: AB

13 Let’s Exercise

14 Multivalued Dependency n Definition There is a multivalued dependency of field B on field A if a value for A is associated with a collection of values for B, independent of values for C. Notation: AB

15 Relational Database Design Where do we get the relation, or relations, to start the proces? Where do we get the relation, or relations, to start the proces? How do we know which relations need to be restructured? How do we know which relations need to be restructured? How do we go about such restructuring? How do we go about such restructuring? How do we know when we are done? How do we know when we are done? Formal criteria for data structuring: normal forms

16

17 Second Normal Form (2NF) A relation is in 2NF if every non-key attribute is functionally dependent on the key as a whole. A relation is in 2NF if every non-key attribute is functionally dependent on the key as a whole. EMPL_PROJ = (SSN, PNumber, Hours, EName, PName)

18 Third Normal Form (3NF) A relation is in 3NF if it is in 2NF and no non-key attribute is functionally dependent on another non- key attribute. A relation is in 3NF if it is in 2NF and no non-key attribute is functionally dependent on another non- key attribute. EMPL_DEPT = (SSN, EName, BDate, DeptNo, DName)

19 Boyce-Codd Normal Form (BCNF) A relation is in BCNF if every determinant is a candidate key. A relation is in BCNF if every determinant is a candidate key. STUDENT = ([StudentId, PhoneNo, Course, Grade]; [StudentId PhoneNo; StudentId, Course Grade])

20 Fourth Normal Form (4NF) Multivalued Dependency (X Y) Multivalued Dependency (X Y) A relation is in 4NF if every multivalued determinant is a key. A relation is in 4NF if every multivalued determinant is a key. EMPLOYEE = ([SSN, FName, Init, LName, Skill]; [SSN FName, Init, Lname; SSN Skill]) Note: the key in the above relation is SSN, Skill and not just SSN.

21 Normalization Procedure I Determine functional and multivalued dependencies Determine functional and multivalued dependencies Determine candidate keys, then key and non-key attributes Determine candidate keys, then key and non-key attributes If needed, decompose the relation to conform with the 1NF If needed, decompose the relation to conform with the 1NF Decompose the relation as needed to conform with the 2NF, 3NF, BCNF, and 4NF Decompose the relation as needed to conform with the 2NF, 3NF, BCNF, and 4NF

22 Determining Candidate Keys Perhaps the most difficult problem is to determine the candidate keys Perhaps the most difficult problem is to determine the candidate keys Procedure: Procedure: –Start with a key made of all the determinants –Eliminate attributes that are determined by other attributes Alternate elimination sequences lead to alternate candidate keys Alternate elimination sequences lead to alternate candidate keys

23 Normalization Procedure II Determine functional and multivalued dependencies Determine functional and multivalued dependencies Determine candidate keys, then key and non-key attributes Determine candidate keys, then key and non-key attributes If needed, decompose the relation to conform with the 1NF and 4NF If needed, decompose the relation to conform with the 1NF and 4NF Decompose the relation to conform with the BCNF Decompose the relation to conform with the BCNF

24 Decomposition Procedure 1 Take a relation, R = (A, B, C, D, E,....), that is not in the BCNF. Find an FD, C D, that is causing R to not be in BCNF 2 Form two new relations: R1 = (A, B, C, E,....) and R2 = (C, D), where the dependency part of the FD has been used to form R2 3 R1 and R2 must now be checked to see if they are in BCNF Note: Every effort should be made to avoid taking out an FD, when the dependency part of that FD is itself, either all or part of it, a determinant for another FD. In other words, start at the end of depencencies chain.

25 Let’s exercise some more!


Download ppt "Defined by Edgar Codd in 1970 Defined by Edgar Codd in 1970 Considered ingenious but impractical Considered ingenious but impractical Conceptually simple."

Similar presentations


Ads by Google