DATABASE

MANAGEMENT
SYSTEMS
Couse code:CSC403
Prof. Juhi Janjua
Module 3: • Introduction to the Relational Model

Relational • Relational schema and concept of keys.

Model and • Mapping the ER and EER Model to the Relational

Model
relational • Relational Algebra-operators

Algebra • Relational Algebra Queries.

Introduction to Relational Model
• Relational Model was proposed by E.F. Codd to model
data in the form of relations or tables.
• After designing the conceptual model of Database using
ER diagram, we need to convert the conceptual model
in the relational model which can be implemented using
any RDBMS languages like Oracle SQL, MySQL etc.
• So, we will see what Relational Model is.
Relational Model
• It represents how data is stored in Relational Databases.

• It stores data in the form of relations (tables).

Terminologies
Attribute: properties that define a relation.
e.g.; ROLL_NO, NAME

Relation Schema: represents name of the relation with its attributes.

e.g.; STUDENT (ROLL_NO, NAME, ADDRESS, PHONE and AGE) is relation schema for
STUDENT.
If a schema has more than 1 relation, it is called Relational Schema.

Tuple: each row in the relation is known as tuple.

In student relation contains 5 tuples, one of which is shown as:
Terminologies…
Relation Instance: set of tuples of a relation at a particular instance of time
Table shows the relation instance of STUDENT at a particular time.
It can change whenever there is insertion, deletion or update in the database.

Degree: no. of attributes in the relation is known as degree of the relation.

STUDENT relation defined above has degree 5.

Cardinality: no. of tuples in a relation is known as cardinality. The STUDENT relation

defined above has cardinality 5.
Properties of Relations
• Name of the relation is distinct from all other relations.
• Each relation cell contains exactly one atomic (single) value
• Each attribute contains a distinct name
• Tuple has no duplicate value
• Order of tuples is irrelevant (tuples may be stored in an arbitrary
order)
Relation Schema in DBMS
• It defines the design and structure of the relation.
• It consists of the relation name & set of attributes.

Example:
There is a student named Smith, he is pursuing B.Tech, in the 4th year, and belongs to
Computer department(deptno. 1) and has roll number 16047 She is mentored by Mrs. S
Mohanty.
If we want to represent this using databases we would have to create a student table
with name, degree, year, department, department number, roll number and mentor as
the attributes.

student(rollNo,name,degree,year,deptNo,mentor)
Relation schema…
This and other departments can be represented by the department table, having
department ID, name and hod as attributes.
department(deptID,name,hod)

The course that a student has selected has a courseid, course name, credit and department
number.
course(courseId,cname,credits,deptNo)

The professor would have an employee Id, name, department no. and phone number.
professor(empId,name,deptNo,phoneNo)
Relation schema…
We can have another table named enrollment (relationship between course &
student), which has roll no, courseId, semester, year and grade as the attributes.
enrollment(rollNo,courseId,sem,year,grade)

Teaching (relationship between professor & course) can be another table, having
employee id, course id, semester, year and classroom as attributes
teaching(empId,courseId,sem,year,classroom)

And so on…
Relations between them is represented through arrows
Concept of keys
• Keys are defined to easily identify any row of data in a table.
• Let's try to understand about all the keys using a student table with
fields student-id, name, phone & age
Super Key
• Super Key is defined as a set of attributes within a table that can
uniquely identify each record within a table.
• It is a superset of Candidate key.
Example:
Considering student table
Super key: {student-id}, {student-id, name}, {phone}
Candidate Key
• They are defined as the minimal set of fields which can uniquely
identify each record in a table.
• It is an attribute or a set of attributes that can act as a primary Key for a
table to uniquely identify each record in that table.
Example:
student-id & phone are candidate keys of student table
Properties of candidate key
• A candidate key can never be NULL or empty.
• Its value should be unique.
• There can be more than one candidate keys for a table.
• A candidate key can be a combination of more than one
columns(attributes).
Primary Key
• There can be more than one candidate key in relation out of which
one can be chosen as the primary key.
• For the table Student we can make the student_id column as the
primary key.
Foreign Key
• It is a column that creates a relationship between two tables.
• The purpose of Foreign keys is to maintain data integrity and allow
navigation between two different instances of an entity.
• It acts as a cross-reference between two tables as it references the
primary key of another table.
Example
• In this example, we have two table,
teach and department in a school.
However, there is no way to see which
teacher work in which department.
• In this table, adding the foreign key
DeptCode to the teach table, we can
create a relationship between the two
tables.
• This concept is also known as
Referential Integrity.
Mapping the ER and EER Model to the Relational
Model
Steps for mapping
• ER-to-Relational Mapping Algorithm
Step 1: Mapping of Regular 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.

