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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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