1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen :1 Relationships These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see

2 © Ellis Cohen Overview of Lecture 1:1 Relationships & Mappings 1:1 Mappings & Performance Modeling, Transforming & Mapping Parallel Relationships 1:1 Dependent Relationships 1:1 Identifying Relationships

3 © Ellis Cohen :1 Relationships & Mappings

4 © Ellis Cohen :1 Relationships DeskEmployee assigned to Each employee may be assigned to at most one desk Each desk may be assigned to at most one employee Assignment: Desk assigned to Employee Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

5 © Ellis Cohen :1 Relationships EmployeeDesk sits at UML EmployeeDesk sits at Chen 0..1 EmployeeDesk EmployeeDesk Crow Magnum Easy Crow Magnum sits at

6 © Ellis Cohen Mapping of 1:1 Relationships Suppose some employees don't have desks & some desks don't have employees Desk Employee assigned to deskno height width depth empno Desks 40694… 15129… 30276… 81107… 60019… Emps empno ename desk references the employee (if any) who sits at it

7 © Ellis Cohen Alternate 1:1 Mapping Desk Employee assigned to deskno height width depth Desks 40694… 15129… … 81107… … Emps empno ename deskno Pick mapping that has fewest NULLS, or (more often) that has best performance for your operations employee references the desk (if any) that they sit at

8 © Ellis Cohen :1 Relational Fingerprint EmployeeDesk assigned to EmployeeDesk Relational Fingerprint for 1:1 relationship. Uniqueness indicator distinguishes 1:1 from 1:M Every employee has at most one desk Desks deskno height width depth empno ename deskno Emps Each desk is associated with at most a single employee! Desks deskno height width depth empno ename deskno Emps assigned to

9 © Ellis Cohen Combining Unique & FK Constraints Desks deskno height width depth empno ename deskno EmployeeDesk Emps Desks deskno height width depth empno ename deskno Emps Combine unique symbol with FK constraint assigned to

10 © Ellis Cohen Desks deskno height width depth Emps empno ename deskno Desks deskno height width depth empno Emps empno ename Alternate Relational Models Desks( deskno, height, width, depth) Emps( empno, ename, deskno) unique( deskno ) deskno references Desks Emps( empno, ename) Desks( deskno, height, width, depth, empno) unique( empno ) empno references Emps Unique references correspond to 1:1 relationships

11 © Ellis Cohen Mandatory 1:1 Relationships DeskEmployee assigned to What's the best relational mapping?

12 © Ellis Cohen Desks deskno height width depth Emps empno ename deskno ! Desks deskno height width depth empno Emps empno ename Mandatory 1:1 Enforcement Enforced directly by a non-null constraint State assertion must be separately enforced: (SELECT count(DISTINCT empno) FROM Desks) = (SELECT count(*) FROM Emps)

13 © Ellis Cohen Desks deskno height width depth Emps empno ename deskno ! SQL for Mandatory 1:1 CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(20), desknonumber(5) not null unique references Desks );

14 © Ellis Cohen :1 Mappings & Performance

15 © Ellis Cohen Desks deskno height width depth Emps empno ename deskno Desks deskno height width depth empno Emps empno ename Deskless Employee Problem Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) For both cases, write the SQL to list the empno's of employees without desks (don’t use subqueries) DeskEmployee assigned to

16 © Ellis Cohen Desks deskno height width depth Emps empno ename deskno Desks deskno height width depth empno Emps empno ename Deskless Employees SELECT empno FROM Emps WHERE deskno IS NULL SELECT empno FROM Desks NATURAL RIGHT JOIN Emps WHERE deskno IS NULL SELECT empno FROM Emps EXCEPT SELECT empno FROM Desks Pattern of queries may drive the choice of which mapping to use Oracle uses MINUS instead of EXCEPT

17 © Ellis Cohen Two Way Mapping ? Desks deskno height width depth empno Emps empno ename deskno DeskEmployee assigned to Would it ever make sense to represent a 1:1 relationship with references in both directions?

18 © Ellis Cohen Two Way Mapping Issues Desks deskno height width depth empno Emps empno ename deskno Pro: Allows more queries to be done without joins or collection operations Con: Adds redundancy and overhead Is there any way to allow cheaper queries without foreign keys in both directions?

19 © Ellis Cohen Desks deskno height width depth Emps empno ename deskno Desks deskno height width depth empno Emps empno ename hasDesk Alternative to Two Way Mapping SELECT empno FROM Emps WHERE deskno IS NULL SELECT empno FROM Emps WHERE hasDesk = 'FALSE' Still redundant, but cheaper to enforce

