ERD to Relational Mapping

Revisit
 Mapping (Table Design) Regular Entity
PROJECT
Name

Number PROJECT Location

ER Model
Relational Schema or ER Diagram

PROJECT Pnumber Pname Plocation

PName must has NOT NULL constraint, Name is

UNIQUE Key
--- Mapping Regular Entity DEPARTMENT
Number Name

NumberOfEmployees DEPARTMENT Location

ER Schema
Relational Schema

DEPARTMENT Dname Dnumber

24
 … Mapping of 1:1 Relationship Types
Locations
SSN … Sex StartDate Name Number

1 1
EMPLOYEE MANAGES DEPARTMENT

ER Model
Relational Schema

Dname DNumber MGRSSN MGRStartDate Loc1 Loc2

DEPARTMENT
Foreign Key

MGRSSN must be UNIQUE KEY to validate 1:1, Dname must has NOT NULL constraint
 … Mapping of 1:N Relationship Types

SSN … Gender
DName DNum Locations

N 1
EMPLOYEE WORKS_FOR DEPARTMENT

ER Model
Relational Schema or ER Diagram
EMPLOYEE

Fname Minit Lname SSN Bdate Gender Address Salary DNum

DEPARTMENT
Loc2 Foreign Key
DNum DName Loc1
 … -- Alternate Mapping of 1:N
Relationship Types
Locations
SSN … Sex Name Number

N 1
EMPLOYEE WORKS_FOR DEPARTMENT
(1,N) (1,1)

ER Model
Relational Schema or ER Diagram

Fname Minit Lname SSN Bdate Sex Address Salary Dnum

EMPLOYEE Foreign Key

Employee is mandatory, each department has one or more employees. Department must has at least
one employee. For example, (1,1)-(0,N) means Employee is optional, some departments may be without
any employee
 … Mapping of M:N Relationship Types
ESSN … Hours …
PNO

N M
EMPLOYEE WORKS_ON PROJECT

ER Model
Relational Schema or ER Diagram
WORKS_ON
ESSN

WORKS_ON ESSN PNO Hours PNO

Hours

WORK_ON table requires in addition to tables EMPLOYEE and PROJECT

ESSN and PNO are the composite keys, Hours must has NOT NULL constraint
 … Mapping of N-ary Relationship Types

SNo Sname PartNo Pname

Quantity PART PNo
L

SUPPLIER SUPPLIES PROJECT

M N

ER Model
Relational Schema or ER Diagram

SUPPLY SNo PartNo PNo Quantity

