1. 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Conceptual State Constraints 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 Conceptual State Constraints Entity Constraints Representing Entity Constraints Visually Functional Dependencies as Entity Class Constraints Relationship Constraints Mandatory Participation in Other ER Models Optional Participation Optional Participation in Other ER Models Participation & Cardinality More About Relationship Constraints General Conceptual State Constraints The Chasm Trap & Redundancy Factored Relationships

3. 3 © Ellis Cohen 2001-2008 Conceptual State Constraints

4. 4 © Ellis Cohen 2001-2008 Identifying State Constraints Suppose you looked at the state of (i.e. the data in) a database (at some arbitrary time – e.g. 2am), and you said "That's not right" (e.g. a job entry's enddate came before it's startdate) Suppose someone asked why, and you gave a reason (e.g. a job entry's enddate must always be later than its startdate) That reason is an example of a Conceptual State Constraint

5. 5 © Ellis Cohen 2001-2008 Business Rules Business Rules specify/ determine Conceptual Model User Operation Functionality Behavior Constraints & Operation Conditions constraints and conditions on the behavior of user and database operations State Constraints constraints on the state of the data that's allowed to be stored in the database Performance Requirements State Constraints are just part of the business rules of a database application

6. 6 © Ellis Cohen 2001-2008 Specifying State Constraints A state constraint must –characterize a property of the database state which must be invariant – i.e. it must ALWAYS be true –be able to be checked at ANY ARBITRARY TIME (e.g. every night at 2 a.m.) -- not just when a user operation is executed! A business rule which does not specify an invariant property of the database state –cannot be a state constraint –could instead be a behavior constraint, which corresponds to a pre-condition or post-condition and which can only be checked when an operation is executed

7. 7 © Ellis Cohen 2001-2008 Enforcing State Constraints There are two places to enforce state constraints Application Enforcement: Enforce (action-specific) state constraints through code implemented in user actions (in the middle-tier) or stored DB actions (in the data-tier) Database Enforcement: Use built-in database features to automatically enforce state constraints in the data-tier table constraints (check, FK, etc) assertions (not commercially implemented) triggers

8. 8 © Ellis Cohen 2001-2008 Enforcement Approaches How do database applications approach enforcement of state constraints? Constant Monitoring –Whenever an attempt is made to change the database state in a way that would violate a state constraint … prevent/abort/undo the action, try to correct the problem, or immediately notify the DBA Interval-Based –At (regular) intervals (e.g. every night at 2am), check that the system is in a consistent state. If not, correct it, or notify the DBA. Administrative Enforcement –DBA checks DB every so often, or when notified (by users or code) of a potential problem Ignore –Hope that nothing bad happens. If it does, scramble …

9. 9 © Ellis Cohen 2001-2008 Conceptual State Constraints Entity Constraints Constrains the values of a single entity class independent of any relationships Relationship Constraints Specifies how entities in one entity class can/must be related (via a single relationship) to entities of the related class, without considering any other relationships or entity classes. General Conceptual State Constraints Constrains values based on multiple relationships or unrelated entity classes

10. 10 © Ellis Cohen 2001-2008 Entity Constraints

11. 11 © Ellis Cohen 2001-2008 Entity Constraints Constrains the values of a single entity class independent of any relationships Examples: Employee( empno, ename, job, sal, addr ) No employee can live in California No employee has a salary of less than 100 All employees have a name Dept( deptno, dname, loc ) All departments have a name Department names are unique describes a constraint Why not include: All departments have a department number All department numbers are unique

12. 12 © Ellis Cohen 2001-2008 Entity Instance & Class Constraints Entity Constraints are either Entity Instance Constraints –You can tell if it is true by looking at a single entity instance at a time e.g. Every employee's salary is > 400 Entity Class Constraints –You need to consider all the instances of the class (or at least more than one at a time) to determine if it is true e.g. There are no more than 4 employees whose salary is > 3000

13. 13 © Ellis Cohen 2001-2008 Entity Instance Constraints What are some examples of entity instance constraints for the Employee class?

14. 14 © Ellis Cohen 2001-2008 Entity Instance Constraint Examples Every employee must have a name (non-null constraint) Every employee's salary must be greater than 300 Every analyst (i.e. employee whose job is ANALYST) must have a salary greater than 800

15. 15 © Ellis Cohen 2001-2008 Entity Class Constraints What are some examples of entity class constraints for the Employee class?

16. 16 © Ellis Cohen 2001-2008 Entity Class Constraint Examples No two employees can have the same address (uniqueness constraint) There must be at least as many clerks as analysts The average employee salary must be greater than 600

17. 17 © Ellis Cohen 2001-2008 Representing Entity Constraints Visually

18. 18 © Ellis Cohen 2001-2008 Required Constraints Employee empno ssno ename {required} addr Crow Magnum attribute constraints are written in curly brackets; ename {required} means that every employee must have a name The ! is shorthand for the required attribute so ename ! also means that every employee must have an name Entity constraints (other than primary key) can be optionally represented visually in Crow Magnum as well Crow Magnum Employee empno ssno ename ! addr

19. 19 © Ellis Cohen 2001-2008 Uniqueness Constraints Employee empno ssno {unique} ename ! addr The unique constraint is also a standard attribute constraint ssno {unique} means that every employee (who has an ssno attribute) has a unique one – i.e no duplicate ssno's ssno ! {unique} would mean that every employee must have a unique ssno The underlined attribute is a primary key constraint so empno is both required and unique; otherwise it could not uniquely identify instances Entity constraints (other than primary key) can be optionally represented visually in Crow Magnum as well Crow Magnum

20. 20 © Ellis Cohen 2001-2008 Attribute Value Constraints Employee empno ename ! addr sal {sal > 200} Crow Magnum Entity instance constraints on the value of a single attribute (e.g. an employee's salary – if present – must be more than $200) can optionally be shown in Crow Magnum.

21. 21 © Ellis Cohen 2001-2008 Other Entity Constraints Employee empno ssno {unique} ename ! addr job sal Crow Magnum Other entity constraints can optionally be shown as a constraint note placed below or adjacent to the attributes. This is almost always discouraged (since it makes the ER diagram too bulky) + There must be at least as many clerks as analysts + The average salary must be at least $600 This is a constraint note

22. 22 © Ellis Cohen 2001-2008 Entity Constraints in UML In UML, attribute-specific entity constraints – e.g. required and unique, can be written as attribute properties {in curly braces} More complicated constraints can optionally be written in a note, and attached to the entity class Employee PK empno ssno {unique} ename {required} addr job sal There must be at least as many clerks as analysts This is a UML note UML

23. 23 © Ellis Cohen 2001-2008 Functional Dependencies as Entity Class Constraints

24. 24 © Ellis Cohen 2001-2008 Specifying Non-Candidate-Key FD's If we left Employee unnormalized as Employee( empno, ename, addr, deptno, dname) We would have to explicitly state the entity constraint. Employee deptno  dname Why is this an entity constraint, and how would you describe it in plain English?

25. 25 © Ellis Cohen 2001-2008 Entity Constraint Description Employee deptno  dname Example: All employees that have the same value for deptno – e.g. 30, must have the same value for dname – e.g. SALES i.e. All employees whose deptno is 30 must have a dname of SALES + All employees that have the same value for deptno must have the same value for dname

26. 26 © Ellis Cohen 2001-2008 Redundancy & Constraints Main problem of redundancy  It can lead to anomalies Suppose an entity class is un-normalized, but the FD is enforced as a state constraint with constant monitoring – e. g. suppose that in Employee( empno, ename, addr, deptno, dname), the DB actually enforced deptno  dname – i.e. on every action, check whether deptno  dname, and if not, abort/undo it! This would prevent anomalies! HOWEVER, FD's are expensive to constantly enforce, so it is better to do the normalization.

27. 27 © Ellis Cohen 2001-2008 FD's and Conceptual Normalization After splitting Employee into Employee & Dept, what happened to the FD empno  deptno Each employee has (at most) a single department Effect of Simple Conceptual Normalization: Splitting turns that FD constraint into a key constraint! Employee( empno, ename, addr ) Dept( deptno, dname )

28. 28 © Ellis Cohen 2001-2008 FD's and Key Constraints empno  deptno A value of empno determines the corresponding value of deptno Employee determines the Dept Chen Key constraint: The primary key of Employee not only uniquely identifies an employee (and their name & addr), but also uniquely identifies their associated department (its deptno & dname) Employee Dept works for empno Child Entity Class Parent Entity Class Crow Magnum EmployeeDept works for empno deptno

29. 29 © Ellis Cohen 2001-2008 Relationship Constraints

30. 30 © Ellis Cohen 2001-2008 Relating Instances empno ename address empnopno EmployeeProject assigned to 7499ALLEN... 7654MARTIN... 7698BLAKE... 7839KING... 7844TURNER... 7986STERN... 2618… pno pname … 2621… 2622… A relationship indicates that instances of one class are associated with instances of the related class

31. 31 © Ellis Cohen 2001-2008 No Constraints empno ename address 7499ALLEN... 7654MARTIN... 7698BLAKE... 7839KING... 7844TURNER... 7986STERN... 2618… pno pname … 2621… 2622… Without constraints on the relationship, any instances of the two classes can potentially be related to one another A relationship constraint place requirements on which instances can be related, based solely on the attributes of the instances which other instances are related to one another

32. 32 © Ellis Cohen 2001-2008 Relationship Constraints What are some other examples of constraints on this relationship (you can assume other attributes)? + Analysts can only be assigned to projects whose budget is larger than $500000 empno job pno budget EmployeeProject assigned to

33. 33 © Ellis Cohen 2001-2008 Key Constraints Crow Magnum Chen A 1:M relationship already imposes a relationship constraint known as a key constraint: An employee works for at most one department EmployeeDept works for Employee Dept works for empno ename addr deptno dname Child Entity ClassParent Entity Class

34. 34 © Ellis Cohen 2001-2008 Mandatory Participation Constraints Dept Employee works for Child Entity ClassParent Entity Class Crow Magnum Mandatory participation is a stronger relationship constraint: An employee works for exactly one department

35. 35 © Ellis Cohen 2001-2008 Mandatory Participation in Other ER Models

36. 36 © Ellis Cohen 2001-2008 Mandatory Child Participation in Various ER Languages UML Crow Magnum Chen EmployeeDept works for * EmployeeDept works for an Employee must be assigned to 1 Dept Employee Dept works for every Employee participates in a relationship with a Dept 1 Child Entity ClassParent Entity Class

37. 37 © Ellis Cohen 2001-2008 Mandatory Parent Participation in Other ER Languages UML Crow Magnum Chen EmployeeDept works for 1..* EmployeeDept works for a Dept must have at least 1 employee Employee Dept works for every Dept participates in a relationship with employee(s) Child Entity ClassParent Entity Class 0..1

38. 38 © Ellis Cohen 2001-2008 M:N ER Language Problem Crow Magnum EmployeeProject works for What's the equivalent in UML & Chen?

39. 39 © Ellis Cohen 2001-2008 M:N ER Language Solution UML Chen EmployeeProject works for 1..* Employee Project works for 0..* Crow Magnum EmployeeProject works for

40. 40 © Ellis Cohen 2001-2008 1:M ER Language Problem Crow Magnum EmployeeDept works for What's the equivalent in UML & Chen?

41. 41 © Ellis Cohen 2001-2008 1:M ER Language Solution UML Chen EmployeeDept works for 1..* Employee Dept works for 1 Crow Magnum EmployeeDept works for

42. 42 © Ellis Cohen 2001-2008 Mandatory Participation in ConText Dept Employee works for Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) (1..*) Employee works for (1) Dept (1..*) Employee works for (!) Dept Note use of cardinalities

43. 43 © Ellis Cohen 2001-2008 Optional Participation

44. 44 © Ellis Cohen 2001-2008 Indeterminate & Optional Participation Optional: There definitely may be employees who do not work for a dept. Effect is same as Indeterminate. Use only to emphasize the design decision. Dept Employee works for Crow Magnum Dept Employee works for Indeterminate: No decision has been made on participation, so it’s possible that an employee may not work for a dept, Crow Magnum Optional participation is NOT a relationship constraint. It does not further CONSTRAIN which entities may be related to one another. It simply reflects a design decision which sometimes is represented visually

45. 45 © Ellis Cohen 2001-2008 Child Participation Mandatory: An Employee MUST work for 1 Dept Optional: An Employee MAY work for 0 Depts Dept Employee Dept Employee Dept Employee works for Indeterminate Deferred participation design decision Child Entity ClassParent Entity Class Crow Magnum

46. 46 © Ellis Cohen 2001-2008 Optional & Indeterminate Participation Optional: There definitely may be employees who do not work for a dept. Effect is same as Indeterminate. Use only to emphasize the design decision. Dept Employee works for UML EmployeeDept works for * 0..1 Child Entity ClassParent Entity Class UML does not distinguish between Optional & Indeterminate Relationships Crow Magnum Dept Employee works for Indeterminate: No decision has been made on participation, so it’s possible that an employee may not work for a dept, Crow Magnum

47. 47 © Ellis Cohen 2001-2008 Parent Participation Mandatory: MUST be 1 Employee in every Dept Optional: MAY be 0 Employees in a Dept Dept Employee Dept Employee Dept Employee Indeterminate: Deferred participation design decision works for Child Entity ClassParent Entity Class Crow Magnum

48. 48 © Ellis Cohen 2001-2008 Participation Exercise Faculty Member DepartmentProgram Student made up of offers majors in advises Each student must declare a major in exactly one program Every program is associated with a department Some faculty members are not part of a department Every department must offer at least one program Some faculty members have no advisees Show the corresponding mandatory & optional participation symbols Business Rules

49. 49 © Ellis Cohen 2001-2008 Participation Answer Faculty Member DepartmentProgram Student made up of offers majors in advise Each student must declare a major in exactly one program Every program is associated with a department Every department must offer at least one program Some faculty members are not part of a department Some faculty members have no advisees Mandatory participation is a kind of state constraint Optional participation isn't; there's nothing to check!

50. 50 © Ellis Cohen 2001-2008 Optional Participation in Other ER Models

51. 51 © Ellis Cohen 2001-2008 Participation in UML Employee 1..* 0..* Dept 1..1 0..1 Employee Dept Crow Magnum UML In standard DB terminology, these are called cardinalities. UML calls them multiplicities.

52. 52 © Ellis Cohen 2001-2008 UML Cardinality Shortcuts Employee 0..* * Dept 1..1 1 Employee Dept Crow Magnum UML any number exactly 1

53. 53 © Ellis Cohen 2001-2008 Alternate Crow Participation Employee Dept Employee Dept Crow Magnum Alternate Crow Alternate Crow’s Foot Representation uses dashed lines and uses a bar to represent both a minimum and maximum cardinality of 1

54. 54 © Ellis Cohen 2001-2008 Alternate Crow's Foot Example Alternate Crow's Foot Employee Dept has 0..* 0..1 Dept Employee works for Crow Magnum Alternate Crow’s Foot Representation uses dashed lines and uses a bar to represent both a minimum and maximum cardinality of 1

55. 55 © Ellis Cohen 2001-2008 Indeterminate Participation Dept Employee works for Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) (*) Employee works for Dept Note that UML does not distinguish between optional and indeterminate participation No decision has been made about whether participation is mandatory or optional

