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 Subclasses These slides are licensed under.

Similar presentations


Presentation on theme: "1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Subclasses These slides are licensed under."— Presentation transcript:

1 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Subclasses 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 Identified Subclasses Multiple & Multi-Level Subclasses Disjoint Subclasses Complete Disjoint Subclasses Subclass Discriminators Subclasses & Relational Integrity Relational Mapping of Subclasses Relationships with Subclasses Relationships with Superclasses Dependent Subclasses Multiple Inheritance Subclassing Relationships

3 3 © Ellis Cohen 2001-2008 Identified Subclasses

4 4 © Ellis Cohen 2001-2008 Identified Subclass Employee Graduate Employee is a Employee Graduate Employee Subclass points to superclass Superclass Generalization Subclass Specialization empno ename collegeName year major empno ename collegeName year major

5 5 © Ellis Cohen 2001-2008 Describing Subclasses Employee Graduate Employee Employee( empno, ename ) <-: GraduateEmployee Employee: GraduateEmployee( collegeName, year, major ) When defining Employee, list all subclasses empno ename collegeName year major Fields relevant to every employee Fields relevant only to Graduate Employees Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) When defining GraduateEmployee, identify its superclass

6 6 © Ellis Cohen 2001-2008 Identified Subclass Instances empno ename collegeName year major 40694… 15129… 30276… 81107… 60019… empno ename Emps 40694……… 30276……… 81107……… empno Name year major GradEmps Employee Graduate Employee college Don't show empno here. That is implied by the superclass relationship

7 7 © Ellis Cohen 2001-2008 Why Use Subclasses? Employee Graduate Employee empno ename collegeName year major Why not just simply use a single class? Employee empno ename collegeName year major

8 8 © Ellis Cohen 2001-2008 Subclass Motivation 40694………… 15129… 30276………… 81107………… 60019… empno ename Name year major Emps college Lots of NULLS! 40694… 15129… 30276… 81107… 60019… empno ename Emps 40694……… 30276……… 81107……… empno Name year major GradEmps college There are many ways to map subclasses; better to defer the decision

9 9 © Ellis Cohen 2001-2008 Superclass/Subclass Mapping for Identified Subclasses empno ename collegeName year major Employee Graduate Employee Emps empno ename GradEmps empno collegeName year major Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) GradEmps( empno, collegeName, year, major) empno references Emps on delete cascade

10 10 © Ellis Cohen 2001-2008 SQL for Identified Subclassing CREATE TABLE GradEmps( empnonumber(4) primary key references Emps on delete cascade, collegeNamevarchar(30), yearnumber(4) majorvarchar(30) ); Emps empno ename GradEmps empno collegeName year major

11 11 © Ellis Cohen 2001-2008 Subclasses UML Chen (variants) Crow Magnum Easy Crow Magnum Graduate Employee Employee Graduate Employee Employee Graduate Employee Employee IS A Employee Graduate Employee Employee

12 12 © Ellis Cohen 2001-2008 Subclass Relationship Problem Person Employee Division ssno name dob divid divnam hiredate What's the corresponding relational schema?

13 13 © Ellis Cohen 2001-2008 Subclass Relationship Mapping Person Employee Division ssno name dob divid divnam hiredate Persons ssno name dob Emps ssno divid ! hiredate Divisions divid divnam Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema)

14 14 © Ellis Cohen 2001-2008 Identified Subclasses with Non-Primary Candidate Key empno ename gradid ! {unique} collegeName year major Employee Graduate Employee Emps empno ename GradEmps empno gradid ! collegeName year major Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) GradEmps( empno, gradid, collegeName, year, major) gradid unique not null empno references Emps on delete cascade

15 15 © Ellis Cohen 2001-2008 SQL for Identified Subclassing with Candidate Key CREATE TABLE GradEmps( empnonumber(4) primary key references Emps on delete cascade, gradidnumber(4) not null unique, collegeNamevarchar(30), yearnumber(4) majorvarchar(30) ); Emps empno ename GradEmps empno gradid ! collegeName year major

16 16 © Ellis Cohen 2001-2008 Multiple & Multi-Level Subclasses

17 17 © Ellis Cohen 2001-2008 Multiple Subclasses Graduate Employee DeptMgr Employee May Overlap An employee can both be a dept manager and a graduate employee Employee( empno, ename ) <-: GraduateEmployee, DeptMgr Employee: GraduateEmployee( collegeName, year, major ) Employee: DeptMgr( yrsManaging, maxEmployees ) Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) Note that each subclass has its own additional attributes Subclasses of Employee empno

