ADVANCED DATABASE CONCEPTS. Mapping EER Conceptual Model and UML Class Diagrams to the Relational Data Model Suzanne W. Dietrich and Susan D. Urban Department of Computer Science and Engineering Arizona State University Tempe, AZ 85287-5406. OUTLINE. Relationships and Associations - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
• 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.
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.
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.
• 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
• 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 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
• 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
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.
• 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)
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.