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

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

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

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

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

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

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