15 ER-EER to Relational

1

CS 338: Computer Applications in Business: Databases (Fall 2014)

1992-2014 by Addison Wesley & Pearson Education, Inc., McGraw Hill, Cengage Learning Slides adapted and modified from Fundamentals of Database Systems (5/6) (Elmasri et al.), Database System Concepts (5/6) (Silberschatz et al.), Database Systems (Coronel et al.), Database Systems (4/5) (Connolly et al. ), Database Systems: Complete Book (Garcia-Molina et al.)

CS 338: Computer Applications in Business: Databases

Relational Database Design by ER- and EER-to Relational Mapping

1992-2014 by Addison Wesley & Pearson Education, Inc., McGraw Hill, Cengage Learning Slides adapted and modified from Fundamentals of Database Systems (5/6) (Elmasri et al.), Database System Concepts (5/6) (Silberschatz et al.), Database Systems (Coronel et al.), Database Systems (4/5) (Connolly et al. ), Database Systems: Complete Book (Garcia-Molina et al.) Rice University Data Center

Fall 2014

Chapter 9

Announcements

Midterm 2 is on Nov 12

Assignment 2 is due on Nov 7

Assignment 2 solutions will be posted on Nov 7

Mid-semester Survey

2

2



Relational Database Design Using ER-to-Relational Mapping

Section 9.1

5

Relational Database Design by ER-to-Relational Mapping

In this lecture, we will discuss how to design a relational database schema based on a conceptual schema design We focus on the logical database design or data model mapping step of

database design

We will discuss the procedures to create a relational schema from an ER schema

Seven-step algorithm to convert the basic ER model constructs into relations (additional steps for EER model)

Many computer aided software engineering (CASE) tools are based on the ER or EER models

Use ER or EER diagrams to develop schema graphically and then convert it into a relational database schema in DDL of a specific relational DBMS

6

3



Recall ER

Diagram

7

End Goal: Relational Model

8

4



Mapping ER diagram into relational schema

Question:

Shall we map everything as separate tables?

Query processing will become expensive

Will involve many JOIN operations

Question:

Shall we map everything into one single table?

Too many redundancies

9

Mapping ER diagram into relational schema

Mapping ER Constructs to Relations

Step 1: Mapping of Regular (Strong) Entity Types

Step 2: Mapping of Weak Entity Types

Step 3: Mapping of Binary 1:1 Relation Types

Step 4: Mapping of Binary 1:N Relationship Types.

Step 5: Mapping of Binary M:N Relationship Types.

Step 6: Mapping of Multivalued attributes.

Step 7: Mapping of N-ary Relationship Types.

Why use this procedure?

Avoid having too many unnecessary tables

Avoid having redundancies in tables

More details on normal forms (Chapter 10)

10

5



ER-to-Relational Mapping Algorithm

11

Step 1: Mapping of Regular Entity Types

For each regular (strong) entity type E in the ER schema, create a relation R that includes all the simple attributes of E

Relations created from mapping entity types are sometimes called entity relations because each tuple represents an entity instance

Include only the simple component attributes of a composite attribute (e.g. flatten composite attributes)

May rename some attributes (e.g., Dname), but not needed

Choose one of the key attributes of E as the primary key for R, declare others to be unique

If chosen key of E is a composite, then the set of simple attributes that form it will together form the primary key of R

Ignore derived attributes

ER-to-Relational Mapping Algorithm Example

12

Primary Key (Ssn)

6




13

PRIMARY KEY (Dnumber)

UNIQUE(Dname)

PRIMARY KEY (Pnumber)

UNIQUE(Pname)


14

Step 2: Mapping of Weak Entity Types

For each weak entity type W in the ER schema with owner entity type E, create a relation R and include all simple attributes (or simple components of composite attributes) of W as attributes of R

Include as foreign key attribute(s) of R, the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s)

Primary key of R is the combination of primary key(s) of the owner(s) with partial key of the weak entity type W (if any)

