cois 342 - databases · chapter 4 –er-to-relational transformations –adapted from...

COIS 342 - Databases

Chapter V

ER-to-Relational Transformations

Faculty of Computing and Information Technology in Rabigh

Adapted from Elmasri & Navathe

by Dr Samir BOUCETTA

First Semester 2011/2012

Chapter 4 – ER-to-Relational transformations – Adapted from Elmasri/Navathe by Dr Samir BOUCETTA 2

1. Relational Model Concepts

2. Relational Integrity Constraints

3. ER-to-Relational Transformation Algorithm

Step 1: Transformation of Normal Entity Types

Step 2: Transformation of Weak Entity Types

Step 3: Transformation of Binary 1:N Relationship Types.

Step 4: Transformation of Binary 1:1 Relationship Types

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

Step 6: Transformation of Multivalued attributes.

Step 7: Transformation of N-ary Relationship Types.

Chapter IV

ER-to-Relational Transformations


1-/ Relational Model Concepts

A Relation is a mathematical concept based on the

ideas of sets.

The strength of the relational approach to data

management comes from the formal foundation

provided by the theory of relations.

The model was first proposed by Dr Ted . Codd of IBM

company in 1970


1-a/ INFORMAL DEFINITIONS

RELATION: A table of values

– A relation may be considered as a set of rows.

– A relation may alternately be considered as a set of columns.

– Each row represents a fact that corresponds to a real-world entity or relationship.

– Each row has a value of an item or set of items that uniquely identifies that row in the table.

– Sometimes row-ids or sequential numbers are assigned to identify the rows in the table.

– Each column typically is called by its column name or column header or attribute name.


1-b/ FORMAL DEFINITIONS

The Schema of a Relation: R (A1, A2, .....An)

Relation schema R is defined over attributes A1, A2, .....An

For Example - CUSTOMER (Cust-id, Cust-name, Address, PhoneNber)

A tuple is an ordered set of values

Each value is derived from an appropriate domain.

Each row in the CUSTOMER table may be referred to as a

tuple in the table and would consist of four values.

<632895, “Ahmad Sultan", “15, Omar Ibn El-Khattab, SAKAKA", “0501234567">

is a tuple belonging to the CUSTOMER relation.

A relation may be considered as a set of tuples (rows).

Columns in a table are also called attributes of the relation.


1-c/ DEFINITION SUMMARY

Informal Terms Formal Terms

Table Relation

Column Attribute/Domain

Row Tuple

Values in a column Domain

Table Definition Schema of a Relation

Populated Table Extension

Stopped Here 4/10/2011


2-/ Relational Integrity Constraints

Constraints are conditions that must be true on all

valid tuples. There are three main types of constraints:

1. Key constraints

2. Entity integrity constraints

3. Referential integrity constraints


2-a/ Key Constraints

Candidate key of R: A minimal set of attributes that

uniquely identifies each tuple in the relation.

Primary Key of R: A candidate key that is chosen to

uniquely identify each tuple in the relation.

The primary key attributes are underlined.


2-b/ Entity Integrity

Relational Database Schema: A set S of relations that belong to

the same database. S is the name of the database.

S = {R1, R2, ..., Rn}

Entity Integrity: The primary key attributes of each relation R in

S cannot have null values in any tuple of R.

Note: Other attributes of R may be similarly constrained to

disallow null values, even though they are not members of the

primary key.


2-c/ Referential Integrity

A constraint involving two relations (the previous constraints involve a

single relation).

Used to specify a relationship among tuples in two relations: the

referencing relation and the referenced relation.

Tuples in the referencing relation R1 have attributes FK (called foreign

key attributes) that reference the primary key attributes PK of the

referenced relation R2.

A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK].


3-/ ER-to-Relational Transformation Algorithm

Step 1: Transformation of Regular Entities.

For each regular (strong) entity E in the ER model, create a

relation R that includes all the simple attributes of E.

Choose one of the key attributes of E as the primary key for R.

If the chosen key of E is composite, the set of simple attributes

that form it will together form the primary key of R.


3-/ ER-to-Relational Transformation Algorithm (continued)

Step 2: Transformation of Weak Entities

For each weak entity W in the ER model with owner entity E,

create a relation R that includes all simple attributes of W.

The primary key of R is the combination of the primary key of

the owner entity E and the partial key of the weak entity W, if any.

In addition, include as a foreign key in R that correspond to the

primary key of the owner entity.


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

There is a relation father-children

The father entity exists at the N-side of the relationship.

The child entity exists at the 1-side of the relationship.

The child entity should have a foreign key to the father entity.