56. 56 © Ellis Cohen 2001-2008 Optional Participation Dept Employee works for Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) (0..*) Employee works for (0..1) Dept (0..*) Employee works for (?) Dept Note use of cardinalities There definitely may be employees who do not work for a dept, and departments that don’t have employees. This design decision has been emphasized.

57. 57 © Ellis Cohen 2001-2008 Indeterminate & Optional Participation Dept Employee works for Crow Magnum Dept Employee works for Crow Magnum Optional participation is NOT a relationship constraint. It does not further CONSTRAIN which entities may be related to one another. It simply reflects a design decision which sometimes is represented visually In practice, there is little difference between indeterminate and optional participation, and most ER design languages only have one or the other.

58. 58 © Ellis Cohen 2001-2008 Participation & Cardinality

59. 59 © Ellis Cohen 2001-2008 General Cardinalities in Crow Magnum Dept Employee has 3 A Dept must have exactly 3 Employees Dept Employee has 2..5 A Dept must have between 2 and 5 Employees Dept Employee has 2..* A Dept must have at least 2 Employees Dept Employee has 0..4 A Dept may have up to 4 Employees Note: Crow's foot still shown Do NOT show general cardinalities when are adequate themselves

60. 60 © Ellis Cohen 2001-2008 General Cardinalities in ConText Dept Employee has 3 Dept has (3) Employee Dept Employee has 2..5 Dept has (2..5) Employee Dept Employee has 2..* Dept has (2..*) Employee Dept Employee has 0..4 Dept has (0..4) Employee

