1. Chapter 9 Logical Database Design : Mapping ER Model To Tables

2. 9-2 Chapter Outline How to   Map an ER model to a set of tables.   Check that tables are capable of supporting the transactions required by the user.   Define and document integrity constraints on tables.

3. 9-3 Steps In Logical Database Design Step 2 Map ER Model to Tables Step 2.1 Create tables Step 2.2 Check tables support user transactions Step 2.3 Check business rules Step 2.4 Review logical database design with users

4. 9-4 Step 2.1 Create Tables   Tables are created for an ER model to represent the entities, relationships, attributes, and constraints.   The ER model information used for creating the structure of tables includes   ER diagrams   ER data dictionary   Any other supporting documentation

5. 9-5 Step 2.1 Create Tables   Database Definition Language To describe the composition of each table, we use a Database Definition Language (DBDL) for relational databases.   Example Staff (staffNo, name, position, salary, branchNo) Primary Key staffNo Foreign Key branchNo references Branch(branchNo)

6. 9-6 Step 2.1 Create Tables   Input   ER diagrams   Data dictionary   Output   Relational tables   Modified data dictionary

7. 9-7 ER Diagram Step 2.1 Create tables

8. 9-8 ER Model - Data Dictionary Composite? Derived? How? Default value? Composite? Derived? How? Default value? Step 2.1 Create tables

9. 9-9 How to Represent Entities   For each entity in ER model, create a table that includes all the entity’s simple attributes.   For each composite attribute, include only the simple attributes of the composite attribute in the table.   E.g., for the composite attribute address, include its simple attributes street, city, state, and zipcode.   Where possible, identify the attribute(s) that make up the primary key in each table. Step 2.1 Create tables

10. 9-10 Initial Table Structures for the Entities Step 2.1 Create tables ERD : 8 entities Data Dictionary for Branch

11. 9-11 How to Represent Entities   In some cases, it is not able to directly identify the full set of attributes that make up a table. Because   The relationship between two entities may have to be represented by using primary key and foreign key.   Might not identify the attributes that make up the primary key for weak entities. Step 2.1 Create tables

12. 9-12 How to Represent Relationships Relationship   Represented by the primary key (PK) and foreign key (FK) mechanism in Relational Model   How to represent a relationship?   First identify the ‘ parent ’ and ‘ child ’ entities involved in the relationship   Place a copy of the PK of parent entity into the table representing child entity, to act as a FK. Step 2.1 Create tables: How to Represent Relationships

13. 9-13 How to Represent Relationships   Types of relationships to consider   one-to-many (1:*) binary relationships   one-to-many (1:*) recursive relationships   one-to-one (1:1) binary relationships   one-to-one (1:1) recursive relationships   many-to-many (*:*) binary relationships   complex relationships   multi-valued attributes Step 2.1 Create tables: How to Represent Relationships

14. 9-14 1:* Binary Relationships   The entity on the ‘1 (one side)' of the relationship is designated as the parent entity   The entity on the ‘* (many side)' is designated as the child entity.   To represent this relationship, a copy of the primary key of the parent entity is placed into the table representing the child entity, to act as a foreign key. Step 2.1 Create tables: How to Represent Relationships Example

15. 9-15 1:* Binary Relationships Can the FK (branchNo) be null? Step 2.1 Create tables: How to Represent Relationships

16. 9-16 1:* Recursive Relationships  The representation of a 1:* recursive relationship is similar to 1:* binary relationship.  However, both the parent and child entities are the same entity. Parent entity: Staff acts as Supervisor Child entity: Staff acts as Supervisee Step 2.1 Create tables: How to Represent Relationships Staff acts as both the parent and child entities.

17. 9-17 1:* Recursive Relationships Can the FK (supervisorStaffNo) be null? Step 2.1 Create tables: How to Represent Relationships

18. 9-18 1:1 Binary Relationships In 1:1 binary relationship,   Cardinality cannot be used to identify parent and child entities in a relationship.   Use participation constraints to help decide whether it’s to represent the relationship   by combining the entities into one table, or   by creating two tables and posting a copy of the primary key from one table to the other   Three Participation Constraints:   Mandatory participation on both sides   Mandatory participation on one sides   Optional participation on both sides Step 2.1 Create tables: How to Represent Relationships

19. 9-19 1:1 Binary Relationships: Mandatory Participation On Both Sides Method I : Combine into one table   Choose one of the primary keys of the two original entities to be primary key of the new relation   Other is used as an alternate key   If the relationship has one or more attributes, these attributes should also be included in the table Step 2.1 Create tables: How to Represent Relationships

20. 9-20 Can the AK (vehLicenseNo) be null? Combine Into One Table Step 2.1 Create tables: How to Represent Relationships