Foreign Keys
Quantity must has NOT NULL constraint. Similar example can be Lecturer teaches course to
students. Other example: Vehicle, Policeman, Ticket (Ticket# is a serial unique number)
 … Mapping of N-ary Relationship Types

ER Model
Relational Schema or ER Diagram

Exercise: Draw table or relational schema and User interface Form of this model
 … Mapping of Recursive Relationship Types
CID CName
SSN Name Sex
… N
N

COURSE Pre-requisite
EMPLOYEE Supervisor
M
Manages
1
ER Model
Relational Schema or ER Diagram

Fname Minit Lname SSN Bdate Sex Address Salary MGRSSN

EMPLOYEE Foreign Key

MGRSSN is a FK references to SSN in the same table Employee
 Representations in relational model

• Relation is the base representation otherwise called as table.

• Relation schema describes the structure of relation.
– For Example
– Student( student_id, student_name)
• Relational Instance describes the table with sample data.
 Relational Terms
• Record or Tuple: Each row in the relation.
• Domain: The set of allowable values for a column.
• Degree: The number of columns in a relation.
• Cardinality: The number of rows in a relation.
• Relational database: a collection of relations with
distinct relation names.
• Relational database schema: the collection of schemas
for the relations.
• Instance of a relational database is a collection of
relation instances
… Mapping of Recursive Relationship Types
CID CName
N

COURSE Pre-requisite

M
1
ER Model
Relational Schema or ER Diagram
 Cardinality
1 N
PROFESSOR teaches CLASS
(1,1) (0,3)

A university limits the professor to teaching a max. of 3 classes per semester.

M N
STUDENT enrolled CLASS
(0,35) (1,6)
A university may decide to limit a student to a max. of 6 classes per semester, and
class size may be limited to 35 students or no student.
(0,35) for class: class may contain no students or up to 35 students
(1,6) for student : student must take at least one class or up to 6 classes
-- Mapping of Weak Entity Types …
• For each weak entity type W in the ER schema with owner entity type E,
create a relation R that includes all the simple attributes of W (or simple
components of composite attributes) as attributes of R.

• In addition, include as foreign key attributes of R the primary key

attribute(s) of the relation(s) that correspond to the owner entity type(s);
this takes care of the identifying relationship type of W. The primary key of
R is the combination of the primary key(s) of the owner(s) and the partial
key of the weak entity type W, if any.

36
… -- Mapping of Weak Entity Types
• In the COMPANY database example, we created
the relation DEPENDENT, in this step to
correspond to the weak entity type DEPENDENT.
• We include the primary key SSN of the
EMPLOYEE relation – which correspond to the
owner entity type as a foreign key attribute of
DEPENDENT; we renamed it ESSN; although this
is not necessary.
• The primary key of dependent relation is the
combination {ESSN, DEPENDENT_NAME}
because DEPENDENT_NAME is the partial key of
the weak entity DEPENDENT.
37
 --- Mapping Weak Entity DEPENDENT
BirthDate
SSN
… Sex Name Relationship

1 M
EMPLOYEE Dependents_of DEPENDENT Sex

ER Schema
Relational Schema

DEPENDENT

ESSN SNO DependentName Sex Bdate Relationship

In the book Dependent name is shown a part of composite Key for Dependent – which is not
valid choice 38
 - Mapping Relationship Types
• Mapping of 1:1 Relationship Types +
• Mapping of 1:N Relationship Types +
• Mapping of M:N Relationship Types +
• Mapping of N-ary Relationship Types +

39
-- Mapping of 1:1 Relationship Types …
• For each binary 1:1 relationship type R in the
ER schema, identify the relations S and T that
correspond to the entity types participating in
R. Choose one of the relations, say S, and
include as the foreign key in S the primary key
of T. It is better to choose S as the entity type
with total participation in R.

40
 … -- Mapping of 1:1 Relationship Types …
• In the COMPANY database example we map the 1:1 relationship type
MANAGES, by choosing the 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).

• We include the primary key of EMPLOYEE relation as a foreign key in the

DEPARTMENT relation and we name it MRGSSN.

• We also include the simple attribute StartDate of the MANAGES

relationship type in the DEPARTMENT relation and rename it as
MGRSTARTDATE.

41
-- Mapping of 1:N Relationship Types …
• For each regular binary 1:N relationship type R in
the ER schema,
– identify the relations S that represent the participating
entity type at the N-side of R.
– Include as foreign key in S the primary key of the
relation T that represents the other entity type
participating in R; this is because each entity instance
on the N-side is related to at most one entity instance
one the 1-side of the relationship type.
– Include any simple attributes (or simple components of
composite attributes) of the 1:N relationship type as
attributes of S.
42
… -- Mapping of 1:N Relationship Types …
• In the COMPANY database example, we now map
the 1:N relationship types WORKS_FOR,
CONTROLS, and SUPERVISION.
– For WORKS_FOR we include the primary key
DNUMBER of the DEPARTMENT relation as a foreign
key in the EMPLOYEE relation and call it DNO.
– For CONTROLS we include the primary key DNUMBER
of the DEPARTMENT relation as a foreign key in the
project relation and call it DNUM.
– For SUPERVISION we include the primary key SSN of
the EMPLOYEE relation as a foreign key in the
EMPLOYEE relation itself and call it SUPERSSN.
43
-- Mapping of M:N Relationship Types …
• For each binary M:N relationship type R in the ER
schema
– 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 entity
types R.
– The combination of these keys will represent the
primary key for S.
– Also include any simple attributes of R (or simple
components of composite attributes) as attribute of S.