61. 61 © Ellis Cohen 2001-2008 Cardinality Constraints Many (most) Visual ER notations correspond to Conceptual Constraints Dept Employee has 2..5 corresponds to the relationship constraint (known as a cardinality constraint) A Dept must have between 2 and 5 Employees In general, it is best to represent constraints by built-in visual notations, whenever possible

62. 62 © Ellis Cohen 2001-2008 Splitting/Joining Relationships PlayerHealth Plan enrolled in 0..2 Suppose that there are 2 kinds of health plans a player can optionally enroll in, a medical plan & a dental plan. Which is the better way to model this? Medical Plan enrolled in Player Dental Plan enrolled in

63. 63 © Ellis Cohen 2001-2008 Visual Complexity vs. Explicit Relationship Constraints PlayerHealth Plan enrolled in 0..2 Medical Plan enrolled in Player Dental Plan enrolled in Visually more complex Simpler, but requires adding a relationship constraint + No player can enroll in more than one medical plan or more than one dental plan

64. 64 © Ellis Cohen 2001-2008 More About Relationship Constraints

65. 65 © Ellis Cohen 2001-2008 Special Relationship Constraints ( special notations in Crow Magnum / ConText ) Key Constraints An employees works for at most a single department  (*) Employee works for Dept Mandatory Participation Constraints Every department has at least a single employee  (1..*) Employee works for Dept Cardinality Constraints Every department has 2-5 employees  (2..5) Employee works for Dept

