1

CHAPTER 3

RELATIONAL DATA MODEL

Relational Database Concepts

A Relational Database is a collection of Tables called Relations.

Relation Schema

A Relation Schema refers to the structure of a Table. It indicates the Name of the
Relation Schema and the Names its Attributes (represented by Columns in the
table). For example R (A1, A2, ……, An) represents a Relation Schema named “R”
having n columns, representing the Attributes A 1,A2, …. An.
Domain of an Attribute The Domain of an Attribute A i is the set of permitted
(legal) values, that can be assigned to Attribute A i. It is possible for more than
one Attributes to have the same Domain or to have overlapping Domains.

- The domains of all attributes of a relation should be atomic (indivisible).

- One value that is member of all domains is null, which implies that the
value is either unknown or non-existent; for example suppose an entity has
attribute telephone-number. It may have null value if an entity does not have a
telephone number or if the entity has telephone number, but number is not
known.
Degree of a Relation Schema

The Degree of a Relation Schema “R” refers to the number of Attributes

(Columns) in the Schema. For example, the Relation Schema R (A 1, A2, ……,An)
has a Degree of n.

Relation or Relation Instance A Relation or relation instance, denoted as

r(R), refers to an actual Table named “r” created on the Relation-Schema “R”. A
table will comprise a set of rows (called tuples).

Let r(R) = {t1, t2 , ……, tm} where t1, t2 , ……, tm are the tuples in the relation.

Each tuple t will be an ordered list of n values.

Let t = <v1, v2, …..vn>

The n-values in a tuple will represent an entity or a relationship. Thus, all the n
values in the tuple will be related to each other. That is why the resulting
database is called a “relational database”.

P S Gill
 2

Note that a tuple is an Ordered List (not a Set) of n values. That is why the
order of the values in the tuple matters. A value V i (1 < I < n) in the tuple t will be
from the Domain of attribute Ai.
i.e. vi Î Domain (Ai)

A Relation can also be defined as a subset of the Cartesian Product of all the
Domains of its Attributes.
i.e. r (R) Í Domain (A1) x Domain (A2) X …… X Domain (An)

Cardinality of a Relation The Cardinality of a Relation r(R) at any moment is

defined as the numbers of rows (tuples) existing in the Relation (Table) at that
moment of time.

The cardinality of relation r(R)= {t1, t2 , ……, tm} will be m.

There can be more than one Relations (Tables) defined on the same Schema,
For example r1(R) and r2(R) are two independent relations defined on the same
Schema R. Both will have same Degree but may have different cardinalities.

The Cardinality of a relation will vary from moment to moment; but degree will
change very rarely.

Some Notations

Since a relation is defined as a set of tuples, the notation t Î r implies that tuple t
is in relation r

t[Ai] denotes the value of tuple t on attribute A i.

Consider the following set of Schemas, representing information about

Students, Subjects and Results:-

STUDENT (Univ_Roll_No, Class_Roll_No, S_Name, DOB, Year,

Branch, Section, Father_Name, Address, Tel_No)

It represents a Relation Schema “STUDENT” with attributes

Univ_Roll_No, Class_Roll_No, S_Name, DOB, Year, Branch, Section,
Father_Name, Address, Tel_No. Let us assume that each student has a
unique Univ_Roll_No. Also, Class_Roll_No of a student is unique in a
class which is defined by the combination of {Year, Branch, Section}

SUBJECT (Sub_Code, Title)

P S Gill
 3

It represents a Relation Schema “SUBJECT” having attributes Sub_Code

(like “TCS-402”), Title (like “DBMS”) such that each subject has a unique
Sub_Code.

RESULT (Univ_Roll_No, Sub_Code, Semester, Marks)

It represents relation Schema “RESULT” having attributes Roll_No,

Sub_Code, Semester and Marks.

Super Key of a Relation Schema R

The Super Key of a Relation Schema R refers to the set of attributes K (K Í R),
which when taken collectively, will uniquely identify each tuple in a relation r(R).
The superset of a super-key will also be a super-key. Thus, a super-key may
have some extraneous attributes, without which the balance set still remains a
super-key. Such extraneous attributes, which need not be there in a super-key,
can be eliminated from the key.

For example in the above schemas, {Univ_Roll_No, S_Name} will form a

super-key of Relation Schema “STUDENT”. This super-key has an extraneous
attribute “S_Name”, without which the balance set i.e. {Univ_Roll_No} still
remains a super-key, since each student has a unique Univ_Roll_No.