18 18 © Ellis Cohen 2001-2008 Mapping Multiple Subclasses Graduate Employee DeptMgr Employee May Overlap An employee can both be a dept manager and a graduate employee Visual Conceptual Model (Crow Magnum) empno Visual Relational Model (Relational Schema) Emps empno ename GradEmps empno collegeName year major DeptMgrs empno yrsManaging maxEmployees

19 19 © Ellis Cohen 2001-2008 Multi-Level Subclasses Graduate Employee DeptMgr Employee UsPerson( ssno, name, dob ) <-: Employee, … UsPerson: Employee( empno, hiredate ) <-: GraduateEmployee, DeptMgr Employee: GraduateEmployee ( collegeName, year, major ) Employee: DeptMgr ( yrsManaging, maxEmployees ) USPerson … empno ! {unique} hiredate ssno name dob yrsManaging maxEmployees collegeName year major Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

20 20 © Ellis Cohen 2001-2008 ssno name dob Mapping Multi-Level Subclasses DeptMgr EmployeeUSPerson … empno ! {unique} hiredate ssno name dob yrsManaging maxEmployees Visual Conceptual Model (Crow Magnum) … Emps ssno empno ! hiredate DeptMgrs ssno yrsManaging maxEmployees Visual Relational Model (Relational Schema) … UsPersons

21 21 © Ellis Cohen 2001-2008 Disjoint Subclasses

22 22 © Ellis Cohen 2001-2008 Disjoint Subclasses Employee DeptMgr Clerk Disjoint No one can be both a dept manager and a clerk Employee( empno, ename ) <-: [ DeptMgr | Clerk ] Employee: DeptMgr( yrsManaging, maxEmployees ) Employee: Clerk( typeSpeed, secSkills ) Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

23 23 © Ellis Cohen 2001-2008 Overlapping vs Disjoint Subclasses Employee DeptMgr Clerk Disjoint No one can be both a dept manager and a clerk Graduate Employee DeptMgr Employee Overlapping An employee can both be a dept manager and a graduate employee Crow Magnum

24 24 © Ellis Cohen 2001-2008 Overlapping Subclasses in UML Employee DeptMgr Graduate Employee UML Graduate Employee DeptMgr Employee UML {overlapping} In UML, the {overlapping} property MUST be explicitly specified to indicate that subclasses may overlap. The {disjoint} property can optionally be used to indicate that they are disjoint, however that's the default if no property is shown Note: UML subclass arrowheads are hollow

25 25 © Ellis Cohen 2001-2008 Visual ER Subclass Constraints Most Visual ER Elements correspond to Conceptual Constraints Dept Employee has 2..5 corresponds to A Dept must have between 2 and 5 Employees Disjointness is a subclass constraint (another kind of conceptual state constraint) Like all conceptual state contraints disjointness must be mapped to a relational state constraint –Check constraint –Uniqueness constraint –Foreign Key constraint –State assertion

26 26 © Ellis Cohen 2001-2008 Disjointedness corresponds to constraint: No employee is in both DeptMgrs and Clerks Corresponding State Assertion NOT EXISTS( SELECT * FROM DeptMgrs NATURAL JOIN Clerks) NOT EXISTS( (SELECT empno FROM DeptMgrs) INTERSECT (SELECT empno FROM Clerks ) ) ( (SELECT empno FROM DeptMgrs) UNION ALL (SELECT empno FROM Clerks) )   (SELECT empno FROM Emps) More generally, if there were n disjoint subclasses, no employee number appears in the empno field of more than one of them Mapping Disjoint Subclasses Emps empno ename Clerks DeptMgrs empno yrsManaging maxEmployees empno typeSpeed secSkills

27 27 © Ellis Cohen 2001-2008 Combined Disjoint & Overlapping Subclasses Employee DeptMgr Clerk Employee( empno, ename ) <-: [ DeptMgr | Clerk ], GraduateEmployee Employee: DeptMgr( yrsManaging, maxEmployees ) Employee: Clerk( typeSpeed, secSkills ) Employee: GraduateEmployee( collegeName, year, major ) GraduateEmployee Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

28 28 © Ellis Cohen 2001-2008 Overlapping Disjoint Groups Employee DeptMgr Clerk Employee( empno, ename ) <-: [ DeptMgr | Clerk ], [ BsOnlyGradEmps, PhDGradEmps ] Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) BsOnlyGradEmps PhDGradEmps

29 29 © Ellis Cohen 2001-2008 Complete Disjoint Subclasses

30 30 © Ellis Cohen 2001-2008 Completeness for Disjoint Subclasses Employee DeptMgr Clerk Employee DeptMgr Staff Complete Every employee is either a dept manager or staff Employee DeptMgr Clerk Incomplete There are other kinds of employees the subclasses completely cover the superclass the subclasses incompletely cover the superclass Indeterminate There may be other kinds of employees

