ITE 2422 – Database Management Systems Week 05

7.0 Relational Model

Introduction

During this 7th lesson you will learn about main concepts in a relational data model
that will be useful in creating a relational database. In the last few lessons you have
learnt about creating a proper ER and EER diagram to a given scenario. Subsequently,
in lesson 8 (next week), you will learn how to convert an ER/EER diagram to a
relational model. Thus, before that we need to understand the concepts used in
structuring data in a relational model.

Let us start the lesson 7.

Learning outcomes

After completing this lesson, you will be able to understand basic concepts in a
relational model and different types of constraints to be considered in creating a
relational model.

From this lesson you will be able to understand,

• An overview of the relational model
• Characteristics of a relational model
• Types of constraints
o Key constraint
o Entity integrity constraint
o Referential integrity constraint
o Domain constraint

In Week 1, we have learnt about data models. Relational model is one such type of a
data model used to define the data to be stored.

Relational Model 1/17

 ITE 2422 – Database Management Systems Week 05

Moreover, after designing the ER or EER diagrams, we can convert it to a relational

model. When creating the relational database, we will be using the data storage
structure defined in the relational model.

Let’s try to understand what a relation model is.

7.1 Relational Model Concept

In the relational data model, there will be a collection of relations. Each relation is
related to another relation.

First, it is important to understand what a relation is.

Informally, we can recognize a relation as a table with columns and rows (See Figure
7.1). Each row in a table represents a collection of related data values. Rows in a
table represent a real-world entity or relationship. Then the table name and column
name are used to interpret the values in each row.

Attributes Relation Name

Student

Name AddmissionNo HomePhone City Age GPA

Jagath Adikari A01201 011 2685043 Colombo 7 20 3.4

Radha Shiva A01204 081 2225741 Kandy 21 3.2

Damani Perera A01307 null Nugegoda 26 3.8

Sam Huk A01219 091 2233222 Galle 28 3.9

Tuples Figure 7.1: Student relation

Relational Model 2/17

ITE 2422 – Database Management Systems Week 05

As illustrated in Figure 7.1, as per formal relational model terminology, row (or a
record) is known as a tuple, column header is called an attribute (or a field) and a
table is called a relation. Each relation will have a name (e.g. Student, Module).

In a relation, there are two key terms as degree and cardinality.

• Degree of Relation − The number of attributes in the given relation schema
• Cardinality of Relation − The number of Tuples in the relation

So, what is the cardinality of Student relation in Figure 7.1? Answer is 4.

What is the degree of student relation? Answer is 6.

As you can notice in Figure 7.1, all the values in a column are of the same data type
(except for null value, which we will discuss later in this lesson). For example, Age
column has integer values and Name column has String values. The data type
describing the type of values that appear in each column is represented by a domain
of possible values.

A value in a tuple can be an element from the domain of a specific attribute or a null
value. The NULL is the term used to represent a missing value.

So, what is a domain?

7.1.1 Domain
A domain is a set of atomic values. By atomic value, we mean that each value in the
domain is indivisible as far as the relational model is concerned.

For example;
• The domain of First Name is the set of character strings that represents names
of people.

Relational Model 3/17

ITE 2422 – Database Management Systems Week 05

• The domain of Marital Status has a set of possibilities: Single, Married,

Divorced.
• The domain of Employee Age is of all integer values between 18 and 65 years.
• The domain of Salary is the set of all real (floating-point) numbers greater than
0 and less than 200,000.
• The domain of Grade Point Average (GPA) is the set all real (floating-point)
number between 0 and 4.2.

A domain is specified with the name of the domain, a data type and set of its
properties.

Data types refers to type of data that you are going to store in a column of a table.
Mainly, we can categorize data types in MySQL (one of the types of relational
database management systems) as Numeric data type, String data type and Date and
Time data type. In addition, there are spatial types, and the JSON data type. Some of
the common data types for each category are given below (note that it is not an
exhaustive list).

Numeric data types:

• INT - An integer that can be signed or unsigned. If signed, the allowable range
is from -2147483648 to 2147483647. If unsigned, the allowable range is from 0
to 4294967295.
• FLOAT(M,D) − A floating-point number (approximate value) that cannot be
unsigned. Here, M represents the display length and D represents the number
of decimals. The default will be (10,2); where 2 is the number of decimals and
10 is the total number of digits (including decimals).
• DECIMAL(M,D) − An floating-point number (exact value) that cannot be
unsigned. Here, M represents the display length and D represents the number
of decimals. NUMERIC is a synonym for DECIMAL.