Candidate Key of a Relation Schema R

A Candidate Key is defined as a super-key, whose no proper subset is a super-

key i.e. a Candidate Key is a minimal super key (having no extraneous
attributes).

A Relation Schema may have more than one Candidate Keys.

In the above schemas, the relation schema “STUDENT” has the following
Candidate Keys:-

{Univ_Roll_No}
{Class_Roll_No, Year, Branch, Section}
{S_Name, DOB, Father_Name, Address} Assuming that twins will not
have same name

And Relation Schema “SUBJECT” has {Sub_Code} as its Candidate Key and
Relation Schema “RESULT” has {Roll_No, Sub_Code} as its candidate key.

Primary Key of a Relation Schema R

P S Gill
 4

It refers to one of the Candidate Keys of R, which is designated as primary

means of uniquely identifying tuples in a relation r(R).

For example, {Univ_Roll_No} will be the most appropriate choice of

Primary Key of Relation Schema “STUDENT”.

Since the other two relation schemas have only one candidate key each,
the same will be designated as their respective Primary Keys.

Composite Key A Key, that includes more than one attributes, is called a
Composite Key.

For example, the relation schema “RESULT” has Composite Primary

Key {Univ_Roll_No, Sub_Code}.

Foreign Key A relation schema R may include among its attributes some
primary key of another schema S. This is called a Foreign Key in schema R.

For example, {Univ_Roll_No} forms a Primary Key in STUDENT but it

forms Foreign Key in RESULT. Similarly {Sub_Code} forms a Primary Key of
SUBJECT but a Foreign Key in RESULT.

Integrity Constraints of a Relational Database

The following three types of Integrity Constraints are applicable to all Relational
Databases:-

(i) Domain Constraint

(ii) Key Constraint
(iii) Foreign Key (FK) Constraint or Referential Integrity Constraint

(i) Domain Constraint

Let there be a Relation Schema R (A1, A2, ……, An).
A Relation r (R) would be legal only if for each tuple t Î r and for each
value t[Ai] in t, it satisfies t[A i] Î Domain (Ai); else the Relation will be
illegal (invalid).
This means that in a legal relation r(R) , all the values appearing under
each attribute must be from the domain of that attribute.

Specifying Domain Constraints in SQL The domain constraints in

SQL are specified by the data types of the attributes or by the CHECK
value clause or by “NOT NULL” clause. Various data types are NUMBER,
CHAR, VARCHAR, DATE etc.

P S Gill
 5

CREATE TABLE STUDENT

( Univ_Roll_No CHAR (10),
Class_Roll_No INT,
S_Name VARCHAR (20) NOT NULL,
DOB DATE NOT NULL,
Year INT,
Branch CHAR(3),
Section INT,
Father_Name VARCHAR(20) NOT NULL,
Address VARCHAR (30) NOT NULL,
Tel_No CHAR (11),
PRIMARY KEY(Univ_Roll_No)
CHECK (Year BETWEEN 1 AND 4)
CHECK (Section BETWEEN 1 AND 2));

CREATE TABLE SUBJECT

( Sub_Code CHAR(7),
Title VARCHAR(20) NOT NULL,
PRIMARY KEY (Sub_Code));

For each attribute, the permitted domain is specified in the schema definition;
for example the domain of “Year” is the set of Integers.

Additionally, the ‘CHECK’ clause can be used to further specify a sub-domain

within the specified domain; for example the permitted domain of “Year” in
“STUDENT” is set of integers between 1 and 4.

(ii) Key Constraint

Let R (A1, A2,…, An) be a relation schema, then for each key K of R
(KÍR) and for each legal Relation r(R) and for each tuple-pair {t 1, t2} Î
r, it must satisfy t1[K] ¹ t2 [K]. Else the Relation will be illegal (invalid).
This means that the values of no two in a legal relation must agree on
the Keys of that schema.

In SQL, a CREATE TABLE statement must explicitly specify PRIMARY

KEY of each Table.

Suppose a relation r(R) with Key {A,B} has the following state:-

r(R)
A B C

P S Gill
 6

A1 b1 c3
A2 b1 c1
A3 b2 c5
A1 b2 c7
A3 b2 c1

This relation state is invalid, since there are two tuples with value of {A,B}
equaling {a3, b2}. One of these two tuples must be deleted, only then it will be a
valid relation.

(iii) Foreign Key (FK) Constraint OR Referential Integrity Constraint

