Page |1

Unit 3: Relational Data Model

The relational data model was first introduced by Ted Codd of IBM Research in 1970 in a classic paper (Codd 1970),
and it attracted immediate attention due to its simplicity and mathematical foundation. The model uses the concept
of a mathematical relation—which looks somewhat like a table of values

Relational model concepts

The relational model represents the database as a collection of relations. each row in the table represents a collection
of related data values. A row represents a fact that typically corresponds to a real-world entity or relationship. The
table name and column names are used to help to interpret the meaning of the values in each row. For example, in
STUDENT table, each row represents facts about a particular department entity. The column names – —Name,
Student_number, Class, and Major specify how to interpret the data values in each row, based on the column each
value is in. All values in a column are of the same data type.
In the formal relational model terminology, a row is called a tuple, a column header is called an attribute, and the table
is called a relation. The data type describing the types of values that can appear in each column is represented by a
domain of possible values. We now define these terms—domain, tuple, attribute, and relation— formally.
A domain D is a set of atomic values. By atomic we mean that each value in the domain is indivisible as far as the
formal relational model is concerned. A common method of specifying a domain is to specify a data type from which
the data values forming the domain are drawn. It is also useful to specify a name for the domain, to help in interpreting
its values. Some examples of domains follow:
■ Usa_phone_numbers. The set of ten-digit phone numbers valid in the United States.
■ Local_phone_numbers. The set of seven-digit phone numbers valid within a particular area code in the United States.
The use of local phone numbers is quickly becoming obsolete, being replaced by standard ten-digit numbers.

■ Social_security_numbers. The set of valid nine-digit Social Security numbers. (This is a unique identifier assigned to
each person in the United States for employment, tax, and benefits purposes.)

■ Names: The set of character strings that represent names of persons.

■ Grade_point_averages. Possible values of computed grade point averages; each must be a real (floating-point)
number between 0 and 4.

■ Employee_ages. Possible ages of employees in a company; each must be an integer value between 15 and 80.

■ Academic_department_names. The set of academic department names in a university, such as Computer Science,
Economics, and Physics.

■ Academic_department_codes. The set of academic department codes, such as ‘CS’, ‘ECON’, and ‘PHYS’.

A data type or format is also specified for each domain. For example, the data type for the domain
Usa_phone_numbers can be declared as a character string of the form (ddd)ddddddd, where each d is a numeric
(decimal) digit and the first three digits form a valid telephone area code. The data type for Employee_ages is an
integer number between 15 and 80. For Academic_department_names, the data type is the set of all character strings
that represent valid department names. A domain is thus given a name, data type, and format.

A relation schema R, denoted by R(A1, A2, ..., An), is made up of a relation name R and a list of attributes, A1, A2, ...,
An. Each attribute Ai is the name of a role played by some domain D in the relation schema R. D is called the domain
of Ai and is denoted by dom(Ai ). A relation schema is used to describe a relation; R is called the name of this relation.
The degree (or arity) of a relation is the number of attributes n of its relation schema.
 Page |2

A relation of degree seven, which stores information about university students, would contain seven attributes
describing each student. as follows: STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa) Using the
data type of each attribute, the definition is sometimes written as: STUDENT(Name: string, Ssn: string, Home_phone:
string, Address: string, Office_phone: string, Age: integer, Gpa: real)

A relation (or relation state) r of the relation schema R(A1, A2, ..., An), also denoted by r(R), is a set of n-tuples r = {t1,
t2, ..., tm}. Each n-tuple t is an ordered list of n values t =, where each value vi , 1 ≤ i ≤ n, is an element of dom (Ai ) or is
a special NULL value. Figure 3.1 shows an example of a STUDENT relation, which corresponds to the STUDENT schema
just specified. Each tuple in the relation represents a particular student entity (or object). We display the relation as a
table, where each tuple is shown as a row and each attribute corresponds to a column header indicating a role or
interpretation of the values in that column.

Figure 3.1 The attributes and tuples of a relation STUDENT

Using the set theory concepts, the relation can be defined as follows:

A relation (or relation state) r(R) is a mathematical relation of degree n on the domains dom(A1), dom(A2), ...,
dom(An), which is a subset of the Cartesian product (denoted by ×) of the domains that define R:

r(R) ⊆ (dom(A1) × dom(A2) × ... × dom(An)).

The Cartesian product specifies all possible combinations of values from the underlying domains. Hence, if we
denote the total number of values, or cardinality, in a domain D by |D| (assuming that all domains are finite), the
total number of tuples in the Cartesian product is

|dom(A1)| × |dom(A2)| × ... × |dom(An)|

This product of cardinalities of all domains represents the total number of possible instances or tuples that can ever
exist in any relation state r(R). Of all these possible combinations, a relation state at a given time—the current
relation state—reflects only the valid tuples that represent a particular state of the real world. In general, as the
state of the real world changes, so does the relation state, by being transformed into another relation state.

Characteristics of relations

Relational model constraints

They are the various restrictions on data that can be specified on a relational database. Constraints on databases can
generally be divided into three main categories:

1. Constraints that are inherent in the data model. We call these inherent model-based constraints or implicit
constraints.
 Page |3

2. Constraints that can be directly expressed in schemas of the data model, typically by specifying them in the DDL.
We call these schema-based constraints or explicit constraints.

3. Constraints that cannot be directly expressed in the schemas of the data model, and hence must be expressed and
enforced by the application programs. We call these application-based or semantic constraints or business rules.