21. 9-21 Method II: Creating Two Tables Staff (staffNo, name, position, salary, branchNo, supervisorStaffNo) Primary Key staffNo Foreign Key branchNo references Branch Foreign Key supervisorStaffNo references Staff; Car (vehLicenseNo, make, model, staffNo) Primary Key vehLicenseNo Foreign Key staffNo references Staff(StaffNo); Staff (staffNo, name, position, salary, branchNo, supervisorStaffNo, vehLicenseNo) Primary Key staffNo Foreign Key branchNo references Branch Foreign Key supervisorStaffNo references Staff Foreign Key vehLicenseNo references Car (vehLicenseNo); Car (vehLicenseNo, make, model) Primary Key vehLicenseNo; OR Can the FK (staffNo or vehLicenseNo) be null? Step 2.1 Create tables: How to Represent Relationships

22. 9-22 1:1 Binary Relationships: Mandatory Participation On One Side   Using participation constraints to identify parent and child entities.   Mandatory participation side ~ parent entity   Optional participation side ~ child entity   A copy of PK of parent table is placed in child table   If relationship has attributes, these attributes should follow the posting of the primary key to the child table. Step 2.1 Create tables: How to Represent Relationships Example

23. 9-23 1:1 Binary Relationships: Mandatory Participation On One Side   The reason   The foreign key will always hold a value and hence avoid the presence of nulls in this column of the resulting table.   If we did not follow this rule and chose to represent this relationship by placing the FK column in the table representing the entity at mandatory participation side, this FK column would contain nulls. Step 2.1 Create tables: How to Represent Relationships

24. 9-24 1:1 Relationships: Mandatory Participation On One Side Can the FK (staffNo) be null? Step 2.1 Create tables: How to Represent Relationships

25. 9-25 1:1 Binary Relationships: Optional Participation On Both Sides  In this case, the designation of the parent and child entities is arbitrary.  Consider relationship with optional participation on both sides.  Consider 1:1 Staff Uses Car relationship with optional participation on both sides. Step 2.1 Create tables: How to Represent Relationships

26. 9-26 1:1 Recursive Relationships   The entity on both sides of the relationship is the same.   A special case of a 1:1 relationship.   Follow the rules for participation as described above for a 1:1 relationship. Step 2.1 Create tables: How to Represent Relationships

27. 9-27 1:1 Recursive Relationships   Contains 3 cases   Mandatory participation on both sides   Mandatory participation on one sides   Optional participation on both sides   Relationship representation :   Represent the recursive relationship as a single table with two copies of the primary key.   One copy of the primary key represents a foreign key and should be renamed to indicate the relationship it represents. Step 2.1 Create tables: How to Represent Relationships

28. 9-28 Converting *:* Binary Relationships   Create a new table to represent the relationship   Include any attributes that are part of the relationship   Post a copy of the primary key attribute(s) of the two entities in the relationship into the new table, to act as foreign keys.   One or both of the foreign keys will also form the primary key of the new table   Possibly in combination with some of the attributes of the relationship. Step 2.1 Create tables: How to Represent Relationships

29. 9-29 *:* Binary Relationships Step 2.1 Create tables: How to Represent Relationships

30. 9-30 Converting Complex Relationships   For degree higher than 2   Create a new table to represent the relationship.   Post a copy of the primary key attribute(s) of the entities in the complex relationship into the new table, to act as foreign keys   Include any attributes that are associated with the relationship.   One or more of the foreign keys will also form the primary key of the new table   Possibly in combination with some of the attributes of the relationship. Step 2.1 Create tables: How to Represent Relationships ERD Example Table design

31. 9-31 Ternary Relationship Step 2.1 Create tables: How to Represent Relationships

32. 9-32 Ternary Relationship Transformation Ternary Relationship Transformation Step 2.1 Create tables: How to Represent Relationships, staffNo

33. 9-33 Multi-valued Attributes   A new table is created to hold the multi-valued attribute   Follow the rule described for 1:* relationships.   The entity on the one side is designated as parent entity   The multi-valued attribute is on the many side and is designated the child entity   The parent entity posts a copy of its primary key, to act as a foreign key.   If the multi-valued attribute is an alternate key of the parent entity, the primary key of the new table is composed of the multi-valued attribute. Otherwise, the primary key of the new table is composed of the multi- valued attribute and the primary key of the parent entity. Step 2.1 Create tables: How to Represent Multi-valued Attributes ERD example Table design

34. 9-34 Multi-valued Attributes Step 2.1 Create tables: How to Represent Relationships

35. 9-35 Multi-valued Attributes – ERD And Representation As Tables Step 2.1 Create tables: How to Represent Relationships

36. 9-36 Document Tables And FK Attributes   The DBDL syntax can be extended to show integrity constraints on the foreign keys.   The data dictionary should be updated to indicate the presence of foreign keys and any new primary keys in this step. Step 2.1 Create tables

37. 9-37 Document New Tables and Foreign Key Attributes Step 2.1 Create tables Initial Result, staffNo

38. 9-38 Step 2.2 Check Tables Support User Transactions Ensures that no error has been introduced while creating tables.   Check that tables support the required transactions, which were documented in the users’ requirements specification.   One approach is to examine the transaction’s data requirements to ensure that the data is present in one or more tables.   Transactions may require data from more than one table   Check these tables are linked through the primary key / foreign key mechanism.

39. 9-39 Step 2.3 Check Tables Support User Transactions Check Foreign Key Linkage Examples of Step 2.2 () (Check Tables Support User Transactions)

