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

2 © Ellis Cohen Overview of Lecture Relational Models and Mappings Adding Constraints & Surrogate Keys During Mapping Mapping Participation & Cardinality Constraints Mapping Conceptual to Relational State Constraints Conceptual Domains Composite Attribute Domains Entity Class Upgrades & Downgrades

3 © Ellis Cohen Relational Models and Mappings

4 © Ellis Cohen Models and Mapping A conceptual model abstractly represents the database design, deferring until later the details of how it is to be represented A relational model concretely represents the details of the database design, including the relations (tables) and their attributes A relational mapping describes how the conceptual model is to be mapped to the relational model

5 © Ellis Cohen Why Formalize Relational Mapping Optimally, you would like to use a system that –Supports design and ongoing maintenance of your conceptual model –Supports specification of how your conceptual model is to be mapped to a relational model –Automatically chooses (or suggests) mappings (possibly monitoring system performance to adjust its choices/recommendations) Note: This is hard for conceptual constraints. It would require a more formal language for conceptual constraints (e.g. OCL or OQL), or a really good natural language front end. –Automatically compiles the relational model from the conceptual model + relational mapping This is where MDA (Model-driven Architecture) is driving system design, so it's important to pay attention to formalizing Relational Mapping

6 © Ellis Cohen Relational Mapping Dept works for Emps empno ename addr sal deptno mgr Depts deptno dname daddr Visual CONCEPTUAL Model Visual RELATIONAL Model Employee manages Entity Class Mapping Employee  Emps Dept  Depts Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Depts Relational Mapping empno ename addr sal deptno dname daddr

7 © Ellis Cohen Relational Mapping Process Conceptual Model Relational Model Entity Classes Relationships Entity Class Mapping Relationship Mapping Attribute Specifications Relational Mapping Relations (i.e. Tables)

8 © Ellis Cohen Adding Attribute Specifications CREATE TABLE Depts( deptnonumber(3) primary key, dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30), addrvarchar(80), salnumber(11,2), deptnonumber(3) references Depts, mgrnumber(4) references Emps ) Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emps.sal: number(11,2) Tables & non-FK attributes result from Entity Class mapping (w optional specification of attribute renaming) Foreign key attributes result from Relationship mapping Data types result from Attribute Specifications Data types of FK attributes derive from the attributes they reference. Can be overridden in Attribute Specifications

9 © Ellis Cohen Complete Relational Mapping Entity Class Mapping Employee  Emps Dept  Depts Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emps.ename: varchar(30) Emps.sal: number(11,2) List together to emphasize that we want all addresses to have the same format

10 © Ellis Cohen Database Design Process Requirements Physical Model Relational Model Conceptual Model Conceptual Design & Conceptual Normalization Relational Mapping & Relational Normalization Physical Mapping

11 © Ellis Cohen Physical Modeling The Physical Model is also expressed in SQL Contains all details of the relational model Also, CREATE TABLE specifies physical placement & organization details, e.g. Whether the tuples or a table are unordered, or whether they are kept on disk in some order Whether all the tuples are kept together on the same disk, or partitioned onto different disks (can lead to efficient parallel query implementation) In addition, CREATE INDEX, can be used to associate indices with tables for performance

12 © Ellis Cohen Adding Constraints & Surrogate Keys During Mapping

13 © Ellis Cohen Column & Table Constraints There are two sources for column and table constraints in the relational model Conceptual Model –Based on entity and mandatory child participation constraints Relational Mapping –New constraints are added during relational mapping, reflecting decisions deferred during conceptual design

14 © Ellis Cohen Adding Constraints During Mapping Entity Class Mapping Dept  Depts, check(deptno > 100 OR daddr IS NOT NULL) Employee  Emps Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) unique not null Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emp.ename: varchar(30) Emps.sal: number(11,2) check(sal > 200) Column constraints added here Table constraints added here

15 © Ellis Cohen Resulting Relational Model CREATE TABLE Depts( deptnonumber(3) primary key, dnamevarchar(20) unique not null, daddrvarchar(80), check(deptno > 100 OR daddr IS NOT NULL) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30), addrvarchar(80), salnumber(11,2) check(sal > 200), deptnonumber(3) references Depts, mgrnumber(4) references Emps) Emps empno ename addr sal deptno mgr Depts deptno dname ! daddr

16 © Ellis Cohen Adding Surrogate Key During Mapping Entity Class Mapping Dept  Depts, check(deptno > 100 OR daddr IS NOT NULL) Employee  Emps add primary key empid Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) not null unique Depts.daddr, Emps.addr: varchar(80) Emps.empid: number(4) Emps.empno: number(4) Emp.ename: varchar(30) Emps.sal: number(11,2) check(sal > 200)

