1. BTM 382 Database Management Chapter 5: Advanced Data Modeling
Chitu Okoli
Associate Professor in Business Technology Management
John Molson School of Business, Concordia University, Montréal

2. Structure of BTM 382 Database Management
Week 1: Introduction and overview
ch1: Introduction
Weeks 2-6: Database design
ch3: Relational model
ch4: ER modeling
ch6: Normalization
ERD modeling exercise
ch5: Advanced data modeling
Week 7: Midterm exam
Weeks 8-10: Database programming
ch7: Intro to SQL
ch8: Advanced SQL
SQL exercises
Weeks 11-13: Database management
ch2,12: Data models
ch13: Business intelligence and data warehousing
ch9,14,15: Selected managerial topics

3. Review of Chapter 5: Advanced Database Modeling
How can the Extended Entity Relationship (EER) model help model IS-A relationships?
How do you select a good (not just legal) primary key for a table?
On which side of a relationship should you place a foreign key?

4. The Extended Entity Relationship Model: Entity clusters

5. Entity cluster
“Virtual” or “abstract” entity type used to represent multiple entities and relationships in ERD
Two primary purposes:
When you have not yet figured out the details of part of the ERD
Full ERD will be developed later
To simplify the ERD or save space
Details of the entity clusters can be displayed on separate pages
You should not display any attributes when entity clusters are used, since foreign keys cannot be correctly specified

6. The Extended Entity Relationship Model: Handling IS-A relationships

7. What is an IS-A relationship?
Sometimes, one kind of entity is a type of another entity
Examples:
A person is a specific type of person: an Employee is an Accountant, a Doctor is a Specialist, a Student is an Undergraduate
A product is a specific type of product: a Bicycle is a type of Vehicle, a Violin is a type of MusicalInstrument, ManufacturingProduct and MaintenanceSupply are types of Product

8. Two ways to handle IS-A relationships
Example: Some employees are pilots, some are mechanics, some are accountants, and some are none of those specialized types
Solution 1: Leave them all in one entity, EMPLOYEE
Disadvantage: Lots of nulls
Solution 2: Create a supertype entity EMPLOYEE and subtype entities PILOT, MECHANIC and ACCOUNTANT

9. Specialization hierarchy: Supertype and subtypes
Entity supertype
Generic entity type related to one or more entity subtypes
Contains common characteristics
Entity subtype
Contains unique characteristics of each entity subtype
Specialization hierarchy
Depicts relationships between supertypes and subtypes

10. Specialization hierarchy: other elements
registers
Inheritance
Subtypes are implemented with 1:1 relationship with the supertype
Supertype’s PK becomes the subtype’s PK/FK
Subtypes inherit all attributes and relationships from supertype
Subtype discriminator
One or more attributes that determines which subtype or subtypes the supertype instance belongs to

11. Disjoint and Overlapping Constraints: One value only, or multiple values allowed?
Disjoint subtypes
Mutually exclusive: entity belongs to one and only one subtype
Implementation: one attribute only (usually one character)
Overlapping subtypes
Multiple subtype values allowed
Implementation: multiple binary (true/false) attributes

12. Completeness Constraint: Subtypes optional or required?
Partial completeness (subtype optional)
Some supertype occurrences are not members of any subtype
Implementation: Null values permitted
Total completeness (subtype required)
Every supertype occurrence must be member of at least one subtype
Implementation: No nulls permitted

13. All the specialization hierarchy constraints

14. SQL implementation of EERD constraints
Disjoint constraints
Disjoint constraint with partial completeness
EMP_TYPE VARCHAR2(1) NULL CHECK (EMP_TYPE IN ('P', 'M', 'A'))
Disjoint constraint with total completeness
STU_TYPE VARCHAR2(1) NOT NULL CHECK (STU_TYPE IN ('U', 'G'))
Overlapping constraints
Overlapping constraint with partial completeness
EMP_IS_ADM VARCHAR2(1) NOT NULL CHECK (EMP_IS_ADM IN ('Y', 'N')), EMP_IS_PROF VARCHAR2(1) NOT NULL CHECK (EMP_IS_PROF IN ('Y', 'N'))
Overlapping constraint with total completeness
P_IS_EMP VARCHAR2(1) NOT NULL CHECK (P_IS_EMP IN ('Y', 'N')), P_IS_STU VARCHAR2(1) NOT NULL CHECK (P_IS_STU IN ('Y', 'N')), CONSTRAINT ENFORCE_TOTAL_OVERLAPPING_PERSON CHECK (P_IS_EMP = 'Y' OR P_IS_STU = 'Y')

15. Entity Integrity: Selecting Primary Keys

16. Natural keys vs. Surrogate keys
Natural key is a real-world identifier used to uniquely identify real-world objects
Familiar to end users and forms part of their day-to-day business vocabulary
E.g. address, SIN, username, etc.
Surrogate key is an attribute that the designer invents only for the purpose of serving as a primary key
E.g. CustomerID with values 1, 2, 3, 4, 5, 6, …, ∞
Natural keys are very common as a primary key, but there are many possible problems
You may instead use composite primary key or surrogate key

17. Ideal characteristics of primary keys
When you consider all these points, then surrogate keys are generally superior to natural keys

18. When to Use Composite Primary Keys
Composite primary keys are useful in two cases:
As identifiers of composite entities (for implementing M:N relationships)
As identifiers of weak entities
Because they are indexed, they automatically provide benefit of ensuring that there cannot be duplicate values
Although they use two attributes instead of one, in SQL programming, you usually need both attributes anyway

19. Design cases Placement of foreign keys Historical data Fan traps
Avoiding redundant relationships

20. Case #1: On which side of a relationship should you place a foreign key?
M:M relationship: Always turn it into two 1:M relationships
1:M relationship: Always place the foreign key on the many side
1:1 relationship:
(1,1):(0,1): Foreign key goes on (0,1) side
(1,0):(0,1): Foreign key goes on whichever side will cause fewer nulls
(1,1):(1,1): This relationship almost never exists in the real world. You probably made a mistake. Verify your cardinalities, or merge the two tables.
Exception: this relationship is sometimes used for database performance optimization

21. Summary of Chapter 5: Advanced Database Modeling
The Extended Entity Relationship (EER) model gives useful notation for modeling IS-A relationships
Although multiple candidate keys might legally be elected as the primary key, some can do the job better than others
Surrogate keys are often the best choice
The foreign key always goes on the many side of a 1:M relationship
For 1:1 relationships, it’s a bit complicated

23. Sources
Most of the slides are adapted from Database Systems: Design, Implementation and Management by Carlos Coronel and Steven Morris. 11th edition (2015) published by Cengage Learning. ISBN 13:
Other sources are noted on the slides themselves