66. 66 © Ellis Cohen 2001-2008 Constraining WorksFor DeptEmployee works for empno ename job sal deptno dname loc What other constraints (other than key, mandatory and cardinality constraints) might we impose on the WorksFor relationship? How else might we constrain how employees can be associated with departments (e.g. based on attributes such as job and loc)? Relationship WorksFor WorksFor: (*) Employee works for Dept

67. 67 © Ellis Cohen 2001-2008 Constraining WorksFor DeptEmployee works for empno ename job sal deptno dname loc Possible additional constraints on WorksFor Every dept must have at least one CLERK Every dept has at most one DEPTMGR All ANALYSTs must work in Philadelphia There are no CLERKs who work for dept 10 There are no PEONs who work for departments located in NEW YORK Every dept that has an ANALYST also has at least one CLERK The average salary of a dept must be greater than 700 No two employees who work in the same location have the same salary

68. 68 © Ellis Cohen 2001-2008 Constraining Reflexive Relationships The Manages relationship identifies which employees manage other employees Because it is 1:M, It imposes the key constraint that an employee MUST not be managed by more than one other employee Employee manages empno job Relationships Manages Manages: Employee manages (*) Employee What other ways might you constrain Manages?

69. 69 © Ellis Cohen 2001-2008 Constraining Manages Employee manages empno job Relationships Manages Manages: Employee manages (*) Employee DeptMgrs are only managed by the President Employees don't manage themselves The are no cycles in the Manages relationship