Let r(R) and s(S) be two relations and let a (aÍs) be a Foreign Key
(FK) in S referencing Primary Key “K” of R. The relation s(S) would be
legal (valid) only if for each tuple t s Î s, there exists a tuple tr Î r such
that tr [K] = ts [a]. A tuple ts Î s that does not satisfy this condition will
be called a “Dangling Tuple”, in the sense, that such tuples do not
have necessary support from relation r. Such Dangling Tuples are
invalid; and DBMS has to ensure that such tuples do not exist in the
database.

Specification of Primary Keys and Foreign Keys in SQL

In SQL, the FOREIGN KEY – PRIMARY KEY mapping is explicitly

specified in a CREATE TABLE statement.

CREATE TABLE RESULT

( Roll_No CHAR (10),
Sub_Code CHAR (7),
Semester INT,
Marks INT,
PRIMARY KEY (Roll_No, Sub_Code),
FOREIGN KEY (Roll_No) REFERENCES STUDENT (Roll_No),
FOREIGN KEY (Sub_Code) REFERENCES SUBJECT (Sub_Code),
CHECK (Semester BETWEEN 1 AND 8),
CHECK (MARKS BETWEEN 0 AND 100));

P S Gill
 7

Example:- Let there be two relations subject (SUBJECT) and result

(RESULT). Attribute Sub_Code in RESULT is a Foreign Key referencing
primary key Sub_Code of relation SUBJECT.

subject
Sub_Code Title
TCS-401 Comp Org
TCS-402 DBMS
TCS-301 Data Structure

result
Roll_No Sub_Code Semester Marks
0209130010 TCS-301 3 66
0209130010 TCS-401 4 57
0209130010 TCS-403 4 78

The relation result has a dangling tuple <”0209130010”, “TCS-403”, 78>,

which is attempting to reference a “Sub_Code” value of “TCS-403” which
does not exist in the relation subject, where “Sub-Code” is Primary Key.
Thus, this tuple is a dangling tuple, which is invalid. This tuple must be
deleted from table result, or a tulpe must be added to relation “subject”
with “Sub_Code” value = “TCS-403”.

How to determine the Primary Keys of Relation Schemas?

1. Strong Entity Set. The Primary key of the entity set forms the primary
key of the relation.

2. Weak Entity Set. Primary key of the relation comprises the union of the
primary key of the strong entity set on which the weak entity set is existence-
dependent and the discriminator of the weak entity set.

3. Relationship Set. The union of the primary keys of the related entity
sets becomes a super key of the relation. If the relationship is many to many,
then this super key is also the primary key of the relation. If the relationship is
many-to-one, then primary key of the “many-side” entity set is the primary key of
the relation. If the relationship is one-to-one, then primary key of any of the
related entity sets can be the primary key of the relation.

4. Combining of Tables. A many-to-one binary relationship R from A to

B can be represented by a table comprising of the attributes, that will be union of
the Primary Keys of A and B and the descriptive attributes of R. Such a table can
be combined with the table of “Many-Side” Entity Set. The attributes of the
combined table will be a union of the attributes of the two fused tables. So, the
Primary Key of the “One-Side” Entity Set will also form part of the table for

P S Gill
 8

“Many-Side” Entity Set. For example, the table for ACCOUNT also contains the
key of Entity Set BRANCH.

For a one-to-one relationship set, the relationship table can be combined with the
table of any of the participating entity sets.

5. Multi-valued Attributes. A multi-valued attribute M is represented by a

table consisting of the primary key of the entity set of which M is an attribute plus
a column C holding individual values of attribute M. Entire set of attributes of the
resultant relation forms a primary key of the relation.

A SAMPLE DATABASE “ACADEMICS DB”

Let us consider an Academics Database “ACADEMICS DB”, with following Entity

Sets & Relationship Sets:-

Entity Sets:-

(i) STUDENT with Attributes Roll_No & S_Name. Suppose attribute

Roll_No has a unique value for each student.
(ii) SUBJECT with Attributes Sub-Code,Title and Semester
(iii) FACULTY with Attributes Fac_Code & Fac_Name
(iv) DEPT with Attributes D_Name & HOD

Relationship Sets:-

(i) SUB-OFFERED A many-to-many relationship between entity

sets FACULTY & SUBJECT. This implies that a Faculty can offer any
number of subjects in a semester and a subject can be offered by any
number of faculty members.

(ii) RESULT A many-to-many relationship between the entity sets

