1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 1: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 http://www.openlineconsult.com/db

2. 2 © Ellis Cohen 2001-2008 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. 3 © Ellis Cohen 2001-2008 1:1 Relationships & Mappings

4. 4 © Ellis Cohen 2001-2008 1: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. 5 © Ellis Cohen 2001-2008 1:1 Relationships EmployeeDesk sits at UML EmployeeDesk sits at Chen 0..1 EmployeeDesk EmployeeDesk Crow Magnum Easy Crow Magnum sits at

6. 6 © Ellis Cohen 2001-2008 Mapping of 1:1 Relationships Suppose some employees don't have desks & some desks don't have employees Desk Employee assigned to 21952936 15129 219628.53630 219729363281107 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. 7 © Ellis Cohen 2001-2008 Alternate 1:1 Mapping Desk Employee assigned to 21952936 219628.53630 2197293632 deskno height width depth Desks 40694… 15129…2195 30276… 81107…2197 60019… 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. 8 © Ellis Cohen 2001-2008 1: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. 9 © Ellis Cohen 2001-2008 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. 10 © Ellis Cohen 2001-2008 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. 11 © Ellis Cohen 2001-2008 Mandatory 1:1 Relationships DeskEmployee assigned to What's the best relational mapping?

12. 12 © Ellis Cohen 2001-2008 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. 13 © Ellis Cohen 2001-2008 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. 14 © Ellis Cohen 2001-2008 1:1 Mappings & Performance

15. 15 © Ellis Cohen 2001-2008 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. 16 © Ellis Cohen 2001-2008 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. 17 © Ellis Cohen 2001-2008 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. 18 © Ellis Cohen 2001-2008 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. 19 © Ellis Cohen 2001-2008 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. 20 © Ellis Cohen 2001-2008 Combine the Tables ? Why else is this design questionable? Wasted Space, Performance, Maintainability, Abstraction 40694…2199295236 15129…2198294830 30276… 81107…21952936 60019…342027.236 219628.53630 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. 21 © Ellis Cohen 2001-2008 Bridge Table Representation Desk Employee assigned to 21952936 219628.53630 2198294830 2199295236 deskno height width depth Desks 40694… 15129… 30276… 81107… 60019… empno … Emps 219581107 219815129 219940694 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. 22 © Ellis Cohen 2001-2008 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. 23 © Ellis Cohen 2001-2008 Modeling, Transforming & Mapping Parallel Relationships

24. 24 © Ellis Cohen 2001-2008 1: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. 25 © Ellis Cohen 2001-2008 Combining Parallel Relationships 7369SMITH20 7499ALLEN30 7698BLAKE30 7566JONES20 empno ename deptno Emps deptno dname dmgr Depts works for manages 10ACCOUNTING7782 20RESEARCH7566 30SALES7698 DeptEmployee works for manages Emps empno ename deptno Depts deptno dname dmgr !

26. 26 © Ellis Cohen 2001-2008 Alternative Design 7369SMITH20 7499ALLEN30 7698BLAKE30 7566JONES20 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. 27 © Ellis Cohen 2001-2008 Boolean Transformation 7369SMITH20 7499ALLEN30 7698BLAKE30 7566JONES20 Emps 7369SMITH200 7499ALLEN300 7698BLAKE301 7566JONES201 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. 28 © Ellis Cohen 2001-2008 Extending Boolean Fields 7369SMITH200 7499ALLEN300 7698BLAKE301 7566JONES201 Emps 7369SMITH20CLERK 7499ALLEN30SALESMAN 7698BLAKE30DEPTMGR 7566JONES20DEPTMGR Emps empno ename deptno isDMgr empno ename deptno job

29. 29 © Ellis Cohen 2001-2008 1:1 Dependent Relationships

30. 30 © Ellis Cohen 2001-2008 1: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. 31 © Ellis Cohen 2001-2008 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. 32 © Ellis Cohen 2001-2008 1:M vs 1:1 Dependent Relationships 1:M1:1 Independent Mandatory Dependent Implied by dependent

33. 33 © Ellis Cohen 2001-2008 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. 34 © Ellis Cohen 2001-2008 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. 35 © Ellis Cohen 2001-2008 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. 36 © Ellis Cohen 2001-2008 1: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. 37 © Ellis Cohen 2001-2008 1: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. 38 © Ellis Cohen 2001-2008 1:1 Identifying Relationships

39. 39 © Ellis Cohen 2001-2008 1: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. 40 © Ellis Cohen 2001-2008 1: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. 41 © Ellis Cohen 2001-2008 1:1 Relationships Independent Mandatory Mandatory Participation Dependent Mandatory Participation Lifetime Dependency Identifying Mandatory Participation Lifetime Dependency Weak Identity

42. 42 © Ellis Cohen 2001-2008 1:M vs 1:1 Relationships 1:M1:1 Independent Mandatory Dependent Identifying

43. 43 © Ellis Cohen 2001-2008 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. 44 © Ellis Cohen 2001-2008 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. 45 © Ellis Cohen 2001-2008 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 1..1 0..1

46. 46 © Ellis Cohen 2001-2008 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. 47 © Ellis Cohen 2001-2008 1: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. 48 © Ellis Cohen 2001-2008 1: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. 49 © Ellis Cohen 2001-2008 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. 50 © Ellis Cohen 2001-2008 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. 51 © Ellis Cohen 2001-2008 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. 52 © Ellis Cohen 2001-2008 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. 53 © Ellis Cohen 2001-2008 "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