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 (n-ary) Relationships
Relationships with Attributes
Foreign Keys
Parent-Child Relationships
Strong-Weak Entities

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

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

5. 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
Relationships allow the system to reconstruct the logic of a transaction from dispersed tables

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

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

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

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

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

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

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

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

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

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

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

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

19. 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)

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