Relational

Relational Model

Cutajar & Cutajar

Overview

The relational model was formally introduced by Dr. E. F. Codd in
1970 and has evolved since then, through a series of writings. The
model provides a simple, yet rigorously defined, concept of how
users perceive data. The relational model represents data in the
form of two-dimension tables. Each table represents some real-
world person, place, thing, or event about which information is
collected. A relational database is a collection of two-dimensional
tables. The organization of data into relational tables is known as
the logical view of the database. That is, the form in which a
relational database presents data to the user and the programmer.
The way the database software physically stores the data on a
computer disk system is called the internal view.

Databases 2

Topics
 A basic understanding of the relational model is necessary to effectively use
relational database software such as Oracle, Microsoft SQL Server, or even
personal database systems such as Access or Fox, which are based on the
relational model.
 This section discusses the basic concepts—data structures, relationships,
and data integrity—that are the basis of the relational model.
 Data Structure and Terminology
 Notation
 Properties of Relational Tables
 Relationships and Keys
 Data Integrity
 Relational Data Manipulation
 Normalization
 Advanced Normalization

Databases 3

Data Structure and
Terminology
In the relational model, a database is a collection of relational tables. A
relational table is a flat file composed of a set of named columns and
an arbitrary number of unnamed rows. The columns of the tables
contain information about the table. The rows of the table represent
occurrences of the "thing" represented by the table. A data value is
stored in the intersection of a row and column. Each named column
has a domain, which is the set of values that may appear in that
column. Named
Domain = (M, F)
Columns

Surname Name Sex Age
Cauchi John M 35
Data Occurrences
Pace Mary F 39
Databases 4

A Relational Database
AUTHOR
au_id au_lname au_fname address city
Relational tables for a simple 12-123 Pace George 7, Main Street Balzan
bibliographic database that 13-344 Grasso Anton 23, Republic Street Marsa

stores information about 45-456 Xuereb Peter 45, St. John Street Zejtun

book title, authors, and 12-332 Zammit Mary 12, Oratory Street Paola
33-345 Pule Anna 1, Paules Street Zabbar
publishers. 77-666 Xuereb Desmond 34, Goconda Ave. B’Kara

TITLE AUTHOR-TITLE
title_id title type price pub_id au_id title_id
GA023 Hobz biz-zejt Gastronomy 1.50 112
PUBLISHER 12-123 GA023
GA104 Hmira Fina Gastronomy 2.04 564 pub_id pub_name city 12-123 GA104
CM002 Virus Alert Computers 9.10 322 112 PEG Marsa 12-322 SP221
CM776 How to switch off Computers 12.50 322 113 McGraw Valletta 13-344 CM002
CM023 Bill Gates Rules Computers 0.20 223 223 Penta Msida 13-344 CM776
SP221 Surfing on shore Sports 12.40 113 322 SKS Msida 33-345 SP273
SP233 Football Shots Sports 5.50 113 564 Media Zejtun 45-456 CM023
SP273 Pascal tar Roti UNDECIDED 986 986 RTF Marsa 77-666 SP223

Databases 5

Alternative Names

There are alternate names used to describe relational
tables. Some manuals use the terms tables, fields, and
records to describe relational tables, columns, and rows,
respectively. The formal literature tends to use the
mathematical terms, relations, attributes, and tuples.

Many Database
Here Formal Terms
Manuals
Relational Table Relation Table
Column Attribute Field
Row Tuple Record

Databases 6

Notation

 Relational tables can be expressed concisely by
eliminating the sample data and showing just the table
name and the column names. For example:

AUTHOR (au_id, au_lname, au_fname, address, city)

TITLE (title_id, title, type, price, pub_id)

PUBLISHER (pub_id, pub_name, city)

AUTHOR_TITLE (au_id, pub_id)

Databases 7

Properties of Relational
Tables

Relational tables have six properties:
 Values are atomic.
 Column values are of the same kind.
 Each row is unique.
 The sequence of columns is insignificant.
 The sequence of rows is insignificant.
 Each column must have a unique name.