31 31 © Ellis Cohen 2001-2008 Alternate Visual Representation Employee DeptMgr Clerk Employee DeptMgr Staff Complete Every employee is either a dept manager or staff Employee DeptMgr Clerk Incomplete There are other kinds of employees the subclasses completely cover the superclass the subclasses incompletely cover the superclass Indeterminate There may be other kinds of employees

32 32 © Ellis Cohen 2001-2008 Complete Disjoint Subclasses Employee DeptMgr Staff Trainee Employee( empno, ename ) <-: (1) [ DeptMgr | Staff | Trainee ] Employee: DeptMgr( yrsManaging, maxEmployees ) Employee: Staff( … ) Employee: Trainee( … ) Suppose we also distinguish trainees Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

33 33 © Ellis Cohen 2001-2008 Complete Disjoint Constraint: Every employee in Emps is in exactly one of DeptMgrs, Staffers or Trainees (SELECT empno FROM Emps) = (SELECT empno FROM DeptMgrs UNION ALL SELECT empno FROM Staffers UNION ALL SELECT empno FROM Trainees) Mapping Complete Disjoint Subclasses Emps empno ename Staffers empno … DeptMgrs empno yrsManaging maxEmployees Trainees empno …

34 34 © Ellis Cohen 2001-2008 Complete Disjoint Subclasses in UML Employee DeptMgr Staff UML Staff DeptMgr Employee UML {complete}

35 35 © Ellis Cohen 2001-2008 Complete Overlapping Subclasses in UML Employee DeptMgr Graduate Employee UML Graduate Employee DeptMgr Employee UML {complete, overlapping} These are relatively rare and not explicitly supported in Crow Magnum (in this case it implies that only DeptMgrs don't have to be college graduates)

36 36 © Ellis Cohen 2001-2008 Subclass Discriminators

37 37 © Ellis Cohen 2001-2008 Subclass SemiJoins Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) Write the SQL to list the enames of the DeptMgrs Employee DeptMgr Clerk Emps empno ename Clerks DeptMgrs empno yrsManaging maxEmployees empno typeSpeed secSkills

38 38 © Ellis Cohen 2001-2008 Extrinsic Subclassing List the names of the dept managers SELECT ename FROM (Emps NATURAL JOIN DeptMgrs) Extrinsic subclassing To tell whether a class instance is a member of a subclass, look for it in the subclass table A join or subquery is a pretty expensive way to determine this. Perhaps there's a better way? Emps empno ename Clerks DeptMgrs empno yrsManaging maxEmployees empno typeSpeed secSkills SELECT ename FROM Emps WHERE empno IN (SELECT empno FROM DeptMgr)

39 39 © Ellis Cohen 2001-2008 Disjoint Subclass Discriminators Employee DeptMgr Clerk Employee( empno, ename, job ) <-: [ job  DEPTMGR:DeptMgr | CLERK:Clerk ] Employee: DeptMgr( yrsManaging, maxEmployees ) Employee: Clerk( typeSpeed, secSkills ) job DEPTMGR CLERK empno ename job Subclass discriminator Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText)

40 40 © Ellis Cohen 2001-2008 Intrinsic Subclassing Emps empno ename job Clerks empno typingSpeed secSkills DeptMgrs empno yrsManaging maxEmployees List the names of the dept managers SELECT ename FROM Emps WHERE job = 'DEPTMGR' Intrinsic subclassing To tell whether a class instance is a member of a subclass, just look at the value of its subclass discriminator What's the assertion? Subclass discriminators are STRONGLY recommended with disjoint subclasses

41 41 © Ellis Cohen 2001-2008 Intrinsic Subclassing Assertion Emps empno ename job Clerks empno typingSpeed secSkills DeptMgrs empno yrsManaging maxEmployees (SELECT empno FROM Emps WHERE job = 'DEPTMGR') = (SELECT empno FROM DeptMgrs) AND (SELECT empno FROM Emps WHERE job = 'CLERK') = (SELECT empno FROM Clerks)

42 42 © Ellis Cohen 2001-2008 Changing Discriminator Values Employee DeptMgr Clerk job DEPTMGR CLERK empno ename job What are the implications of a job change? Suppose an employee who was a Clerk now become a Dept Mgr?

43 43 © Ellis Cohen 2001-2008 Changing Subclasses Emps empno ename job Clerks empno typingSpeed secSkills DeptMgrs empno yrsManaging maxEmployees Unlike many OO programming languages, the subclass of an database instance can be changed. Changing an employee's job from Clerk to DeptMgr will additionally require deleting the tuple from the Clerks table and inserting a tuple in the DeptMgrs table. The yrsManaging & maxEmployees attributes would either need to be provided or set to default values

44 44 © Ellis Cohen 2001-2008 Subclasses & Relational Integrity