70. 70 © Ellis Cohen 2001-2008 Other Relationship Constraints in UML Relationship constraints (that can’t be represented directly in UML) can optionally be written in a note, and attached to the relationship UML EmployeeDept works for * 0..1 PK empno ename job PK deptno dname Every dept that has an analyst also has at least one clerk

71. 71 © Ellis Cohen 2001-2008 Other Relationship Constraints in Crow Magnum Relationship constraints (that can’t be directly represented by built-in Crow Magnum notations) can optionally be visually represented as a constraint note. But it's OK if they are only included as separate explicitly specified state constraints + Every dept that has an analyst also has at least one clerk Dept Employee has Crow Magnum

72. 72 © Ellis Cohen 2001-2008 General Conceptual State Constraints

73. 73 © Ellis Cohen 2001-2008 General Conceptual State Constraints Constrains values based on multiple relationships or unrelated entity classes Example: An employee must work for a department at the same location as their direct manager, unless they are managed by the President. (Involves both the WorksFor relationship and the Manages relationship)

74. 74 © Ellis Cohen 2001-2008 General State Constraints in UML (1) General constraints in UML can be written in a note, and optionally attached to all the relationships involved UML EmployeeDept works for * 0..1 PK empno ename job PK deptno dname loc An employee must work for a department at the same location as their direct manager, unless they are managed by the President. 0..1 * manages

