ADVANCED DATABASE CONCEPTS

1Mapping Object-Oriented Conceptual Models © 2002 by Dietrich and Urban

Mapping EER

Conceptual Model and UML Class Diagramsto the Relational Data Model

Suzanne W. Dietrich and Susan D. UrbanDepartment of Computer Science and Engineering

Arizona State UniversityTempe, AZ 85287-5406

ADVANCED DATABASE CONCEPTS


OUTLINE

• Relationships and Associations • Class Hierarchies

– Creating a table for each class– Creating a table for each subclass– Flattening the hierarchy

• Shared Subclasses• Categories• Interface Classes


RELATIONAL DATA MODELExtensional and Intensional Schema

When mapping to the relational data model, some components of the conceptual model will be explicitly stored in tables while other semantics will be provided by views.

• Extensional Schema: – relations that are explicitly stored

• Intensional Schema: – relations defined as views


RELATIONAL SCHEMA NOTATION

The specification of an extensional schema summarizes a table definition by– Listing the attribute names,– Underlining the candidate keys, and– Listing the additional table constraints

tableName(keyAttribute, attr1, attr2, foreignKeyAttr)foreign key (foreignKeyAttr) reference primaryKeyTable(primaryKeyAttr)

An explicit primary key table constraint is included only when there is more than one candidate key shown.


NAVIGATION OF ASSOCIATIONS

• By default, binary associations can be traversed in both directions in UML.

• 1:N and 1:1 associations can be unidirectional in UML, though (as is the default in EER), and have an alternative mapping approach that does not require creating a separate table for the association.

• M:N associations are inherently bidirectional, since a separate table must be created to represent the association.


NAVIGATION1:N

A(keyOfA, attrOfA, attrA1, attrA2, attrA3, keyOfB, attrOfBA) foreign key (keyOfB) references B(keyOfB), constraint totalParticipationAinBA not null (keyOfB)B(keyOfB, attrOfB)

Include the key from the 1 side of the association and any relationship attribute in the relation on the N side of the association.

UMLEER


NAVIGATION1:1

B(keyOfB, attrOfB, keyOfC) primary key (keyOfB), foreign key (keyOfC) references C(keyOfC), constraint notNullCandidateKey not null (keyOfC), constraint candidateKeyConstraint unique (keyOfC)C(keyOfC, attrOfC)

Include the key on the partial side of the association and any relationship attribute in the table on the total side of the association.

EER UML


N-ARY ASSOCIATIONS

Create a table with the primary key attributes of each class involved in the association and any descriptive attributes of the association itself.

finance(inventoryId, ssn, bankId,loanAmount)foreign key (inventoryId) references car(inventoryId)foreign key (ssn) references person(ssn)foreign key (bankId) references bank(bankId)


WEAK OR QUALIFIED ASSOCIATION

Create a table for the weak class with a composite key that includes the key of the owner class.

A(keyOfA, attrOfA, attrA1, attrA2, attrA3)Weak(keyofA, partialKey, attrOfWk)

UMLEER


RELATIONAL SCHEMA OF GENERIC EXAMPLE


HOLLYWOOD SCHEMA: EER


HOLLYWOOD SCHEMA: UML


CLASS HIERARCHIES

• Create a table for each class.• Create a table for subclasses only, including the attributes

inherited from the superclass.• Flattening the hierarchy: create a single table to represent the

hierarchy with type fields to indicate class membership.

There are alternative strategies for mapping superclass/subclass hierarchies to relations:


MAPPING TERMINOLOGY

Recall that a relational schema consists of the specification of the extensional schema (explicitly stored tables), the intensional schema (view definitions) and integrity constraints. The term relation refers to either a table or a view.Throughout the mapping of classes, the name of a class refers to a relation that describes the attributes of that class. The name of a table that is created to assist with the definition of a class will use a suffix to differentiate it from the relation for the class.


TABLE FOR EACH CLASS

• Create a separate table for each class in the hierarchy.• Include the primary key of the root class in the table for each

subclass (inclusion dependency).• An equijoin must be performed to view all (specialized and

inherited) attributes of a subclass.


TABLE FOR EACH CLASS Example: Extensional Schema

person (ssn, gender, name, isMarriedTo, phone, address)movieProfessionalEDB (ssn, company)foreign key (ssn) references person (ssn)celebrityEDB (ssn, agent, birthDate) foreign key (ssn) references person (ssn)