Databases 8

Values are Atomic

 This property implies that columns in a relational
table are not repeating group or arrays. Such tables
are referred to as being in the "first normal form"
(1NF). The atomic value property of relational tables
is important because it is one of the cornerstones of
the relational model.
 The key benefit of the one value property is that it
simplifies data manipulation logic.

Databases 9

Column Values are of the
Same Kind
 In relational terms this means that all values in a
column come from the same domain. A domain is a
set of values which a column may have. For example,
a Monthly_Salary column contains only specific
monthly salaries. It never contains other information
such as comments, status flags, or even weekly
salary.
 This property simplifies data access because
developers and users can be certain of the type of
data contained in a given column. It also simplifies
data validation. Because all values are from the same
domain, the domain can be defined and enforced with
the Data Definition Language (DDL) of the database
software.
Databases 10

Each Row is Unique

 This property ensures that no two rows in
a relational table are identical; there is at
least one column, or set of columns, the
values of which uniquely identify each
row in the table. Such columns are called
primary keys and are discussed in more
detail in Relationships and Keys.
 This property guarantees that every row
in a relational table is meaningful and
that a specific row can be identified by
specifying the primary key value.
Databases 11

The Sequence of Columns is
Insignificant

 This property states that the ordering of
the columns in the relational table has
no meaning. Columns can be retrieved
in any order and in various sequences.
The benefit of this property is that it
enables many users to share the same
table without concern of how the table is
organized. It also permits the physical
structure of the database to change
without affecting the relational tables.

Databases 12

The Sequence of Rows is
Insignificant
 This property is analogous the previous one but
applies to rows instead of columns. The main benefit
is that the rows of a relational table can be retrieved
in different order and sequences. Adding information
to a relational table is simplified and does not affect
existing queries.

Databases 13

Each Column Has a Unique
Name
 Because the sequence of columns is insignificant,
columns must be referenced by name and not by
position. In general, a column name need not be unique
within an entire database but only within the table to
which it belongs.

Peppi Pawlu Pietru

Databases 14

Relationships and Keys

 A relationship is an association between two or more
tables. Relationships are expressed in the data
values of the primary and foreign keys.
 There are primarily four types of keys:
 Primary Key
 Foreign Key
 Candidate Key
 Secondary Key

Databases 15

Types of Keys
 A primary key is a column or columns in a table whose values
uniquely identify each row in a table.
 A foreign key is a column or columns whose values are the same
as the primary key of another table. You can think of a foreign key
as a copy of primary key from another relational table.
 If there is more than one key whose values uniquely identify each
row, then these keys are called candidate keys. The key chosen to
select the particular row in the database is called the Primary Key,
while the other candidate keys are called secondary keys.
The relationship is made between two relational
tables by matching the values of the foreign key in
one table with the values of the primary key in
another.

Databases 16

Database Navigation

Keys are fundamental to the concept of
relational databases because they enable
tables in the database to be related with
each other. Navigation around a relational
database depends on the ability of the
primary key to unambiguously identify
specific rows of a table. Navigating between
tables requires that the foreign key is able to
correctly and consistently reference the
values of the primary keys of a related table.

Databases 17

Example

For example, keys in the AUTHOR-TITLE
relational tables are used to au_id (FK) title_id (FK)
navigate from AUTHOR to
12-123 GA023
TITLE to PUBLISHER.
12-123 GA104
AUTHOR_TITLE is an all
12-322 SP221
key table used to link
13-344 CM002
AUTHOR and TITLE. This
13-344 CM776
relational table is required
33-345 SP273
because AUTHOR and
45-456 CM023
TITLE have a many-to-
77-666 SP223
many relationship.
Databases 18

