1. DATABASE DESIGN AND DEVELOPMENT: A VISUAL APPROACH
Chapter 5
DATABASE DESIGN AND DEVELOPMENT: A VISUAL APPROACH
Raymond Frost – John Day – Craig Van Slyke
Chapter 5
Advanced Database Designs
Database Design and Development: A Visual Approach © 2006 Prentice Hall

2. Recursive Relationships
Chapter 5
Recursive Relationships
Original Design of the Enrollment Database
Exhibit 5-1: Enrollment Database Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

3. Mentor Recursive Relationships
Chapter 5
Mentor Recursive Relationships
Instructor 11 mentors instructors 22 and 33.
Instructor 33 mentors instructor 44.
Exhibit 5-2: Mentor Relationships for Enrollment Database
Database Design and Development: A Visual Approach © 2006 Prentice Hall

4. Implementing a Recursive Relationship
Chapter 5
Implementing a Recursive Relationship
A foreign key (INSTRUCTOR$id) is added to the INSTRUCTOR table, which is a copy of the primary key of that same table.
Exhibit 5-3: Data Relationships for Mentor
Recursive Relationship
Database Design and Development: A Visual Approach © 2006 Prentice Hall

5. ER Diagram with a Recursive Relationship
Chapter 5
ER Diagram with a Recursive Relationship
With the foreign key added, there is now a one-to-many relationship between instructors.
Exhibit 5-4: Enrollment Database Diagram
with Recursive Relationship
Database Design and Development: A Visual Approach © 2006 Prentice Hall

6. Chapter 5
Bill-of-Materials
A bill-of-materials is a structure that shows a relationships between products.
This is a many-to-many relationship: a product can have many sub-products, and a product can be a sub-product in many larger products.
Exhibit 5-5: Bill-of-Materials Example
Database Design and Development: A Visual Approach © 2006 Prentice Hall

7. Bill-of-Materials in Table Form
Chapter 5
Bill-of-Materials in Table Form
Trying to represent a many-to-many recursive relationship does not work since you could not determine how many component columns would be needed, and there will be a large number of empty cells.
Exhibit 5-6: Bill of Materials Table
Database Design and Development: A Visual Approach © 2006 Prentice Hall

8. ER Diagram for a Many-to-Many Recursive Relationship
Chapter 5
ER Diagram for a Many-to-Many Recursive Relationship
As with all many-to-many relationships, a many-to-many recursive relationship is represented with an associative table.
In this case, however, the associative table is linked back to the same table (PRODUCT), with both halves of its primary key being foreign keys from the PRODUCT table.
Exhibit 5-7: Bill-of Materials ER Diagram
Database Design and Development: A Visual Approach © 2006 Prentice Hall

9. Many-to-Many Recursive Relationship Data
Chapter 5
Many-to-Many Recursive Relationship Data
Exhibit 5-8: Bill-of-Materials Database Tables
Database Design and Development: A Visual Approach © 2006 Prentice Hall

10. Supertype/Subtype Hierarchies
Chapter 5
Supertype/Subtype Hierarchies
The first four columns apply to all equipment but the last four apply to only some equipment, which results in empty cells.
Exhibit 5-9: Equipment Entity and Data
Database Design and Development: A Visual Approach © 2006 Prentice Hall

11. Equipment Supertype/Subtype Hierarchy
Chapter 5
Equipment Supertype/Subtype Hierarchy
Supertype Entity: General entity with the common field.
Subtype Entites: specialized entities with unique fields.
Partial Specialization: Instances of the supertype don’t have to belong to a subtype.
Total Specialization: Instances of the supertype must belong to a subtype.
Disjoint rule: Supertype may belong to, at most, one subtype.
Overlap rule: Supertype may belong to multiple subtypes.
Exhibit 5-10: Equipment Supertype/Subtype
Hierarchy
Database Design and Development: A Visual Approach © 2006 Prentice Hall

12. Supertype/Subtype Example
Chapter 5
Supertype/Subtype Example
All three tables share four common fields.
Exhibit 5-11: STUDENT, FACULTY and
STAFF tables
Database Design and Development: A Visual Approach © 2006 Prentice Hall

13. Person Supertype/Subtype Hierarchy
Chapter 5
Person Supertype/Subtype Hierarchy
Step 1: Tables
Start by identifying three different tables.
Step 2: Fields and Keys
- Add the fields and designate the primary keys.
Step 3: Recognize Common Fields
- Make sure that the fields actually store the same data for each entity.
Exhibit 5-12: Person Supertype/Subtype
Hierarchy
Database Design and Development: A Visual Approach © 2006 Prentice Hall

14. Person Supertype/Subtype Hierarchy
Chapter 5
Person Supertype/Subtype Hierarchy
Step 4: Create Supertype/Subtype Hierarchy
Put Common fields into new table: PERSON.
The overlap rule requires adding discriminating fields to each subtype.
Fields specific to a category are put in matching subtypes.
Primary keys of supertype is coped into subtypes as foreign keys.
Step 5: Determine Total/Partial Specialization and Disjoint/Overlap Rule
Overlap Rule is in effect since a person can be in more than one subtype.
Total Specialization is in effect since data will only be stored about these three categories.
Exhibit 5-12: Person Supertype/Subtype
Hierarchy
Database Design and Development: A Visual Approach © 2006 Prentice Hall