45 45 © Ellis Cohen 2001-2008 Subclasses without Attributes Employee DeptMgr Staff Trainee job empno ename job DEPTMGR TRAINEE yrsManaging maxEmployees evaldate else

46 46 © Ellis Cohen 2001-2008 Superclass/Subclass Instances 40694320 1512922250 30276512 empno yrsManaging maxEmployees DeptMgrs 81107 60019 81222 empno Staffers 719248-27-01 387652-15-02 912556-12-01 Trainees empno evaldate 40694BLAKEDEPTMGR 15129SONIDEPTMGR 30276CHUDEPTMGR 81107DESDECLERK 60019OTOANALYST 81222AHMADENGINEER 71924PLAUCHTRAINEE 38765SOTOTRAINEE 91255LEVITRAINEE empno ename job Emps If there were no Staffers table, how would you find the employees who are Staffers?

47 47 © Ellis Cohen 2001-2008 Finding Staffers Emps empno ename job Staffers empno DeptMgrs empno yrsManaging maxEmployees Trainees empno evaldate Is there a reason to have a Staffers table at all? Because Emps has a job attribute, the Staffers table is not needed to determine which employees are Staffers SELECT ename FROM Emps WHERE job NOT IN ( 'DEPTMGR', 'TRAINEE' )

48 48 © Ellis Cohen 2001-2008 Relationships & Subclasses Employee DeptMgr Staff Trainee job empno ename job DEPTMGR TRAINEE yrsManaging maxEmployees evaldate else Toy Consider how this would be represented if there were no table corresponding to the Staff class toyid owns

49 49 © Ellis Cohen 2001-2008 Superclass/Subclass Mapping Emps empno ename job Staffers empno DeptMgrs empno yrsManaging maxEmployees Trainees empno evaldate Toys toyid empno If we eliminate Staffers, then empno in Toys can only reference Emps, not Staffers. This only ensures that toys are owned by employees, but not specifically limited to Staffers

50 50 © Ellis Cohen 2001-2008 Relational Mapping of Subclasses

51 51 © Ellis Cohen 2001-2008 Relational Mapping Approaches 1.Superclass/Subclass Separate table for each superclass and subclass 2.Superclass-Only Table for superclass only 3.Subclass-Only Tables for subclasses only Various combinations of these are also possible

52 52 © Ellis Cohen 2001-2008 Mapping Example Employee DeptMgr Staff Trainee job empno ename job DEPTMGR TRAINEE yrsManaging maxEmployees evaldate else

53 53 © Ellis Cohen 2001-2008 Superclass/Subclass Mapping Emps empno ename job Staffers empno DeptMgrs empno yrsManaging maxEmployees Trainees empno evaldate Entity Class Mapping Employee map to Emps DeptMgr map to DeptMgrs, with empno references Emps Staff map to Staffers, with empno references Emps Trainee map to Trainees with empno references Emps

54 54 © Ellis Cohen 2001-2008 Superclass-only Mapping Emps empno ename job evaldate yrsManaging maxEmployees Entity Class Mapping Employee map to Emps DeptMgr map via superclass to Emps Staff map via superclass to Emps Trainee map via superclass to Emps You could also map just some subclasses to the superclass' table, and use separate tables for other subclasses Attributes of all subclasses are placed in the table mapped from the superclass

55 55 © Ellis Cohen 2001-2008 Superclass-Only Instances 40694BLAKEDEPTMGR320 15129SONIDEPTMGR22250 30276CHUDEPTMGR512 81107DESDECLERK 60019OTOANALYST 81222AHMADENGINEER 71924PLAUCHTRAINEE8-27-01 38765SOTOTRAINEE2-15-02 91255LEVITRAINEE6-12-01 yrs max empno ename job evaldate Managing Employees Emps Main problem: Too many NULLs 1. What if the subclasses incompletely cover Employee? 2. What if the subclasses overlap?

56 56 © Ellis Cohen 2001-2008 Partial Superclass-only Mapping Emps empno ename job evaldate Entity Class Mapping Employee map to Emps DeptMgr map to DeptMgrs with empno references Emps Staff map via superclass to Emps Trainee map via superclass to Emps DeptMgrs empno yrsManaging maxEmployees All employees are represented in the Emps tables. Attributes specific to Trainees are also placed in Emps, but not attributes specific to DeptMgrs

57 57 © Ellis Cohen 2001-2008 Subclass-Only Mapping Staffers empno ename job DeptMgrs empno ename yrsManaging maxEmployees Trainees empno ename evaldate Entity Class Mapping Employee map via subclasses to DeptMgrs, Staffers, Trainees DeptMgr map to DeptMgrs Staff map to Staffers Trainee map to Trainees The superclass attributes are moved to each subclass. Why does only Staffers need a job attribute? You could also just use subclass-only mappings for some subclasses, while the remaining employees still have entries in a superclass or superclass-only table

