1. Relationship Problems—Topics
Foreign Keys (review)
Many to Many relationships
Ternary (n-ary) relationships
Relationships with Attributes
Parent-Child Relationships
Strong-Weak Entities
Unary Relationships
Binary 1:1 relationships

2. Identify “Information Elements” Identify Entities
Database Design Steps
Identify “Information Elements”
Identify Entities
Identify Primary Keys
Identify Relationships
Fix Relationship Problems
Identify Non-Key Attributes
Fix Attribute Problems
Address Performance Issues
Build Application Objects (stored procedures, views)
Design Reports
List is not strictly sequential
Some steps performed recursively
Some steps require returning to previous steps

3. Problem Relationships
Three kinds of relationship create serious implementation problems
Many-to-Many relationships
Ternary relationships
Attributes on relationships
What are they?
What does the nature of the problem tell us about what we should do to fix it?

4. These attributes are called Foreign Keys in the other entity
Relationships are established when the Primary Key attribute(s) of one entity is/are found in another entity
These attributes are called Foreign Keys in the other entity
Foreign Keys

5. Many-to-Many Relationships
What is the problem with implementing foreign keys for the following Many-to-Many relationships?

6. Many-to-Many Relationships (cont.)
Many-to-Many (M:N) relationships must be decomposed into a new entity and two relationships
Carefully examine the cardinality of the two new relationships

7. Many-to-Many Relationships (cont.)
Always try the combination of the primary keys from the two original entities as the PK of the new entity
Sometimes not all attributes of a composite parent PK are needed
Sometimes an alternate PK suggests itself
Add appropriate nonkey attributes to the new entity
Sometimes there won't be any—the new entity serves no role but to decompose the M:N relationship

8. Many-to-Many Relationships (cont.)
Two kinds of entities created this way
A real ‘person, place, thing, event…’ that was overlooked in the original design
An ‘associative entity’ that has no purpose except to decompose the M:M relationship
The distinction isn’t terribly important
Both kinds can have non-key attributes

9. Many-to-Many Relationships (cont.)
Decompose this relationship
Sometimes the new entity has a natural meaning that should have been identified in the original data modeling step

10. Unary Relationships
Unary relationships are relationships between an entity and itself
One employee supervises many other employees; each employee is supervised by, at most, one other employee
One part is a component of many other parts; One part (assembly) contains many other parts

11. Unary Relationships and Foreign Keys
The foreign key in a unary relationship will be a different attribute in the entity
EmployeeID
LastName
FirstName …
ReportsTo 3
Jones
Sally 9 5
Jefferson
Mark 6
Wilson
John 8
Adamski
Justin
Boss
Big 13
Dowd
Russ 19
Brown
Larry

12. Unary Many-to-Many Relationships
Decomposing Unary M:N relationships

13. Unary M:M Relationships (cont.)
Fix this one

14. Ternary Relationships
Ternary (or n-ary) relationships are relationships between three (or more) entities
It will almost always be possible to identify a natural associative entity that reflects the relationship between the entities
Create the weak associative entity and bring in foreign keys from the original entities

15. Ternary Relationships (cont.)
In n-ary relationships there is a higher likelihood that the new entity will have its own 'natural' PK
Examine the default PK carefully to see if it is appropriate
Can you think of an alternate PK for the HouseSale entity?
(What other entities are likely to be related to the HouseSale entity?)

16. Binary 1:1 Relationships
In a 1:M relationship the parent entity will always be on the '1' side of the relaionship
Foreign key will be in the 'M' side
Q: Where should the FK be in a 1:1 relationship?

17. Binary 1:1 Relationships (cont.)
A: It doesn't matter (much)
Some considerations
Use the simplest PK/FK available
If there is a 'natural' parent (e.g., employee 'owns' the office, not the other way around) make it the parent
If an occurrence of one member of the relationship may stand alone (not participate in a relationship) while the other will usually be in a relationship make it the parent

18. Binary 1:1 Relationships (cont.)
Watch for 1:1 relationships that are really relationships between two versions of the same entity
Some 1:1 relationships may actually be supertype/subtype relationships
Relationships modeled as Supertype/Subtype in the modeling process are implemented in the database as 1:1 relationships
Supertype/Subtype covered later in course

19. Attributes on Relationships
We cannot have attributes on relationships
There is to container for the values
Create a new entity for the attributes