Navigation Example
AUTHOR-TITLE TITLE
au_id (FK) title_id (FK) title_id(PK) title type price pub_id (FK)
12-123 GA023 GA023 Hobz biz-zejt Gastronomy 1.50 112
12-123 GA104 GA104 Hmira Fina Gastronomy 2.04 564
12-322 SP221 CM002 Virus Alert Computers 9.10 322
13-344 CM002 CM776 How to switch off Computers 12.50 322
13-344 CM776 CM023 Bill Gates Rules Computers 0.20 223
33-345 SP273 SP221 Surfing on shore Sports 12.40 113
45-456 CM023 SP233 Football Shots Sports 5.50 113
77-666 SP223 SP273 Pascal tar Roti UNDECIDED 986

AUTHOR
au_id (PK) au_lname au_fname address city
pub_id (PK) pub_name city
12-123 Pace George 7, Main Street Balzan
112 PEG Marsa
13-344 Grasso Anton 23, Republic Street Marsa
113 McGraw Valletta
45-456 Xuereb Peter 45, St. John Street Zejtun
223 Penta Msida
12-332 Zammit Mary 12, Oratory Street Paola
322 SKS Msida
33-345 Pule Anna 1, Paules Street Zabbar
564 Media Zejtun
77-666 Xuereb Desmond 34, Goconda Ave. B’Kara
986 RTF Marsa

Databases PUBLISHER 19

Data Integrity
 Data integrity means, in part, that you can correctly and
consistently navigate and manipulate the tables in the database.
There are two basic rules to ensure data integrity
 The entity integrity rule states that the value of the primary key, can
never be a null value (a null value is one that has no value and is not
the same as a blank). Because a primary key is used to identify a
unique row in a relational table, its value must always be specified and
should never be unknown. The integrity rule requires that insert,
update, and delete operations maintain the uniqueness and existence
of all primary keys.
 The referential integrity rule states that if a relational table has a
foreign key, then every value of the foreign key must either be null or
match the values in the relational table in which that foreign key is a
primary key.

Databases 20

Relational Data Manipulation

 Relational tables are sets. The rows of the tables can
be considered as elements of the set. Operations that
can be performed on sets can be done on relational
tables. The eight relational operations are:
 Union
 Difference
 Intersection
 Product
 Projection
 Selection
 Join
 Diision

Databases 21

Union
 The union operation of two relational tables is formed by appending
rows from one table with those of a second table to produce a third.
Duplicate rows are eliminated. The notation for the union of Tables
A and B is A UNION B.
 The relational tables used in the union operation must be union
compatible. Tables that are union compatible must have the same
number of columns and corresponding columns must come from the
same domain. A UNION B
one
A B K X Y Duplicate
K X Y K X Y 1 A 2 row
removed
1 A 2 1 A 2 2 B 4
U
2 B 4 4 D 8 3 C 6
3 C 6 5 E 10 4 D 8
5 E 10
Databases 22

Difference

 The difference of two relational tables is a third that
contains those rows that occur in the first table but
not in the second. The Difference operation requires
that the tables be union compatible. As with
arithmetic, the order of subtraction matters. That is,
A - B is not the same as B – A (non-commutative).
A B A-B B-A
K X Y K X Y K X Y K X Y
1 A 2 1 A 2 2 B 4 4 D 8
2 B 4 4 D 8 3 C 6 5 E 10
3 C 6 5 E 10

Databases 23

Intersection
 The intersection of two relational tables is a third table
that contains common rows. Both tables must be union
compatible. The notation for the intersection of A and B
is A [intersection] B = C or A INTERSECT B.

A B
K X Y K X Y A INTERSECT B
1 A 2 U 1 A 2 K X Y
2 B 4 4 D 8 1 A 2
3 C 6 5 E 10
Appears in both A and B

Databases 24

Product
 The product of two relational tables, also called the Cartesian
Product, is the concatenation of every row in one table with every
row in the second. The product of table A (having m rows) and
table B (having n rows) is the table C (having m x n rows). The
AXB
product is denoted as A X B or A TIMES B.
AK AX AY BK BX BY
A B 1 A 2 1 A 2
K X Y K X Y 1 A 2 4 D 8
1 A 2 X 1 A 2 1 A 2 5 E 10
2 B 4 4 D 8 2 B 4 1 A 2
3 C 6 5 E 10 2 B 4 4 D 8
2 B 4 5 E 10
3 C 6 1 A 2
The product operation is by itself, not very
useful. However, it is often used as an 3 C 6 4 D 8
intermediate process in a Join. 3 C 6 5 E 10
Databases 25