Relational Model 4/17

ITE 2422 – Database Management Systems Week 05

String data types:

• CHAR(M) − A fixed-length string between 1 and 255 characters in length.
Defining a length is not required (default is 1).
• VARCHAR(M) − A variable-length string between 1 and 255 characters in length.
You must define a length when creating a VARCHAR field.
• TEXT – It holds large amounts of data. You do not define a length.

Date and Time data type:

• DATE − A date in YYYY-MM-DD format, between 1000-01-01 and 9999-12-31. For
example, November 30th, 2018 would be stored as 2018-11-30.
• DATETIME − A date and time combination in YYYY-MM-DD HH:MM:SS format,
between 1000-01-01 00:00:00 and 9999-12-31 23:59:59. For example, 5:30 PM
on November 30th, 2018 would be stored as 2018-11-30 17:30:00.
• TIMESTAMP − A timestamp between midnight, January 1st, 1970 and sometime
in 2037. This looks like the DATETIME format without the hyphens between
numbers as YYYYMMDDHHMMSS. For example, 5:30 PM on November 30th, 2018
would be stored as 20191130173000
• TIME – This stores the time in a HH:MM:SS format.

Note: For more details refer, MySQL reference manual

Data types of the above defined attributes with domains are;

• First_Name – varchar(20)
• Marital_Status – varchar(10)
• Age - int
• Salary – decimal(8,2)
• GPA – decimal(3,2)

Relational Model 5/17

ITE 2422 – Database Management Systems Week 05

MySQL does not have built-in Boolean type to indicate values true/false or yes/no.
However, it uses TINYINT(1) instead. To make it more convenient, MySQL provides
BOOLEAN or BOOL as the synonym of TINYINT(1).

Other than the data type, a domain for an attribute can be defined with a format.
For example;
• The USA_phone_numbers may have a format: (ddd)ddd-dddd where each d is a
decimal digit.
• Dates have various formats such as year, month, date formatted as yyyy-mm-
dd, or as dd mm,yyyy etc.

Moreover, when defining a domain for an attribute we can provide additional

information. For an example, a numeric domain like a person’s weight – should have
unit of measurement, kilo grams

Several attributes can be from the same domain. For example, HomePhone,
OfficePhone are in the same domain.

7.1.2 Relation Schema and Relation State

Relation is made up of 2 parts as schema and state (instance).

Schema is used to describe a relation. It is denoted by R(A1, A2,…, An). It is made up

of a relation name R and a list of attributes A1, A2, …. An. It specifies name of
relation, plus name and type of each column.

For example the relation schema for Student relation in Figure 7.1 is,
Student(Name: varchar(20), AddmissionNo: char(6), HomePhone: integer, City:
varchar(20), Age: integer, GPA: decimal(3,2))

State (instance) is a table, with rows and columns. Relation state is a set of n-tuples
r= {t1, t2, …, tn}.

Relational Model 6/17

ITE 2422 – Database Management Systems Week 05

Current relation state is a relation state at a given time. It reflects only the valid
tuples that represent a particular state of the real world and it changes as the state
of the real-world changes.

Compared to relation state, relation schema is relatively static. As adding a new

column is not common as adding new records to a table.

Do Activity 7.1, to understand the termology used in a relational model.

Activity 7.1

Identify the formal terms used in a relational model for the following terms given below.

• Table
• All the possible values for a column
• Row in a table
• Definition of a table structure
• Populated table

In the next section, you will learn about characteristics of a relation.

7.2 Characteristics of a Relation

The characteristics mentioned below will make a relation different from a table.
1. Ordering of Tuples in a Relation
As you know, a relation is a set of tuples. Mathematically we can say, elements
of a set have no order among them. Therefore, we can say tuples in a relation
do not have any particular order (tuple ordering is not part of a relation
definition).
However, when we display a relation as a table, the rows are displayed in a
certain order. Many logical orders can be specified on a relation. For example,

Relational Model 7/17

ITE 2422 – Database Management Systems Week 05

we can order tuples in Student relation in Figure 7.1, by Name, Age, or

AdmissionNo.
Table 7.1: Student (a)

