Relational Data Model &

ER-Relational Mapping
COMP 353/453
Database Programming
Prof. Silva

These slides were prepared by Prof. Silva adapting the slides from Fundamentals of Database Systems (Elmasri and Navathe) and Understanding
Relational Database Query Languages (Dietrich)
Relational Data Model: Informally

Informally, a relational database consists of a collection of tables, each of which

is assigned a unique name.
relation  table
tuple  row
attribute  column (name)

attribute1 relation attribute2

tuple1valueAttr1 tuple1valueAttr2
tuple2valueAttr1 tuple2valueAttr2
tuple3valueAttr1 tuple3valueAttr2
Example Relation

Conceptually, we can view a relation as a table:

student

id name major
1111 Student1 CSE
2222 Student2 EEE
3333 Student3 CSE
4444 Student4 EEE
5555 Student5 CSE

The set of attributes names for a relation schema is denoted by

STUDENT = {id, name, major}
Alternatively, we abbreviate a relation schema as shown:
student(id, name, major)
Relational Data Model: Formally
Let D1,D2,...,Dn be sets of atomic values, called domains

An n-tuple is an ordered sequence (d1,d2,...,dn) s.t. di  Di

A relation with n attributes is a set of n-tuples, which is a subset of the

cartesian product of the domains of the attributes
D1  ...  Dn where Di is the domain of the ith attribute

Let |Di| denote the cardinality (number of values) of domain D i

Then the cartesian product specifies all possible combinations of values from
the underlying domains and has total number of tuples:
|D1| * |D2| * ... * |Dn|
Relational Database

A relational database is a set of relations.

Since a relation is a set (unordered collection of unique elements) of

tuples:
• The tuples in a relation are unordered.
• There are no duplicate elements in a set, i.e., each tuple is different.
University Database: Schema & Instance

cse_majors eee_majors
id name class
id name class
1111 Student1 FR
2222 Student2 SO
2222 Student2 SO
3333 Student3 JR 4444 Student4 SR
4444 Student4 SR 6666 Student6 SR
5555 Student5 GR

cse_courses
cse_profs crsid crstitle
name office
CSE412 Database Management
Prof1 Office1
CSE414 Advanced Database Concepts
Prof2 Office2
CSE514 Object Oriented Databases
University Database: teaches

• The teaches table relates the

name of a CSE Professor to a
CSE course that the professor is
teaching. teaches
• Assumes that the attribute name name crsid
uniquely identifies a professor
and the attribute crsid uniquely Prof1 CSE412
identifies a course. Prof1 CSE414
• Intuitively, the values of the Prof2 CSE514
columns in the table should refer
to a valid value in the cse_profs
and cse_courses tables.
DB Schema & Instances: A More Formal Look

• A Relational Database Schema S is a set of relation schemes

S={R1, R2, ..., Rm} and a set of integrity constraints IC.
• A Relational Database Instance DB of S is a set of relation instances
DB={r1, r2, ..., rm} s.t. each ri is an instance of Ri and the ri's satisfy IC.
• Integrity Constraints
- Key Constraint:
specify the candidate key of each relation schema.
- Entity Integrity Constraint:
no primary key value can be null.
- Referential Integrity Constraint:
a tuple in one relation that refers to another relation must refer
to an existing tuple in that relation.
Key Constraint

We underline the attributes that form the candidate key of the table
(similar definition to a candidate key in the ER model) :

cse_majors(id, name, class)

eee_majors(id, name, class)
cse_profs(name, office)
cse_courses(crsid, crstitle)

What is the candidate key for teaches?

teaches(name, crsid)

Does a teacher teach many courses?

Is a course taught by one teacher or many teachers?
Entity Integrity Constraint
No primary key value can be null

Recall that a primary key is a candidate key that is chosen by the

DBA as the principal means of identifying entities.

In the University schema, each table has only one candidate key,
which is therefore the primary key.
If a table has multiple candidate keys, a uniqueness constraint can
be used on the candidate keys that do not comprise the primary
key. More later…
Referential Integrity Constraint: Foreign Key

Consider a referential integrity constraint between two relation schemes

R1 and R2.

A set of attributes Fk in R1 is a foreign key of R1 if

1. the attrs of Fk have the same domain as the primary key attrs Pk of
the relation scheme R2 that Fk references, and

2. let t1 be a tuple of r1, either

t1[Fk] is null. // partial participation

or
t1[Fk]=t2[Pk] for some t2 of r2
 Foreign Key Example
teaches(name, crsid)
cse_profs(name, office) PK
cse_courses(crsid, crstitle) FK
Example: FK
• The name attribute of teaches has the same domain as the name attribute of
cse_profs, and
• the non-null value of the name attribute of teaches (teaches[name]) must be equal
to some name value in cse_profs (cse_profs[name]).

A similar constraint holds for the crsid attribute between the tables teaches and
cse_courses.

Initially, we will use similar names to remind us of the referential integrity

constraint. The SQL standard, which we will learn later, will provide a syntax to
explicitly define foreign keys.
Mapping ER to Relations

The ER approach represents a conceptual design, which provides the

database designer with a tool to use in an actual design for a particular data
model.

How does one take the ER conceptual design and map it to the relational
data model for implementation?

We consider here the mapping of entities and relationships from an ER