• Mapping EER Model Constructs to Relations

Step 8: Options for Mapping Specialization or Generalization.
Step 9: Mapping of Union Types (Categories). 20
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.
• 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.

21
Step 1

Example: We create the relations

EMPLOYEE, DEPARTMENT, and
PROJECT in the relational schema
corresponding to the regular
entities in the ER diagram. SSN,
DNUMBER, and PNUMBER are the
primary keys for the relations
EMPLOYEE, DEPARTMENT, and
PROJECT as shown.
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.
• 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).
• 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.

23
Step 2

Example: Create the relation

DEPENDENT in this step to correspond
to the weak entity type DEPENDENT.
Include the primary key SSN of the
EMPLOYEE relation as a foreign key
attribute of DEPENDENT (renamed to
ESSN).
The primary key of the DEPENDENT
relation is the combination {ESSN,
DEPENDENT_NAME} because
DEPENDENT_NAME is the partial key
of DEPENDENT.
Step 3: Mapping of Binary 1:1 Relation 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. There
are three possible approaches:
(1) Foreign Key approach: Choose the relations with total participation in R
– say S-- and include T’s primary key in S.
(2) Merged relation option: An alternate mapping of a 1:1 relationship type
is possible by merging the two entity types and the relationship into a single
relation. This may be appropriate when both participations are total.
(3) Cross-reference or relationship relation option: The third alternative is
to set up a third relation W(T.primarykey, S.primaryKey) for the purpose of
cross-referencing the primary keys of the two relations S and T representing
the entity types.

25
Step 3 (Foreign
key approach)
Example: 1:1 relation MANAGES is
mapped by choosing the
participating entity type
DEPARTMENT to serve in the role of
S, because its participation in the
MANAGES relationship type is total.
Step 4: Mapping of Binary 1:N Relationship Types
• For each regular binary 1:N relationship type R, identify the
relation S that represent the participating entity type at the
N-side of the relationship type.
• Include as foreign key in S the primary key of the relation T
that represents the other entity type participating in R.
• Include any simple attributes of the 1:N relation type as
attributes of S.

27
Step 4

Example: 1:N relationship types

WORKS_FOR, CONTROLS, and
SUPERVISION in the figure. 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 5: Mapping of Binary M:N Relationship Types

• For each regular binary M:N relationship type R, 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; their combination will form the
primary key of S.
• Also include any simple attributes of the M:N relationship type (or simple
components of composite attributes) as attributes of S

29
 Step 5

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

• For each multivalued attribute A, create a new 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 that has A as an
attribute.
• The primary key of R is the combination of A and K. If the
multivalued attribute is composite, we include its simple
components.

31
Step 6

Example: The relation

DEPT_LOCATIONS is created. The
attribute DLOCATION represents the
multivalued attribute LOCATIONS of
DEPARTMENT, while DNUMBER-as
foreign key-represents the primary
key of the DEPARTMENT relation.
The primary key of R is the
combination of {DNUMBER,
DLOCATION}.
Step 7: Mapping of N-ary Relationship Types
• For each n-ary relationship type R, where n>2, create a new
relationship S to represent R.
• Include as foreign key attributes in S the primary keys of the
relations that represent the participating entity types.
• Also include any simple attributes of the n-ary relationship type
(or simple components of composite attributes) as attributes of S.

33
Step 7

Example: The relationship type

SUPPLY in the ER
This can be mapped to the relation
SUPPLY shown in the relational
schema, whose primary key is the
combination of the three foreign
keys {SNAME, PARTNUM, JOBNAME}
Solution to n-ary example
Tables that already exist:
Supplier (sname, …)
Job (jname, …)
Part (partNum, …)

Add new Table:

Supply (sname, jname, partNum, quantity, …)
sname is FK -> Supplier (sname)
jname is FK -> Job (jname)
partNum is FK -> Part (partNum)
35
Result of mapping the COMPANY ER schema into a relational schema.

36
Summary of mapping constructs &
constraints
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

38
Option 8A

Option 8A: Multiple relations-Superclass and

subclasses
Create a relation L for C as L{k,a1,…an}, and
PK(L) = k. Create a relation Li for each
subclass Si, 1 < i < m, Li{k, si1,…,siik}, where
si1,…,siik are the local attributes of Si, and
PK(Li)=k. This option works for any
specialization (total or partial, disjoint or
over-lapping).
Option 8B

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).
Option 8C

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.
This option works for disjoint specilaization.
Option 8D
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.
This option works for overlapping
specilaization.
Mapping EER Model
Constructs to 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.

43
In the example, 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.

44
Mapping the EER categories (union types) to relations.

45