1. THE RELATIONAL DATA MODEL SECTION 4 General Concepts

2. Introduction E.F. Codd in 1970 Existing databases used physical pointers What is the problem with pointers?

3. User unaware of physical structure Codd proposed two data manipulation languages Relation model overcame problems

4. Fundamental Concepts Organizes data using tables or relations What is a relation? The following example

5. An ER model Hours- per-Week Bonus-Rate Skill-Type SKILL HAS- SKILL 1 M 1 ASSIGNED TO MN WORKER NameWorker-Id Hourly- Rate WORKER Bldg-Id Address Type Quality- Level Status BUILDING SUPERVISES M No.-of-Days Start-Date

6. Recursive relationship Relation attribute Degree of relation Tuple Attribute Domain

7. Conceptual ModelRelation Attribute Worker –ID (Attribute)WORKER-ID Name (Attribute)NAME Hourly-Rate (Attribute)HOURLY-RATE HAS-SKILL (Relationship)SKILL-TYPE SUPERVISES (Relationship)SUPV-ID Attributes of WORKER

8. WORKER TABLE WORKER-IDNAMEHOURLY-RATESKILL-TYPESUPV-ID 1235M. Faraday12.50Electric1311 1412C. Nemo13.75Plumbing1520 2920R. Garret10.00Roofing 3231P. Mason17.40Framing 1520H. Rickover11.75Plumbing 1311C. Coulomb15.50Electric 3001J. Barrister8.20Framing3231 attributes rows or tuples

9. Null Values Might not know the value Null value is not a blank or zero Attribute may not be applicable

10. Keys Primary Key Key

11. Functionally Determine Composite key

12. Foreign Keys Need not have the same name Recursive foreign key Relational database schema What is a foreign key?

13. Integrity Constraints –No key attribute of any row in a relation may have a null value Referential integrity rule –Every foreign key must either be null, or its value must be the actual value of a key in another relation Entity integrity rule

14. The Normalization Process Normalization WORKER TABLE WORKER-IDNAMESKILL-TYPESUPV-IDBLDG-ID 1235M. FaradayElectric1311312 1235M. FaradayElectric1311515 1412C. NemoPlumbing312 1412C. NemoPlumbing460 1412C. NemoPlumbing435 1412C. NemoPlumbing515 1311C. CoulombElectric435

15. Data Redundancy Data Integrity Update Anomaly

16. Insertion Anomaly Decomposition of Relations Normal Forms

17. First Normal Form (1NF) An example not in 1NF All attribute values must be atomic WORKER TABLE WORKER-IDNAMESKILL-TYPESUPV-IDBLDG-ID 1235M. FaradayElectric1311{312, 515} 1412C. NemoPlumbing{312, 460, 435, 515} 1311C. CoulombElectric435

18. Functional Dependencies Examples: –FD:WORKER-ID  NAME –FD:WORKER-ID  SKILL-TYPE Definition: –FD:A  B

19. Second Normal Form (2NF) Can be violated only when a key is a composite key A relation is in 2NF if no nonkey attribute is functionally dependent on just part of the key

20. WORKER-BLDG TABLE WORKER-IDBLDG-IDSTART-DATENAME 123531210/10M. Faraday 141231210/01C. Nemo 123551510/17M. Faraday 14246012/08C. Nemo 14243510/5C. Nemo Leaving this relation in non-2NF can cause problems

21. Worker name repeated Update anomaly Data inconsistency Insertion anomaly

22. How to solve? WORKER-BLDG TABLE WORKER-IDBLDG-IDSTART-DATE 123531210/10 141231210/01 123551510/17 141246012/08 141243510/5 WORKER-ID TABLE WORKER-IDNAME 1235M. Faraday 1412C. Nemo The tables are projections of the previous table

23. Third Normal Form (3NF) A relation is in 3NF if for every FD: X  Y, X is a key WORKER TABLE WORKER-IDSKILL-TYPEBONUS-RATE 1235Electric13.50 1412Plumbing13.00 1311Plumbing13.00 Note. FD: WORKER-ID  SKILL-TYPE