1 Domain Constraints
Domain constraints specify that within each tuple, the value of each attribute A must be an atomic value from the
domain dom(A). The data types associated with domains typically include standard numeric data types for integers
(such as short integer, integer, and long integer) and real numbers (float and doubleprecision float), Characters,
Booleans, fixed-length strings, and variable-length strings,date, time, timestamp etc

2 Key Constraints
They state that no two tuples in any relation state r of R should have the same combination of values for these
attributes.

Suppose that we denote one such subsetof attributes by SK; then for any two distinct tuples t1 and t2 in a relation
state r of R,we have the constraint that:

t1[SK]≠ t2[SK]

A superkey SK specifies a uniqueness constraint that no two distinct tuples in any state r of R can have the same
value for SK.

A key K of a relation schema R is a superkey of R with the additional property that removing any attribute A from K
leaves a set of attributes K that is not a superkey of R any more.

Hence, a key satisfies two properties:

1. Two distinct tuples in any state of the relation cannot have identical values for (all) the attributes in the key. This
first property also applies to a superkey.

2. It is a minimal superkey—that is, a superkey from which we cannot remove any attributes and still have the
uniqueness constraint in condition 1 hold.This property is not required by a superkey.

The attribute set {Ssn} is a key of STUDENT because no two student tuples can have the same value for Ssn. 8 Any set
of attributes that includes Ssn—for example, {Ssn, Name, Age}—is a superkey. However, the superkey {Ssn, Name,
Age} is not a key of STUDENT because removing Name or Age or both from the set still leaves us with a superkey.

A relation schema may have more than one key. In this case, each of the keys is called a candidate key. For example,
the CAR relation in Figure 3.4 has two candidate keys: License_number and Engine_serial_number. It is common to
designate one of the candidate keys as the primary key of the relation. This is the candidate key whose values are
used to identify tuples in the relation.

3 Integrity constraints
 Page |4

The entity integrity constraint states that no primary key value can be NULL. This is because the primary key value is
used to identify individual tuples in a relation. Having NULL values for the primary key implies that we cannot
identify some tuples. For example, if two or more tuples had NULL for their primary keys, we may not be able to
distinguish them if we try to reference them from other relations.

This is also known as primary key constraint

4 Referential integrity constraint

It states that a tuple in one relation that refers to another relation must refer to an existing tuple in that relation. For
example, the attribute Dno of EMPLOYEE gives the department number for which each employee works; hence, its
value in every EMPLOYEE tuple must match the Dnumber value of some tuple in the DEPARTMENT relation which is
already existing.

The conditions for a foreign key, given below, specify a referential integrity constraint between the two relation
schemas R1 and R2. A set of attributes FK in relation schema R1 is a foreign key of R1 that references relation R2 if it
satisfies the

following rules:

1. The attributes in FK have the same domain(s) as the primary key attributes PK of R2; the attributes FK are said to
reference or refer to the relation R2.

2. A value of FK in a tuple t1 of the current state r1(R1) either occurs as a value of PK for some tuple t2 in the current
state r2(R2) or is NULL. In the former case, we have t1[FK] = t2[PK], and we say that the tuple t1 references or refers
to the tuple t2.

This is also known as foreign key constraint

5 NULL values
It specifies whether NULL values are permitted or not. For example, if every STUDENT tuple must have a valid, non-
NULL value for the Name attribute, then Name of STUDENT is constrained to be NOT NULL.

Relational Algebra
These operations enable a user to specify basic retrieval requests as relational algebra expressions. The result of a
retrieval is a new relation, which may have been formed from one or more relations.

The SELECT Operation

The SELECT operation is used to choose a subset of the tuples from a relation that satisfies a selection condition.One
can consider the SELECT operation to be a filter that keeps only those tuples that satisfy a qualifying condition.

For example, to select the EMPLOYEE tuples whose department is 4, or those whose salary is greater than $30,000,
we can individually specify each of these two conditions with a SELECT operation as follows:

σDno=4(EMPLOYEE) σSalary>30000(EMPLOYEE)

In general, the SELECT operation is denoted by

 Page |5

where the symbol σ (sigma) is used to denote the SELECT operator and the selection condition is a Boolean
expression (condition) specified on the attributes of relation R. comparison operator is normally one of the operators
{=,<,≤,>, ≥, ≠}.For example, to select the tuples for all employees who either work in department 4 and make over
$25,000 per year, or work in department 5 and make over $30,000, we can specify the following SELECT operation:

would correspond to the following SQL query:

SELECT *
FROM EMPLOYEE
WHERE Dno=4 AND Salary>25000;
The result is shown in here:

The PROJECT Operation

The PROJECT operation, on the other hand, selects certain columns from the table and discards the other columns. If
we are interested in only certain attributes of a relation, we use the PROJECT operation to project the relation over
these attributes only.

For example, to list each employee’s first and last name and salary, we can use the PROJECT operation as follows:

would correspond to the following SQL query:

SELECT DISTINCT Lname,Fname, Salary

FROM EMPLOYEE

RENAME Operation

Sometimes, we need to feed the result of one query to another query. In such situations, we have to rename the
intermediary results. To rename the attributes in a relation, we simply list the new attribute names in parentheses,
as in the following example:

Result of this expression is shown below:

 Page |6

Set theory

The UNION(ᴜ), INTERSECTION(Ⴖ), and MINUS(-) Operations