20 © Ellis Cohen Combine the Tables ? Why else is this design questionable? Wasted Space, Performance, Maintainability, Abstraction 40694… … … 81107… … empno ename deskno height width depth Desk not assigned to an employee Employee not assigned to a desk Neither empno nor deskno ALONE can be candidate keys, since both of them can be null. Also, most DBs will not allow even part of a primary key to be NULL!

21 © Ellis Cohen Bridge Table Representation Desk Employee assigned to deskno height width depth Desks 40694… 15129… 30276… 81107… 60019… empno … Emps deskno empno Assignments Used INFREQUENTLY for sparse relationships Can choose either key Assignments empno deskno Desks deskno height width depth Emps empno ename p.s. Good for sparse 1:M too!

22 © Ellis Cohen Mapping 1:1 Relationships One-way Reference –Direction generally picked based on # of NULLs Mandatory participation pattern of queries Two-way Reference –Arguable example of trading off cost of managing redundancy for increased query performance (but only do at end of design process after performance analysis) Combined Table –Generally a bad approach Bridge Table –Useful for 2-way sparse relationships (for both 1:1 and 1:M relationships)

23 © Ellis Cohen Modeling, Transforming & Mapping Parallel Relationships

24 © Ellis Cohen :M/1:1 Parallel Relationships DeptEmployee works for manages What's the best relational schema for this? There are many examples of parallel relationships between entity classes, which may be related to one another. In these cases, the obvious mapping may not necessarily be the best one empno ename deptno dname

25 © Ellis Cohen Combining Parallel Relationships 7369SMITH ALLEN BLAKE JONES20 empno ename deptno Emps deptno dname dmgr Depts works for manages 10ACCOUNTING RESEARCH SALES7698 DeptEmployee works for manages Emps empno ename deptno Depts deptno dname dmgr !

26 © Ellis Cohen Alternative Design 7369SMITH ALLEN BLAKE JONES20 empno ename deptno mdno Emps deptno dname Depts works for manages 10ACCOUNTING 20RESEARCH 30SALES DeptEmployee works for manages Emps empno ename deptno mdno Depts deptno dname But this has more NULLs and requires an assertion to enforce "each dept has a single dept mgr"

27 © Ellis Cohen Boolean Transformation 7369SMITH ALLEN BLAKE JONES20 Emps 7369SMITH ALLEN BLAKE JONES201 Emps empno ename deptno mdnoempno ename deptno isDMgr DeptEmployee works for manages empno ename deptno dname DeptEmployee works for empno ename isDMgr Make this change either in the Conceptual Model or just during Relational Mapping manages

28 © Ellis Cohen Extending Boolean Fields 7369SMITH ALLEN BLAKE JONES201 Emps 7369SMITH20CLERK 7499ALLEN30SALESMAN 7698BLAKE30DEPTMGR 7566JONES20DEPTMGR Emps empno ename deptno isDMgr empno ename deptno job

29 © Ellis Cohen :1 Dependent Relationships

30 © Ellis Cohen :1 Dependent Relationships Note that, when an Employee is deleted, their Benefits Membership should be deleted as well. That is, BenefitsMembership is dependent upon Employee Employee Benefits Membership has Suppose every employee who pays a nominal fee can get a Benefits Membership. But every Benefits Membership is associated with an employee

31 © Ellis Cohen Describing 1:1 Dependent Relationships [Employee:] BenefitsMembership( membid, … ) Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) Identifies a 1:1 dependent relationship Crow Magnum Easy Crow Magnum Employee Benefits Membership has Employee Benefits Membership has empno membid Lifetime Dependency: When an Employee is deleted, their Benefits Membership is deleted as well

32 © Ellis Cohen :M vs 1:1 Dependent Relationships 1:M1:1 Independent Mandatory Dependent Implied by dependent

33 © Ellis Cohen UML 1:1 Dependent Relationships UML Crow Magnum Employee Benefits Membership has empno ename membid paydate level Employee Benefits Membership has 0..1 PK empno ename PK membid paydate level This is the closest UML equivalent, although it implies composition as well as lifetime dependency & mandatory participation, which is not really accurate.

34 © Ellis Cohen Mapping 1:1 Dependent Relationships Emps empno ename BenefitMemberships membid empno ! paydate level Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) Employee Benefits Membership has empno ename membid paydate level BenefitsMembership( membid, empno, paydate, level) empno unique not null references Emps on delete cascade

35 © Ellis Cohen SQL for Dependent 1:1 CREATE TABLE BenefitsMembership( membidnumber(4) primary key, empnonumber(4) unique not null references Emps on delete cascade, paydatedate, levelchar ); Emps empno ename BenefitMemberships membid empno ! paydate level