Omit the identifying relationship when subsequently translating (other) relationship types to relation schemas

7




15

EMPLOYEE Ssn

1

PRIMARY KEY(Essn, Dependent_name)

DEPENDENT(Essn) REFERENCES EMPLOYEE(Ssn)

ON DELETE CASCADE

For each binary 1:1 relationship type R, identify the relations S and T that correspond to the entity types participating in R

Apply one of three possible approaches

1. Foreign key approach

Choose one of the relations (lets say S) and include as a foreign key in S the primary key of T (other participating relation)

It is better to choose an entity type with total participation in R in the role of S

Include all the simple attributes of 1:1 relationship type R as attributes of S


16

Step 3: Mapping of Binary 1:1 Relationship Types

8



1. Foreign key approach (contd)


17


Choose participating entity type DEPARTMENT to serve in the role of S (because its participation in the MANAGES relationship type is total (every department has a manager))

For each binary 1:1 relationship type R, identify the relations S and T that correspond to the entity types participating in R

Apply one of three possible approaches

2. Merged relation approach

Merge the two entity types and the relationship into a single relation

Possible if both participations are total

Make one of the primary keys unique instead

3. Cross-reference or relationship relation approach

Set up a third relation R for the purpose of cross-referencing the primary keys of the two relations S and T representing the entity types

The relation R (called a relationship relation or lookup table) will include the primary key attributes of S and T as foreign keys to S and T

The primary key of R will be one of the two foreign keys, and the other foreign key will be a unique key of R


18


9



Apply one of two possible approaches

1. Foreign key approach

Identify relation S that represents participating entity type at N-side of the relationship type

Include as foreign key in S the primary key of the relation T (representing other entity type participating in R)

2. Relationship relation approach

Create a separate relation R whose attributes are the primary keys of S and T (which will also be foreign keys to S and T)

Declare the foreign key attribute for the relation schema corresponding to the participating entity type on the N-side as primary key


19

Step 4: Mapping of Binary 1:N Relationship Types


20

Step 4: Mapping of Binary 1:N Relationship Types

10



For each binary M:N relationship type, create a new relation S

Include primary keys of participating entity types as foreign key attributes in S

Make all these attributes primary key of S

Include any simple attributes of relationship type in S


21

Step 5: Mapping of Binary M:N Relationship Types

For each multivalued attribute A, create new relation R

Add attribute to hold multivalued attribute values

If multivalued attribute is composite, include its simple components

Add attribute(s) for primary key of relation schema for entity type or relationship type to be foreign key for R

Primary key of R is the combination of all its attributes


22

Step 6: Mapping of Multivalued Attributes

11



For each n-ary relationship type R, where n > 2, create a new relation S

Include the primary keys of the relations that represent the participating in the relationship type as foreign key attributes of S

Include any simple attributes of the n-ary relationship type R as attributes of S


23

Step 7: Mapping of N-ary Relationship Types

Correspondence Between ER and Relational Models

24

12



Relational Database Design Using EER-to-Relational Mapping

Section 9.2

25

Mapping EER Model Constructs to Relations

Mapping Specialization or Generalization

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 of shared subclasses

Mapping of union types (categories)

26

13



Mapping EER Model Constructs to Relations Mapping of Specialization or Generalization

Let C denote the (generalized) superclass

Attributes of C are {k, a1, , an} and k is the (primary) key

{S1, S2, , Sm} are the subclasses

Each of these subclasses can have its own local attributes

27

C

S1 S2 Sm

k a1

a2

b1

b2

z1

z2

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 m with

Attrs(Li) = {k} { } and =

This option works for any specialization (total or partial, disjoint or overlapping)


28

Step 8A: Multiple relations Superclass and subclasses

C

S1 S2 Sm

k a1

a2

b1

b2

z1

z2

k a1 a2

L

k z1 z2

Lm

k b1 b2

L1

14




29

Step 8A: Multiple relations Superclass and subclasses

