1. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL (PART I) Modern Database Management 11 th Edition Jeffrey A. Hoffer, V. Ramesh, Heikki Topi We learned Database Analysis; We are moving into Database Design

2. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 2 OBJECTIVES Part 1:  Define terms  List five properties of relations  State two properties of candidate keys  Define first, second, and third normal form  In Part 2  Describe problems from merging relations  Transform E-R and EER diagrams (w Part 2) to relations  Create tables with entity and relational integrity constraints Part 2:  Use normalization to convert anomalous tables to well-structured relations Disambiguation: -“Data model” means E-R diagram; -“Relational model” means data in 2- dimensional tables (current chapter) -1) short text statement, and -2) graphical representation

3. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall DATABASE SCHEMA (CH 1, SLIDE #40)  External Schema  User Views  Subsets of Conceptual Schema  Can be determined from business-function/data entity matrices [Fig 1-6; pasted as next slide]  DBA determines schema for different users  Conceptual Schema  E-R models – covered in Chapters 2 and 3  Internal Schema  Logical structures–covered in Chapter 4 (Relational model)  Physical structures–covered in Chapter 5 3

4. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 4 FIGURE 1-6 Example business function-to-data entity matrix 4 Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall Can use this matrix to help with your DB project: “Did I get the right entities for my biz functions?”

5. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 5 INTRODUCTION  Logical DB design: process of transforming the conceptual data model (i.e., ERD) into a logical data model (i.e., models in this chap)  Conceptual data modeling: getting the right requirements >>model the biz logic correctly  biz rules  Logical DB design: getting the requirements right >>correctly transform the biz logic for implementation  An E-R data model is not a relational data model  need normalization [2 nd half of Ch 4]  ERD is developed for the purpose of understanding biz rules, not structuring data for sound DB processing  The last part is the goal of logical DB design

6. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 6RELATION  A relation is a named, two-dimensional table of data.  A table consists of rows (records) and columns (attributes or fields).  Requirements for a table to qualify as a relation: 1. It must have a unique name. 2. Every attribute value must be atomic 1. (not multivalued, not composite). 3. Every row must be unique (can’t have two rows with exactly the same values for all their fields). 4. Attributes (columns) in tables must have unique names. 5. The order of the columns must be irrelevant. 6. The order of the rows must be irrelevant. NOTE: all relations are in 1 st Normal form (Definition P.177) Are all tables a relation?

7. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 7 CORRESPONDENCE WITH E-R MODEL 1. Relations (tables) correspond with entity types and with many-to-many relationship types (______ entity) 2. Columns correspond with attributes. 3. Rows correspond with entity instances and with many-to-many relationship instances.  We can express the structure of a relation by a shorthand notation (“text description”): RELATION (attribute1, attribute2, attribute3, …) Example: PRODUCT( … )  exercise  NOTE: The word relation (in relational database) is NOT to be confused with the word relationship (in E-R model): …

8. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 8 Entity (type)Entity instanceAttribute Relation/Table RowColumn Examples: STUDENTJ Smith M Acct 3.53.5 (for GPA field) COMPANY Google Mountain View GOOGGOOG (for stock ticker) STUD_CLUB MISA 1985 Nguyen1985 (for year est.) EXAM E1 100 10/0910/09 (for date field)

9. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 9 KEY FIELDS  Keys are special fields that serve two main purposes:  Primary keys are unique identifiers of the relation in question. - how we can guarantee that all rows are unique.  Foreign keys are identifiers that enable a dependent relation (on the many side of a relationship) to refer to its parent relation (on the one side of the relationship).  an attribute in a relation (table) of a database that serves as the primary key of another relation in the same database  Keys can be simple (a single field) or composite (more than one field).  Keys usually are used as indexes to speed up the response to user queries (Ch 5).

10. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall  Identify the multivalued attributes for several records (entity instances) 10

11. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall  Simple ways of treating multivalued and composite attributes … 11

12. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 12 SCHEMAS  The structure of the DB is described through schemas  Two common methods for expressing schema: 1. Short text statements (example: Slide 13)  RELATION (attribute1, attribute2, attribute3, …)  EMPLOYEE (Emp_ID, LastName, FirstName, …) 2. Graphical representation (example: Slide 14)  Each relation represented by a rectangle containing attributes  RELATION Attr1 Attr5 Attr4Attr3 Attr2

13. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 13 SHORT TEXT STATEMENT OF PVFC Lines/curves with arrowhead are used to indicate the referencing relationship (referential integrity – Slides #13 and 17) between foreign key and primary key. Graphical representation: Primary key Foreign key

14. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 14 Primary Key Foreign Key (implements 1:N relationship between customer and order) Combined, these are a composite primary key (uniquely identifies the order line)… Individually, they are foreign key s (implement M:N relationship between order and product) Fig 4-3 Schema for four relations (graphical representation) Will be req’d the most for HW The curvy arrows here indicate relationships (PK – FK pairs)

15. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 15 INTEGRITY CONSTRAINTS  Domain Constraints  Allowable values for an attribute. See Table 4-1, P160  Other examples: next slide  Entity Integrity  No primary key attribute may be null  Referential integrity  Primary key – Foreign key relationship (    Slide #17) (    Slide #17)

16. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 16 Domain definitions enforce domain integrity constraints

17. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 17 INTEGRITY CONSTRAINTS – REFERENTIAL INTEGRITY  Rule states that any foreign key value (in the relation of the many side) MUST match a primary key value (in the relation of the one side). (Or the foreign key can be null)  For example: Delete Rules  Restrict–don’t allow delete of “parent” side if related rows exist in “child” / “dependent” side  Cascade–automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted  Set-to-Null–set the foreign key in the dependent side to null if deleting from the parent side  not allowed for weak entities Example using IS 312 DB

18. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 18 Figure 4-5 Referential integrity constraints (Pine Valley Furniture) Referential integrity constraints are drawn via arrows from dependent to parent table … From “M” to”1” Compared w next slide: Note: From ____ To ___

19. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 19 Figure 1-3(b), P.11 (1) Primary key appears… (2) Foreign key departs from… ends at…

20. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall In ERDIn Rel SchemaNote EntityTableNo space in table name AttributeColumn attribute domains Primary key can be composite 1:M relationshipPrim. key on 1-side Foreign on M-side Don’t flip the two ! ! ! M:N relationshipNew relation/table for the M:N relationship itself M:N   associative entity   table on its own Relationship (curvy) arrow always points from ___-side to __- side; From _______ key to _______ key 20

21. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 21 Figure 4-6 SQL table definitions Referential integrity constraints are implemented with foreign key to primary key references

22. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 22 ANOMALIES Three anomalies in this relation/table: 1. Insertion anomaly 2. Deletion anomaly 3. Modification anomaly (PP. 162~163)

23. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 23 TRANSFORMING EER DIAGRAMS INTO RELATIONS (PP. 165-6) Three types of entities:

24. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 24 TRANSFORMING EER DIAGRAMS INTO RELATIONS Mapping Regular Entities to Relations – handling attributes: 1. Simple attributes: E-R attributes map directly onto the relation (Fig 4-8, next slide) 2. Composite attributes: Use only their simple, component attributes (Figure 4-9) 3. Multivalued attribute: Becomes a separate relation with a foreign key taken from the superior entity (Figure 4-10)

25. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 25 (a) CUSTOMER entity type with simple attributes Figure 4-8 Mapping a regular entity (b) CUSTOMER relation 25

26. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 26 (a) CUSTOMER entity type with composite attribute Figure 4-9 Mapping a composite attribute (b) CUSTOMER relation with address detail Breaking up

27. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 27 Figure 4-10 Mapping an entity with a multivalued attribute One–to–many relationship between original entity and new relation (a) Multivalued attribute becomes a separate relation with foreign key Ref Slide #24 (b) Q: from the left, who’s 1 and who’s M? Imagine tables? How many columns does the new table have?

28. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall  The first relation EMPLOYEE has the primary key Employee_ID  The second relation EMPLOYEE_SKILL has attributes attributes Employee_ID and Skill, which form the primary key  Note on Skill:

29. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 29 TRANSFORMING EER DIAGRAMS INTO RELATIONS (CONT.) Mapping Weak Entities  Becomes a separate relation with a foreign key taken from the superior entity  Primary key composed of:  Partial identifier of weak entity  Primary key of identifying relation (strong entity)

30. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 30 Figure 4-11 Example of mapping a weak entity a) Weak entity DEPENDENT 1.What is this? 2.What is its function/role?

31. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 31 NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity Foreign key Composite primary key (= ___? + ___?) Figure 4-11 Example of mapping a weak entity (cont.) b) Relations resulting from weak entity “a foreign key taken from…” S#29

32. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 32 TRANSFORMING EER DIAGRAMS INTO RELATIONS (CONT.) Mapping Binary Relationships  One-to-Many–Primary key on the one-side becomes a foreign key on the many-side  Many-to-Many–Create a new relation with the primary keys of the two entities as its primary key  One-to-One–Primary key on the mandatory side becomes a foreign key on the optional side  (curvy) Arrows indicating referential integrity constraints  Points from M-side to 1-side  From foreign key to primary key

33. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 33 Figure 4-12 Example of mapping a 1:M relationship a) Relationship between customers and orders Note the mandatory one b) Mapping the relationship Again, no null value in the foreign key…this is because of the mandatory minimum cardinality Foreign key If there’s no field name/table name, can you still tell the table on 1-side from the table on M-side?

34. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall  If M:N relationship exists between entity types A and B, we create a new relation C,  include as foreign keys in C the primary keys for A and B,  these attributes, together, become the primary key of C

35. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall A Ka B Kb A Ka B Kb C Ka + Kb Note the cardinalities A Ka B Kb C KaKb Intersection relation

36. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 36 Figure 4-13 Example of mapping an M:N relationship a) Completes relationship (M:N) The Completes relationship will need to become a separate relation Will be treated as an associative entity

37. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 37 New intersection relation Foreign key Composite primary key Figure 4-13 Example of mapping an M:N relationship (cont.) b) Three resulting relations Associative entity/intersection relation is always on the M-side What can we say about arrow direction? The old “ Completes ” relationship

38. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 38 Figure 4-14 Example of mapping a binary 1:1 relationship a) In charge relationship (1:1) Often in 1:1 relationships, one direction is optional

39. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall  In a 1:1 relationship, the association in one direction is often optional one, while the association in the other direction is mandatory one  think about STUDENT and PARKING_PERMIT  The primary key of one of the relations is included as a foreign key in the other relation  The primary key of the Mandatory side   The foreign key of the optional side

40. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 40 b) Resulting relations Figure 4-14 Example of mapping a binary 1:1 relationship (cont.) Foreign key goes in the relation on the optional side, matching the primary key on the mandatory side Arrow points from _______ side to ____ side, from ______ key to ____ key Practice the same for the STUDENT and PARKING_PERMIT relationship

41. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 41 TRANSFORMING EER DIAGRAMS INTO RELATIONS (CONT.) Mapping Associative Entities  Three relations will be created: one for each of the original entities, and a third for the associative entity. Two situations: 1. Identifier Not Assigned  Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship) 2. Identifier Assigned (, when- )  It is natural and familiar to end-users  Default identifier may not be unique

42. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 42 Figure 4-15 Example of mapping an associative entity a)An associative entity (will be transformed to an “Intersection Relation”) Regular entityAssociative entityRegular entity Regular relationIntersection relationRegular relation

43. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 43 Figure 4-15 Example of mapping an associative entity (cont.) b) Three resulting relations 1.Composite primary key - two primary key attributes from the other two relations 2.two foreign keys, referencing the other two entities Associative entity/intersection relation is on _____-side; arrow points from ~~ to ~~

44. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 44 Figure 4-16 Example of mapping an associative entity with an identifier a) SHIPMENT associative entity In this situation, the associative entity type has a natural identifier that is familiar to end users – Shipment ID

45. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 45 Figure 4-16 Example of mapping an associative entity with an identifier (cont.) b) Three resulting relations Primary key differs from foreign keys - identifier assigned

46. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 46 TRANSFORMING EER DIAGRAMS INTO RELATIONS (CONT.) Mapping Unary Relationships  One-to-Many: Recursive foreign key in the same relation  Many-to-Many: Two relations:  One for the entity type  One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity

47. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 47 Figure 4-17 Mapping a unary 1:N relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recursive foreign key Note the direction of the arrow! Examine the tables: …

48. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 48 Figure 4-17 Mapping a unary 1:N – More explanation Recursive is NOT “circular”: A record’s ManagerID does NOT point to ITS OWN EmployeeID; It points to SOMEONE ELSE’s EmployeeID – the EmployeeID of the person’s manager’s EmployeeID One row points to ANOTHER row YOUR ManagerID is … … SOMEONE ELSE’s EmployeeID

49. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 49 Figure 4-18 Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations An associative entity How do I know?? Is_contained_in

50. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 50 Figure 4-18 Mapping a unary M:N – More explanation Is_contained_in Points to the SAME ItemNo in “Main” table, to _____________________ Points to a DIFFERENT ItemNo in “Main” table, to _________________

51. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 51 TRANSFORMING EER DIAGRAMS INTO RELATIONS (CONT.) Mapping Ternary (and n-ary) Relationships  One relation for each entity, and one for the associative entity  Associative entity has foreign keys to each of the regular entities in the relationship

52. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 52 Figure 4-19 Mapping a ternary relationship a) PATIENT TREATMENT Ternary relationship with associative entity

53. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 53 b) Mapping the ternary relationship PATIENT TREATMENT Remember that the primary key MUST be unique Figure 4-19 Mapping a ternary relationship (cont.) This is why treatment date and time are included in the composite primary key But this makes a cumbersome key… It would be better to create a surrogate key like Treatment# An associative entity

54. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 54 TRANSFORMING EER DIAGRAMS INTO RELATIONS (CONT.) Mapping Supertype/Subtype Relationships  One relation for supertype and for each subtype  Supertype attributes (including identifier and subtype discriminator) go into supertype relation  Subtype attributes go into each subtype; primary key of supertype relation also becomes primary key of subtype relation  1:1 relationship established between supertype and each subtype, with supertype as primary table The last three slides – 54~56 – wait till we learn Chap 3

55. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 55 Figure 4-20 Supertype/subtype relationships

56. Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 56 Figure 4-21 Mapping supertype/subtype relationships to relations These are implemented as one-to-one relationships