Projection & Selection

The two selection operations are:

 Projection
 The project operator retrieves a subset of columns from a
table, removing duplicate rows from the result.
 Selection
 The select operator, sometimes called restrict to prevent
confusion with the SQL SELECT command, retrieves subsets
of rows from a relational table based on a value(s) in a
column or columns.

Databases 26

Join
 A join operation combines the product, selection, and, possibly,
projection. The join operator horizontally combines (concatenates)
data from one row of a table with rows from another or the same
table when certain criteria are met. The criteria involve a
relationship among the columns in the join relational table. If the
join criterion is based on equality of column value, the result is
called an equijoin. A natural join, is an equijoin with redundant
columns removed. Equijoin Natural Join
D E
K X Y K Z K x y k z K x y z

1 A 2 1 20 1 A 2 1 20 1 A 2 20
2 B 4 4 24 4 D 8 4 24 4 D 8 24
3 C 6 5 28 5 E 10 5 28 5 E 10 28
4 D 8 7 32
Note: Joins can also be done on criteria other
5 E 10 9 36 than equality
Databases 27

Division

 The division operator results in columns values in one table for
which there are other matching column values corresponding to
every row in another table.
A (dividend)
K X Y
10 1101 A B (divisor) C (result)
10 1201 B X Y K
10 1301 C 1101 A 10
/
20 1201 B 1201 B 30
30 1101 A 1301 C
30 1201 B
30 1301 C

Databases 28

Normalization

 Normalization is a design technique that is widely
used as a guide in designing relational databases.
Normalization is essentially a two step process that
puts data into tabular form by removing repeating
groups and then removes duplicated from the
relational tables.
 Normalization theory is based on the concepts of
normal forms. A relational table is said to be a
particular normal form if it satisfied a certain set of
constraints. There are currently five normal forms
that have been defined.

Databases 29

Basic Concepts
 The goal of normalization is to create a set of relational tables that
are free of redundant data and that can be consistently and
correctly modified. This means that all tables in a relational
database should be in the third normal form (3NF).
 A relational table is in 3NF if and only if all non-key columns are:
a. mutually independent and
b. fully dependent upon the primary key.
 Mutual independence means that no non-key column is dependent
upon any combination of the other columns. The first two normal
forms are intermediate steps to achieve the goal of having all
tables in 3NF.
 In order to better understand the 2NF and higher forms, it is
necessary to understand the concepts of functional dependencies
and lossless decomposition.

Databases 30

Functional Dependencies
 The concept of functional dependencies is the basis for the first
three normal forms. A column, Y, of the relational table R is said to
be functionally dependent upon column X of R if and only if each
value of X in R is associated with precisely one value of Y at any
given time. X and Y may be composite. Saying that column Y is
functionally dependent upon X is the same as saying the values of
column X identify the values of column Y. If column X is a primary
key, then all columns in the relational table R must be functionally
dependent upon X.
 A short-hand notation for describing a functional dependency is:
R.x —>; R.y
which can be read as in the relational table named R, column x
functionally determines (identifies) column y.
Databases 31

Full functional dependence

Full functional dependence applies to
tables with composite keys. Column Y in
relational table R is fully functional on X of
R if it is functionally dependent on X and
not functionally dependent upon any
subset of X. Full functional dependence
means that when a primary key is
composite, made of two or more columns,
then the other columns must be identified
by the entire key and not just some of the
columns that make up the key.
Databases 32

Overview of Normalization
Simply stated, normalization is the process
of removing redundant data from relational
tables by decomposing (splitting) a
relational table into smaller tables by
projection. The goal is to have only primary
keys on the left hand side of a functional
dependency. In order to be correct,
decomposition must be lossless. That is, the
new tables can be recombined by a natural
join to recreate the original table without
creating any spurious or redundant data.

