1. Relationships—Topics
Goal of the Relational Data Model
Introducing Relationships
Relationship Notation Schemes
Binary Relationships
Relationship Cardinality & Notation
Policy and Cardinality
Recursive (Unary) Relationships
Ternary Relationships
Relationships with Attributes
Foreign Keys
Parent-Child Relationships
Strong-Weak Entities
Many to Many relationships
Unary Relationships
n-ary relationships
Binary 1:1 relationships

2. The Goal of the Relational Data Model
Recall that entities hold data about one type of object or event of interest to the organization
A goal of the relational data model is to minimize the amount of stored data subject to:
Necessity to record data needed by the organization
Necessity to maintain relationships

3. The Goal of the Relational Data Model (cont).
Data minimization is achieved by removing any redundant data
Achieved through good entity and relationship design
Normalization
Our approach
Design properly normalized (minimal redundancy) data structures
Selectively denormalize (introduce redundancy) to improve performance

4. The Goal of the Relational Data Model (cont).
DB design results in many tables, sometimes for simple organizational needs
Identifying entities from information requirements analysis
Creating new entities to fix attribute-level and relationship problems (covered soon)
Relationships between tables enable us to reconnect data that is dispersed into many tables

5. Relationships
"A meaningful association between (or among) entities"
What in the world does this mean?
Relationships indicate how entities interact from the organization's perspective
Relationships will end up defining paths through the database along which data will be retrieved
The paths usually mirror real world associations between entities

6. Relationships (cont.)
While entities are nouns relationships are verbs
Buys, teaches, sells, owns, …
Is a
Has
Relationship verb describes how two entities interact with each other
If two entities do not interact (from the organization’s official viewpoint) then there is no relationship between them
Professor ?? Football_Play
‘Direction’ of verb is not very important
Important special cases

7. Introducing Relationships
Relationships are defined in three ways
In data modeling by conceptually identifying and documenting the fact that two entities do relate to each other
In data modeling by identifying shared attributes between the two entities (primary key / foreign key)
In the physical database by implementing common attributes and declaring the relationship

8. Introducing Relationships (cont.)
Relationships are the glue that connects different stored data in a way that meets the organization’s needs
File-based vs. Relational systems
In file-based systems each transaction record had all necessary data stored with it, including redundant copies of data
In relational systems only data of a particular type is stored in each entity (table)—little redundancy
Relationships allow the system to reconstruct the logic of a transaction

9. Introducing Relationships (cont.)
We deal with relationships in three ways
Modeling relationships as part of a process of discovery of the organization’s structure, etc
Adapting or correcting the relationships we find into the form required for database implementation
Implementing the relationships in the physical database

10. Two Notation Schemes (Chen LDM)
Relationships are connected to entities by notation to indicate the cardinality of the relationship
Entities are indicated by a box with the entity name inside
Relationships are indicated by diamonds
Attributes are listed in ovals attached to entities

11. Two Notation Schemes (Alternative LDM)
Relationship shown without the diamond
Entity name
Attributes
Entities shown as boxes

12. Binary Relationships
The most commonly found relationship is between two entities (binary)
Chen Diagram
Entities
Relationship
Entities
Cardinality
Cardinality
My Approach

13. Cardinality
Understanding “Cardinality” is one of the most fundamentally important concepts in DB design
Cardinality indicates how many occurrences of an entity must or may be allowed in the relationship with any one occurrence in the other entity
Cardinality goes in each direction
One student may/must take ? Classes
One class must/may be taken by ? Students

14. Relationship Cardinality (cont.)
The measure of cardinality has two components at each end of the relationship:
A maximum (usually either 1 or an unconstrained number greater than one, referred to as “many”)
A minimum (usually either 0 or 1 but other values are possible, though rare)
Relationship is mandatory if at least one matching record is required (minimum is 1)
Relationship is optional if a matching record is not required (minimum is 0)

15. Cardinality Notation Mandatory One
One professor must have exactly one phone number
Mandatory Many
A customer must have at least one purchase to be a customer but may have many
Optional One
One professor may have as few as zero reserved parking spaces but may have only one at most
Optional Many
One student may take as few as zero classes but may take more than one class

16. Cardinality Notation (cont.)
Interpret these cardinalities

17. Cardinality Notation (cont.)
Relationship cardinality is governed by the number of related occurrences you could have
If a student could have two majors then relationship is ‘Many’ on the Major side
May a car or house have more than one owner?
May an Employee be assigned to more than one job title at a time?
Will you record a Supplier if you do not currently carry any of their products?
Will you enter an Employee without assigning them to a position?

18. Cardinality Notation (cont.)
Commonly used verbal shorthand ignores the minimum component of a relationship
1:M (one-to-many)
1:1 (one-to-one)
M:M (or M:N) (many-to-many)

19. Cardinality Notation (cont.)
The graphical layout of a relationship is purely arbitrary

20. Organization Policy and Cardinality
Business policies (or regulations) may affect cardinality
Identify legitimate business policies that support each of the different cardinality combinations reflected here

21. 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

22. Ternary Relationships
A ternary relationship is one between three entities
This relationship is for modeling and discovery only
Model the relationship the way the user describes it
Recognize that there are problems with implementing this relationship
Relationship will be decomposed into multiple binary relationships for the final ERD
(What is the solution?)

23. Attributes on Relationships
The modeling process will sometimes produce attributes of relationships
These also will be eliminated in the final ERD
(What is the solution?)
Look for the missing entity and implement it now

24. Multiple Relationships
Sometimes there can be two relationships between the same two entities

25. Implementing Relationships
Relationships are implemented by sharing attributes between entities
When the Identifier Attribute of one entity appears as an attribute in another entity set a relationship is established (whether you intended it or not)
These shared identifier attributes are called foreign keys (more next time)
Identifier
Attribute
Shared
Identifier
Attribute

26. Problem Relationships
Ternary relationships, attributes on relationships, multiple relationships, and Many-to-Many relationships all have serious implementation problems
What are they?
What does the nature of the problem tell us about what we should do to fix it?

27. 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

28. Parent & Child Relationships (Terminology)
The entity contributing the primary key is the parent
The entity receiving the foreign key is the child
Foreign Keys always, always, always go on the ‘many’ side of a 1:M relationship
Shared
Identifier
Attribute (Foreign Key)
Parent
Child
Identifier
Attribute

29. Strong & Weak Entity Types
Traditional definitions:
Strong entity type exists independently of any other entity
Weak entity type depends on some other entity type
Strong Entity Type
Weak Entity Type

30. Strong & Weak Entity Types (cont.)
Identifying weak entities will often not happen until identifier attributes are specified
When the Identifier Attribute of one entity set appears as an attribute in another entity set a relationship is established
If the foreign key in the child table is not part of the child's PK the child is a strong entity
Identifier
Attribute
Shared
Identifier
Attribute

31. Strong & Weak Entity Types (cont.)
When the identifying attribute of one entity appears as part of a composite identifying attribute set in another entity the child entity is a weak entity
Dept Code part of Course PK
Indicates Weak Entity in some documentation styles (We will
not use.)
Parent (Strong)
Child (Weak)

32. Strong vs. Weak Entity Types (Terminology)
The identifying attribute that appears in the composite identifying attribute in a weak entity is sometimes called a cascading primary key.
These primary key attributes can sometimes cascade through three or more entities
Do not confuse mandatory relationships with weak entities

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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

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

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

42. 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

43. 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?)

44. 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?

45. 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

46. 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