36 © Ellis Cohen :M Relational Mappings Dept Div deptno divno Dept Div deptno Dept Div deptno divno Depts deptno divno ! Divs divno … Depts deptno divno ! Divs divno … Depts deptno divno Divs divno …

37 © Ellis Cohen :1 Relational Mappings Memb Emp membid empno Memb Emp membid Memb Emp membid empno Membs membid empno ! Emps empno … Membs membid empno ! Emps empno … Membs membid empno Emps empno …

38 © Ellis Cohen :1 Identifying Relationships

39 © Ellis Cohen :1 Relationships and Weak Identity There really is no reason for a Benefits Membership to have its own primary key. It can be uniquely identified by the primary key of its associated Employee It can use weak identity, resulting in a 1-1 identifying relationship Employee Benefits Membership has empno ename membid paydate level

40 © Ellis Cohen :1 Identifying Relationships [Employee:] BenefitsMembership( paydate, level ) Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) Identifies a 1:1 identifying relationship Crow Magnum Easy Crow Magnum Employee Benefits Membership has Employee Benefits Membership has empno paydate level paydate level Identifying: Weak Identity & Lifetime Dependency Instance Discriminator not needed

41 © Ellis Cohen :1 Relationships Independent Mandatory Mandatory Participation Dependent Mandatory Participation Lifetime Dependency Identifying Mandatory Participation Lifetime Dependency Weak Identity

42 © Ellis Cohen :M vs 1:1 Relationships 1:M1:1 Independent Mandatory Dependent Identifying

43 © Ellis Cohen UML 1:1 Identifying Relationships UML Crow Magnum Employee Benefits Membership has 0..1 PK empno ename paydate level Employee Benefits Membership has empno ename paydate level This is the closest UML equivalent, although it implies composition as well as lifetime dependency & mandatory participation, which is not really accurate

44 © Ellis Cohen level paydate Employee Chen 1:1 Identifying Relationships Chen Crow Magnum Employee Benefits Membership has empno ename paydate level Benefits Membership has ename empno

45 © Ellis Cohen Alternate Crow's Foot 1:1 Identifying Relationships Alternate Crow's Foot Crow Magnum Employee Benefits Membership has empno ename paydate level Employee Benefits Membership has In alternate Crow's Foot representations, Ordinary independent relationships are drawn with dashed lines, while continuous lines are only used for identifying relationships

46 © Ellis Cohen Mapping 1:1 Identifying Relationships Employee Benefits Membership has a Emps empno ename BenefitMemberships empno paydate level empno ename paydate level No instance discriminator needed Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) BenefitsMembership( empno, paydate, level) empno references Emps on delete cascade

47 © Ellis Cohen :M Relational Mappings Dept Div deptno divno Dept Div deptno Dept Div deptno Dept Div deptno divno Depts divno deptno Divs divno … Depts deptno divno ! Divs divno … Depts deptno divno ! Divs divno … Depts deptno divno Divs divno …

48 © Ellis Cohen :1 Relational Mappings Memb Emp membid empno Memb Emp membid Memb Emp membid Memb Emp empno Emps empno … Membs membid empno ! Emps empno … Membs membid empno ! Emps empno … Membs membid empno Emps empno … Membs empno

49 © Ellis Cohen Adding Non-Primary Candidate Key Employee Benefits Membership has a Emps empno ename BenefitMemberships empno membid ! paydate level empno ename membid ! {unique} paydate level Visual CONCEPTUAL Model (Crow Magnum) RELATIONAL Model (Relational Schema) Also make unique, but not the PK BenefitsMembership( empno, membid, paydate, level) empno references Emps on delete cascade membid unique not null

50 © Ellis Cohen SQL for Identifying 1:1 CREATE TABLE BenefitsMembership( empnonumber(4) primary key references Emps on delete cascade, membidnumber(4) unique not null, paydatedate, levelchar ); Emps empno ename BenefitMemberships empno membid ! paydate level

51 © Ellis Cohen Optional Composite Domains as Weak Entity Classes Employee empno enamecollegeinfo Employee empno ename College Info name year major 40694… 15129… 30276… 81107… 60019… empno ename Emps 40694……… 30276……… 81107……… empno name year major CollegeInfos Not every Employee has CollegeInfo

52 © Ellis Cohen The "is a" Relationship USPerson Employee is a USPersons ssno name address phone Emps ssno job sal comm The "is a" relationship is better represented using subclasses Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) Could instead use a 1:1 dependent relationship. Then Emps would have its own primary key.

53 © Ellis Cohen "is a" as a Subclass USPerson Employee is a USPerson Employee ssno name address phone job sal comm ssno name address phone job sal comm Subclass representation, with arrow pointing towards the superclass