58 58 © Ellis Cohen 2001-2008 Subclass-Only Instances 40694BLAKE320 15129SONI22250 30276CHU512 empno ename yrsManaging maxEmployees DeptMgrs 81107DESDECLERK 60019OTOANALYST 81222AHMADENGINEER empno ename job Staffers 71924PLAUCH8-27-01 38765SOTO2-15-02 91255LEVI6-12-01 Trainees empno ename evaldate What is the impact if … 1. The subclasses are disjoint, but are an incomplete cover of Employee? 2. The subclasses overlap? How do you get the empno's and enames of all employees? Why use this mapping?

59 59 © Ellis Cohen 2001-2008 Using Union with Subclasses SELECT empno, ename FROM DeptMgrs UNION ALL SELECT empno, ename FROM Staffers UNION ALL SELECT empno, ename FROM Trainees ORDER BY empno Get the empno's and enames of all employees Suppose you also wanted to list the job of each employee? Because the subclasses are disjoint, use UNION ALL, which is more efficient that UNION

60 60 © Ellis Cohen 2001-2008 Using Union with Subclasses SELECT empno, ename, 'DEPTMGR' AS job FROM DeptMgrs UNION ALL SELECT empno, ename, job FROM Staffers UNION ALL SELECT empno, ename, 'TRAINEE' AS job FROM Trainees ORDER BY empno Get the empno's and enames of all employees

61 61 © Ellis Cohen 2001-2008 Mixed Mapping Emps empno ename job evaldate Entity Class Mapping Employee For DeptMgrs, map via subclasses to DeptMgrs otherwise map to Emps DeptMgr map to DeptMgrs Staff map via superclass to Emps Trainee map via superclass to Emps DeptMgrs empno ename yrsManaging maxEmployees All employees except DeptMgrs are represented in the Emps tables. Attributes specific to Trainees are also placed in Emps. The DeptMgrs table contains all info about DeptMgrs, including both their Employee and DeptMgr attributes

62 62 © Ellis Cohen 2001-2008 Relationships with Subclasses

63 63 © Ellis Cohen 2001-2008 Subclass Relationships Problem Medical Plan enrolled in Player Dental Plan enrolled in playid name medinfo dentinfo What's the relational schema resulting from a superclass-subclass mapping subclass-only mapping superclass-only mapping [do in this order] Health Plan plantyp MEDICAL DENTAL planid planame plantyp

64 64 © Ellis Cohen 2001-2008 playid name mplan dplan planid planame plantyp Superclass/Subclass Mapping Entity Class Mapping Player mapped to Players Health Plan mapped to Plans Medical Plan mapped to MedPlans, planid references Plans Dental Plan mapped to DentPlans, planid references Plans Plans Players planid medinfo planid dentinfo MedPlans DentPlans Relationship Mapping MedEnrollment In Players, add mplan references MedPlans DentEnrollment In Players, add dplan references DentPlans

65 65 © Ellis Cohen 2001-2008 playid name mplan dplan Subclass-Only Mapping Players planid planame medinfo planid planame dentinfo MedPlans DentPlans Relationship Mapping MedEnrollment In Players, add mplan references MedPlans DentEnrollment In Players, add dplan references DentPlans Entity Class Mapping Player map to Players Health Plan map via subclasses to MedPlans, DentPlans Medical Plan map to MedPlans Dental Plan map to DeptPlans Why isn't plantyp needed?

66 66 © Ellis Cohen 2001-2008 playid name mplan dplan planid planame plantyp medinfo dentinfo Superclass-only Mapping Plans Players Relationship Mapping MedEnrollment In Players, add mplan references Plans add state assertion … DentEnrollment In Players, add dplan references Plans add state assertion … Entity Class Mapping Player map to Players Health Plan map to Plans Medical Plan map via superclass to Plans Dental Plan map via superclass to Plans What state assertion is needed and why? If medinfo & dentinfo were the same type, could just have a single info attribute, but then info should have been an attribute of HealthPlan in the ER diagram!

67 67 © Ellis Cohen 2001-2008 playid name mplan dplan planid planame plantyp medinfo dentinfo Superclass-only Assertion Plans Players Assertions are needed to ensure that mplan only refers to Medical Plans and that dplan only refers to Dental Plans (SELECT plantyp FROM (Players JOIN Plans ON mplan = planid)) ALL = 'MEDICAL' (SELECT plantyp FROM (Players JOIN Plans ON dplan = planid)) ALL = 'DENTAL'

68 68 © Ellis Cohen 2001-2008 Relationships with Superclasses