Name AddmissionNo HomePhone City Age GPA

Jagath Adikari A01201 011 2685043 Colombo 7 20 3.4

Radha Shiva A01204 081 2225741 Kandy 21 3.2
Damani Perera A01307 null Nugegoda 26 3.8
Sam Huk A01219 091 2233222 Galle 28 3.9

Table 7.2: Student (b)

Name AddmissionNo HomePhone City Age GPA

Jagath Adikari A01201 011 2685043 Colombo 7 20 3.4

Sam Huk A01219 091 2233222 Galle 28 3.9
Damani Perera A01307 null Nugegoda 26 3.8
Radha Shiva A01204 081 2225741 Kandy 21 3.2

What can we tell about Student (a) and Student (b) relations? Are those
relations the same?
Yes, they are the same. We do not care about the ordering of tuples in a table.

2. Ordering of Values within a Tuple

There are two definitions we can consider.
o First Definition: An n-tuple is an ordered list of n values. t = <v 1, v2, v3…
vn> where each value vi, is an element from the domain of an attribute
Ai or a null value. ith value in tuple t corresponds to attribute A i, is
referred to as t[Ai] (or t[i] if we use the positional notation). Here, 1 ≤ i
≤ n.
e.g. < ‘Jagath Adikari’, ‘A01201’, ‘011 2685043’, ‘Colombo 7’, 20, 3.4>

Here, the 5th value represents the age of a student.

Relational Model 8/17

ITE 2422 – Database Management Systems Week 05

That is, t[Age] = t[5] = 20.

As per the example given below, we can say that ordering of a relational
schema is important when ordering of values in a tuple.

o Alternative Definition: Ordering of values in a tuple is unnecessary

A tuple can be considered as a set of (<attrbiute>, <value>) pairs
e.g.
< (Name, ‘Jagath Adikari’), (AdmissionNo, ‘A01201’), (HomeTelephone,
‘011 2685043’), (City, ‘Colombo 7’), (Age, 20), (GPA, 3.4)>
Or
< (Name, ‘Jagath Adikari’), (Age, 20), (AdmissionNo, ‘A01201’), (City,
‘Colombo 7’), (HomeTelephone, ‘011 2685043’), (GPA, 3.4)>

Here, ordering is not important as attribute name appears with its value.

3. Values and Nulls in the Tuples

Each value in a tuple is an atomic value. Hence, composite and multivalued
attributes are not allowed as a value in a tuple. Other than an atomic value, a
null value can be a value in a tuple. Null is used to represent values of
attributes that may be unknown, value exists but is not available, or may not
apply to a tuple.

4. Interpretation (Meaning) of a Relation

Each tuple in the relation can be interpreted as a fact or a particular instance
of the assertion. For example, first tuple asserts that there is a student whose
name is Jagath Adikari, AdmissionNo is A0120, Age is 20 and so on….

In the next section, we will be learning about the constraints of a relation.

Relational Model 9/17

ITE 2422 – Database Management Systems Week 05

7.3 Constraints of a Relation

There are three main categories of constraints; namely, inherent model-based
constraints, schema-based constraints, and application-based constraints.

• Inherent model-based constraints – Constraints that are inherent in the data

model. They are based on the characteristics of a relation (Section 7.2).
• Schema-based constraints – Constraints that can be directly expressed in the
schemas of the data model. It includes domain constraints, key constraints,
constraints on nulls, entity integrity constraints and referential integrity
constraints (we will discuss them later in this section).
• Application-based constraints – Constraints that cannot be expressed in the
schemas of the data model. Therefore, they are expressed and enforced by the
application programs. Since, this is not handled from the database level, we
will not discuss it here.

Now let’s discuss about schema-based constraints, one by one.

7.3.1 Domain Constraint

Within each tuple, the value of each attribute A must be an atomic value from the
domain dom(A). There should be a data type associated with a domain as we
discussed earlier in this lesson.

7.3.2 Key Constraint

A relation is set of tuples. Also, all the elements of a set are distinct. Therefore, all
the tuples in a relation should be distinct.
To get a better idea about this, lets try to understand the following terms first.
• Superkey (SK) is a subset of attributes in a relation where t 1[SK] ≠ t2[SK]
o It specifies no two distinct tuples in (any state r of) relation R can have
the same value for SK. Here, R stands for relation, r stands for relation
state and ti stands for the ith tuple.