17 © Ellis Cohen Added Surrogate Key CREATE TABLE Depts( deptnonumber(3) primary key, dnamevarchar(20) unique not null, daddrvarchar(80), check(deptno > 100 OR daddr IS NOT NULL) ) CREATE TABLE Emps( empidnumber(4) primary key, empnonumber(4) unique not null, enamevarchar(30), addrvarchar(80), salnumber(11,2) check(sal > 200), deptnonumber(3) references Depts, mgrnumber(4) references Emps) Emps empid empno ! ename ! addr sal deptno mgr Depts deptno dname ! daddr No longer the primary key, but still unique & not null

18 © Ellis Cohen Mapping Participation & Cardinality Constraints

19 © Ellis Cohen Mapping Visual Constraints Many Visual ER Elements correspond to Conceptual State Constraints Dept Employee has 2..5 corresponds to A Dept must have between 2 and 5 Employees All Conceptual State Constraints, whether visual or textual must be mapped to Relational State Constraints –Check constraints –Uniqueness constraints –Foreign Key constraints –State assertions

20 © Ellis Cohen Optional Child Participation An employee may be in 0 Depts, so an employee's deptno can be null 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename address deptno 7499ALLEN MARTIN… SLUMBO… 7839KING… TURNER… STERN…50 Emps Dept Employee works for Optional: An employee MAY work for a Dept (Looks like a 0: The Employee may be in 0 Depts) Child Entity ClassParent Entity Class Not a constraint!

21 © Ellis Cohen Mandatory Child Participation Dept Employee works for Emps … deptnonumber(3) not null references Depts … Mandatory: An employee MUST work for a Dept CONCEPTUAL Model RELATIONAL Model Relationship Mapping WorksFor  Emps.deptno not null references Depts

22 © Ellis Cohen Mapping Child Participation Entity Class Mapping Dept  Depts Employee  Emps Relationship Mapping WorksFor  Emps.deptno not null references Depts Manages  Emps.mgr references Emps Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emps.ename: varchar(30) Emps.sal: number(11,2)

23 © Ellis Cohen Resulting Relational Model CREATE TABLE Depts( deptnonumber(3) primary key, dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30), addrvarchar(80), salnumber(11,2), deptnonumber(3) not null references Depts, mgrnumber(4) references Emps) Emps empno ename addr sal deptno ! mgr Depts deptno dname daddr

24 © Ellis Cohen Optional Parent Participation A Dept may have 0 employees, so dept's deptno need not appear in Emps.deptno 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts Dept Employee works for Optional: MAY be an Employee in a Dept (Looks like a 0: The Dept may have 0 Employees) 7499ALLEN MARTIN… BLAKE… KUNG… TURNER… STERN…50 Emps empno ename address deptno Not a constraint!

25 © Ellis Cohen Mandatory Parent Participation STATE ASSERTIONS DeptEmps: (SELECT count(DISTINCT deptno) FROM Emps) = (SELECT count(*) FROM Depts) Mandatory: There MUST be an Employee in every Dept CONCEPTUAL Model Dept Employee works for RELATIONAL Model Relationship Mapping WorksFor  Emps.depno references Depts, state assertion DeptEmps

26 © Ellis Cohen Mapping Parent Participation Entity Class Mapping Dept  Depts Employee  Emps Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps, state assertion DeptEmps Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emps.ename: varchar(30) Emps.sal: number(11,2)

27 © Ellis Cohen Relational Model w Assertion CREATE TABLE Depts( deptnonumber(3) primary key, dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30), addrvarchar(80), salnumber(11,2), deptnonumber(3) references Depts, mgrnumber(4) references Emps) CREATE ASSERTION DeptEmps CHECK( (SELECT count(DISTINCT deptno) FROM Emps) = (SELECT count(*) FROM Depts) ) Emps empno ename addr sal deptno mgr Depts deptno dname daddr

28 © Ellis Cohen Cardinality Constraints STATE ASSERTIONS DeptEmpsC: (SELECT deptno FROM Emps GROUP BY deptno WHERE depno IS NOT NULL HAVING count(*) BETWEEN 2 AND 5) = (SELECT deptno FROM Depts) CONCEPTUAL Model Dept Employee works for RELATIONAL Model Relationship Mapping WorksFor  Emps.depno references Depts, state assertion DeptEmpsC 2..5