40. 9-40 Step 2.3 Check Business Rules   Business rules ( 業務規則 )   Represented as Constraints   To protect the database from becoming incomplete, inaccurate, or inconsistent.   Concerned only with high-level design   Specifying what business rules are required   Irrespective of how this might be achieved.

41. 9-41   Types of business rules:   Required data   Domain constraints of attributes   Entity integrity   Multiplicity   Referential integrity   Other business rules Step 2.3 Check Business Rules

42. 9-42 Referential Integrity   There are two issues regarding foreign keys 1. 1. Are nulls allowed for the foreign key? If the participation of the child table in the relationship is   mandatory, then nulls are not allowed.   optional, then nulls are allowed. 2. How to ensure referential integrity ?   There are 6 cases for further discussion Step 2.4 Check Business Rules

43. 9-43 How to Ensure Referential Integrity?  Consider the 1:* relationship Branch Has Staff.  The PK of the Branch table ( branchNo ) is a FK in the Staff table. Step 2.4 Check Business Rules child table parent table

44. 9-44 How to Ensure Referential Integrity? Case 1: Insert a record into child table (Staff)   To ensure referential integrity, check that the foreign key column ( branchNo ) of a new Staff record is set   to null (violates referential integrity), or   to a value of an existing Branch record. Case 2: Delete record from child table (Staff)   If a record in the child table is deleted, referential integrity is unaffected. Step 2.4 Check Business Rules ERD

45. 9-45 How to Ensure Referential Integrity? Case 3: Update foreign key of a child record (Staff)  This is similar to Case 1 (update = delete + insert).  To ensure referential integrity, check that the foreign key column ( branchNo ) of the updated Staff record is set to null or to a value of an existing Branch record. Case 4: Insert record into parent table (Branch)  Inserting a record into the parent table (Branch) does not affect referential integrity  It simply becomes a parent without any children (A branch without members of staff) Step 2.4 Check Business Rules

46. 9-46 How to Ensure Referential Integrity? Case 5: Delete record from parent table (Branch)   If a record of the parent table is deleted, referential integrity is lost if there exists any child record referencing the deleted parent record.   In other words, referential integrity is lost if the deleted branch currently has one or more staff members working at it.   There are several strategies you can consider in this case Step 2.4 Check Business Rules

47. 9-47 Strategies: Delete a Parent Record with Child Records The available strategies are : 1. 1.NO ACTION 2. 2.CASCADE 3. 3.SET NULL 4. 4.SET DEFAULT 5. 5.NO CHECK Step 2.4 Check Business Rules

48. 9-48 Strategies: Delete a Parent Record with Child Record 1. 1.NO ACTION   Prevent the deletion from the parent table if there are any referencing child records.   In our example, 'You cannot delete a branch if there are currently staff members working there '. Step 2.4 Check Business Rules

49. 9-49 Strategies: Delete a Parent Record with Child Record 2. 2.CASCADE (Do the same operation to child records)   When the parent record is deleted, automatically delete any referencing child records.   For example, 'Deleting a branch automatically deletes all members of staff working there '.   In this situation, this strategy would not be wise.   If any deleted child record also acts as a parent record in another relationship, then the delete operation should be applied to the records in the child table of this child table, and so on in a cascading manner. Step 2.4 Check Business Rules DBDL example

50. 9-50 Strategies: Delete a Parent Record with Child Record 3. 3.SET NULL   When a parent record is deleted, the FK values in all related child records are automatically set to null.   You can only consider this strategy if FK columns can accept nulls. 4. 4.SET DEFAULT   When a parent record is deleted, the FK values in all related child records are automatically set to their default values.   You can only consider this strategy if FK columns can accept default values Step 2.4 Check Business Rules

51. 9-51 Strategies: Delete a Parent Record with Child Record 5. 5.NO CHECK   When a parent record is deleted, do nothing to ensure that referential integrity is maintained.   This strategy should only be considered in extreme circumstances. Step 2.4 Check Business Rules

52. 9-52 How to Ensure Referential Integrity? CASE 6: Update Primary Key of Parent Record (Branch)   lf the PK value of a parent table record is updated, referential integrity is lost if there exists any child record referencing the old PK value.   To ensure referential integrity, the strategies described in CASE 5 can be used.   In the case of CASCADE, the updates to the PK of the parent record are reflected in any referencing child records, and so on in a cascading manner. Step 2.4 Check Business Rules

53. 9-53 Example of Referential Integrity Constraints  The referential integrity constraints for the tables that have been created for the Branch user views Step 2.4 Check Business Rules

54. 9-54 Other Business Rules   Finally, you consider constraints for any remaining business rules that have not been defined so far.   Business rules should be represented as constraints on the DB to ensure that only permitted table updates are executed.   For example, StayHome has a business rule that prevents a member from renting more than 10 videos at any one time. Step 2.4 Check Business Rules

55. 9-55 Document All Business Rules   Document all business rules for consideration during physical database design. Step 2.4 Check Business Rules

56. 9-56 Step 2.4 Review Logical Database Design with User   To ensure that the logical database design is a true representation of the data requirements of an organization (or part of the organization) to be supported by the database.