Copyright © 2007 Ramez Elmasri and Shamkant B.

Navathe Slide 5- 1
Chapter 5
The Relational Data Model and
Relational Database Constraints

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter Outline
„ Relational Model Concepts
„ Relational Model Constraints and Relational
Database Schemas
„ Update Operations and Dealing with Constraint
Violations

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 3

Relational Model Concepts
„ The relational Model of Data is based on the concept
p of a
Relation
„ A Relation is a mathematical concept based on the ideas
off sets
t
„ The model was first proposed by Dr. E.F. Codd of IBM
Research in 1970 in the following paper:
„ "A Relational Model for Large Shared Data Banks,"
Communications of the ACM, June 1970
„ The above
Th b paper caused
d a major
j revolution
l ti iin th
the fifield
ld off
database management and earned Dr. Codd the coveted
ACM Turingg Award

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 4

Informal Definitions

„ Informally, a relation looks like a table of values.

„ A relation typically
yp y contains a set of rows.

„ The data elements in each row represent certain facts that

correspond
p to a real-world entity
y or relationship
p
„ In the formal model, rows are called tuples

„ Each column has a column header that gives an indication

of the meaning of the data items in that column
„ In the formal model, the column header is called an attribute
name (or just attribute)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 5

Example of a Relation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 6