75. 75 © Ellis Cohen 2001-2008 General State Constraints in UML (2) General constraints in UML can optionally be attached to the classes involved, or a combination of classes & relationships UML EmployeeDept works for * 0..1 PK empno ename job PK deptno dname loc An employee must work for a department at the same location as direct manager, unless they are managed by the President. 0..1 * manages

76. 76 © Ellis Cohen 2001-2008 General State Constraints in Crow Magnum General state constraints in Crow Magnum can optionally be written as a constraint note + An employee must work for a department at the same location as their direct manager, unless they are managed by the President DeptEmployee works for manages Crow Magnum

77. 77 © Ellis Cohen 2001-2008 Relationship Constraint Exercise Faculty Member DeptProgram Student made up of offers majors in advises 1.Invent 2 good relationship constraints which are NOT key, participation or cardinality constraints. Identity the relationship they constrain. 2.Invent 2 good general conceptual state constraints. Identify the relationships they constrain. DeptPrograms: Dept offers (*) Program DeptFaculty: Dept made up of (*) FacultyMember Majors: (*) Student majors in Program Advises: FacultyMember advises (*) Student

78. 78 © Ellis Cohen 2001-2008 Relationship/General Conceptual Constraint Answers DeptPrograms Any department with 12 or more faculty members has at least 2 programs Advises No faculty member advises more than 9 students  Every faculty in a department advises the same number of students (plus or minus 1) (involves both DeptFaculty and Advises)  A student is advised by a faculty member in the department whose program the student is majoring in. (involves all 4 of the relationships) Relationship Constraints General State Constraints

79. 79 © Ellis Cohen 2001-2008 The Chasm Trap & Redundancy

80. 80 © Ellis Cohen 2001-2008 The Chasm Trap EmployeeDeptDivision works for part of 7698BLAKE 7499ALLEN 7654MARTIN 7986STERN 7844TURNER 10SALES 30ACCOUNTING DIV A DIV B … … Suppose there are employees who are unassigned to a department, but we require the added state constraint that every employee is assigned to a division. How can we change our model so we can find out which division they are in?

81. 81 © Ellis Cohen 2001-2008 Resolve via Added Relationship employed by EmployeeDeptDivision works for part of + If an employee works for a dept that is part of a division, they must also be employed by that division We can resolve the chasm trap by adding a works for relationship directly between Employee and Division. However, this is mostly redundant. When an employee is assigned to a department, you can already find out the division by navigating from the Employee to the Dept and the Dept to the Division. Enforcing the redundancy requires a general state constraint

82. 82 © Ellis Cohen 2001-2008 Relationship Redundancy 7499ALLEN 7654MARTIN 7844TURNER 10SALES DIV A employed by EmployeeDeptDivision works for part of

83. 83 © Ellis Cohen 2001-2008 Specialized Relationship Instances 7499ALLEN 7654MARTIN 7844TURNER 10SALES DIV A only works for EmployeeDeptDivision works for part of

84. 84 © Ellis Cohen 2001-2008 Specialized Relationship Redundancy only works for The "only works for" relationship keeps track of the division associated with an employee only for those employees not assigned to a department! Also redundant (but less evident) [An employee only works for a division is true ≡ An employee works for a dept is false] Changing one but not the other  update anomaly, so this also requires a general state constraint EmployeeDeptDivision works for part of + If an employee works for a dept that is part of a division, they must not only work for the division