15. More Complex Supertype/Subtype Example
Chapter 5
More Complex Supertype/Subtype Example
Subtypes not only contain different data, but can also be involved in different relationships with other tables.
Here, an athlete student subtype is involved in a relationship with a team.
Exhibit 5-13: Athlete/SGA Hierarchy
Database Design and Development: A Visual Approach © 2006 Prentice Hall

16. Complex Design Example: Summer Reading Fun
Chapter 5
Complex Design Example: Summer Reading Fun
Step 1: Tables
The problem statement refers to five entities: students, books, skills, fiction books and non-fiction books.
Exhibit 5-14: Summer Reading Fun
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

17. Complex Design Example: Summer Reading Fun
Chapter 5
Complex Design Example: Summer Reading Fun
Step 2: Relationships
Fiction and Non-fiction are subtypes of books.
Since there are no other types of books, we have total specialization.
The disjoint rule is in effect since a book cannot be both fiction and non-fiction.
A student has many skills and a skill is related to many students.
A student reads many books and a book is read by many students.
A book can be used to develop many skills and a skill can be developed in many books.
Exhibit 5-14: Summer Reading Fun
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

18. Complex Design Example: Summer Reading Fun
Chapter 5
Complex Design Example: Summer Reading Fun
Step 3: Resolve Many-to-Many Relationships
Associative Entities are created to resolve the many-to-many relationships.
There is also a many-to-many recursive relationship between skills: some skills are related to other skills as prerequisites.
The recursive relationship between skills is resolved with the PREREQ associative entity.
Exhibit 5-14: Summer Reading Fun
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

19. Complex Design Example: Summer Reading Fun
Chapter 5
Complex Design Example: Summer Reading Fun
Step 4: Fields
The fields identified in the problem statement are added to the tables.
Exhibit 5-14: Summer Reading Fun
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

20. Complex Design Example: Summer Reading Fun
Chapter 5
Complex Design Example: Summer Reading Fun
Step 5: Keys
Primary keys are created for STUDENT, SKILL, and BOOK.
Primary keys from tables related to associative entities are copied into the associative tables as foreign keys: the pair of foreign keys becomes the primary key of the associative tables.
The primary key in the BOOK supertype table is copied into the subtype tables as foreign keys, which also serve as the primary keys of those tables.
Exhibit 5-14: Summer Reading Fun
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

21. Complex Design Example: Summer Reading Fun
Chapter 5
Complex Design Example: Summer Reading Fun
Data Types
Exhibit 5-15: Summer Reading Fun ER Diagram
With Data Types
Database Design and Development: A Visual Approach © 2006 Prentice Hall

22. Complex Design: Swampland Real Estate
Chapter 5
Complex Design: Swampland Real Estate
Step 1: Tables
The problem statement refers to seven entities: property, agency, area, outlet, client and the single-family and condo property types.
Exhibit 5-16: Swampland Real Estate
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

23. Complex Design: Swampland Real Estate
Chapter 5
Complex Design: Swampland Real Estate
Step 2: Relationships
Clients are related to properties in two ways: as a buyer and as a seller.
Singlefamily and condo are subtypes of books.
Since there are other types of property, we have partial specialization.
The disjoint rule is in effect since a property cannot be both single family and condo.
Clients can also refer other clients to the agency, so there is a recursive relationship between clients.
Exhibit 5-16: Swampland Real Estate
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

24. Complex Design: Swampland Real Estate
Chapter 5
Complex Design: Swampland Real Estate
Step 3: Resolve Many-to-Many Relationships
The many-to-many relationship between properties and outlets is resolved by adding the PROPERTYOUTLET associative table.
Exhibit 5-16: Swampland Real Estate
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

25. Complex Design: Swampland Real Estate
Chapter 5
Complex Design: Swampland Real Estate
Step 4: Fields
The fields identified in the problem statement are added to the tables.
Exhibit 5-16: Swampland Real Estate
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

26. Complex Design: Swampland Real Estate
Chapter 5
Complex Design: Swampland Real Estate
Step 5: Keys
Each one-to-many relationship is represented by duplicating the primary key from the one side of the relationship into the table on the many side as a foreign key.
The primary keys of the tables linked to the associative are duplicated into the associate table as foreign keys.
These two foreign keys are combined with the ad date to be the primary key of the associative table.
The client recursive relationship is resolved by duplicating the primary key into the same table as a foreign key.
The primary key in the PROPERTY supertype table is copied into the subtype tables as foreign keys, which also serve as the primary keys of those tables.
Exhibit 5-16: Swampland Real Estate
Step-by-Step Design
Database Design and Development: A Visual Approach © 2006 Prentice Hall

27. Complex Design: Swampland Real Estate
Chapter 5
Complex Design: Swampland Real Estate
Data Types
Exhibit 5-17: Swampland Real Estate
ER Diagram
Database Design and Development: A Visual Approach © 2006 Prentice Hall

28. Practice Exercise 6: Event Planning Sheet
Chapter 5
Practice Exercise 6: Event Planning Sheet
Exhibit 5-18: The Event Planning Sheet
Database Design and Development: A Visual Approach © 2006 Prentice Hall

29. Practice Exercise 6: Recipe Card
Chapter 5
Practice Exercise 6: Recipe Card
Exhibit 5-19: A Recipe Card
Database Design and Development: A Visual Approach © 2006 Prentice Hall

30. Practice Exercise 6: Second Recipe Card
Chapter 5
Practice Exercise 6: Second Recipe Card
Exhibit 5-20: A Second Recipe Card
Database Design and Development: A Visual Approach © 2006 Prentice Hall