69 69 © Ellis Cohen 2001-2008 Conceptual Mapping Alternatives Let's explore the impact of having Player directly related to the superclass rather than to the subclasses

70 70 © Ellis Cohen 2001-2008 Subclasses with Superclass Relationships PlayerHealth Plan enrolled in Medical Plan Dental Plan plantyp MEDICAL DENTAL playid name planid planame plantyp medinfo dentinfo What's the relational schema resulting from a superclass-only mapping superclass / subclass mapping subclass-only mapping [do in this order] 0..2

71 71 © Ellis Cohen 2001-2008 playid name planid playid Superclass-Only Mapping Entity Class Mapping Player map to Players Health Plan map to Plans Medical Plan map via superclass to Plans Dental Plan map via superclass to Plans Plans planid planame plantyp medino dentinfo Players Relationship Mapping Enrollment Map to PlayerPlans with playid references Players planid references Plans PlayerPlans However, using a bridge table is overkill if a Player can have at most two plans

72 72 © Ellis Cohen 2001-2008 Better Superclass-Only Mapping Plans planid planame plantyp medino dentinfo Players playid name plan1 plan2 Relationship Mapping Enrollment map by Multiple Foreign Keys: add plan1, plan2 to Players, references Plans Entity Class Mapping Player map to Players Health Plan map to Plans Medical Plan map via superclass to Plans Dental Plan map via superclass to Plans

73 73 © Ellis Cohen 2001-2008 Using a Combination Table Plans planid planame plantyp medino dentinfo Players playid name planpairid Relationship Mapping Enrollment map to combination table PlanPairs( planpairid ) with Multiple Foreign Keys: plan1, plan2, references Plans in Players, add planpairid references PlanPairs PlayerPlans planpairid plan1 plan2 Combination tables cause more joins, but can save space if there are few plans and many players Entity Class Mapping Player map to Players Health Plan map to Plans Medical Plan map via superclass to Plans Dental Plan map via superclass to Plans

74 74 © Ellis Cohen 2001-2008 planid medinfo planid dentinfo Superclass/Subclass Mapping Plans planid planame plantyp MedPlans DentPlans Players playid name plan1 plan2 Relationship Mapping Enrollment map by Multiple Foreign Keys: add plan1, plan2 to Players, references Plans Entity Class Mapping Player map to Players Health Plan map to Plans Medical Plan map to MedPlans, with planid references Plans Dental Plan map to DeptPlans, with planid references Plans

75 75 © Ellis Cohen 2001-2008 playid name plan1 plan2 Constrained Subclass-Only Mapping MedPlans planid planame medinfo DentPlans planid planame dentinfo Players ONLY With the conceptual state constraint: A player has at most one Medical Plan & at most one Dental Plan Relationship Mapping Enrollment add plan1 to Players, references MedPlans add plan2 to Players, references DentPlans Entity Class Mapping Player map to Players Health Plan map via subclasses to MedPlans, DentPlans Medical Plan map to MedPlans Dental Plan map to DeptPlans What if that constraint is not added?

76 76 © Ellis Cohen 2001-2008 playid name plan1 plan2 Subclass-Only Tables MedPlans planid planame medinfo DentPlans planid planame dentinfo Players Without the added constraint, there is no way to use a built-in referential integrity constraint This is a reason NOT to use a subclass-only representation in this kind of situation

77 77 © Ellis Cohen 2001-2008 playid name plan1med plan1dent plan2med plan2dent Alternative with Referential Integrity MedPlans planid planame medinfo DentPlans planid planame dentinfo Players Have two references for plan1; one if it’s a medical plan and one of it's a dental plan. Add a check constraint to ensure that at least one of them is NULL. Same for plan2 check( plan1med IS NULL OR plan1dent IS NULL) check( plan2med IS NULL OR plan2dent IS NULL)

78 78 © Ellis Cohen 2001-2008 Dependent Subclasses

79 79 © Ellis Cohen 2001-2008 Dependent Subclass Employee Graduate Employee is a Employee Graduate Employee empno ename gradid collegeName year major empno ename gradid collegeName year major Subclass uses its own primary key. Less commonly used

80 80 © Ellis Cohen 2001-2008 Identified & Dependent Subclasses Employee Graduate Employee is a Employee Graduate Employee empno ename gradid collegeName year major empno ename gradid collegeName year major Employee Graduate Employee is a Employee Graduate Employee empno ename gradid collegeName year major empno ename gradid collegeName year major Identified SubclassDependent Subclass The subclass notation is strongly preferred