29 © Ellis Cohen Mapping Conceptual to Relational State Constraints

30 © Ellis Cohen Conceptual State Constraints Entity Constraints Constrains the values of a single entity class independent of any relationships Relationship Constraints Constrains values based on a single relationship General Conceptual State Constraints Constrains values based on multiple relationships or unrelated entity classes

31 © Ellis Cohen Conceptual Model with Entity Constraints Dept works for Visual CONCEPTUAL Model Employee manages empno ename addr sal deptno dname daddr CONCEPTUAL Entity Class Specifications Dept( deptno, dname, daddr ) deptno is always > 9 Employee( empno, ename, addr, sal ) Every employee has an ename

32 © Ellis Cohen Mapping Entity Constraints Entity Class Mapping Dept  Depts deptno is always > 9  check(deptno > 9) Employee  Emps Every employee has an ename  ename not null Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emps.ename: varchar(30) Emps.sal: number(11,2)

33 © Ellis Cohen After Mapping Entity Constraints CREATE TABLE Depts( deptnonumber(3) primary key check(deptno > 9), dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30) not null, addrvarchar(80), salnumber(11,2), deptnonumber(3) references Depts, mgrnumber(4) references Emps ) Emps empno ename ! addr sal deptno mgr Depts deptno dname daddr

34 © Ellis Cohen Conceptual Model with Relationship Constraints Dept works for Visual CONCEPTUAL Model Employee manages empno ename addr sal deptno dname daddr CONCEPTUAL Relationship Specifications WorksFor: (*) Employee works for (?) Dept Every department has a clerk Manages: (?) Employee manages (*) Employee No employee can be their own manager

35 © Ellis Cohen Mapping Relationship Constraints Entity Class Mapping Dept  Depts Employee  Emps Relationship Mapping WorksFor  Emps.deptno references Depts Every department has a clerk  state assertion DeptClerks Manages  Emps.mgr references Emps, No employee can be their own manager  In Emps, check(empno <> mgr) Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emps.ename: varchar(30) Emps.sal: number(11,2)

36 © Ellis Cohen After Mapping Relationship Constraints CREATE TABLE Depts( deptnonumber(3) primary key, dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30), addrvarchar(80), salnumber(11,2), deptnonumber(3) references Depts, mgrnumber(4) references Emps, check(empno <> mgr) STATE ASSERTIONS: DeptClerks: (SELECT DISTINCT deptno FROM Emps WHERE job = 'CLERK') = (SELECT deptno FROM Depts)

37 © Ellis Cohen Conceptual Model with General State Constraints Dept works for Visual CONCEPTUAL Model Employee manages empno ename addr sal deptno dname daddr CONCEPTUAL General State Constraints All managers except for the President work at the same location as the employees they manage

38 © Ellis Cohen Mapping General State Constraints Entity Class Mapping Employee  Emps Dept  Depts Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps General State Constraint Mapping All managers except for the President work at the same location as the employees they manage  state assertion ManageLoc Attribute Specifications Depts.deptno: number(3) Depts.dname: varchar(20) Depts.daddr, Emps.addr: varchar(80) Emps.empno: number(4) Emps.ename: varchar(30) Emps.sal: number(11,2)

39 © Ellis Cohen Relational Mapping Process with Constraints Conceptual Model Relational Model Entity Classes Relationships General State Constraints Entity Mapping Relationship Mapping Attribute Specifications General State Constraint Mapping Relational Mapping Relations (i.e. Tables) State Assertions

40 © Ellis Cohen Conceptual Domains

41 © Ellis Cohen Conceptual Domains During Detailed Conceptual Design, we can identify the conceptual domain of each attribute A conceptual domain abstractly characterizes the domain of values of an attribute, deferring until later the decision about how the attribute will be represented.

42 © Ellis Cohen Using Domain in the Conceptual Model Conceptual Domains Address US Address DeptId Department Id DeptName Department Name EmpId Employee Id Name Person Name Salary Salary Amount Entity Classes Dept deptnoDeptId dnameDeptName daddrAddress Employee empnoEmpId enameName addrAddress salSalary Note: more complex examples will have more reuse of Domains from Conceptual Model

43 © Ellis Cohen Domain Mapping During Relational Mapping, we decide how to map conceptual domains to datatypes & constraints EmpId Non-numericvs. 4 digit numbers vs. 4 digit #'s between 3010 and 9799 Address Specific format vs. varchar

