Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Relationship Classes & N-ary Relationships.

Similar presentations


Presentation on theme: "1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Relationship Classes & N-ary Relationships."— Presentation transcript:

1 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Relationship Classes & N-ary 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 Relationship Classes Discriminated Relationship Classes 1:M Discriminated Relationships Relationships with Relationship Classes using Link Extensions N-ary Relationships Participation in N-ary Relationships Partial N-ary Relationships Comparing Relationship Models 1:M:N Relationships 1:1:M Relationships 1:1:1 Relationships

3 3 © Ellis Cohen 2001-2008 Relationship Classes

4 4 © Ellis Cohen 2001-2008 Representing 1:1 Relationships Employee Crow Magnum Relationships can optionally use diamonds when you want to emphasize them empno EmployeeDesk sits at empno deskno Crow Magnum Desk deskno Chen Employee Desk sits at

5 5 © Ellis Cohen 2001-2008 Representing 1:M Relationships Employee Crow Magnum Relationships can optionally use diamonds when you want to emphasize them empno EmployeeDept works for empno deptno Crow Magnum Retain the crow's feet! Dept deptno Chen EmployeeDept works for

6 6 © Ellis Cohen 2001-2008 Representing M:N Relationships Employee Crow Magnum Relationships can optionally use diamonds when you want to emphasize them empno EmployeeDept assigned to empno deptno Crow Magnum Retain the crow's feet! Dept deptno Chen Employee Dept assigned to

7 7 © Ellis Cohen 2001-2008 Relationship Attributes assigned to EmployeeProject hrsPerWeek empno pno Relationship Attribute: How many hrs per week is the employee assigned to the project Assignment( hrsPerWeek ): (*) Employee assigned to (*) Project Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

8 8 © Ellis Cohen 2001-2008 Weak Bridge Entity Classes and Relationship Classes EmployeeAssignment assigned via empno ename Project pno pname budget description assigned via Essentially Identical hrsPerWeek assigned to EmployeeProject hrsPerWeek empno ename pno pname budget description

9 9 © Ellis Cohen 2001-2008 M:N Relationship Class Notations EmployeeProject Crow Magnum Easy Crow Magnum EmployeeProject assigned to hrsPerWeek Employee assigned to Project hrsPerWeek Chen Relationship class EmployeeProject * * UML Assignment hrsPerWeek

10 10 © Ellis Cohen 2001-2008 UML Relationship Indicator EmployeeProject * * UML Assignment hrsPerWeek EmployeeProject * * UML Assignment hrsPerWeek UML also allows an optional diamond

11 11 © Ellis Cohen 2001-2008 Mapping M:N with Attributes Asns empno pno hrsPerWeek Projs pno pname budget description Emps empno ename assigned to EmployeeProject hrsPerWeek empno ename pno pname budget description Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema)

12 12 © Ellis Cohen 2001-2008 Attributed M:N Relationships & Bridge Classes w Partial Dependency Asns empno pno hrs Projs pno Emps empno EmpAsn empno Proj pno empno pno hrs Assigns EmpProj hrs + There is at most one assignment for the same employee & project EmpAsn empno Proj pno hrs + An employee with assignments cannot be deleted

13 13 © Ellis Cohen 2001-2008 Mapping 1:M with Attributes Depts deptno dname Emps empno ename deptno importance works for EmployeeDept importance empno ename deptno dname Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) ONLY FOR 1:M Relationships

14 14 © Ellis Cohen 2001-2008 Combining 1:M Relationship Emps 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename … empno deptno importance WorksFor 7499306 7654303 7844301 769810 7986104 Combine Employee Dept works for empnodeptno 7499ALLEN… 7654MARTIN… 7844TURNER… 7212LAVICH… 7698BLAKE… 7986STERN… importance

15 15 © Ellis Cohen 2001-2008 Discriminated Relationship Classes

16 16 © Ellis Cohen 2001-2008 M:N Discriminated Relationships has appointment with PatientDoctor ptno name drno dname specialty datetime length Appointment( datetime, length ): (*) Patient has appointment with (*) Doctor (include in Relationships section) Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) A patient may have more than one appointments with the same doctor. These are discriminated by the date/time of the appontment