• The primary key and referential integrity constraints enforce the “isa” constraint.

• The EDB suffix on the movieProfessionalEDB and celebrityEDB tables shown above indicate that these tables, which are part of the Extensional DataBase, store the key and specialized attributes for the subclasses only. A view must be defined to include the inherited attributes from person.


TABLE FOR EACH CLASS Example: Intensional Schema

A view must be provided for each subclass with its inherited attributes:

create view movieProfessional as select p.ssn, p.gender, p.name, p.address,

p.IsMarriedTo, p.phone, m.companyfrom person p, movieProfessionalEDB mwhere p.ssn=m.ssn;

A similar view must be defined for the celebrity subclass.


TABLE FOR EACH CLASSDisjoint Specialization Constraint

// enforce constraintcreate assertion disjointSpecialization check (not exists(select * from person P where

P.ssn in(select M.ssn from movieProfessional M) andP.ssn in (select C.ssn from celebrity C) ) )

// find violationscreate view disjointViolation asselect P.ssnfrom person Pwhere P.ssn in

(select M.ssn from movieProfessional M) andP.ssn in(select C.ssn from celebrity C)


TABLE FOR EACH CLASSTotal Specialization Constraint

// enforce constraintcreate assertion totalSpecialization check (not exists(select * from movieProfessional M where M.ssn not in

(select C.ssn from critic Cunion select A.ssn from agent A) ) )

// find violationscreate view totalViolation asselect M.ssnfrom movieProfessional Mwhere M.ssn not in

(select C.ssn from critic C) andM.ssn not in (select A.ssn from agent A)


TABLE FOR EACH CLASSAttribute-Defined Specialization

// enforce constraintcreate assertion attrDefinedSpecializationcheck (not exists(select * from project P where P.pid in

(select F.pid from filmProject F) andP.type <> ‘F’) orP.type = ‘F’ and P.pid not in (select F.pid from filmProject F) ) )

// find violationscreate view attrDefinedViolation asselect P.pidfrom project Pwhere P.pid in

(select F.pid from filmProject F)

andP.type <> ‘F’)

orP.type = ‘F’ and P.pid not in (select F.pid from filmProject F)


TABLE FOR EACH CLASSSpecialization Constraints Summary


TABLE FOR EACH SUBCLASS

• Create a table for each subclass.• Include inherited attributes from the superclass in the table

for the subclass.• Create a view to represent the superclass.


TABLE FOR EACH SUBCLASS Example

• Extensional SchemafilmProject (pid, title, cost, type, location)modelingProject (pid, description, cost, type, location)

• Intensional Schemacreate view project as

(select pid, cost, type, location from filmProject) union

(select pid, cost, type, location from modelingProject)


TABLE FOR EACH SUBCLASSConstraints

• ISA: The isa constraint is enforced by the intensional schema since the superclass is defined as the union of its subclasses.

Since each class is defined by a relation name in the schema, the specifications for the following specialization constraints do not require modification:

• Disjoint Specialization• Total Specialization• Attribute-defined Specialization


TABLE FOR EACH SUBCLASS Specialization Constraints Summary


FLATTENING THE HIERARCHY

• Create a single table to represent the hierarchy. • Include all attributes of each superclass/subclass in the table. • Include type fields to indicate the (sub)classes to which a

tuple belongs. • If a tuple does not belong to a subclass, then the

corresponding specific attributes of that subclass will have null values.

• Not recommended if there are many specific attributes for the subclasses.


FLATTENING THE HIERARCHYExample: Single Type Indicator

MovieProfessional Hierachy: Critic and Agent Subclasses• Extensional Schema

mpCriticAgentHierarchy (ssn, company, popularity, agentFee,subtype)• Intensional Schema (agent view not shown)

create view movieProfessional asselect H.ssn, H.company,

P.gender, P.name, P.address, P.isMarriedTo, P.phonefrom person P natural join mpCriticAgentHierarchy H;

create view critic asselect M.ssn, M.gender, M.name, M.address, M.isMarriedTo, M.phone M. company, H. popularityfrom movieProfessional M natural join criticAgentHierarchy Hwhere H.subtype = ‘c’;


FLATTENING THE HIERARCHY Example: Multiple Type Indicators

Celebrity Hierachy: MovieStar and Model Subclasses

