The Relational Model

Elisa Bertino
CS Department and CERIAS
Purdue University

1
 The relational model
 It was developed by E. F. Codd in 1970 to
enhance data independency and adopted as
logical model in DBMS in 1980
 It is based on the mathematical notion of
relation; the model has thus a theoretical
foundation that supports a formal definition of
operations and properties of data
 The relations can be naturally represented by
tables
2
 The relational model
 The relational model, even though it has not been
the first data model, has become the most widely
used and today is used in almost all commercial
DBMS
 The reason of its popularity is that it provides
languages that are simple and declarative, and
powerful at the same time, to express operations
for data access and manipulation

3
 Relation
 Let D1, D2, …, Dn be n sets of values (not necessarily
distinct)
 The Cartesian product D1×D2×…×Dn, is the set of all tuples
(d1, d2, …, dn) such that d1D1, d2  D2, …, dn  Dn
 A relation on D1, D2, …, Dn is a (finite) subset of the
Cartesian product D1×D2×…×Dn
 D1, D2, …, Dn are called domains of the relation
 A relation defined on n domain has degree n
 The number of tuples in the relation is the relation
cardinality
4
 Domains
 A domain is a set (possibly infinite) of values
 Examples:
 The set of the integer numbers
 The set of all character strings of length 20
 The set {0,1}

5
 Example
 D1={a,b} a x
a y
 D2={x,y,z}
a z
 Cartesian Product D1 × D2
b x
b y
b z

a x
a z
 A relation r  D1 × D2 b y
b z
6
 Relation – some properties
 According to the definition, a relation is a set of
tuples:
(d1, d2,…, dn) such that d1D1, d2  D2,…, dn  Dn
 A relation is a set, thus:
 no ordering is defined among the set of tuples
 each tuple in a relation is distinct from all the other tuples
in the relation
 A tuple is internally ordered: the i-th value of each
tuple is a value from the i-th domain
7
 Notation
 Let r a relation of degree k:
 let t be a tuple of r
 let i an integer in the set {1,...,k}
 t[i] denote the i-th component of t

 Example:
 let r={(0,a), (0,c),(1,b)}
 let t=(0,a) be a tuple of r
 t[2] = a
 t[1] = 0

8
 Relational model
 We can see a relation as a table, in which each
row is a tuple and each column corresponds to a
component
 Each column has associated a name; such
names are called
attribute names
 The pair (attribute name, domain) is called
attribute
 The set of attributes of a relation is the schema
of the relation
9
 Relational model - Notation
 If a relation has name R and attributes with
names A1, A2,...,Ak, the schema is often denoted
by
R(A1, A2,...,Ak)
 In addition UR = {A1, A2,...,Ak} denotes the set of
all the attribute names of R

10
 Example
 Info_Cities
 Schema: Info_Cities(City,Region,Population)

City Region Population

Rome Lazio 3000000
Milan Lombardy 1500000
Genoa Liguria 800000
Pisa Tuscany 150000
11
 Relational model
 In such definition of the relational model, the components of
tuples are denoted by the names (notation based on names as
opposed to the positional notation)
 Given a relation schema R(A1, A2,...,Ak), a tuple t on such
schema can be represented as
[A1:v1, A2:v2,...,Ak:vk]
Where vi (i=1,..,k) is a value belonging to the set which is the
domain of attribute Ai (denoted by dom(Ai))
 t[Ai] denotes the value of attribute Ai for the tuple t

12
 Example
 t=[City: Rome, Region: Lazio, Population:
3000000]
 Is a tuple defined on the schema Info_City

 Positional notation
 t[1] = Rome
 t[City] = Rome
The value of attribute City for the tuple t is Rome

13
 Null Values
 In some cases, information certain entities of the
domain of interest may be missing:
 some tuples may not have a value for one or
more attributes
 The lack of a value is handled through the use of
a special value (null value) denoting the
absence of a value (often denoted by “?”)
 The presence of null value requires using a 3-
value Boolean logic for predicate evaluation
14
 The notion of key
 Given a relation, a key of the relation is a set of