diagram to the relations for the relational data model. Although this
mapping is somewhat flexible, we will consider heuristics for this mapping
by looking at examples of various entities and relationships of different
cardinality ratios.
Strong Entity

Attributes: simple attributes of the entity and the simple

components of the composite attributes
Candidate Key: candidate key of entity

emp(eID, eName, eSal, eStr, eCity, eSt, eZip)

Weak Entity

Attributes: simple attributes and simple components of composite

attributes of the entity itself and the attributes corresponding
to the primary key of its identifying owner
Candidate Key: combination of the attributes of the primary key of the
identifying owner and the discriminator (partial key) of the
weak entity

dep(empID, fName, bDate, sex)

Relationship Types

Attributes: simple attributes and simple components of composite

attributes of the relationship type and the attributes
corresponding to the primary key of each entity
involved in the relationship type.
Candidate Key: dependent on the cardinality ratio of the relationship type

Note that this is a general scheme for mapping relationship types to

relations. We will see other alternatives based on the cardinality ratio of the
relationship type.
1:1 Cardinality Ratio

Candidate Key: each primary key of the entity types involved in the relationship
represents a candidate key; choose one as a primary key

mgr(id,dnum)
dept(dnum,dname)
emp(id,name)

Alternative Design:
• No relation for the relationship type itself
• Add to one of the relations:
- attributes corresponding to the primary key of the other entity
involved in the relationship type
- attributes of the relationship type itself (if any);
- If possible, add the attributes to the relation for the entity that has total
participation in the relationship type.

dept(dnum,dname,mgrid)
emp(id,name)
1:N Cardinality Ratio

Candidate Key: the attributes that form the primary key of the many entity in the
relationship
teaches(crsid,tname)
course(crsid,title)
teacher(tname,dept)

Alternative Design:
• No relation for the relationship type itself
• Add to the relation for the entity on the many side of the relationship
type:
- attributes corresponding to the primary key of the entity on the one side of
the relationship type
- attributes of the relationship type itself (if any)

course(crsid,title,tname)
teacher(tname,dept)
M:N Cardinality Ratio

Candidate Key: combination of the attributes that form the primary

keys of both entities involved in the relationship type

export(cname,pnum,qty)

NOTE:
The candidate key must be based on the semantics of the enterprise.
The meaning of the descriptive attributes of the relationship must be
considered when determining the candidate key of the relation.
Mapping: Multivalued Attributes and Identifying
Relationships

o(oKey, oSingleValuedAttr)
Mapping: Multivalued Attributes

Attributes: The primary key of the entity that the multivalued

attribute describes, and the multivalued attribute.
Candidate Key: A composite key consisting of the combination of the
primary key of the entity and the multivalued
attribute.

oMulti(oKey, oMultiValuedAttr)
Mapping: Identifying Relationships

• An identifying relationship is NOT explicitly mapped to its own

table.
• Identifying relationships link a weak entity to its identifying owner,
and are implicitly mapped in the table representing the weak entity.
• Any descriptive attributes of an identifying relationship will be
included in the table for the weak entity.

w(oKey, wPartialKey, wDescriptiveAttr)

Mapping Exercise

Map the ER diagram for employee training courses into the relational data
model:

1
MGR 1
id dnum
name EMP DEPT
N 1 dname
sal M
WORKS
date TAKES

N
crsid inst
COURSE
cname length
 Creation of Tables (DDL, DML)
• Data Definition Language (DDL)
• Create tables, constraints, etc.
• Data Manipulation Language (DML)
• Insert data, delete, update, etc.
• Example: PostgreSQL
• Emp (id, name, sal)
• Course (crsid, cname, inst, length)
• Takes (eid, crsid, cdate);

CREATE TABLE Emp (id integer,

name varchar(40), INSERT INTO Emp VALUES (0001, 'Josh', 10000);
salary numeric,
INSERT INTO Emp VALUES (0002, 'Spencer', 8000);
primary key (id));

CREATE TABLE Course (crsid integer, INSERT INTO Course VALUES (001, 'MS Access', 'Y. Silva', 4);
cname varchar(30), INSERT INTO Course VALUES (002, 'SQL Server', 'G. Smith', 4);
inst varchar(40),
length integer, INSERT INTO Takes
primary key (crsid));
VALUES (0001, 001, to_date('2012/01/05', 'YYYY/MM/DD'));
INSERT INTO Takes
CREATE TABLE Takes (eid integer,
crsid integer, VALUES (0001, 002, to_date('2012/01/05', 'YYYY/MM/DD'));
cdate date, INSERT INTO Takes
primary key (eid, crsid), VALUES (0002, 002, to_date('2012/01/05', 'YYYY/MM/DD'));
foreign key (eid) references Emp(id),
foreign key (crsid) references Course(crsid));
Summary

• Relational data model

• Constraints: Key, Entity Integrity, Foreign Key
• Mapping the ER conceptual design to the relational data model for
storing the data

What is next?
• The retrieval of information from the relational database using a
query language.
Video: Introduction to Databases

http://www.gcflearnfree.org/access2010
pgModeler: PostgreSQL Database Modeler

• Open-source tool
• Supports the creation of
logical data models
(similar to E-R models)
• Supports the generation
of the corresponding
relational models
• Supports DDL
generation

https://pgmodeler.io/