• Extensional Schema celebrityHierarchy (ssn, birthDate, agentSsn, movieStar, movieType, model, preferences) where the boolean attributes movieStar and model indicate membership of the celebrity in the corresponding subclass.

• Intensional Schema (model view not shown) create view movieStar as select C.ssn, C.gender, C.name, C.address, C.isMarriedTo, C.phone,

C.birthdate, C.agentSsn, E.movieTypefrom celebrity C natural join celebrityEDB Ewhere C.movieStar=‘TRUE’


FLATTENING THE HIERARCHY Example: Attribute-Defined Subclasses

For attribute-defined subclasses, there is no need for an additional type field since there already exists an attribute that defines the type of the subclass.

• Extensional Schema projectHierarchy (pid, location, cost, type, title, description)where type can be either "f" for filmProject or "m" for modelingProject

• Intensional Schema (modelingProject not shown)create view project as

select P.pid, P.location, P.cost, P.typefrom projectHierarchy P;

create view filmProjectselect P.pid, P.location, P.cost, P.type, P.titlefrom projectHierarchy Pwhere P.type = ‘f’;


FLATTENING THE HIERARCHY Constraints

• ISA: The isa constraint is enforced by the intensional schema.

Since each class is defined (either extensionally or intensionally) in the schema, the following constraint specifications already presented can be reused:

• Disjoint Specialization• Total Specialization• Attribute-defined Specialization


FLATTENING THE HIERARCHY Specialization Constraints Summary


SHARED SUBCLASSESIf the superclasses of the shared subclass all have the same key attribute, any of the previous options for superclass/subclass mapping can be used.


SHARED SUBCLASSES starModel Example: Table for each class

• Extensional SchemacelebrityEDB (ssn, birthDate)movieStarEDB (ssn, movieType)modelEDB (ssn, preferences)starModelEDB (ssn)

• Intensional Schema (assuming views for model, movieStar & celebrity) create view starModel as select S.ssn, C.birthdate, MS.movieType, M.preferences from (((starModelEDB S natural join model M)

natural join movieStar MS) natural join celebrity C)


SHARED SUBCLASSES starModel Example: Flattening the hierarchy

• Extensional Schema celebrityHierarchy (ssn, birthDate, movieStar, movieType, model, preferences)

• Intensional Schema create view starModel as select C.ssn, C.birthDate, C.movieType, C.preferences

from celebrityHierarchy Cwhere movieStar = ‘TRUE’ and model = ‘TRUE’


CATEGORIES

• Define a surrogate key attribute. • Define a relation for the category class that includes

the surrogate key. • Each superclass relation must contain the surrogate

key.


CATEGORIES Example: EER


CATEGORIESExample: UML

In UML, the category mapping also applies to XOR Constraints


CATEGORIES Example: Sponsor Mapping

person (ssn, name, phone, gender, address, sponsorCode)company (cid, cname, sponsorCode)modelingProject (pid, description, sponsorCode)sponsor (sponsorCode)

sponsorCode is used as a surrogate key.


CATEGORY CONSTRAINT

// enforce constraintcreate assertion category check (not exists(select * from sponsor S where S.sponsorCode not in

(select P.sponsorCode from person Punion select C.sponsorCode from company C) ) )

// find violationscreate view categoryViolation asselect S.sponsorCodefrom sponsor Swhere S.sponsorCode not in

(select P.sponsorCode from person Punion select C.sponsorCode from company C)


RELATION FOR EACH CLASSTotal Category Constraint

// enforce constraintcreate assertion totalSponsorCategory check (not exists(select * from person P where P.sponsorCode not in

(select S.sponsorCode from sponsor S)

or(select * from company C where C.sponsorCode not in

(select S.sponsorCode from sponsor S)));

// find violationscreate view totalSponsorPersonViolation asselect *from person Pwhere P.sponsorCode not in

(select S.sponsorCode from sponsor S) ;

create view totalSponsorCompanyViolation asselect *from company Cwhere C.sponsorCode not in

(select S.sponsorCode from sponsor S) ;


INTERFACE CLASSES• Since an interface class defines behavior inheritance, a relation is

not required for an interface class.

• Appropriate procedures that implement the operations specified in an interface class should be implemented in the concrete subclasses of an interface class.


ONLINE SHOPPING EER SCHEMA

Documents

ADVANCED DATABASE CONCEPTS