STUDENT and the aggregated relationship SUB_OFFERED with
descriptive attribute MARKS. This relationship represents the Marks
obtained by the students in various subjects. Assume that each student
can take many of the offered subjects and each offered subject can be
taken by many students.

(iii) FAC-DEPT A many-to-one relationship between the entity sets

FACULTY & DEPT with descriptive attribute DOJ (Date of Joining). This
implies that a Dept can have many faculty but a faculty can belong to only
one Dept.

P S Gill
 9

The above Database can be represented by the following E-R

Diagram:-

Aggregated Relationship “SUB-OFFERED” S_Name

Roll_No
Sub_Code
Semester
S_Add
Title r
Marks

SUBJECT STUDENT
RESULT

SUB-
OFFERED

Dept_Nam
e HOD
Fac_Code

Fac_Name

FACULTY DEPT
FAC-DEPT
Relational Database:-

The above scenario can be represented by the following Relational

Schemas:-

STUDENT (Roll_No, S_Name)

SUBJECT(Sub_Code, Title, Semester)
DEPT (D_Name, HOD)
FACULTY (Fac_Code, Fac_Name, D_Name)
SUB_OFFERED (Fac_Code, Sub_Code)
RESULT (Roll_No, Fac_Code, Sub_Code, Marks)

No table is required for the “one-to-many” relationship set “FAC-DEPT”; it

is combined with the “many-side” entity-set “FACULTY”; that is why the table for
“FACULTY” also includes the Primary Key “Dept_Name” of entity set “DEPT”.

P S Gill
 10

The attribute “Dept_Name” forms a Foreign Key in table “FACULTY”, referencing

the Primary Key of table “DEPT”.

“SUB_OFFERED” represents a “many-to-many” relationship between the

entity sets “FACULTY” and “SUBJECT”; that is why the table “SUB_OFFERED”
contains primary keys of both participating entity sets. The attributes “Fac_Code”
and “Sub_Code” form foreign keys in this table; “Fac_Code” is referencing the
primary key of “FACULTY” and “Sub_Code” is referencing the primary key of
“SUBJECT”.

The relationship set “RESULT” represents a “many-to-many” relationship

between aggregated relationship set “SUB_OFFERED” and entity set
“STUDENT”. The table “RESULT” includes its descriptive attribute “Marks” and
the primary keys of both “SUB-OFFERED” and “STUDENT”. The attributes
“Roll_No”, “Sub_Code” and “Fac_Code” form foreign keys in table “RESULT”.

Schema Diagram The Schema diagram represents diagrammatically the Relation

Schemas of a database. A Relation Schema is depicted by a rectangle, divided into
two parts- the top part depicts key-attributes and the bottom part depicts the non-
key attributes. As compared to E-R Diagram, the Schema Diagram also depicts
PK-FK relationship between various relation schemas, by a directed edge drawn
from FK to PK. The above E-R Diagram can be represented by a Schema
Diagram, as follows:-

SUBJECT RESULT STUDENT

Sub_Code Roll_No Roll_No
S_Name
Title Sub_Code

Fac_Code
Semester S_Addr
Marks

SUBJECT-OFFERED FACULTY DEPT

Fac_Code Dept_Name
Sub_Code
Fac_Name

Dept_Name HOD
Fac_Code

P S Gill
 11

Exercises

Ex.3.1 Explain mathematically a relation (table) “r” defined on a Schema R (A1,

A2, ….., An). Define its degree and cardinality.

EX.3.2 Explain the concepts of Domain Constraint, Key Constraint and

Referential Integrity Constraint.

Ex.3.3 Make Schema diagrams for the following set of schemas:-

(a) Student (Roll_No, S_Name, S_Address)

Subject (Sub_Code, Title, Credits, Semester)
Dept (D_Code, D_Name, HOD)
Faculty (F_Code, F_Name, D_Code)
Assigned (F_Code, Sub_Code)
Result (Roll_No, Sub_Code, Semester, Marks)

(b) Emp (E#, E_Name, Salary, D#)

Dept (D#, D_Name, Mgr#, Total_Salary)

Where D# is foreign key in Emp referencing D# of Dept and Mgr# is

foreign key in Dept referencing E# of Emp.

(c ) Supplier (S#, S_Name, S_City)

Part (P#, P_Name, P_Weight)
Project (J#, J_Name, J_City, Manager)
Order (S#, P#, J#, Qty)

Ex.3.4 What additional information is conveyed by a Schema Diagram as

compared to an E-R Diagram?

P S Gill
 12

P S Gill