attributes the values of which are unique for
each tuple in the relation
 More precisely, a set X of attributes of a relation
R, is a key of R if verifies both the following
properties:
1. For each state of R, there are no two distinct tuples in
R having the same value for all attributes in X
2. No proper subset of X verifies property (1)

15
 Example
In the previous example on cities:
 key(Info_Cities) = {City}
 If no two cities exist with the same name in different
regions
 key(Info_Cities) = {City,Region)
 If different cities may exist having the same name in
different regions

16
 The notion of key
 A key cannot have null values
 A relation can have more than one attribute set
verifying the properties of keys
 In some cases, one has to choose a key if the
used system does not support multiple keys.
 In such case, the term candidate keys is used to refer
to all possible keys
 The term primary key is used to refer to the selected
key

17
 The notion of foreign key
 Let R and R’ be two relations such that:
 R has a set X of attributes
 R' has a set Y of attributes as key
 Y is an external key of R on R’ if Y is a subset of
X
 In other words, if a relation R includes, among its
attributes, a set of attributes which is the key of a
relation R’, then such attribute set is an external
key of R on R’
 R’ is called referenced relation
18
 The notion of foreign key
 The foreign keys allow one to connect tuples of
different relations; they represent a value-based
mechanism to represent relationships among
entities
 A tuple that must reference another tuple t needs
thus to include among its attributes the values of
the key of t

19
 Example

 Let define two relations representing information

concerning the employees and departments of a
company:
 Employees(Emp#,Name,Job,HiringD,Salary,Bonus,Dept#)
 key(Employees) = {Emp#}
 Foreign_key(Employees) = {Dept#}
 (referenced relation: Departments)
 Departments(Dept#,DeptName,Office#,Division,Manager)
 key(Departments) = {Dept#}

20
 Employees
Emp# Name Job HiringD Salary Bonus Dept#
7369 Red Engineer 17/12/80 1600.00 500.00 20
7499 Andrews Technician 20/02/81 800.00 ? 30
7521 White Technician 20/02/81 800.00 100.00 30
7566 Pink Manager 02/04/81 2975.00 ? 20
7654 Martin Secretary 28/09/81 800.00 ? 30
7698 Black Manager 01/05/81 2850.00 ? 30
7782 Neri Engineer 01/06/81 2450.00 200.00 10
7788 Scott Secretary 09/11/81 800.00 ? 20
7839 Dare Engineer 17/11/81 2600.00 300.00 10
7844 Turni Technician 08/09/81 1500.00 ? 30
7876 Adams Engineer 23/09/81 1100.00 500.00 20
7900 Gianni Engineer 03/12/81 1950.00 ? 30
7902 Ford Secretary 03/12/81 1000.00 ? 20
7934 Mill Engineer 23/01/82 1300.00 150.00 10
7977 Green Manager 10/12/80 3000.00 ? 10
21
 Departments
Dept# DeptName Office# Division Manager
Building
10 1100 D1 7977
Construction
20 Research 2200 D1 7566
30 Road Maintenance 5100 D2 7698

22
 Referential integrity
 Referential integrity represents an important
semantic integrity constraint
 If a tuple t contains a foreign key with values v 1,
…,vn then the referenced relation must contain a
tuple t’ that has as values of its key v 1,…,vn
 The relations Employees and Departments verify
the referential integrity

23
 Referential integrity
 Suppose that the following tuple be inserted in the
Employee relation:
 [Emp#: 7899, Name: Smith, Job: technician, HiringD:03-Dic-81,
Salary:2000, Bonus: 100, Dept#: 50]
 Such tuple violates the referential integrity in that no
department exists (in the Departments relation) that has
as value for the key the value 50.

Dept# DeptName Office Division Manager

10 Building Construction 1100 D1 7977
20 Research 2200 D1 7566
30 Road Maintenance 5100 D2 7698
24
 Referential integrity
 The database languages (SQL) allows the
database designer to specify for which relations
and for which attributes the referential integrity
has to be maintained (and the actions to be
executed in case of violations)

25