1. Transforming E-R Models into Relations Though this be madness, yet there is method in it. Shakespeare

2. Class Outline u What is the primary key-foreign key basis of a relational database? u How is an Entity-Relationship model converted to relational tables? Specifically, how are these converted: l 1:1, 1:M, M:N relationships binary relationships l ternary or recursive relationships l optional/ mandatory relationships l generalized hierarchies l weak entities u What are common data types provided by databases? u Describe some guidelines for designing tables. u Describe common database design flaws.

3. Steps to E-R Transformation 1. Identify entities 2. Identify relationships 3. Determine relationship type 4. Determine level of participation 5. Assign an identifier for each entity 6. Draw completed E-R diagram 7. Deduce a set of preliminary skeleton tables along with a proposed primary key for each table (using cases provided) 8. Develop a list of all attributes of interest (not already listed and systematically assign each to a table in such a way to achieve a 3NF design (i.e., no repeating groups, no partial dependencies, and no transitive dependencies)

4. Primary Key The basis of a relational database is the ability to link instances from different entities if they share a common attribute (primary key, foreign key). l Each entity must have a primary key - an attribute that contains a unique value for each instance. The primary key cannot be null. The primary key is selected from all possible identifiers or candidate keys. l A primary key is a determinant of all other attributes in a given row (e.g., knowing a supplier number allows us to look up all of the other characteristics of that supplier (name, phone #, etc.) l A primary key should ideally be one attribute but can be a combination of attributes (multi- valued) that uniquely identify each entity instance. Each attribute is called a key attribute and together are a composite key.

5. Requirements for a Relationship between tables (a) Primary key - every row of a table must have a unique identifier which cannot include null entries (b) Foreign key- an entry that must match a primary key value in a table to which it is related; may be null primary key foreign keyprimary key Parent Table Dependent Table

6. Case 1. 1:1 relationship, both entities mandatory CASE 1a u When the relationship type of a binary relationship is 1:1 with the level of participation of both entities mandatory, generally only one table is required. u The primary key of this table can be the entity key from either entity (usually the strong entity’s primary key). u If the weaker entity is not part of any other relationships, it is probably an attribute of the stronger entity. EMPLOYEEJOB-DESCRIPTION has a 11 EMPLOYEE (EMP_NUM, EMP_LNAME,…, JOB_DESC)

7. Case 1. 1:1 relationship, both entities mandatory CASE 1b u When the relationship type of a binary relationship is 1:1 with the level of participation of both entities mandatory, two tables may be created if they are indeed two different entities u Place the foreign key (not null) in the strong entity (most frequently accessed) PLUMBERBUILDING assigned 11 PLUMBER (PLUMBER_ID, PLUMBER_LNAME,…BUILDING_ID) BUILDING (BUILDING_ID, BUILDING_ADDRESS,...)

8. Case 2. 1:1 relationship, one entity mandatory u When the relationship type of a binary relationship is 1:1 with the level of participation of one entity mandatory and the other optional, two tables are required. u There must be one table for each entity, and each entity must have a corresponding primary key. u Additionally, the primary key from the entity with mandatory participation must be added as a foreign key (not null) to the corresponding table of the entity with optional participation. EMPLOYEE (EMP_ID, EMP_LNAME, EMP_PHONE,…) AUTO (LIC_NUM, SERIAL_NUM, MAKE, MODEL,, …, EMP_ID) EMPLOYEEAUTO has 11

9. Case 3. 1:1 relationship, both entities optional u When the relationship type of a binary relationship is 1:1 with the level of participation of both entities optional, two tables are required. u There must be one table for each entity, and each entity must have a corresponding primary key. u Place the foreign key (null allowed) in the strong entity (most frequently accessed). EXERCISER (EXERCISER_ID, EXERCISER_LNAME, …TRAINER_ID) TRAINER (TRAINER_ID, TRAINER_LNAME,...) TRAINER EXERCISER has 11

10. Case 4. 1:M relationship, both entities mandatory u When the relationship type of a binary relationship is 1:M with level of participation of both sides mandatory, two tables are required. u There must be one table for each entity, and each entity must have a corresponding primary key. u The table corresponding to the M-side, will have among its attributes, the foreign key (not null) corresponding to the 1-side of the entity. EMPLOYEE (EMP_ID, EMP_DEPT, …) PRODUCT (PROD_ID, PROD_NAME, PROD_%FIBRE, EMP_ID... ) EMPLOYEEPRODUCT checks 1M

11. Case 5. 1:M relationship, 1-entity mandatory, M-entity optional u When the relationship type of a binary relationship is 1:M with the level of participation of the entity on the M-side optional, two tables are required. u There must be one table for each entity, and each entity must have a corresponding primary key. u The primary key from the entity on the 1-side must be added as a foreign key (not null) in the corresponding table of the entity on the M-side. MACHINE (MACH_ID, MACH_NAME, MACH_DEPT,...) PART (PART_ID, PART_NAME, PART_CATEGORY, …, MACH_ID) MACHINEPARTS contains 1M

12. Case 6. 1:M relationship, 1-entity optional, M-entity mandatory u When the relationship type of a binary relationship is 1:M with the level of participation of the entity on the 1-side optional, two tables are required. u There must be one table for each entity, and each entity must have a corresponding primary key. u The primary key from the entity on the 1-side must be added as a foreign key (null allowed) in the corresponding table of the entity on the M-side. BAND (BAND_ID, BAND_NAME, MUSIC_TYPE...) MUSICIAN (MUSICIAN_ID, MUSICIAN_INSTRUMENT, … BAND_ID) BANDMUSICIAN accepts 1M

13. Case 7. 1:M relationship, both entities optional u When the relationship type of a binary relationship is 1:M with the level of participation of both entities optional, two tables are required. u There must be one table for each entity, and each entity must have a corresponding primary key. u The primary key from the entity on the 1-side must be added as a foreign key (null allowed) in the corresponding table of the entity on the M-side. PHYSIOTHERAPIST (PT_ID, PT_LNAME,...) CLIENT (CLIENT_ID, CLIENT_LNAME, CLIENT_OHIP#, …PT_ID) PHYSIOTHERAPIST CLIENTS has 1 M

14. Case 8. M:N Relationships u When the relationship type of a binary relationship is M:N three tables are required: one for each entity, with the entity key from each entity serving as the primary key for the corresponding table, and one for the relationship. u The table corresponding to the relationship (intersection table) will have among its attributes the foreign keys (not null) from each entity. The combination of foreign keys may be the composite primary key for the relationship table. PATIENT (PATIENT_ID, PATIENT_LNAME, PATIENT_PHYSICIAN,...) DRUG (DRUG_ID, DRUG_NAME, DRUG_MANUFACTURER,...) PRESCRIPTION (PATIENT_ID, DRUG_ID, DOSAGE, DATE…) PATIENTMEDICATIONprescribed MN NOTE: The relationship may have its own attributes.

15. Example of decomposing entities with a binary M:N relationship Students:Classes have an M:N relationship, therefore, decompose to three tables. Bridge table

16. Case 9. Decomposing Weak Entities u When the relationship type of a binary relationship is 1:M between an entity and its weak entity, two tables are required: one for each entity, with the entity key from each entity serving as the primary key for the corresponding table. u Additionally, the entity that has a dependency on the existence of another entity has a primary key that is partially or totally derived from the parent entity of the relationship. u Weak entities must be deleted when the strong entity is deleted. HOSPITAL (HOSP_ID, HOSP_NAME, HOSP_ADDRESS,...) UNIT (HOSP_ID, UNIT_NAME, HEAD_NURSE,...) HOSPITAL UNIT contains 1M

17. Entity CLIENT contains ClientNumber ClientName Address AmountDue SocialInsuranceNumber TaxIdentificationNumber ContactPerson Phone Problem: Too many NULL values Solution: Separate into CLIENT entity plus several subtypes Considerations in a Generalized Hierarchy CLIENT INDIVIDUAL CLIENT CORPORATE CLIENT 1

18. Case 10. Decomposing a Generalization Hierarchy u To transform a subtype relationship, create a table for the parent entity and each of the child entities or subtypes u Move the associated attributes from the parent entity into the child table to which they correspond u From the parent entity take the entity key and add it as the primary key to the corresponding table for each child entity u In the event a table corresponding to a child entity already has a primary key then simply add the entity key from the parent entity as an attribute of the table corresponding to the child entity CLIENT (CLIENT_ID, AMOUNT_DUE, …) INDIVIDUAL_CLIENT (CLIENT_ID, SIN#, …) CORPORATE_CLIENT(CLIENT_ID, GST#, …) CLIENT INDIVIDUAL CLIENT CORPORATE CLIENT 1

19. Transforming Recursive Relationships u 1:1 - create a foreign key field (duplicate values not allowed) that contains the domain of primary key u 1:M - create a foreign key field (duplicate values allowed) that contains the domain of primary key

20. Transforming M:N Recursive Relationships u M:N - create a second relation that contains two foreign keys: one for each side of the relationship

21. Decomposing Ternary relationships u When a relationship is three-way (ternary) four preliminary tables are required: one for each entity, with the entity key from each entity serving as the primary key for the corresponding table, and one for the relationship. u The table corresponding to the relationship will have among its attributes the entity keys from each entity u Similarly, when a relationship is N-way, N+1 preliminary tables are required.

22. Library Database Example PUBLISHER AUTHORBOOK write publishes M 1 NM PUBLISHER (Pub_ID, ___, ___, ___, ___, …) BOOK (ISBN, Pub_ID, ___, ___, ___, ___, …) AUTHOR (Author_ID, ___, ___, ___, ___, …) WRITE (ISBN, Author_ID, ___, ___, ___, ___, …) Case 5 Case 8

23. University Example MN FACULTY COURSESTUDENT takes taught by advise s 1 MM N STUDENT (StudID, ___, ___, FacID, …) COURSE (CourseID, ___, ___, ___, …) FACULTY (FacID, ___, ___, ___, ___, …) Case 8 TEACH (FacID, CourseID,…) ENROLL (StudID, CourseID, ___,...) Case 8 Case 5

24. Characteristics of Fields u Each field within a table must have a unique name (avoid spaces and special characters). u Data within a field must be of the same data type. The following are common data types: l character (text or string) l memo (large character field) l integer (whole numbers for calculations) l number (values with decimals for calculations) l currency (formatted number) l logical or Boolean (true/false; 0,-1; yes/no) l date/ time (use computer’s internal calendar/clock) l graphic (picture)

25. Guidelines for Ideal Table Design u Each table should represents a single theme or subject or entity or transaction u Tables should include primary keys that uniquely identify each record of each table u Avoid the use of smart keys that attempt to embed meaning into primary keys (keys should be meaningless) u A primary key should be a unique, random or sequential collection of alphabetic, numeric or alphanumeric characters u The domain of primary keys should be large enough to accommodate the identification of unique rows for the entire potential universe of records u Use the suffix ID in constructing primary keys to ensure they are readily identifiable u Tables should not contain any of the following: multipart fields, multivalued fields, calculated or derived fields or unnecessary duplicate fields u There should be a minimum amount of redundant data

26. Common Errors in Database Design u Flat file database u Too much data u Compound fields u Missing keys u Bad keys u Missing relationships u Unnecessary relationships u Incorrect relationships u Duplicate field names u Cryptic field or table names u Referential integrity u Database Security u Missing or incorrect business rules u Missing or incorrect constraints John Paul Ashenfelter, “Common Database Mistakes”, May 26, 1999, (Oct 10, 1999).

27. The Well-Structured Database u E-R modeling is top-down method of designing u Transforming an E-R model does not guarantee the best design (e.g., E-R model could be way off) u Best to transform E-R model and then check the design according to the Cases of normalization u Normalization is bottom-up method of designing a database u Use both approaches to develop a well-structured database