Relational Model 10/17

ITE 2422 – Database Management Systems Week 05

o All the attributes together in a relation will be the default superkey. For
example, in Student relation in Figure 7.1, the default SK would be
{Name, AdmissionNo, HomePhone, City, Age, GPA}.

• Key (K) is a superkey of a relation R with the additional property that removing
any attribute A for K leaves a set of attributes K` that is not a superkey
anymore.
o A key satisfies two constraints:
1. Two distinct tuples in any state of the relation cannot have identical
values for (all) the attributes in the key. For example, two tuples in
Student relation in Table 7.3 are distinct (even though some of the
attributes have the same value).
Table 7.3: Student

Name AddmissionNo HomePhone City Age GPA

Jagath Adikari A01201 011 2685043 Colombo 20 3.4

Radha Shiva A01204 081 2225741 Colombo 20 3.4
Damani Perera A01307 011 2986754 Colombo 20 3.8

2. It is a minimal superkey. It is a superkey from which we cannot

remove any attributes and still have the uniqueness constraint in
condition 1 hold.
For example, Attribute set {AdmissionNo} is a key but Attribute set
{AdmissionNo, Name, Age} is a super key but not a key.

• Candidate key – If there are more than 1 key, each of keys is called a candidate
key.
For example, for a Person relation schema: Key1 ={NIC}, Key2= {PassportNo}

• Primary Key (PK) – Select one of the candidate keys as PK. Attributes that form
the primary key are underlined.

Relational Model 11/17

ITE 2422 – Database Management Systems Week 05

For example, in the Person relation mentioned above NIC is selected as the PK.
Select a key with a single attribute or small number of attributes as the PK.

7.3.3 NOT NULL Constraint

It specifies whether null values are allowed or not on an attribute. For example, the
Name of the Student Relation is constrained to be NOT NULL.

7.3.4 Entity Integrity Constraint

First, we should know, ‘what is an integrity constraint?’
An integrity constraint is a condition that must be true for any instance of the
database. e.g., domain constraints. This is specified when relation schema is defined,
and it will be checked when relations are modified. A valid instance of a relation
satisfies all specified integrity constraints. As such, a DBMS should not allow illegal
instances.

In entity integrity constraint, the primary key attributes, PK of each relation schema
R in S cannot have null values in any tuple of a relation instance of R. This is because
primary key values are used to identify the individual tuples. If PK is having a null
value, we cannot uniquely identify each tuple. If PK has several attributes, null is not
allowed in any of these attributes. For example, to uniquely identify each tuple in a
Student_Subject_Registration relation, there is a PK as {AdmissionNo, SubjectCode}.
Thus, AdmissionNo cannot have a null value. Similarly, SubjectCode cannot have a
null value.

Note: Based on the requirements of the database designer, any other attribute of R
may be constrained to disallow null values, even though they are not members of the
primary key.

Relational Model 12/17

ITE 2422 – Database Management Systems Week 05

7.3.5 Referential Integrity Constraint

This is a constraint involving two relations. The previous constraints we discussed
involve only a single relation. This is used to specify a relationship among tuples in
two relations known as the referencing relation and the referenced relation.

The tuples in the referencing relation R1 have attributes FK (called foreign key
attributes) that reference the primary key attributes PK of the referenced relation R 2.

For example,
Employee (EmployeeNo, NIC, FullName, Address, DOB, DNum)

Department (DNo, DeptName, DeptLocation)

As indicated above, a referential integrity constraint can be displayed in a relational

database schema as a directed arc from R1.FK to R2. Here, Employee is the
referencing relation and Department is the referenced relation.

Foreign key (FK) is a set of fields in one relation that is used to `refer’ to a tuple in
another relation. Here the FK is DNum in Employee relation.
A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK].

A set of attributes in R1 is a foreign key of R1 that references relation R2, if it satisfies

the following two rules:
1. The attributes in FK have the same domain as the primary key attributes,
PK of R2
2. A value of FK in a tuple t1 of the current state of R1 can be either a value of
PK for some tuple t2 in the current state of R2 or is null.
In case (2), the FK in R1 should not be a part of its own primary key.

A foreign key can refer to its own relation.

Relational Model 13/17

ITE 2422 – Database Management Systems Week 05