Formal Definitions - Schema
„ The Schema ((or description)
p ) of a Relation:
„ Denoted by R(A1, A2, .....An)
„ R is the name of the relation
„ The attributes of the relation are A1,
A1 A2
A2, ..., An
„ Example:
CUSTOMER (Cust-id, Cust-name, Address, Phone#)
„ CUSTOMER is the relation name
„ Defined over the four attributes: Cust-id, Cust-name,
Address,, Phone#
„ Each attribute has a domain or a set of valid values.
„ For example, the domain of Cust-id is 6 digit numbers.
„ The domain may have a data
data-type
type and/or format

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 7

Formal Definitions - Tuple
„ A tuple
p is an ordered set of values ((enclosed in angled
g
brackets ‘< … >’)
„ Each value is derived from an appropriate domain.
„ A row in the CUSTOMER relation is a 4-tuple and would
consist of four values, for example:
„ <632895, "John
<632895 John Smith"
Smith , "101
101 Main StSt. Atlanta
Atlanta, GA 30332"
30332 ,
"(404) 894-2000">
„ This is called a 4-tuple as it has 4 values
„ A tuple (row) in the CUSTOMER relation.
„ A relation is a set of such tuples (rows)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 8

Formal Definitions - State
„ The relation state is a subset of the Cartesian
product of the domains of its attributes
„ each domain contains the set of all p
possible values
the attribute can take.
„ Example: attribute Cust-name is defined over the
domain of character strings of maximum length
25
„ dom(Cust-name) is varchar(25)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 9

Formal Definitions - Summary
„ Formally,
y,
„ Given R(A1, A2, .........., An)
„ r(R) ⊂ dom (A1) X dom (A2) X ....X dom(An)
„ R(A1, A2, …, An) is the schema of the relation
„ R is the name of the relation
„ A1 A2
A1, A2, …, An are the attributes of the relation
„ r(R): a specific state (or "value" or “population”) of
relation R – this is a set of tuples
p ((rows))
„ r(R) = {t1, t2, …, tn} where each ti is an n-tuple
„ ti = <v1, v2, …, vn> where each vj element-of dom(Aj)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 10

Formal Definitions - Example
„ Let R(A1,
( , A2)) be a relation schema:
„ Let dom(A1) = {0,1}
„ Let dom(A2) = {a,b,c}
„ Then: dom(A1) X dom(A2) is all possible combinations:
{<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> }

„ The relation state r(R) ⊂ dom(A1) X dom(A2)

„ For example:
p r(R)
( ) could be {{<0,a>
, , <0,b>
, , <1,c>
, }
„ this is one possible state (or “population” or “extension”) r of
the relation R, defined over A1 and A2.
„ It has three 2
2-tuples:
tuples: <0
<0,a>
a> , <0
<0,b>
b> , <1
<1,c>
c>

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 11

Definition Summary
Informal Terms Formal Terms
Table Relation
Column Header Attribute
All possible Column Domain
Values
Row Tuple

Table Definition Schema of a Relation

Populated Table State of the Relation
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 12
Example – A relation STUDENT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 13

Characteristics Of Relations
„ Ordering of tuples in a relation r(R):
„ The tuples are not considered to be ordered,

even though
g they y appear
pp to be in the tabular
form.
„ Orderingg of attributes in a relation schema R ((and
of values within each tuple):
„ We will consider the attributes in R(A1, A2, ...,

An) and the values in t=<v1, v2, ..., vn> to be

ordered.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 14

Same state as previous Figure (but
with different order of tuples)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 15

Characteristics Of Relations
„ Values in a tuple:
„ All values are considered atomic (indivisible).
„ Each value in a tuple must be from the domain of
the attribute for that column
„ If tuple t = <v1, v2, …, vn> is a tuple (row) in the
relation state r of R(A1, A2, …, An)
„ Then each vi must be a value from dom(Ai)

„ A special null value is used to represent values

that are unknown or inapplicable to certain tuples.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 16

Characteristics Of Relations
„ Notation:
„ We refer to component values of a tuple t by:
„ t[Ai]
[ ] or t.Ai
„ This is the value vi of attribute Ai for tuple t
„ Similarly, t[Au, Av, ..., Aw] refers to the subtuple of
t containing the values of attributes Au, Av, ..., Aw,
respectively in t

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 17

Relational Integrity Constraints
„ Constraints are conditions that must hold on all valid
relation states.
„ There are three main types of constraints in the relational
model:
d l
„ Key constraints
„ Entity integrity constraints
„ Referential integrity constraints
„ Another implicit constraint is the domain constraint
„ Every value in a tuple must be from the domain of its
attribute (or it could be null, if allowed for that attribute)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 18

Key Constraints
„ Superkey
p y of R:
„ Is a set of attributes SK of R with the following condition:
„ No two tuples in any valid relation state r(R) will have the
same value for SK
„ That is, for any distinct tuples t1 and t2 in r(R), t1[SK] ≠ t2[SK]
„ Key of R:
„ A "minimal" superkey
„ That is, a key is a superkey K such that removal of any
attribute from K results in a set of attributes that is not a
superkey (does not possess the superkey uniqueness
property)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 19

Key Constraints (continued)
„ Example:
p Consider the CAR relation schema:
„ CAR(State, Reg#, SerialNo, Make, Model, Year)
„ CAR has two keys:
„ Key1 = {State, Reg#}
„ Key2 = {SerialNo}
„ Both are also superkeys
p y of CAR
„ {SerialNo, Make} is a superkey but not a key.
„ In general:
„ Any key is a superkey (but not vice versa)
„ Any set of attributes that includes a key is a superkey
„ A minimal superkey is also a key

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 20

Key Constraints (continued)
„ If a relation has several candidate keys, one is chosen
arbitrarily
bit il tto bbe th
the primary
i key.
k
„ The primary key value is used to uniquely identify each
tuple in a relation
„ Th primary
The i key
k attributes
tt ib t are underlined.
d li d
„ General rule: Choose as primary key the smallest of the
candidate keys (in terms of size)
„ Example: Consider the CAR relation schema:
„ CAR(State, Reg#, SerialNo, Make, Model, Year)
„ We chose SerialNo as the primary key
„ K constraint
Key t i t statement:
t t t
„ Not two tuples in a relation must have the same value for
the key attribute(s).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 21

CAR table with two candidate keys –
LicenseNumber chosen as Primary Key

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 22

Relational Database Schema
„ A set S of relation schemas that belong to the
same database.
„ S is the name of the whole database schema
„ S = {R1, R2, ..., Rn}
„ R1 R2,
R1, R2 …, Rn are the names of the individual
relation schemas within the database S

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 23

COMPANY D
Database
t b S
Schema
h

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 24

Entity Integrity
„ The primary key attributes PK of each relation
schema R in S cannot have null values in any tuple of
r(R).
„ This is because primary key values are used to identify the
individual tuples.
„ [ ] ≠ null for anyy tuple
t[PK] p t in r(R)
( )
„ If PK has several attributes, null is not allowed in any of
these attributes
„ Note:
N t Oth
Other attributes
tt ib t off R may be
b constrained
t i d to
t
disallow null values, even though they are not
members of the primary key.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 25

Referential Integrity
„ A constraint used to specify
p y a relationship
p among
g tuples
p
in two relations:
„ The referencing relation and the referenced relation.
„ Tuples
T l iin th
the referencing
f i relation
l ti R1 h have attributes
tt ib t FK
(called foreign key attributes) that reference the primary
keyy attributes PK of the referenced relation R2.
„ A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK]
= t2[PK].
„ A referential integrit
integrity constraint can be displa
displayed
ed in a
relational database schema as a directed arc from R1.FK
to R2.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 26

Referential Integrity (or foreign key)
Constraint
„ Statement of the constraint
„ The value in the foreign key column (or columns)
FK of the the referencingg relation R1 can be
either:
„ (1) a value of an existing primary key value of a
corresponding primar primary ke
key PK in the referenced
relation R2, or
„ ((2)) a null ((if it is not part
p of its own p primary
y key)
y)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 27

Displaying a relational database
schema and its constraints
„ Each relation schema can be displayed
p y as a row of
attribute names
„ The name of the relation is written above the attribute
names
„ The primary key attribute (or attributes) will be underlined
„ A foreign key (referential integrity) constraints is displayed
as a directed arc (arrow) from the foreign key attributes to
the referenced table
„ Can also point to the primary key of the referenced relation
for clarity

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 28

Referential Integrity Constraints for COMPANY database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 29

Other Types of Constraints
„ Semantic Integrity Constraints:
„ based on application semantics and cannot be
expressed by y the model per se
„ Example: “the max. no. of hours per employee for
all projects he or she works on is 56 hrs per week”
„ SQL-99 allows triggers and ASSERTIONS to
express for some of these

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 30

Populated database state
„ Each relation will have manyy tuples
p in its current
relation state
„ The relational database state is the union of all
the
h iindividual
di id l relation
l i states
„ Whenever the database is changed, a new state
arises
„ Basic operations for changing the database:
„ INSERT a new tuple in a relation
„ DELETE an existing tuple from a relation
„ MODIFY an attribute of an existing
g tuple
p

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 31

P
Populated
l t dddatabase
t b state
t t for
f COMPANY

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 32

Update Operations on Relations
„ Integrity
g y constraints should not be violated by y the
update operations: INSERT, DELETE, MODIFY
„ In case of integrity violation, several actions can
b taken:
be k
„ Cancel the operation that causes the violation
(RESTRICT or REJECT option)
„ Perform the operation but inform the user of the
violation
„ Trigger additional updates so the violation is
corrected (CASCADE option, SET NULL option)
„ Execute a user
user-specified
specified error
error-correction
correction routine

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 33

The INSERT operation
„ INSERT mayy violate anyy of the constraints:
„ Domain constraint:
„ if one of the attribute values provided for the new tuple is not
of the specified attribute domain
„ Key constraint:
„ if the value of a key attribute in the new tuple already exists in
another tuple in the relation
„ Referential integrity:
„ if a foreign
g key
y value in the new tuple
p references a p primary
y key
y
value that does not exist in the referenced relation
„ Entity integrity:
„ if the primary key value is null in the new tuple

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 34

The DELETE operation
„ DELETE mayy violate only
y referential integrity:
g y
„ If the primary key value of the tuple being deleted is
referenced from other tuples in the database
„ Can be remedied by several actions: RESTRICT,
RESTRICT CASCADE,
CASCADE
SET NULL (see Chapter 8 for more details)
„ RESTRICT option: reject the deletion
„ CASCADE option: delete the tuples that reference the tuple that
is being deleted
„ SET NULL option: set the foreign keys of the referencing tuples
to NULL
„ One of the above options must be specified during
database design for each foreign key constraint

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 35

The UPDATE operation
„ UPDATE ((or MODIFY)) mayy violate domain constraint and
NOT NULL constraint on an attribute being modified
„ Any of the other constraints may also be violated,
d
depending
di on ththe attribute
tt ib t being
b i updated:
d t d
„ Updating the primary key (PK):
„ Similar to a DELETE followed by y an INSERT
„ Need to specify similar options to DELETE
„ Updating a foreign key (FK):
„ May violate referential integrity
„ Updating an ordinary attribute (neither PK nor FK):
„ Can only violate domain constraints

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 36