44 © Ellis Cohen Relational Mapping with Domains Entity Class Mapping Employee  Emps Dept  Depts Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps Domain Mapping Deptid: number(3) Deptname: varchar(20) Address: varchar(80) Empid: number(4) Name: varchar(30) Salary: number(11,2) Attribute Specifications are only needed to override names or datatypes, or to override or add column constraints

45 © Ellis Cohen Domain-Mapped Relational Model CREATE TABLE Depts( deptnonumber(3) primary key, dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30), addrvarchar(80), salnumber(11,2), deptnonumber(3) references Depts, mgrnumber(4) references Emps) Emps empno ename addr sal deptno mgr Depts deptno dname daddr

46 © Ellis Cohen Domains & Relational Mapping Conceptual Model Relational Model Entity Classes Relationships Conceptual Domains General State Constraints Entity Class Mapping Relationship Mapping Domain Mapping Attribute Specification General State Constraint Mapping Relational Mapping Relations (i.e. Tables) State Assertions If Conceptual Domains are used, Attribute Specifications may not be needed

47 © Ellis Cohen Conceptual Domain Constraints Conceptual Domains Address US Address DeptId Department Id always higher than 9 DeptName Department Name EmpId Employee Id Name Person Name from Conceptual Model Conceptual Domain specifications can specify constraints in the conceptual model for all attributes of that domain A domain constraint can be used in place of the corresponding entity constraint (especially useful if multiple attributes have the same domain)

48 © Ellis Cohen Relational Mapping with Mapped Domain Constraints Entity Class Mapping Employee  Emps Dept  Depts Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps Domain Mapping Deptid: number(3) always higher than 9  check( Deptid > 9 ) Deptname: varchar(20) Address: varchar(80) Empid: number(4) Name: varchar(30) Salary: number(11,2) Mapped constraints will need to refer to the domain name rather than the actual attribute

49 © Ellis Cohen After Mapping Domain Constraints CREATE TABLE Depts( deptnonumber(3) primary key check(deptno > 9), dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key, enamevarchar(30), addrvarchar(80), salnumber(11,2), deptnonumber(3) references Depts, mgrnumber(4) references Emps ) Check constraint uses actual attribute name deptno rather than domain name Deptid No need to add the check constraint here; automatically enforced because of the foreign key constraint

50 © Ellis Cohen Deferring Constraints to Domain Mapping Conceptual Domains Address US Address DeptId Department Id … from Conceptual Model A new constraint can be associated with a domain during relational mapping Entity Classes Dept deptnoDeptId dnameDeptName daddrAddress Employee empnoEmpId enameName addrAddress Domain Mapping EmpId: number(4) check(Empid > 1000) Name: varchar(30) Address: varchar(80) DeptId: number(3) DeptName: varchar(20) from Relational Mapping

51 © Ellis Cohen Relational Mapping with Added Domain Constraints Entity Class Mapping Employee  Emps Dept  Depts Relationship Mapping WorksFor  Emps.deptno references Depts Manages  Emps.mgr references Emps Domain Mapping Deptid: number(3) always higher than 9  check( Deptid > 9 ) Deptname: varchar(20) Address: varchar(80) Empid: number(4) check( Empid > 1000 ) Name: varchar(30) Salary: number(11,2)

52 © Ellis Cohen After Adding Domain Constraints CREATE TABLE Depts( deptnonumber(3) primary key check(deptno > 9), dnamevarchar(20), daddrvarchar(80) ) CREATE TABLE Emps( empnonumber(4) primary key check(empno > 1000), enamevarchar(30), addrvarchar(80), salnumber(11,2), deptnonumber(3) references Depts, mgrnumber(4) references Emps )

53 © Ellis Cohen Generating Column Constraints Domain- Specific Allows constraint to be written once, even if multiple attributes use the same domain Attribute- Specific Best place if constraint is related to application semantics rather than domain itself. Allows attributes with same domain to have different constraints Included in Conceptual Design Conceptual Domain Specification Entity Constraints Deferred to Relational Mapping Domain Mapping Attribute Specifications

54 © Ellis Cohen Requirements 2.Initial Conceptual Design Identify Entity Classes Identify Relationships 3.Detailed Conceptual Design Identify Attributes & Domains Do Conceptual Normalization Determine Participation & Constraints 4.Relational Mapping Map Entity Classes to Tables Map Domains to Datatypes & Constraints Map Attributes to Columns Map Relationships to Columns, Constraints & Assertions Map Conceptual Constraints (including Participation) to Constraints & Assertions Database Design Methodology

