TransformingE-R Models
into Relations
Though this be madness, yet there is method in it. Shakespeare
Class Outline What is the primary key-foreign key basis of a relational
database? How is an Entity-Relationship model converted to relational
tables? Specifically, how are these converted: 1:1, 1:M, M:N relationships binary relationships ternary or recursive relationships optional/ mandatory relationships generalized hierarchies weak entities
What are common data types provided by databases? Describe some guidelines for designing tables. Describe common database design flaws.
Steps to E-R Transformation
1. Identify entities2. Identify relationships3. Determine relationship type4. Determine level of participation5. Assign an identifier for each entity6. Draw completed E-R diagram7. 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)
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).
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.
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.)
Supplier ID Supplier Name1 Bikes-R-Us2 Small moter suppliers3 All Bikes Allways
Student ID Course Mark1 MIT 252 100%3 BIO 20 56%2 CHEM 100 77%1 CHEM 100 44%2 BIO 20 60%1 BW 101 80%
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.
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
Product ID Product Description Price Supplier ID801 Shur-Lock U-Lock 75.00 3802 SpeedRite Cyclecomputer 60.00 3803 SteelHead Microshell Helmet 40.00 804 SureStop 133-MB Brakes 25.00 1805 Diablo ATM Mountain Bike 1,200.00 2806 Ultravision Helmet Mount Mirrors 7.45 3
Supplier ID Supplier Name1 Bikes-R-Us2 Small moter suppliers3 All Bikes Allways
primary keyforeign keyprimary key
Parent TableDependent Table
Case 1. 1:1 relationship, both entities mandatory
CASE 1a 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. The primary key of this table can be the entity key from either entity (usually
the strong entity’s primary key). If the weaker entity is not part of any other relationships, it is probably an
attribute of the stronger entity.
EMPLOYEE JOB-DESCRIPTIONhas a1 1
EMPLOYEE (EMP_NUM, EMP_LNAME,…, JOB_DESC)
Case 1. 1:1 relationship, both entities mandatory
CASE 1b 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
Place the foreign key (not null) in the strong entity (most frequently accessed)
PLUMBER BUILDINGassigned1 1
PLUMBER (PLUMBER_ID, PLUMBER_LNAME,…BUILDING_ID)
BUILDING (BUILDING_ID, BUILDING_ADDRESS,...)
Case 2. 1:1 relationship, one entity mandatory
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.
There must be one table for each entity, and each entity must have a corresponding primary key.
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)
EMPLOYEE AUTOhas1 1
Case 3. 1:1 relationship, both entities optional
When the relationship type of a binary relationship is 1:1 with the level of participation of both entities optional, two tables are required.
There must be one table for each entity, and each entity must have a corresponding primary key.
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, ...)
TRAINEREXERCISER has1 1
Case 4. 1:M relationship, both entities mandatory
When the relationship type of a binary relationship is 1:M with level of participation of both sides mandatory, two tables are required.
There must be one table for each entity, and each entity must have a corresponding primary key.
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... )
EMPLOYEE PRODUCTchecks
1 M
Case 5. 1:M relationship,1-entity mandatory, M-entity optional
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.
There must be one table for each entity, and each entity must have a corresponding primary key.
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)
MACHINE PARTScontains1 M
Case 6. 1:M relationship,1-entity optional, M-entity mandatory
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.
There must be one table for each entity, and each entity must have a corresponding primary key.
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)
BAND MUSICIANaccepts1 M
Case 7. 1:M relationship, both entities optional
When the relationship type of a binary relationship is 1:M with the level of participation of both entities optional, two tables are required.
There must be one table for each entity, and each entity must have a corresponding primary key.
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 CLIENTShas1 M
Case 8. M:N Relationships 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.
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…)
PATIENT MEDICATIONprescribedM N
NOTE: The relationship may have its own attributes.
Example of decomposing entitieswith a binary M:N relationship
Students:Classes have an M:N relationship, therefore, decompose to three tables.
Bridge table
Case 9. Decomposing Weak Entities
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.
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.
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 UNITcontains1 M
Entity CLIENT containsClientNumberClientNameAddressAmountDueSocialInsuranceNumberTaxIdentificationNumberContactPersonPhone
Problem: Too many NULL valuesSolution: Separate into CLIENT entity plus several subtypes
Considerations in a Generalized Hierarchy
CLIENT
INDIVIDUALCLIENT
CORPORATECLIENT
1
Case 10. Decomposing aGeneralization Hierarchy
To transform a subtype relationship, create a table for the parent entity and each of the child entities or subtypes
Move the associated attributes from the parent entity into the child table to which they correspond
From the parent entity take the entity key and add it as the primary key to the corresponding table for each child entity
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
INDIVIDUALCLIENT
CORPORATECLIENT
1
Transforming Recursive Relationships
1:1 - create a foreign key field (duplicate values not allowed) that contains the domain of primary key
Stud_ID Stud_FName Stud_LNameLockerPartner
1 Rodney Jones 42 Joki Singh 33 Francine Moire 24 Anne Abel 1
1:M - create a foreign key field (duplicate values allowed) that contains the domain of primary key
Prod_ID Prod_Name Base_Prod
1 Chicken burger 22 Raw Chicken3 Weiner Schnitzel 54 Fried Chicken 25 Ground pork6 Pork dumplings 5
Transforming M:N Recursive Relationships
M:N - create a second relation that contains two foreign keys: one for each side of the relationship
BookID BookTitle Author
1 Open Secrets Alice Munro2 Wilderness Tips Margaret Atwood3 Stones from the River Ursula Hegi4 Cat's Eye Margaret Atwood
BookID RecommendedBook
1 21 42 44 24 3
Decomposing Ternary relationships
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.
The table corresponding to the relationship will have among its attributes the entity keys from each entity
Similarly, when a relationship is N-way, N+1 preliminary tables are required.
Library Database Example
PUBLISHER
AUTHOR BOOKwrite
publishes
M
1
NM
PUBLISHER (Pub_ID, ___, ___, ___, ___, …)
BOOK (ISBN, Pub_ID, ___, ___, ___, ___, …)
AUTHOR (Author_ID, ___, ___, ___, ___, …)
WRITE (ISBN, Author_ID, ___, ___, ___, ___, …)
Case 5
Case 8
University Example
M N
FACULTY
COURSESTUDENT takes
taught by
advises
1
M M
N
STUDENT (StudID, ___, ___, FacID, …)
COURSE (CourseID, ___, ___, ___, …)
FACULTY (FacID, ___, ___, ___, ___, …)
Case 8
TEACH (FacID, CourseID,…)
ENROLL (StudID, CourseID, ___, ...)
Case 8
Case 5
Characteristics of Fields
Each field within a table must have a unique name (avoid spaces and special characters).
Data within a field must be of the same data type. The following are common data types:
character (text or string) memo (large character field) integer (whole numbers for calculations) number (values with decimals for calculations) currency (formatted number) logical or Boolean (true/false; 0,-1; yes/no) date/ time (use computer’s internal calendar/clock) graphic (picture)
Guidelines for Ideal Table Design Each table should represents a single theme or subject or entity or transaction Tables should include primary keys that uniquely identify each record of
each table Avoid the use of smart keys that attempt to embed meaning into primary
keys (keys should be meaningless) A primary key should be a unique, random or sequential collection of
alphabetic, numeric or alphanumeric characters The domain of primary keys should be large enough to accommodate the
identification of unique rows for the entire potential universe of records Use the suffix ID in constructing primary keys to ensure they are readily
identifiable Tables should not contain any of the following: multipart fields, multivalued
fields, calculated or derived fields or unnecessary duplicate fields There should be a minimum amount of redundant data
Common Errors in Database Design Flat file database Too much data Compound fields Missing keys Bad keys Missing relationships Unnecessary relationships Incorrect relationships
Duplicate field names Cryptic field or table
names Referential integrity Database Security Missing or incorrect
business rules Missing or incorrect
constraints
John Paul Ashenfelter, “Common Database Mistakes”, May 26, 1999, <http://webreview.com/wr/pub/1999/03/26/feature/index3.html> (Oct 10, 1999).
The Well-Structured Database
E-R modeling is top-down method of designing Transforming an E-R model does not guarantee the
best design (e.g., E-R model could be way off) Best to transform E-R model and then check the
design according to the Cases of normalization Normalization is bottom-up method of designing a
database Use both approaches to develop a well-structured
database