Databases 33

Sample Data
A company obtains parts from a number of suppliers. Each supplier is
located in one city. A city can have more than one supplier located
there and each city has a status code associated with it. Each supplier
may provide many parts. The company creates a simple relational
table to store this information that can be expressed in relational
notation as:
FIRST (s#, status, city, p#, qty)
Where: s# supplier identification number (this is the primary key)
status status code assigned to city
city name of city where supplier is located
p# part number of part supplied
qty quantity of parts supplied to date

In order to uniquely associate quantity supplied (qty) with part (p#) and
supplier (s#), a composite primary key composed of s# and p# is used.
Databases 34

First Normal Form
A relational table, by s# status city p# qty
definition, is in first normal s1 20 London p1 300
form. All values of the s1 20 London p2 200

columns are atomic. That is, s1 20 London p3 400
s1 20 London p4 200
they contain no repeating s1 20 London p5 100
values. s1 20 London p6 100
s2 10 Paris p1 300
s2 10 Paris p2 400
s3 10 Paris p2 200
s4 20 London p2 200
s4 20 London p4 300
s4 20 London p5 400

Databases 35

Update Anomalies
 Although the table FIRST is in 1NF it contains redundant data. For
example, information about the supplier's location and the location's
status have to be repeated for every part supplied. Redundancy
causes what are called update anomalies. Update anomalies are
problems that arise when information is inserted, deleted, or
updated. For example, the following anomalies could occur in
FIRST:
 INSERT. The fact that a certain supplier (s5) is located in a particular
city (Athens) cannot be added until they supplied a part.
 DELETE. If a row is deleted, then not only is the information about
quantity and part lost but also information about the supplier.
 UPDATE. If supplier s1 moved from London to New York, then six rows
would have to be updated with this new information.

Databases 36

Second Normal Form
 The definition of second normal form states that only tables with
composite primary keys can be in 1NF but not in 2NF.
 A relational table is in second normal form 2NF if it is in 1NF and
every non-key column is fully dependent upon the primary key.
 That is, every non-key column must be dependent upon the entire
primary key. FIRST is in 1NF but not in 2NF because status and city
are functionally dependent upon only on the column s# of the
composite key (s#, p#). This can be illustrated by listing the
functional dependencies in the table:

s# —> city, status
city —> status
(s#,p#) —> qty

Databases 37

2NF Transformation

The process for transforming a 1NF table to 2NF is:
 Identify any determinants other than the composite key, and the
columns they determine.
 Create and name a new table for each determinant and the
unique columns it determines.
 Move the determined columns from the original table to the new
table. The determinate becomes the primary key of the new
table.
 Delete the columns you just moved from the original table except
for the determinate which will serve as a foreign key.
 The original table may be renamed to maintain semantic
meaning.
Databases 38

Second Normal Form
PARTS
 To transform FIRST into 2NF we s# p# qty
move the columns s#, status, and s1 p1 300

city to a new table called SECOND. s1 p2 200
s1 p3 400
The column s# becomes the s1 p4 200
primary key of this new table. s1 p5 100
SECOND s1 p6 100
s# status city s2 p1 300
s1 20 London s2 p2 400

s2 10 Paris s3 p2 200
s4 p2 200
s3 10 Paris
s4 p4 300
s4 20 London
s4 p5 400
s5 30 Athens
Databases 39

Modification Anomalies

Tables in 2NF but not in 3NF still contain modification
anomalies. In the example of SECOND, they are:

 INSERT. The fact that a particular city has a certain
status (Rome has a status of 50) cannot be inserted
until there is a supplier in the city.
 DELETE. Deleting any row in SECOND destroys the
status information about the city as well as the
association between supplier and city.

Databases 40

Third Normal Form

 The third normal form requires that all columns in a
relational table are dependent only upon the primary
key. A more formal definition is:
 A relational table is in third normal form (3NF) if it is
already in 2NF and every non-key column is non
transitively dependent upon its primary key. In other
words, all non-key attributes are functionally
dependent only upon the primary key.

Databases 41

Transitive Dependencies

Table PARTS is already in 3NF. The non-key column, qty, is fully
dependent upon the primary key (s#, p#). SECOND is in 2NF but
not in 3NF because it contains a transitive dependency. A transitive
dependency is occurs when a non-key column that is a determinant
of the primary key is the determinate of other columns. The
concept of a transitive dependency can be illustrated by showing
the functional dependencies in SECOND:

SECOND.s# —> SECOND.status status

SECOND.s# —> SECOND.city S#

SECOND.city —> SECOND.status
city

Note that SECOND.status is determined both by the primary key
s# and the non-key column city.
Databases 42

3NF Transformation

The process of transforming a table into 3NF is:
 Identify any determinants, other the primary key, and the
columns they determine.
 Create and name a new table for each determinant and the
unique columns it determines.
 Move the determined columns from the original table to the new
table. The determinate becomes the primary key of the new
table.
 Delete the columns you just moved from the original table
except for the determinate which will serve as a foreign key.
 The original table may be renamed to maintain semantic
meaning.

Databases 43

Third Normal Form
PARTS
To transform SECOND into 3NF, we create a new
s# p# qty
table called CITY_STATUS and move the columns city
s1 p1 300
and status into it. Status is deleted from the original
s1 p2 200
table, city is left behind to serve as a foreign key to
s1 p3 400
CITY_STATUS, and the original table is renamed to
s1 p4 200
SUPPLIER_CITY to reflect its semantic meaning.
s1 p5 100
SECOND SUPPLIER CITY s1 p6 100
s# city city status
s2 p1 300
s1 London London 20
s2 p2 400
s2 Paris Paris 10 s3 p2 200
s3 Paris London 30 s4 p2 200
s4 London Athens 50 s4 p4 300
s5 Athens s4 p5 400

Databases 44

Pseudo-SQL Representation

The results of putting the original table into 3NF has
created three tables. These can be represented in
"psuedo-SQL" as:
 PARTS (#s, p#, qty)
Primary Key (s#,#p)
Foreign Key (s#) references SUPPLIER_CITY.s#
 SUPPLIER_CITY(s#, city)
Primary Key (s#)
Foreign Key (city) references CITY_STATUS.city
 CITY_STATUS (city, status)
Primary Key (city)

Databases 45

Advantages of Third Normal
Form
 The advantages to having relational tables in 3NF is
that it eliminates redundant data which in turn saves
space and reduces manipulation anomalies. For
example, the improvements to our sample database
are:
 INSERT. Facts about the status of a city, Rome has a status
of 50, can be added even though there is not supplier in that
city. Likewise, facts about new suppliers can be added even
though they have not yet supplied parts.
 DELETE. Information about parts supplied can be deleted
without destroying information about a supplier or a city.
UPDATE. Changing the location of a supplier or the status of
a city requires modifying only one row.

Databases 46

Advanced Normalization
After 3NF, all normalization problems involve only
tables which have three or more columns and all the
columns are keys. Many practitioners argue that
placing entities in 3NF is generally sufficient because it
is rare that entities that are in 3NF are not also in 4NF
and 5NF. They further argue that the benefits gained
from transforming entities into 4NF and 5NF are so
slight that it is not worth the effort. However,
advanced normal forms are presented because there
are cases where they are required.

Databases 47

Boyce-Codd Normal Form

 Boyce-Codd normal form (BCNF) is a more rigorous
version of the 3NF deal with relational tables that had
 multiple candidate keys,
 composite candidate keys, and
 candidate keys that overlapped.
 BCNF is based on the concept of determinants. A
determinant column is one on which some of the
columns are fully functionally dependent.
 A relational table is in BCNF if and only if every
determinant is a candidate key.

Databases 48

Relational

More Related Content

What's hot (19)

Viewers also liked (20)

Similar to Relational (20)

Relational