For example,
Employee (EmployeeNo, NIC, Address, DOB, Supervisor_EmployeeNo)

Here, EmployeeNo is the PK of Employee relation. Supervisor_EmployeeNo is an FK in

Employee relation and it is referencing the Employee relation.

Enforcing referential integrity constraint:

Consider Employee and Department relations; DNum in Employee relation is a foreign
key that references Department relation.

Employee (ENo, NIC, FullName, Address, DOB, DNum)

Department (DNo, DeptName, DeptLocation)

Let’s consider the following populated tables with data (relation instance).

Table 7.4: Employee Relation

ENo NIC FullName Address DOB DNum

1 765623455V Jagath Adikari 23, Galle Road, Colombo 3 1976-12-30 1

2 933426751V Radha Shiva 67, Main Street. Kandy 1993-03-14 2
3 872287421V Damani Perera 7, Colombo Road, 1987-05-10 3
Ginthota
4 785734246V Janith Govin 892, High Level Road, 1978-10-24 2
Nugegoda

Relational Model 14/17

ITE 2422 – Database Management Systems Week 05

Table 7.5: Department Relation

DNo DeptName DeptLocation

1 HR Level 1
2 Sales Level 1
3 Finance Level 2
4 Research Level 3

What should be done if a tuple is added to Employee relation with a non-existent

DNum is inserted? Reject it!

Let’s assume that you are adding a new employee who joined your organization and
trying to add DNum in Employee Relation as 5. DNo = 5 is not in the Department
Relation as such we cannot add a non-existent department number to the employee
relation (DNum in Employee relation is the FK referencing the Department relation).
Therefore, reject the insert.

What should be done if a tuple in Department relation is deleted?

Let’s assume that you are deleting the record in Department relation where DNo=2.

There are several options you can follow. They are;

• Delete all Enrolled tuples that refer to it.
As per our example, we can delete the records in the Employee table where
DNum =2. That is delete employee records with ENo =2 and 4.

• Or Disallow deletion of a Department tuple that is referred to.

Let’s consider our example again. If not, you can disallow the deletion of
Department record where DNo =2 since it is referred in the Employee relation.
However, you will be allowed to delete the Department record where DNo is 4
as it is not referred in the Employee relation.

Relational Model 15/17

ITE 2422 – Database Management Systems Week 05

• Or Set DNum in Employee tuples that refer to it to a default DNum.

You can set the DNum value in the 2 records affected in Employee relation
(ENo=2 and 4) to a default value. For example, set DNum to 1 (if 1 is the
default value). If not, you can set it to null.

Similar approach can be followed if primary key of a Department tuple is updated.

Do Activities 7.2 and 7.3 to get a better understanding of the constraints.

Activity 7.2

Identify the Foreign Keys of the relations given below.

Student (StudentNo, FirstName, LastName, Address, Telephone, Date_of_Birth, Gender)

Enrolment (StudentNo, SubjectNo, EnrolledDate)
Subject (SubjectNo, SubjectName, Credits)
BookAdoption (BookCode, SubjectNo, AdopedDate)
Book (Tile, BookCode, AuthorName, PublicationYear, Publisher, Edition)

Next do Activity 7.3.

Activity 7.3
Consider Table 7.4 and Table 7.5.

Identify the possible violations to the domain constraint, key constraint, entity integrity
constraint and referential integrity constraint when
• Inserting a tuple to Employee relation
• Modifying a tuple in the Employee relation (e.g. value in the DNum field)
• Deleting a record in the Department relation

Explain possible actions that can be taken to avoid the violations mentioned above.
Note: How to avoid referential integrity constraint when inserting/deleting a record is
explained in the lesson.

Relational Model 16/17

ITE 2422 – Database Management Systems Week 05

Summary
Now we have completed learning the Lesson 7. In this lesson, we discussed various
concepts in a relational model.

It is important to develop a relational model when creating a relational database.

When creating a relational model, it is important to learn about the terminology
used and the concepts. After creating a relation model, to structure the data in a
database, it is important to ensure that different constraints are not violated when
inserting/modifying/deleting tuples from relations.

In the lesson 8, you will learn more details about a relational model and how to
convert an ER/EER diagram to a relational model. Thus, you will be able to start
creating a relational database. Before you go to the next lesson, complete the
self-assessment Quiz to check what you have learnt in the Lesson 7.

Relational Model 17/17