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 – Mandatory – Mandatory – Optional – 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)