81 81 © Ellis Cohen 2001-2008 Superclass/Subclass Mapping for Dependent Subclasses empno ename gradid collegeName year major Employee Graduate Employee Emps empno ename GradEmps gradid empno ! collegeName year major Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) GradEmps( gradid, empno, collegeName, year, major) empno unique not null references Emps on delete cascade Subclass uses its own primary key. Less commonly used

82 82 © Ellis Cohen 2001-2008 SQL for Dependent Subclass CREATE TABLE GradEmps( gradidnumber(4) primary key, empnonumber(4) unique not null references Emps on delete cascade, collegeNamevarchar(30), yearnumber(4) majorvarchar(30) ); Emps empno ename gradid empno ! collegeName year major

83 83 © Ellis Cohen 2001-2008 Subclass Relational Schema GradEmp Emp gradidempno GradEmps gradid empno ! Emps empno … GradEmp Emp gradidempno is a Emps empno … GradEmp Emp empno GradEmp Emp empno is a GradEmps empno gradid ! gradid ! {unique}

84 84 © Ellis Cohen 2001-2008 Reverse Engineering Problem Persons ssno name dob Emps empno divid ! ssno ! hiredate Divisions divid divnam What's the corresponding Crow Magnum Diagram?

85 85 © Ellis Cohen 2001-2008 Using a 1-1 Dependent Relationship Person Employee Division ssno name dob divid divnam empno hiredate Visual Conceptual Model (Crow Magnum) Persons ssno name dob Emps empno divid ! ssno ! hiredate Divisions divid divnam Visual Relational Model (Relational Schema) But what kind of relationship is this?

86 86 © Ellis Cohen 2001-2008 Using a Dependent Subclass Person Employee Division ssno name dob divid divnam empno hiredate Person Employee Division ssno name dob divid divnam empno hiredate is a

87 87 © Ellis Cohen 2001-2008 Multi-Level Dependent Subclasses Graduate Employee DeptMgr Employee USPerson( ssno, name, dob ) <-: Employee, … USPerson:Employee( empno, hiredate) <-: GraduateEmployee, DeptMgr Employee: GraduateEmployee( collegeName, year, major ) Employee: DeptMgr( yrsManaging, maxEmployees ) USPerson … empno hiredate ssno name dob yrsManaging maxEmployees collegeName year major Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) What's the corresponding relational schema?

88 88 © Ellis Cohen 2001-2008 empno ssno ! hiredate ssno name dob Mapping Multi-Level Dependent Subclasses DeptMgr EmployeeUSPerson … empno hiredate ssno name dob yrsManaging maxEmployees Visual Conceptual Model (Crow Magnum) … Emps DeptMgrs empno yrsManaging maxEmployees Visual Relational Model (Relational Schema) … USPersons

89 89 © Ellis Cohen 2001-2008 Dependent Superclass Relationship Employee DeptMgr Staff Trainee job empno ename job DEPTMGR TRAINEE mgrid yrsManaging maxEmployees trainid evaldate else staffid Equipment equipid descr assigned to What's the relational model if you use a subclass-only mapping for Employee?

90 90 © Ellis Cohen 2001-2008 Using Superclass Key Staffers staffid empno ! ename job DeptMgrs mgrid empno ! ename yrsManaging maxEmployees Trainees trainid empno ! ename evaldate Equipments equipid descr empno job Can't include a referential integrity constraint, since empno could either be a DeptMgr, a Staffer, or a Trainee job is not required in Equipments table, but can be helpful because empno isn't bound to a single table

91 91 © Ellis Cohen 2001-2008 Using Subclass Keys Staffers staffid empno ! ename job DeptMgrs mgrid empno ! ename yrsManaging maxEmployees Trainees trainid empno ! ename evaldate Equipments equipid descr mgrid staffid trainid job ! job is not required, but makes it possible to write a complicated but useful CHECK constraint What is it?

92 92 © Ellis Cohen 2001-2008 Subclass Keys Check Constraint Equipments equipid descr mgrid staffid trainid job ! CHECK( (job != 'DEPTMGR' OR ((mgrid IS NOT NULL) AND (staffid IS NULL) AND (trainid IS NULL))) AND (job != 'TRAINEE' OR ((trainid IS NOT NULL) AND (staffid IS NULL) AND (mgrid IS NULL))) AND (job IN ('DEPTMGR', 'TRAINEE') OR ((staffid IS NOT NULL) AND (trainid IS NULL) AND (mgrid IS NULL))) )

93 93 © Ellis Cohen 2001-2008 Missing Superclass Key Employee DeptMgr Staff Trainee job ename job DEPTMGR TRAINEE mgrid yrsManaging maxEmployees trainid evaldate else staffid Equipment equipid descr assigned to If all subclasses have their own primary key, there's no need to include a superclass key (e.g. empno) is the ER diagram. What are the implications for each kind of mapping?