24. Also note. FD: WORKER-ID  BONUS-RATE But there is one more functional dependency Thus is the relation in 3NF? Problems if not in 3NF?

25. Skill type’s bonus rate is repeated Update and deletion anomalies Insertion anomaly

26. WORKER-SKILL TABLE WORKER-IDSKILL-TYPE 1235Electric 1412Plumbing 1311Plumbing Boyce-Codd Normal Form Transitive dependencies SKILL-BONUS TABLE SKILL-TYPEBONUS-RATE Electric13.50 Plumbing13.00 Plumbing13.00

27. Transforming a Conceptual Model to a Relational Model Conceptual models provide an accurate representation Few systems exist on which conceptual models are implemented A conceptual model consists of –Entities/objects, relationships, and attributes

28. Transforming Entity Sets and Attributes Can transform this conceptual model into a relation as follows:  PERSON (SIN, Sex, DOB) PERSON SINSexDOB

29. The transformation:  SALE (Amount, Product-#) The problem?  SALE (Sale-#, Amount, Product-#) SALE AmountProduct-# Transforming Models Without External Keys

30. Summarization: If no attribute can be identified as a key, then an attribute is added to the relation with the understanding that its values uniquely identify entity instances. An entity set with attributes can be transformed using the entity set as the relation’s name, and the entity attributes as the relations attributes. If any attribute can be used as key, then it becomes the relations key.

31. Transforming Specialization Entity Sets PERSON SINNameAddress MARRIED PERSON Spouse What to do with MARRIED PERSON?  MARRIED-PERSON (SIN, NAME, ADDRESS, SPOUSE) Foreign Key: SIN References PERSON

32. Transforming Relationships One-One Three ways depending on the relationships cardinality CUSTOMER CHEQUING ACCOUNT HAS- ACCOUNT 11 CUST-#NAMEADDRESSCH-AC-#

33. Have two relations  CUSTOMER (CUSTOMER-#, NAME ADDRESS)  CHEQUING-ACCOUNT (CH-AC-#) How to relate the two relations?  CUSTOMER (CUSTOMER-#, NAME ADDRESS, CH-AC-#)  CHEQUING-ACCOUNT (CH-AC-#, CUSTOMER-#) The problem?  CUSTOMER (CUSTOMER-#, NAME ADDRESS)  CHEQUING-ACCOUNT (CH-AC-#, CUSTOMER-#, BALANCE) Foreign Key:CUSTOMER-# References CUSTOMER

34. One-Many CUSTOMER CHEQUING ACCOUNT HAS- ACCOUNT 1M CUST-#NAMEADDRESSCH-AC-# CHEQUING-ACCOUNT (CH-AC-#, CUSTOMER-#, BALANCE) Foreign Key:CUSTOMER-# References CUSTOMER CUSTOMER (CUSTOMER-#, NAME, ADDRESS)

35. Many-Many CUSTOMER CHEQUING ACCOUNT HAS- ACCOUNT NM CUST-#NAMEADDRESSCH-AC-# Must establish an Intersection Relation  CUSTOMER (CUSTOMER-#)  CHEQUING-ACCOUNT (CH-AC-#)  HAS-ACCOUNT (CUSTOMER-#, CH-AC-#) Foreign Key:CUSTOMER-# References CUSTOMER CH-AC-# References CHEQUING ACCOUNT

36. CHEQUING ACCOUNT RELATION CH-AC-#-# CA888 CA777 CA999 HAS-ACCOUNT RELATION CUSTOMER-#CH-AC-# 2222CA999 2222CA888 3333CA777 1111CA777 1111CA888 The Relations CUSTOMER RELATION CUSTOMER-# 1111 2222 3333

37. Transforming Aggregate Entity Sets PRODUCT COUNTRY IS –SOLD-IN NM Quantity  PRODUCT (PRODUCT-#)  COUNTRY (COUNTRY-NAME)  IS-SOLD-IN (PRODUCT-#, COUNTRY-NAME, QUANTITY) Foreign Key:PRODUCT-# References PRODUCT COUNTRY-NAME References COUNTRY

38. SALESPERSON SOLD-BY Quantity PRODUCT COUNTRY IS –SOLD-IN NM Relating IS-SOLD-IN to SALESPERSON

39. Resulting Relational Model  PRODUCT (PRODUCT-#)  COUNTRY (COUNTRY-NAME)  SALESPERSON (SALESPERSONNUMBER)  IS-SOLD-IN (PRODUCT-#, COUNTRY-NAME)  SOLD-BY (PRODUCT-#, COUNTRY-NAME, SPN, QUANTITY) Problems?

40. Essentially a Three-Way Relationship  PRODUCT (PRODUCT-#)  COUNTRY (COUNTRY-NAME)  SALESPERSON (SPN)  SOLD (PRODUCT-#, COUNTRY-NAME, SPN,QUANTITY) Foreign Key:PRODUCT-# References PRODUCT COUNTRY-NAME References COUNTRY SPN References SALESPERSON Quantity PRODUCT COUNTRY SOLD NM SALESPERSON M

41. Transforming Recursive Relationships Could do the following:  WORKER (WORKER-ID, NAME, HOURLY-RATE, WORKER-ID) Instead:  WORKER (WORKER-ID, NAME, HOURLY-RATE, SUPV-ID) Foreign Key:SUPV-ID References WORKER WORKER SUPERVISES 1M Hourly-Rate Worker-Id Name

42. WORKER WORKER-IDNAMEHOURLY-RATESUPV-ID 1235M. Faraday12.501311 1412C. Nemo13.751520 2920R. Garret10.00 3231P. Mason17.40 1520H. Rickover11.75 1311C. Coulomb15.50 3001J. Barrister8.203231

43. Transforming Example: Name CHARGE CLIENT ASSESSED- FOR Title Address PROJECT Total Invoice-Date Invoice-# PERFORMED- FOR 1 M M 1 DescriptionAmount SERVICE SUPPLY- CHARGE Consultant

44. CLIENT Title Address Name PROJECT Total Invoice-Date Invoice-# PERFORMED- FOR 1 M Project and Client Entity Sets  CLIENT (CLIENT-NAME, CLIENT-ADDRESS)  PROJECT (PROJECT-#, CLIENT-NAME, PROJECT-TITLE, TOTAL-CHARGE, INVOICE-#, INVOICE-DATE) Foreign Key:CLIENT-NAME References CLIENT

45. Charge and Service Entity Sets  CHARGE (CHARGE-#, PROJECT-#, AMOUNT, DESCRIPTION)  SERVICE (CHARGE-#, PROJECT-#, CONSULTANT) Foreign Key: CHARGE-#, PROJECT-#, References CHARGE DescriptionAmount CHARGE SERVICE Consultant

46. What about the Assessed-For Relation and the Entity Supply-Charge? ASSESSED- FOR 1 SUPPLY- CHARGE M DescriptionAmount CHARGE SERVICE Consultant CLIENT Title Address Name PROJECT Total Invoice-Date Invoice-# PERFORMED- FOR 1 M

47. Why Bother with a Conceptual Model? Why create a conceptual model at all? Complexity

48.  CLIENT (CLIENT-NAME, CLIENT-ADDRESS)  PROJECT (PROJECT-#, CLIENT-NAME, PROJECT-TITLE, TOTAL-CHARGE, INVOICE-#, INVOICE-DATE) Foreign Key:CLIENT-NAME References CLIENT  CHARGE (CHARGE-#, PROJECT-#, AMOUNT, DESCRIPTION)  SERVICE (CHARGE-#, PROJECT-#, CONSULTANT) Foreign Key: CHARGE-#, PROJECT-#, References CHARGE Consider this example