Entity Relationships

Relationships

• Relationships exist between entities• The type of relationship is entirely dependent

on the business rules• The business rules must be known first before

determining the type of relationship.– E.g. • Can a customer place more than one order?• Can they have more than one phone number that the

business needs to know about?

Relationships are Bidirectional

• Relationships have to be assessed in both directions between the entities

• Relationships are viewed from the standpoint of one record to its relationship to records in the other table

• A Customer can place many Orders, but any single order can only be placed by a single Customer

There are Four Relationship Types

• 1-1 One to One• 1-M One to Many• M-M Many to Many• Recursive

One to one Relationships

• One to One (1:1) or (1-1)– Rare but a database can support it– E.g. “One employee is married to one Spouse”– It is a 1-1 relationship in both directions– One record in one table relates to only one record

in the other table

1-1 Relationship

• When a record in one table matches up with only one record in the other table and vice versa

One to Many Relationships

• One to Many (1:n) or (1-M)– Most common and easily implemented in a

database– E.g. “One customer places many orders”– It is a 1-M from Customer to Order – Is a 1-1 from Order to Customer– One record relates to many, but any single record

in the second table relates back to only the parent in the first table

1-M Relationship• When one record relates to one or many in the

other table, but any one record in the second table will tie back to only one parent record

Many to Many Relationships

• Many to Many (M:n) or (M-M)• Very common in the real world• Can not be directly implemented in a database• Will require a third “Junction Table” for

implementation in the database• A single record in one table may relate to many in the

other table and vice versa• E.g.– One student can take many classes, but any single class can

be taken by many students

Many to Many Relationships• One customer can hold many license types and any license

type can be held my many customers– We can’t add Cust_Num to Licenses because it would be multi-

valued – We can’t add License_Type to customer because it would be

multi-valued– What can we do?

Many to Many Relationships

• M-M relationships are “bad” in a because they cause multi-valued fields if directly implemented

• To “solve” the issue, it does not work to:– Add additional columns– Add a record– Attempt a composite field

• The solution is adding a third “Junction Table”– Junction table primary key:

• Either a concatenation of the primary keys of the parent tables• A combination of additional fields if the primary key combo is not

unique• Creating an artificial key

Junction Tables• We can add a third table, a junction or bridge table• This allows the M-M relationship to decompose into two 1-M

relationships. • 1 Customer can have many junction records• 1 License can be related to many junction records• A single junction record will relate back to one customer and

one license

Recursive Relationships• Recursive Relationship• Rare but can be implemented in a database• Occurs when a table has a 1-M relationship with

itself• Implemented by added the Primary Key of the

table to the same table as a Foreign Key• E.g. If an employee is also a team leader. The

Employee_ID of the leader is added to the table as a foreign key to identify the team members of the leader

Recursive Relationships

• Recursive Relationship• Employee ID has been added as the foreign key

Manager ID.• Who is Shemp’s manager? Employee #1, Moe

Relationship Optionality

• The relationship between entities may be optional or mandatory

• Since relationships are bidirectional, relationship optionality is also bidirectional

Relationship Optionality

• Relationships can be “optional” or “mandatory”• Since relationships are bidirectional, they can be

optional or mandatory in either direction– Optional – Optional– Optional – Mandatory– Mandatory – Optional– Mandatory – Mandatory

• Relationship optionality is dependent on the business rules of that particular database

Optional Relationship

• Optional Relationship:• A parent record may exist with or without children• A child record may exist without being tied to a parent• Examples (optional in both directions)– A Model record may exist that does not have a Vehicle

representing it– A Vehicle record could exist but be of an unknown Model

Relationship Optionality

• Mandatory Relationship:• A parent record must have children• A child record must be tied to a parent• Examples (mandatory in both directions)– An Order record must have one or more Items– An Item record can not exist unless it is tied to a

valid order

Relationship Optionality

• Optional and Mandatory relationships• Optional in one direction, mandatory in the other• Example:• A Customer record may exist without a Rental• But a rental record must be tied back to a valid

Customer record.

Relationship Optionality and ERD’s

• Syntax in ERDs is used to convey relationship optionality (covered later in the class)