44
… -- Mapping of M:N Relationship Types
• In the COMPANY database example
– we map M:N relationship type WORKS_ON by
creating a new relation WORKS_ON.
– We include the primary keys of the PROJECT and
EMPLOYEE relations as foreign keys in WORKS_ON
and rename them PNO and ESSN, respectively.
– We also include the attribute HOURS in WORKS_ON
to represent Hours attribute of the relationship type.
– The primary key of the WORKS_ON relation is the
combination {ESSN, DNO}
45
-- Mapping of N-ary Relationship Types …

• For each n-ary relationship type R in the ER schema,

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 entity
types in R.
– The combination of these keys will represent the
primary key of S.
– Also, include any simple attributes of R (or simple
components of composite attributes) as attributes of S.

46
… -- Mapping of N-ary Relationship Types
– For example, the relationship type SUPPLY (shown in the
following figure) can be mapped to the relation SUPPLY
whose primary key is the combination of foreign keys
{SNAME, PARTNO, PROJNAME}

47
 - Mapping Multi-valued Attributes …
• For each multi-valued attribute Am create anew relation R.
• This relation R will include an attribute corresponding to A plus the
primary key attribute K – as a foreign key in R – of the relation that
represents the entity type or relationship type that has A as an attribute.
• The primary key of R is the combination of A and K.
• If the multi-valued attribute is composite, we include its simple
components.

48
Summary – Strong & Weak Entities
Practical Exercise – Draft to Refine Shape
versions

Make at least 3 versions of one ER Model to get optimum solution

 Summary – DB Implementation
 Create PK/ CK (must), FK (if any), Cardinalities
 At least one non-key column NOT NULL in table
 Other constraints
 Check/ Range, UNIQUE, NOT NULL, Default (if any)
 Constraints using triggers
 Validate Normalization
 Assign appropriate data types and size

51
 Integrity Constraints

• They are rules that relation should satisfy for a

relational instance.
• Domain Constraints
– Unique
– Null
– Not Null
– Check
• Key Constraints
 Key Constraints
• Primary Key Constraints
– Rule that specifies a field to be a primary key.
– A Primary Key is a field (Column) which is used to identify the
whole record.
• Composite Key Constraints
– Rule specifies one or more field as a primary key.
• Foreign Key Constraints
– Rule specifies a field to be a foreign key
– Foreign key specifies a field which can be used to relate a table
with other table.
 Conversion of ER Model to
Tables
• Entity sets to Tables.
– Each Entity set can be represented into a
separate relation or table. i.e. the entity set
name is considered as the table name.
– Each attribute is represented as the field or
column in the table.
– Key attribute is represented as the primary
key for that table.
Conversion of ER Model to Tables

• If there is Mulitvalued attribute then a

separate table has to be represented only for
that mulitvalued attribute with each field
representing different values that the attribute
can hold for an entity instance and a separate
field which represents the primary key of the
parent table must also be represented.
• If there is a composite attribute then each of
its subcomponent are represented as fields in
that table.
Example
Table
 Conversion of ER Model to Tables

• Relationship sets to tables (Without Constraints)

– A relationship set is also represented as a table in
relational model with fields as the key attributes of
the participating entity set.
– Descriptive attributes of the relationship set is also
represented as a field in the table.
 Conversion of ER Model to Tables

• Translating ER diagrams with Generalization and

Specialization.
• For each sub entities a separate relation is created
with fields as attributes of the sub entity and
another additional field as the primary key of the
parent entity set.
 Summary
• Can map E-R model schemas to relational
model schemas very easily – Mapping process
is straightforward and unambiguous
• Some flexibility in optimizing relation schemas
– Mapping cardinalities, etc.
• Some E-R concepts are more expensive –
Multi-valued attributes (especially composite
ones)