0% found this document useful (0 votes)
4 views

lecture 5,6

Uploaded by

norantharwat58
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

lecture 5,6

Uploaded by

norantharwat58
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 42

Relational Database Design by ER-to-Relational

Mapping & EER Model

Chapter
Person

Biker Camper Runner


Person

Biker Camper Runner


Person

Biker Camper Runner


Person

Biker Camper Runner


Acc_no Date open Balance

Accounts

Service
charge d

Checking Saving Loan

Interest Interest
Payment
Rate Rate
Mapping EER Model Constructs to
Relations
 Step8: Options for Mapping Specialization or Generalization.
 Convert each specialization with m subclasses {S1, S2,….,Sm} and generalized
superclass C, where the attributes of C are {k,a1,…an} and k is the (primary) key, into
relational schemas using one of the four following options:
 Option 8A: Multiple relations-Superclass and subclasses
 Option 8B: Multiple relations-Subclass relations only
 Option 8C: Single relation with one type attribute
 Option 8D: Single relation with multiple type attributes
Mapping EER Model Constructs to Relations

 Option 8A: Multiple relations-Superclass and subclasses


 Create a relation L for C with attributes Attrs(L) = {k,a1,…an} and PK(L) = k.
Create a relation Li for each subclass Si, 1 < i < m, with the attributesAttrs(Li) =
{k} U {attributes of Si} and PK(Li)=k. This option works for any specialization
(total or partial, disjoint of over-lapping).
 Option 8A works for any constraints on the specialization :
Disjoint or overlapping, total or partial

Slide 7- 9
• Option 8B: Multiple relations-Subclass relations only
Create a relation Li for each subclass Si, 1 < i < m, with the attributes Attr(Li) =
{attributes of Si} U {k,a1…,an} and PK(Li) = k. This option only works for a
specialization whose subclasses are total (every entity in the superclass must belong to
(at least) one of the subclasses).
Mapping EER Model Constructs to Relations

• Option 8B works well only when both the disjoint and Overlapping and total
constraints hold
FIGURE 4.4
EER diagram notation for an attribute-defined specialization on
JobType.
FIGURE 7.4
Options for mapping specialization or generalization.
(a) Mapping the EER schema in Figure 4.4 using option 8A.
FIGURE 4.3
Generalization. (b) Generalizing CAR and TRUCK into the superclass VEHICLE.

d
FIGURE 7.4
Options for mapping specialization or generalization.
(b) Mapping the EER schema in Figure 4.3b using option 8B.

Tonnage
Mapping EER Model Constructs to Relations
(contd.)

Option 8C: Single relation with one Option 8D: Single relation with
type attribute multiple type attributes
Create a single relation L with attributes Create a single relation schema L with
Attrs(L) = {k,a1,…an} U {attributes of attributes Attrs(L) = {k,a1,…an} U
S1} U…U {attributes of Sm} U {t} and {attributes of S1} U…U {attributes of
PK(L) = k. The attribute t is called a Sm} U {t1, t2,…,tm} and PK(L) = k.
type (or discriminating) attribute that Each ti, 1 < I < m, is a Boolean type
indicates the subclass to which each attribute indicating whether a tuple
tuple belongs belongs to the subclass Si.
FIGURE 4.4
EER diagram notation for an attribute-defined specialization on JobType.
FIGURE 7.4
Options for mapping specialization or generalization.
(c) Mapping the EER schema in Figure 4.4 using option 8C.
FIGURE 4.5
EER diagram notation for an overlapping (non-disjoint) specialization.

O
FIGURE 7.4
Options for mapping specialization or generalization. (d) Mapping Figure
4.5 using option 8D with Boolean type fields Mflag and Pflag.
Mapping EER Model Constructs
to Relations (contd.)
 Mapping of Shared Subclasses (Multiple Inheritance)
 A shared subclass, such as STUDENT_ASSISTANT, is a subclass of
several classes, indicating multiple inheritance. These classes must all
have the same key attribute; otherwise, the shared subclass would be
modeled as a category.
 We can apply any of the options discussed in Step 8 to a shared subclass,
subject to the restriction discussed in Step 8 of the mapping algorithm.
Below both 8C and 8D are used for the shared class
STUDENT_ASSISTANT.
FIGURE 4.7
A specialization lattice with multiple inheritance for a UNIVERSITY
database.

Option A
Options
c

d
Option
D

Option D
FIGURE 7.5
Mapping the EER specialization lattice in Figure 4.6 using multiple
options.
Mapping EER  Step 9: Mapping of Union Types (Categories).
Model  For mapping a category whose defining superclass

Constructs to
have different keys, it is customary to specify a new
key attribute, called a surrogate key, when creating

Relations
a relation to correspond to the category.
 In the example below we can create a relation
(contd.) OWNER to correspond to the OWNER category and
include any attributes of the category in this relation.
The primary key of the OWNER relation is the
surrogate key, which we called OwnerId.
FIGURE 4.8
Two categories (union
types): OWNER and
REGISTERED_VEHICLE.
Ownerld

FIGURE 7.6
Mapping the EER
categories
(union types) in
Figure 4.7 to
relations.
Summary

Options Constraints for Options


A(Multiple relations for superclass and • Disjoint or Overlapping
subclass) • Completeness(Partial or Total)
B(Multiple relations for subclasses) • Disjoint or Overlapping
• Completeness(Total)

C(single relations with single type • Disjoint


attribute) • Completeness(Partial or Total)

D(single relations with Multiple type • Disjoint or Overlapping(prefer)


attribute) • Completeness(Partial or Total)

You might also like