17 17 © Ellis Cohen 2001-2008 Discriminated Relationships & Weak Bridge Entity Classes PatientAppointment for datetime length Doctor with ptno name drno dname specialty has appointment with PatientDoctor ptno name drno dname specialty datetime length Essentially Identical

18 18 © Ellis Cohen 2001-2008 Mapping Discriminated Relationships Appts ptno drno datetime length Doctors drno dname specialty Patients ptno name Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) has appointment with PatientDoctor ptno name drno dname specialty datetime length

19 19 © Ellis Cohen 2001-2008 Discriminated M:N Relationships & Bridge Classes Asns empno pno sdate Projs pno Emps empno EmpAsn empno Proj pno empno pno EmpAsn empno Proj pno sdate Assigns EmpProj sdate + There is at most one assignment for the same employee, project & start date

20 20 © Ellis Cohen 2001-2008 Discriminated M:N Relationships & Bridge Classes w Partial Dependency Asns empno pno sdate Projs pno Emps empno EmpAsn empno Proj pno empno pno sdate Assigns EmpProj sdate + There is at most one assignment for the same employee, project & start date EmpAsn empno Proj pno sdate + An employee with assignments cannot be deleted

21 21 © Ellis Cohen 2001-2008 Instance Discrimination & Cardinality PatientAppointment for datetime length Doctor with ptno name drno dname specialty has appointment with PatientDoctor ptno name drno dname specialty datetime length 0..99 A doctor has appointments set up with at most 99 patients. Appointments with the same patient are discriminated by datetime. This cannot be visually represented using a bridge entity class! 0..99 A doctor has at most 99 appointments. OOPS! Not the same! Appointment( datetime, length): (*) Doctor has appointment with (0..99) Patient

22 22 © Ellis Cohen 2001-2008 Relationship Cardinalities PatientAppointment for datetime length Doctor with ptno name drno dname specialty has appointment with PatientDoctor ptno name drno dname specialty datetime length 0..99 A doctor has at most 99 appointments. Use relationship cardinalities to represent this using a relationship class Appointment( datetime, length): (*) Doctor (0..99) has appointment with (*) Patient

23 23 © Ellis Cohen 2001-2008 1:M Discriminated Relationships

24 24 © Ellis Cohen 2001-2008 1:M Discriminated Relationships has appointment with PatientDoctor ptno name drno dname specialty datetime length Appointment( datetime, length ): (*) Patient has appointment with Doctor (include in Relationships section) A patient who only sees one doctor may still have multiple appointments with that doctor. These are discriminated by the date/time of the appointment Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

25 25 © Ellis Cohen 2001-2008 Possible Mapping 1:M Discriminated Relationships PatientDoctor ptno name drno dname specialty datetime length Visual Conceptual Model (Crow Magnum) has appointment with Visual Relational Model (Relational Schema) Almost, but if all a patient's appts are deleted, the connection between the patient and doctor is lost Doctors drno dname specialty Patients ptno name Appts ptno drno datetime length drno doesn't need to be part of primary key since ptno  drno

26 26 © Ellis Cohen 2001-2008 Another Possible Mapping 1:M Discriminated Relationships PatientDoctor ptno name drno dname specialty datetime length Visual Conceptual Model (Crow Magnum) has appointment with Visual Relational Model (Relational Schema) Doctors drno dname specialty Patients ptno drno name ptno datetime length Almost, but doesn't ensure that appt is deleted when doctor is Appts

27 27 © Ellis Cohen 2001-2008 Alternate Conceptual Model Patient ptno name datetime length Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) Appointment Doctors drno dname specialty Patients ptno drno name ptno datetime length Doctor drno dname specialty + Business Rule: When a doctor is deleted, all their patient's appts are deleted Can’t be enforced directly by this relational schema (a separate trigger is needed) Appts

28 28 © Ellis Cohen 2001-2008 Equivalent Factored Model PatientDoctor ptno name drno dname specialty datetime length Appointment has (by Doctor) PatientDoctor ptno name drno dname specialty datetime length has appointment with Equivalent