Create a relation Li for each subclass Si, 1 m with

Attrs(Li) = , 1, , and =

This option works for total specialization (e.g. every entity in the superclass must belong to (at least) one of the subclasses)


30

Step 8B: Multiple relations Subclass relations only

C

S1 S2 Sm

k a1

a2

b1

b2

z1

z2

a1 a2 k z1 z2

Lm

a1 a2 k b1 b2

L1

15




31

Step 8B: Multiple relations Subclass relations only

Total specialization

Create a single relation L with Attrs(L) = , 1, , {}

and =

The attribute t is called a single type (called discriminating) attribute whose value indicates the subclass to which each tuple belongs, if any

This option works for disjoint specialization and has the potential of generating many NULL values if many specific attributes exist in the subclasses


32

Step 8C: Single relation with one type attribute (t)

z1 z2 k a1 a2

L

b1 b2 t

16




33

Step 8C: Single relation with one type attribute (t)

Create a single relation L with Attrs(L) = , 1, , 1, , and =

Each ti (called flag) is a Boolean type attribute indicating whether a tuple belongs to subclass Si This option works for overlapping specialization


34

Step 8D: Single relation with multiple type attributes

z1 z2 k a1 a2

L

b1 b2 t1 tm

17




35

Step 8D: Single relation with multiple type attributes

Which Option is Better?

This depends on the application. One has to consider the tradeoffs

Options 8A and 8B too many relations

Called the multiple-relation options

Problems with efficient query processing

Options 8C and 8D Single relation

Called the single-relation options

May lose some of the usefulness of relationships

Can potentially have many NULL values

36

18



A shared subclass (such as ENGINEERING_MANAGER) is a subclass of several superclasses, indicating multiple inheritance

These classes must all have the same key attribute; otherwise, the shared subclass would be modeled as a union type (or category)

Can apply any of the four options discussed in Step 8 to a shared subclass (subject to restrictions total/partial, overlapping/disjoint)

Mapping EER Model Constructs to Relations Mapping of Shared Subclasses

37

Mapping of Shared Subclasses (Multiple Inheritance)


38

STUDENT_ASSISTANT is a shared subclass of the EMPLOYEE and STUDENT entity types

19




39

Option 8A is used for PERSON/{EMPLOYEE,

ALUMUNUS, STUDENT}

Person, Employee, Alumnus, Student

Option 8B is used for PERSON/{EMPLOYEE,

ALUMUNUS, STUDENT}

Employee, Alumnus, Student

Possible Mapping


40

Option 8C is used for EMPLOYEE/{STAFF, FACULTY,

STUDENT_ASSISTANT} by including the type attribute

Employee_type in EMPLOYEE

Option 8D is used for

STUDENT_ASSISTANT/{RESEARCH_ASSISTANT,

TEACHING_ASSISTANT} by including the type attributes

Ra_flag and Ta_flag in EMPLOYEE

Possible Mapping

20




41

o


STUDENT/{GRADUATE_STUDENT,

UNDERGRADUATE_STUDENT} by

including the type attributes Grad_flag

and Undergrad_flag in STUDENT


STUDENT/STUDENT_ASSISTANT by

including the type attribute

Student_assist_flag in STUDENT

Possible Mapping


42

Mapping EER specialization lattice in Figure in slide 37 using multiple options

21



Mapping EER Model Constructs to Relations Mapping of Categories (Union Types)

43

Mapping of Categories (Union Types)

Superclasses can have several keys

If all the superclasses have the same key

Include the key as an attribute of the category

Otherwise

Create a new key attribute called a surrogate key, as the primary key of the union type

Add the surrogate key as a foreign key to every superclass relation of the union type

Recommended: Add an attribute type to the category that identifies particular entity type of the superclasses (e.g. PERSON, BANK, COMPANY)


44


Owner_id is

surrogate key

22




45



46

15 ER-EER to Relational

Documents

Transcript of 15 ER-EER to Relational