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

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

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

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

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

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

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

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

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

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

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

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

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)

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

Cardinality Notation (cont.) Interpret these cardinalities

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?

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)

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

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

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

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

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

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

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

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?

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

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

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

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

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)

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

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