94 94 © Ellis Cohen 2001-2008 Weakly Identified Subclasses Person Employee Division ssno name dob divid divnam empno hiredate Though infrequent, a subclass can be identified with respect to some other entity class (not its superclass) Persons ssno name dob Emps divid empno ssno ! hiredate Divisions divid divnam Instance Discriminator

95 95 © Ellis Cohen 2001-2008 Multiple Inheritance

96 96 © Ellis Cohen 2001-2008 Multiple Inheritance SalesOperative Employee Salesman Employee( empno, ename, sal ) <-: Salesman, … SalesOperative( sopid, target ) <-: Salesman, … [Employee & SalesOperative]: Salesman( comm ) Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) empno sopid Multiple Inheritance

97 97 © Ellis Cohen 2001-2008 Superclass/Subclass Mapping 40694… 15129… 30276… 81107… 60019… Emps empno … 3042560000 61692400000 2057850000 8169265000 40111800000 SalesOps sopid target 616915129… 205730276… 816960019… Salesmen sopid empno comm Worst case scenario: sopid's were allocated completely independently of empno's The Salesmen table identifies (some or all) employees who are also sales operatives. Either sopid or empno can be chosen as its primary key. Or: Salesman could even provide its own key!

98 98 © Ellis Cohen 2001-2008 Mapping Multiple Inheritance SalesOperative Employee Salesman Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) sopid target Emps empno sal SalesOps empno sopid ! comm empno sopid empno ! sopid comm sopid target Emps empno sal SalesOps What about Subclass-only or Superclass-only mappings? Salesman

99 99 © Ellis Cohen 2001-2008 Rooted Hierarchies Are Better SalesOperative Employee Salesman USPerson USPerson( ssno, pname ) <-: Employee, SalesOperative USPerson: Employee( empno, sal ) <-: Salesman, … USPerson: SalesOperative( sopid, target ) <-: Salesman, … [Employee & SalesOperative]: Salesman( comm ) Visual Conceptual Model (Crow Magnum) Textual Conceptual Model (Brief ConText) sopid target ssno name empno sal comm

100 100 © Ellis Cohen 2001-2008 Mapping Rooted Hierarchies sopid target SalesOperative Employee Salesman USPerson ssno name empno sal comm USPersons ssno name ssno sopid target Emps ssno empno sal SalesOps ssno comm Salesmen Visual Conceptual Model (Crow Magnum) Visual Relational Model (Relational Schema) Multiple references!

101 101 © Ellis Cohen 2001-2008 Describing Rooted Multiple Inheritance Salesman( ssno, comm ) ssno references Emps on delete cascade references SalesOps on delete cascade Conjunctive Referential Integrity USPersons ssno name ssno sopid target Emps ssno empno sal SalesOps ssno comm Salesmen

102 102 © Ellis Cohen 2001-2008 SQL for Rooted Multiple Inheritance CREATE TABLE Salesmen( ssnochar(9) primary key references Emps on delete cascade references SalesOps on delete cascade, commnumber(9,2) ); USPersons ssno name ssno sopid target Emps ssno empno sal SalesOps ssno comm Salesmen

103 103 © Ellis Cohen 2001-2008 Complex Hierarchies EmployeeSalesman SalesOperative ContractorTelemarketer Person

104 104 © Ellis Cohen 2001-2008 Subclassing Relationships

105 105 © Ellis Cohen 2001-2008 General State Constraint EquipmentResearcher manages permitted to use + State Constraint: If a researcher manages a piece of equipment, then that researcher must also be permitted to use it Crow Magnum

106 106 © Ellis Cohen 2001-2008 General State Constraint in UML EquipmentResearcher manages permitted to use 1 * * * If a researcher manages a piece of equipment, then that researcher must also be permitted to use it UML

107 107 © Ellis Cohen 2001-2008 State Constraints Between Relationships EquipmentResearcher manages permitted to use + State Constraint: Every researcher/equipment link in the Manages relationship must also be in the Permissions relationships Crow Magnum

108 108 © Ellis Cohen 2001-2008 Relationship Subclass EquipmentResearcher manages permitted to use + State Constraint: Every researcher/equipment link in the Manages relationship must also be in the Permissions relationships Crow Magnum

109 109 © Ellis Cohen 2001-2008 UML Relationship Subclass EquipmentResearcher 1 * * * UML manages permitted to use

110 110 © Ellis Cohen 2001-2008 Representing Relationship Subclasses Adding relationship subclass constraint rschid rname Permissions eqpid rschid Equipment eqpid eqpnam mgr ! Researchers rschid rname Permissions eqpid rschid Equipment eqpid eqpnam mgr ! Researchers


Download ppt "1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Subclasses These slides are licensed under."

Similar presentations


Ads by Google