29 29 © Ellis Cohen 2001-2008 Relational Mapping PatientDoctor ptno name drno dname specialty datetime length Doctors drno dname specialty Patients ptno drno name Appts ptno drno datetime length Appointment has (by Doctor) (SELECT ptno, drno FROM Appts)  (  (SELECT ptno, drno FROM Patients)

30 30 © Ellis Cohen 2001-2008 Modeling the Inclusion Dependency Doctors drno dname specialty Patients ptno drno name Appts ptno drno datetime length (SELECT ptno, drno FROM Appts)  (  (SELECT ptno, drno FROM Patients) Doctors drno dname specialty Patients ptno drno name Appts ptno drno datetime length The factored relationship is modeled by an inclusion constraint based on ptno + drno, which directly enforces the inclusion dependency. This requires declaring ptno + drno in Patients as unique. That may seem unnecessary, since ptno is a PK. However, it forces the DB to maintain an index on ptno + drno, so the foreign key reference can check that every pair of ptno + drno's in Appts is also in Patients. Inclusion Dependency

31 31 © Ellis Cohen 2001-2008 Relationships with Relationship Classes using Link Extensions

32 32 © Ellis Cohen 2001-2008 Agency agencyid Relationships involving Relationship Classes assigned to ContractorProject hrsPerWeek cno … pno … An alternate representation, using relationship classes with link extensions Contractor Project hrsPerWeek cno … pno … Agency agencyid Assignment arranged by

33 33 © Ellis Cohen 2001-2008 Agency agencyid Easy Crow Magnum Relationships assigned to ContractorProject cno … pno … arranged by EmployeeProject Task No link extension needed

34 34 © Ellis Cohen 2001-2008 ConText for Relationship Class Relationships Assignment( hrsPerWeek ): (*) Contractor assigned to (*) Project AgentArrange: (*) Assignment arranged by Agency Agency agencyid assigned to ContractorProject hrsPerWeek cno … pno … arranged by

35 35 © Ellis Cohen 2001-2008 Mandatory Relationship Class Relationships Assignment( hrsPerWeek ): (*) Contractor assigned to (*) Project AgentArrange: (1) Assignment billed using (*) Bill assigned to ContractorProject hrsPerWeek cno … pno … Bill billid billed using

36 36 © Ellis Cohen 2001-2008 Easy Crow Magnum Version EmployeeProject Bill No link extension needed assigned to ContractorProject cno … pno … Bill billid billed using

37 37 © Ellis Cohen 2001-2008 N-ary Relationships

38 38 © Ellis Cohen 2001-2008 N-ary Relationships assigned to EmployeeProject Task hrsPerWeek Diamonds required for n-ary (n > 2) relationships There may be many employees who do the same task on the same project There may be many projects on which the same employee does the same task There may be many tasks done by the same employee on the same project

39 39 © Ellis Cohen 2001-2008 N-ary Relational Schema assigned to Employee Task Asns empno pno taskid hrsPerweek Projs pno pname Emps empno ename Tasks taskid taskname empno ename pno pname taskid taskname Project hrsPerWeek Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema)

40 40 © Ellis Cohen 2001-2008 N-ary Relationship Example Asns empno pno taskid hrsPerWeek 4069440272080 15129402737717 15129402820812 1512940283773 15129402889449 assigned to EmployeeProject Task hrsPerWeek empno pno taskid n-ary composite primary key

41 41 © Ellis Cohen 2001-2008 N-way Bridge Classes assigned to EmployeeProject Task hrsPerWeek EmployeeProject Task Assignment hrsPerWeek empnopno taskid empnopno taskid Equivalent

42 42 © Ellis Cohen 2001-2008 N-ary Relationships: Easy & Textual Models EmployeeProject Task (*) Employee assigned to (*) Project doing (*) Task

43 43 © Ellis Cohen 2001-2008 Chen N-ary Relationship EmployeeProject assigned to hrsPerWeek Chen Task

44 44 © Ellis Cohen 2001-2008 UML N-ary Relationship EmployeeProject * * UML Assignment hrsPerWeek Task *

45 45 © Ellis Cohen 2001-2008 Using n-Ary Relationships In general, I recommend that you do NOT use n-ary relationships. It is almost always better to split them up into relationships with relationship or bridge entity classes

46 46 © Ellis Cohen 2001-2008 Participation in N-ary Relationships

47 47 © Ellis Cohen 2001-2008 N-ary Entity Participation assigned to Employee Project Task hrsPerWeek There may be many tasks done by the same employee on the same project (and there's at least 1) (*) Employee assigned to (*) Project doing (1:*) Task

48 48 © Ellis Cohen 2001-2008 Entity Participation & Assertion (SELECT empno, pno FROM Emps, Projs) = (SELECT DISTINCT empno, pno FROM Asns) Asns empno pno taskid hrsPerweek Projs pno pname Emps empno ename Tasks taskid taskname At least one task is done by each employee working on each project If a bridge class is used instead of an n-ary relationship, there is no way to represent this constraint visually. An explicit conceptual state constraint must be specified.

49 49 © Ellis Cohen 2001-2008 Bridge Classes with Participation EmployeeProject Task Assignment hrsPerWeek empno … pno taskid EmployeeProject Task Assignment hrsPerWeek empno … pno taskid Redundant, and just requires that an assignment have an associated task Implies that every task is done by at least one employee on one project

50 50 © Ellis Cohen 2001-2008 N-ary Bridge/Relationship Participation assigned to EmployeeProject Task hrsPerWeek EmployeeProject Task Assignment hrsPerWeek empnopno taskid empnopno taskid Equivalent

51 51 © Ellis Cohen 2001-2008 N-ary Relationship Participation assigned to EmployeeProject Task hrsPerWeek There may be many tasks done by the same employee on the same project (and each task is done by at LEAST one employee working on a project) (*) Employee assigned to (*) Project doing (*) Task (1:*)

52 52 © Ellis Cohen 2001-2008 Relationship Participation & Assertion (SELECT DISTINCT taskid FROM Asns) = (SELECT taskid FROM Tasks) Asns empno pno taskid hrsPerweek Projs pno pname Emps empno ename Tasks taskid taskname Every task is done by some employee working on some project

53 53 © Ellis Cohen 2001-2008 Partial N-ary Relationships

54 54 © Ellis Cohen 2001-2008 Partial Relationship Exercise assigned to EmployeeProject Task empno pno taskid This keeps track of which tasks are being done by an employee assigned to a project Suppose we also want to keep track of which employees are assigned to a project, even if there are no tasks assigned to them yet How would you represent this? hrsPerWeek

55 55 © Ellis Cohen 2001-2008 Adding Partial Relationship assigned to EmployeeProject Task empno pno taskid hrsPerWeek Redesign this to ensure that a task can be assigned to an employee for a project, only if the employee is already assigned to the project

56 56 © Ellis Cohen 2001-2008 Use Related Relationships Employee Project Project Assignment hrsPerWeek empno pno performing Task taskid Task Assignment What's the corresponding relational schema?

57 57 © Ellis Cohen 2001-2008 Using Link Extensions assigned to EmployeeProject Task hrsPerWeek taskid performing empno pno ProjectAssignment: (*) Employee assigned to (*) Project TaskAssignment( hrsPerWeek ): (*) ProjectAssignment performing (*) Tasks An alternate representation, using relationship classes with link extensions Relationships

58 58 © Ellis Cohen 2001-2008 Related Relationship Schema ProjAsns empno pno startDate Projs pno pname budget description Emps empno ename Asns Tasks taskid taskname empno pno taskid hrsPerWeek This represents the n-ary relationship between Employee, Project & Task This is an added table that allows us to represent the subsidiary relationship between Employee & Project, and provides a place to hold attributes (e.g. startdate) specific to just that relationship

59 59 © Ellis Cohen 2001-2008 Use Dummy Tasks assigned to EmployeeProject Task empno pno taskid hrsPerWeek Asns 4069440272080 15129402737717 15129402820812 1512940283773 15129402900 When an employee is assigned to a project, but doesn’t have a task assigned to them, assign them a dummy task (task 0) instead. Simpler to keep the dummy task there even if a real task is assigned. In either case, there's no built-in check that a task can be assigned to an employee for a project, only if the employee is already assigned to the project empno pno taskid hrsPerWeek

60 60 © Ellis Cohen 2001-2008 Multiple Partial Relationships assigned to EmployeeProject Task empno pno taskid Suppose we also want to keep track of which employees are assigned to a project, even if there are no tasks assigned to them yet keep track of which tasks are needed for each project, even if no employee is assigned to it yet How would you represent this? hrsPerWeek

61 61 © Ellis Cohen 2001-2008 Adding Separate Relationship assigned to EmployeeProject Task hrsPerWeek taskid performing empno pno Project Assignment What's the corresponding relational schema?

62 62 © Ellis Cohen 2001-2008 Schema w Separate Relationships ProjAsns empno pno startDate Projs pno pname budget description Emps empno ename Asns Tasks taskid taskname empno pno taskid hrsPerWeek ProjTasks pno taskid But don't we want to ensure that a pno + taskid can only show up in Asns if it is also in Tasks?

63 63 © Ellis Cohen 2001-2008 With Extra Checking ProjAsns empno pno startDate Projs pno pname budget description Emps empno ename Asns Tasks taskid taskname empno pno taskid hrsPerWeek ProjTasks pno taskid What's the corresponding ER Model?

64 64 © Ellis Cohen 2001-2008 Adding State Constraint assigned to EmployeeProject Task hrsPerWeek taskid performing empno pno Project Assignment + Conceptual State Constraint A task is associated with a project assignment only if the task is also associated with the corresponding project

65 65 © Ellis Cohen 2001-2008 Comparing Relationship Models

66 66 © Ellis Cohen 2001-2008 N-ary Simplification assigned to EmployeeProject Task empno pno taskid Is there a simpler way to model a simple n-ary relationship?

67 67 © Ellis Cohen 2001-2008 Possible Decomposition? EmployeeProject Task works on can do needs

68 68 © Ellis Cohen 2001-2008 Constraint-Based Decomposition EmployeeProject Task works on can do needs The decomposition can be done only if the following state constraint is always true: If an employee works on a project, and an employee can do a task, and the project needs that task then the employee does that task on the project!

69 69 © Ellis Cohen 2001-2008 Decomposition NOT Always Possible empno pno 7499212 7499213 8181213 empno taskid 7499JAVA 7499C# 8181C# pno taskid 212JAVA 212C# 213JAVA 213C# empno pno taskid 7499212JAVA 7499212C# 7499213JAVA 7499213C# 8181213C# (*) Employee works on (*) Project (*) Employee can do (*) Task (*) Project needs (*) Task The decomposed tuples above would be required whether or not employee 7499 does C# on project 213 Such a decomposition is said to be "lossy" – it loses information We will revisit this topic when we discuss 5NF

70 70 © Ellis Cohen 2001-2008 Alternate Specificity Models assigned to EmployeeProject Task hrsPerWeek empnopno taskid assigned to EmployeeProject Task empnopno taskid hrsPerWeek Explain how these differ Draw the Relational Schema

71 71 © Ellis Cohen 2001-2008 Link Extensions & Bridge Classes assigned to EmployerProject empno pno Employer Project empno pno Assignment Task Equivalent taskid hrsPerWeek taskid hrsPerWeek

72 72 © Ellis Cohen 2001-2008 Compare Relational Models Asns empno pno Projs pno … Emps empno … Tasks taskid empno pno hrsPerWeek Asns taskid empno pno hrsPerweek Emps empno ename Tasks taskid … Projs pno pname

73 73 © Ellis Cohen 2001-2008 Generic vs Specific Tasks assigned to EmployeeProject Task hrsPerWeek empnopno taskid assigned to EmployeeProject Task empnopno A task is generic: The same task can be associated with multiple employees/projects A task is specific: A task is associated with a single employee/ project assignment taskid hrsPerWeek

74 74 © Ellis Cohen 2001-2008 1:M:N Relationships

75 75 © Ellis Cohen 2001-2008 1:M:N Relationships There may be many employees who do the same task on the same project There may be many projects on which the same employee does the same task An employee working on a project does at most one task for it assigned to Employee Task empno ename pno pname taskid taskname Project hrsPerWeek

76 76 © Ellis Cohen 2001-2008 1:M:N Relational Example Asns empno pno taskid hrs 40934272400812 4094427240080 15294278137717 15294282400812 1529429240086 assigned to Employee Task empno ename pno pname taskid taskname Project hrsPerWeek composite PK

77 77 © Ellis Cohen 2001-2008 1:M:N Relationships assigned to Employee Task empno ename pno pname taskid taskname Project hrsPerWeek Tasks Asns pno empno hrsPerWeek taskid Projs pno … taskid … Emps empno …

78 78 © Ellis Cohen 2001-2008 1:M Relationship to Weak Bridge Class Employer Project hrsPerWeek empno pno Assignment Task taskid Tasks Asns pno empno hrsPerWeek taskid Projs pno … taskid … Emps empno …

79 79 © Ellis Cohen 2001-2008 1:M Relationship to Relationship Link assigned to EmployeeProject Task hrsPerWeek empnopno taskid Tasks Asns pno empno hrsPerWeek taskid Projs pno … taskid … Emps empno …

80 80 © Ellis Cohen 2001-2008 Equivalent 1:M:N Model assigned to EmployeeProject Task hrsPerWeek empnopno taskid assigned to Employee Task empno pno taskid Project hrsPerWeek Equivalent

81 81 © Ellis Cohen 2001-2008 1:1:M Relationships

82 82 © Ellis Cohen 2001-2008 1:1:M Relationships assigned to TaskEmployee Project An employee may work on the same task for many projects There is at most one employee who does a particular task for a project There is at most one task that an employee does for a project hrsPerWeek

83 83 © Ellis Cohen 2001-2008 Modeling 1:1:M Relationships Asns empno pno taskid hrsPerWeek Asns empno pno taskid hrsPerWeek or That is, Asns have two candidate keys: pno + empno and pno + taskid assigned to TaskEmployee Project Within each project, every employee works on one task i.e. There's a 1-1 relationship between employees and tasks relative to a particular project hrsPerWeek

84 84 © Ellis Cohen 2001-2008 1:1:M Relational Schema Asns empno pno taskid hrsPerWeek Projs pno pname Emps empno ename Tasks taskid taskname Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) assigned to TaskEmployee Project hrsPerWeek

85 85 © Ellis Cohen 2001-2008 Factoring 1:1:M Relationships assigned to TaskEmployee Project Employee Assign Task Task Assign Employee Project has (by Project) done by hrsPerWeek empno ename pno pname taskid taskname

86 86 © Ellis Cohen 2001-2008 Containing 1:1:M Relationships Employee Assign Task Task Assign Employee done by hrsPerWeek Project pno pname empno ename taskid taskname has*

87 87 © Ellis Cohen 2001-2008 1:1:M w Relationships as Constraints TaskProjectEmployee hrsPerWeek assigned to

88 88 © Ellis Cohen 2001-2008 1:1:1 Relationships

89 89 © Ellis Cohen 2001-2008 1:1:1 Relationships There is at most one project for which an employee performs a particular task There is at most one employee who does a particular task for a project There is at most one task that an employee does for a project assigned to TaskEmployee Project hrsPerWeek

90 90 © Ellis Cohen 2001-2008 1:1:1 Relational Example Asns pno taskid empno hrs 2014079120812 201407923770 2014079345717 2024079137712 2024079245712 202407932080 2034079145717 2034079220812 203407933776 assigned to TaskEmployee Project hrsPerWeek Candidate keys are pno + taskid pno + empno taskid + empno

91 91 © Ellis Cohen 2001-2008 1:1:1 Relational Schema Asns empno pno taskid hrsPerWeek Projs pno pname Emps empno ename Tasks taskid taskname Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) assigned to TaskEmployee Project hrsPerWeek

92 92 © Ellis Cohen 2001-2008 1:1:1 w Relationships as Constraints TaskProjectEmployee hrsPerWeek assigned to


Download ppt "1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Relationship Classes & N-ary Relationships."

Similar presentations


Ads by Google