85. 85 © Ellis Cohen 2001-2008 Resolve via Pseudo Dept 7698BLAKE 7499ALLEN 7654MARTIN 7986STERN 7844TURNER 10SALES 30ACCOUNTING DIV A DIV B … … 91 UNASSIGNED A EmployeeDeptDivision works for part of Add a "pseudo-dept" (per division) to represent employees not assigned to a department in that division 92 UNASSIGNED B

86. 86 © Ellis Cohen 2001-2008 Redundancy & Participation Health PlanTeamPlayer uses employed by enrolled in Is this relationship redundant? Suppose a team only allows players to choose a single health plan

87. 87 © Ellis Cohen 2001-2008 The Participation Trap Health PlanTeamPlayer uses employed by enrolled in This relationship is only redundant if every player MUST enroll in a health plan. But in the diagram above, that's not true! The added relationship doesn't tell us new information about which health plan the player joined (it must be the team's plan). But it does indicate whether or not the player enrolled Suppose a team only allows players to choose a single health plan Is there a way to track whether the player enrolled in the team's health plan without adding a relationship?

88. 88 © Ellis Cohen 2001-2008 Using Boolean Attributes Health PlanTeamPlayer uses employed by If a player has enrolled in a health plan, it must be the team's health plan. The only thing left to determine is whether the player actually enrolled or not. This can be represented by adding a boolean attribute (e.g. hasEnrolled) to Player Suppose a team only allows players to choose a single health plan playerid hasEnrolled... teamid planid Note: some databases don't support boolean attributes. Instead use a varchar with values 'TRUE' and 'FALSE' or a char with values 'T' or 'F' or an int with values 0 and 1

89. 89 © Ellis Cohen 2001-2008 Redundancy & Consistency DivisionDeptEmployee part of works for employed by Is this relationship redundant?

90. 90 © Ellis Cohen 2001-2008 The Consistency Trap DivisionDeptEmployee part of works for employed by Suppose an employee can be employed by one division, but (perhaps temporarily) work for a department in a different division If so, then employed by is not redundant. It is only redundant if the state constraint shown is added! + An employee may only work for a department that is part of the division that employs them

91. 91 © Ellis Cohen 2001-2008 Truly Redundant Relationships DivisionDeptEmployee part of works for employed by Suppose employed by is truly redundant. Should we show it? No. The only reason to show the redundancy is to suggest that a similar redundancy should be included in the relational model, which would enable speedier queries at the possible cost of update anomalies (e.g. if an employee is moved from a dept in one division to a dept in another division) or enforcing the state constraint that would prevent them In this class, we will generally avoid including truly redundant relationships

92. 92 © Ellis Cohen 2001-2008 Independent vs. Redundant Parallel Inter-Relationships DivisionDeptEmployee part of works for employed by Possibly Redundant DivisionDeptEmployee part of works for was initially hired into Independent

93. 93 © Ellis Cohen 2001-2008 Factored Relationships

94. 94 © Ellis Cohen 2001-2008 Factoring Constraint Coach Team Player works for employs coaches + A coach only coaches players who are employed by the team that the coach works for Without adding the general state constraint, the coach could possibly coach a player on a different team. Although this can be represented as a general state constraint, it can also be represented by factoring the coaches relationship by Team

95. 95 © Ellis Cohen 2001-2008 Factored Relationship Coach Team Player works for employs coaches (by Team) A factorable relationship (e.g. coaches) is one between two classes (e.g. Coach and Player) that both have a 1:M relationship with a common parent or ancestor (e.g. Team) Factoring that relationship specifies that two instances can be related (e.g. a coach and a player) only if they have the same parent/ancestor (i.e. the same team) Coaches Coaches: (*) Coach coaches (*) Player (by Team) common parent

96. 96 © Ellis Cohen 2001-2008 Qualified Factored Relationship Coach Team Player works for employs coaches (by Team via employs) If there is more than one path from Coach or Player to the common ancestor, Team, then use via to specify which path should be used based on the relationship(s) in the path Coaches Coaches: (*) Coach coaches (*) Player (by Team via Employs) initially hired

97. 97 © Ellis Cohen 2001-2008 Factoring Can Result in a Truly Redundant Relationship Employee Division Dept employs part of divid divnam deptno dname empno ename works for (by Division) If an employee can only work for an department that is part of the division that employs them, Then, the employs relationship is redundant and can be eliminated!