55 © Ellis Cohen Domains in SQL The SQL-92 standard actually allows domains to be defined in SQL, but this is not supported by most commercial databases: CREATE DOMAIN DeptId NUMBER(3) CHECK( DeptId > 9 ) CREATE DOMAIN DeptName VARCHAR(20) CREATE TABLE Depts ( deptno DeptId, dname DeptName ) DOMAINs not supported in most commercial databases

56 © Ellis Cohen Composite Conceptual Domains

57 © Ellis Cohen Composite Conceptual Domains In a Domain Mapping, a conceptual domain can be mapped to a group of distinct attributes Example: Address The Address domain can be mapped to the group of attributes: street city state zip

58 © Ellis Cohen Mapping Composite Conceptual Domains Domain Mapping EmpId: number(4) Name: varchar(30) Address: streetvarchar(40) cityvarchar(20) statechar(2) zipchar(5) DeptId: number(3) DeptName: varchar(20) Entity Classes Employee empnoEmpId enameName addrAddress Dept deptnoDeptId dnameDeptName from Conceptual Modelfrom Relational Mapping

59 © Ellis Cohen Resulting Detailed Relational Model Relations Depts deptnonumber(3) primary key dnamevarchar(20) unique not null Emps empnonumber(4) primary key enamevarchar(30) not null streetvarchar(40) cityvarchar(20) statechar(2) zipchar(5) salnumber(11,2) deptnonumber(3) references Depts mgrnumber(4) references Emps Use attribute specification to choose different attribute names, if desired

60 © Ellis Cohen Multivalued Domains What about domains that represent a collection of values of the same type (each of which may itself be composite) These are called multivalued domains (and the attributes with those domains are called multivalued attributes), and they are allowed in conceptual models (although, except in simple cases, it’s better to avoid them) However, mapping multivalued domains to the relational model is both varied and complicated; we'll deal with it separately later on.

61 © Ellis Cohen Entity Class Upgrades & Downgrades

62 © Ellis Cohen Conceptual Model Transformations: Upgrades & Downgrades Entity Class Upgrade Transformation –Turns a (composite) conceptual domain into a relationship with a separate entity class, or –Turns a group of attributes into a relationship with a separate entity class –Similar to conceptual normalization, but also used to support reusability & extensibility Entity Class Downgrade Transformation –Turns the parent entity class of a 1:M relationship into a (composite) conceptual domain attribute in the child entity class –Used to simplify models by eliminating unneeded reusability & extensibility

63 © Ellis Cohen Upgrading Composite Conceptual Domains Upgrade a composite conceptual domain to an entity class if 1.It might reasonably have been an entity class in the first place 2.It is possible (or perhaps even likely) that multiple tuples of the parent entity class have the same value for the composite conceptual domain attribute 3.In the future, the parent entity class might need to have multiple values of the composite conceptual domain attribute Example: Address 1.Address might reasonably be an entity class anyway 2.Two employees could well have the same address (e.g. roommates) 3.In the future, we might want to allow for an employee having multiple addresses

64 © Ellis Cohen Example Upgrade Transformation DeptEmployee works for manages deptno dname empno enameaddr Dept Employee works for deptno dname empno ename Address resides at What's its primary key? manages If it is common for multiple employees to have the same address

65 © Ellis Cohen Composite Conceptual Domains & Surrogate Primary Keys Address Employee resides at ssno empno ename street city state zip Address Employee resides at ssno empno ename addrno street city state zip vs Define a surrogate primary key Composite primary key

66 © Ellis Cohen Example Downgrade Transformation Separate Address class is overkill Dept Employee works for deptno dname empno ename Address resides at manages DeptEmployee works for manages deptno dname empno enameaddr

67 © Ellis Cohen Upgrade & Downgrade Mappings Do the conceptual transformation as part of relational mapping Maintain the original conceptual model as working documentation Treats upgrades & downgrades as a mapping decision (like the rest of relational mapping) Entity Class Upgrade Mapping: Turns a (composite) conceptual domain or a group of attributes into separate relation Entity Class Downgrade Mapping: Turns the parent entity class of a 1:M relationship into attribute(s) in the relation derived from the child entity class

68 © Ellis Cohen Example Upgrade Mapping Emps empno ename addr deptno mgr Employee manages empno enameaddr Addrs addrno street city state zip Employee.addr upgrade to Addrs, add primary key addrno number(5) from Attribute Specifications

69 © Ellis Cohen Example Downgrade Mapping Emps empno ename street city state zip deptno mgr Address downgrade to domain, remove primary key addrno from Entity Class Mapping addrno street city state zip Dept Employee works for deptno dname empno ename Address resides at manages