Include any simple attributes of the relationship as attributes of

the child entity.

Example: WORKS_FOR, CONTROLS and SUPERVISION are relationship

of type 1:N. For WORKS_FOR we include the primary key DNUMBER of

the DEPARTMENT relation as foreign key in the EMPLOYEE relation and

call it DNO.



Step 4: Transformation of Binary 1:1 Relationships

There are three cases :

Case 1- The relationship is of type (1,1) - (1,1)

The two entities may be merged in one relation.


There is a relation father-children, so, the child entity should have a foreign key to the father entity.



Step 4: Transformation of Binary 1:1 Relationships


Merging the two entities or putting foreign keys in the entities

are left to the designer initiative.



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

– Create a new relation S to represent the M:N relationship.

– Include as foreign keys in S the primary keys of the relations

that represent the participating entities; their combination

will form the primary key of S.

– Also include any simple attributes of the M:N relationship as

attributes of S.

Example: The M:N relationship type WORKS_ON from the ER diagram is mapped by creating a relation WORKS_ON in the relational database schema. The primary keys of the PROJECT and EMPLOYEE relations are included as foreign keys in WORKS_ON and renamed PNO and ESSN, respectively. Attribute HOURS in WORKS_ON represents the HOURS attribute of the relation type. The primary key of the WORKS_ON relation is the combination of the foreign key attributes {ESSN, PNO}.



Step 6: Mapping of Multivalued attributes.

– Create a new relation R for each multivalued attribute A.

– The relation R will include :

an attribute corresponding to A. If the multivalued attribute

is composite, we include its simple components.

a foreign key FK corresponding to the primary key PK of

the relation that has A as an attribute.

– The primary key of R is the combination of A and FK.

Example: The department locations.



Step 7: Mapping of N-ary Relationship Types.

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

S to represent R.

– Include as foreign key attributes in S the primary keys of the

relations that represent the participating entities.

– Also include any simple attributes of the n-ary relationship (or

simple components of composite attributes) as attributes of S.

Example: The relationship type SUPPY in the ER below.



Summary of Mapping constructs and constraints

Correspondence between ER and Relational Models

ER Model Relational Model

Entity type “Entity” relation

1:1 or 1:N relationship type Foreign key (or “relationship” relation)

M:N relationship type “Relationship” relation and two foreign keys

n-ary relationship type “Relationship” relation and n foreign keys

Simple attribute Attribute

Composite attribute Set of simple component attributes

Multivalued attribute Relation and foreign key

Value set Domain

Key attribute Primary (or secondary) key


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.

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 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).


EER diagram

notation for an

attribute-

defined

specialization

on JobType.


Options for mapping specialization or generalization.

(a) Mapping the EER schema (previous slide) using option 8A.


Generalization.

(b) Generalizing CAR and TRUCK into the superclass VEHICLE.



(b) Mapping the EER schema (in slide 22) using option 8B.



Relations (cont)

Option 8C: Single relation with one type attribute.

Create a single relation L with attributes Attrs(L) = {k,a1,…an} U {attributes

of S1} U…U {attributes of Sm} U {t} and PK(L) = k. The attribute t is called

a type (or discriminating) attribute that indicates the subclass to which each

tuple belongs

Option 8D: Single relation with multiple type attributes.

Create a single relation schema L with attributes Attrs(L) = {k,a1,…an} U

{attributes of S1} U…U {attributes of Sm} U {t1, t2,…,tm} and PK(L) = k.

Each ti, 1 < I < m, is a Boolean type attribute indicating whether a tuple

belongs to the subclass Si.


EER diagram

notation for an

attribute-defined

specialization on

JobType.



(c) Mapping the EER schema in Figure 4.4 using option 8C.


EER diagram notation for an overlapping (nondisjoint)

specialization.



(d) Mapping Figure 4.5 using option 8D with Boolean type

fields Mflag and Pflag.



Relations (cont)

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.


A specialization

lattice with multiple

inheritance for a

UNIVERSITY

database.


Mapping the EER specialization lattice in Figure 4.6

using multiple options.



Relations (cont)

Step 9: Mapping of Union Types (Categories).

– For mapping a category whose defining superclass have

different keys, it is customary to specify a new key attribute,

called a surrogate key, when creating a relation to

correspond to the category.

– In the example below we can create a relation 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.


Two categories (union types):

OWNER and

REGISTERED_VEHICLE.


Mapping the EER

categories (union

types) in Figure

4.7 to relations.


Mapping Exercise

An ER schema for a SHIP_TRACKING database.

cois 342 - databases · chapter 4 –er-to-relational transformations –adapted from...

Documents