Copyright © 2017 Ramez Elmasri and Shamkant B.

Navathe
 CHAPTER 5

The Relational Data Model and

Relational Database Constraints

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 1- 2

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

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

Relational Model Concepts
 The relational Model of Data is based on the concept of a
Relation
 The strength of the relational approach to data management
comes from the formal foundation provided by the theory of
relations
 A Relation is a mathematical concept based on
the ideas of sets
 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
Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 4
Informal Definitions

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

 A relation typically contains a set of rows.

 The data elements in each row represent certain facts

that correspond to a real-world entity or relationship
 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 © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 5

Example of a Relation

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

Informal Definitions
 Key of a Relation:
 Each row has a value of a data item (or set of items)
that uniquely identifies that row in the table
 Called the key
 In the STUDENT table, SSN is the key

 Sometimes row-ids or sequential numbers are

assigned as keys to identify the rows in a table
 Called artificial key or surrogate key

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

Formal Definitions - Schema
 The Schema (or description) of a Relation:
 Denoted by R(A1, A2, .....An)
 R is the name of the relation
 The attributes of the relation are A1, 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.

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

Formal Definitions - Tuple
 A tuple is an ordered set of values (enclosed in angled
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 Smith", "101 Main St. Atlanta, GA 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 © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 9

Relational Data Structure

• More formally - Name Age

• A scheme is a set John 23
Mary 20
of attributes Mark 18
• A tuple assigns a Jane 21
value to each
{ { (Name, John), (Age, 23) },
attribute in its { (Name, Mary), (Age, 20) },
scheme { (Name, Mark), (Age, 18) },
{ (Name, Jane), (Age, 21) } }
• A relation is a set
of tuples with
the same
scheme

The Relational Model

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe
Relations

Scheme is {ID, Name, Salary, Department}

Attributes are ID, Name, Salary, and Department

ID Name Salary Department

M139 John Smith 18,000 Marketing Tuples, e.g.
Mary Jones 22,000 Marketing { (ID, A368),
M140 Jane Brown 22,000 Accounts (Name, Jane Brown),
A368 Mark Brown 24,000 Personnel (Salary, 22,000),
P222 David Jones 20,000 Accounts (Department, Accounts) }
A367

The Relational Model

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe
Formal Definitions - Domain
 A domain has a logical definition:
 Example: “USA_phone_numbers” are the set of 10 digit phone
numbers valid in the U.S.
 A domain also has a data-type or a format defined for it.
 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.

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

 Attributes and Domains

• A domain is given for • Examples

each attribute • An ‘age’ might have
to come from the set
• The domain lists the
of integers between 0
possible values for and 150
that attribute • A ‘department’ might
• Each tuple assigns a come from a given list
of strings
value to each
• A ‘notes’ field might
attribute from its
allow any string at all
domain

The Relational Model

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe
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 © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 14
Example – A relation STUDENT

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

Relational Integrity Constraints
 Constraints are conditions that must hold on all valid
relation states.
 There are three main types of (explicit schema-based)
constraints that can be expressed in the relational model:
 Key constraints
 Entity integrity constraints
 Referential integrity constraints
 Another schema-based 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 © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 16

Key Constraints
Candidate Keys

• A set of attributes in ID First Last

a relation is called a S139 John Smith
candidate key if, and S140 Mary Jones
only if, S141 John Brown
• Every tuple has a S142 Jane Smith
unique value for the
Candidate key: {ID}; {First,Last}
set of attributes looks plausible but we may get
(uniqueness) people with the same name
• No proper subset of {ID, First}, {ID, Last} and {ID,
the set has the First, Last} satisfy uniqueness,
uniqueness property but are not minimal
(minimality) {First} and {Last} do not give
a unique identifier for each row
The Relational Model

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe

Choosing Candidate Keys

• Important: don’t look just on the data in

the table to determine what is a candidate
key

• The table may contain just one tuple, so

anything would do!

• Use knowledge of the real world – what is

going to stay unique!

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
 Primary Keys

• One Candidate Key is usually chosen to be

used to identify tuples in a relation
• This is called the Primary Key
• Often a special ID attribute is used as the
Primary Key

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
CAR table with two candidate keys –
LicenseNumber chosen as Primary Key

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

 NULLs and Primary Keys

• Entity Integrity:
 Missing information Primary Keys cannot
can be represented contain NULL values
using NULLs  Why: if primary key
 A NULL indicates a has NULLs then will
missing or unknown not uniquely identify
value the tuple/entity

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe The Relational Model
 Foreign Keys

• Foreign Keys are used to link data in

two relations. A set of attributes in the
first (referencing) relation is a Foreign
Key if its value always either
• matches a Candidate Key value in the

second (referenced) relation, or

• is wholly NULL

• This is called Referential Integrity

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
Foreign Keys - Example

Department Employee
DID DName EID EName DID
13 Marketing 15 John Smith 13
14 Accounts 16 Mary Brown 14
15 Personnel 17 Mark Jones 13
18 Jane Smith NULL

{DID} is a Candidate Key {DID} is a Foreign Key in Employee -

for Department - Each each Employee’s DID value is either
entry has a unique value NULL, or matches an entry in the
for DID Department relation. This links each
Employee to (at most) one Department

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe

Foreign Keys - Example

Employee
{ID} is a Candidate Key for
ID Name Manager Employee, and {Manager} is a
E1496 John Smith E1499 Foreign Key, which refers to
E1497 Mary Brown E1498 the same relation - every
tuple’s Manager value is either
E1498 Mark Jones E1499
NULL or matches an ID value
E1499 Jane Smith NULL

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
Referential Integrity
 A constraint involving two relations
 The previous constraints involve a single relation.
 Used to specify a relationship among tuples in
two relations:
 The referencing relation and the referenced
relation.

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

Referential Integrity Constraints for COMPANY database

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

 Referential Integrity

• When relations are • There are a number

updated, referential of options:
integrity can be • RESTRICT - stop the
violated user from doing it
• CASCADE - let the
• This usually occurs changes flow on
when a referenced • NULLIFY - make
tuple is updated or values NULL
deleted

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe

Update Operations on Relations
 INSERT a tuple.
 DELETE a tuple.
 MODIFY a tuple.
 Integrity constraints should not be violated by the
update operations.
 Several update operations may have to be grouped
together.
 Updates may propagate to cause other updates
automatically. This may be necessary to maintain
integrity constraints.
Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 28
Update Operations on Relations
 In case of integrity violation, several actions can
be taken:
 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-specified error-correction routine

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

Example

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

 Referential Integrity - Example

• What happens if Department

• Marketing’s DID is DID DName
changed to 16 in 13 Marketing
Department? 14 Accounts
• The entry for 15 Personnel
Accounts is deleted
from Department? Employee
EID EName DID
15 John Smith 13
16 Mary Brown 14
17 Mark Jones 13
18 Jane Smith NULL

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
 RESTRICT
Department
• RESTRICT stops any
DID DName
action that violates
integrity 13 Marketing
14 Accounts
• You cannot update or
15 Personnel
delete Marketing or
Accounts
Employee
• You can change
Personnel as it is not EID EName DID
referenced
15 John Smith 13
16 Mary Brown 14
17 Mark Jones 13
ON DELETE RESTRICT means you can't 18 Jane Smith NULL
delete a given parent row if a child row
exists that references the value for that
parent row

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
 CASCADE

• CASCADE allows the

changes made to flow Department
through DID DName
• If Marketing’s DID is Marketing
changed to 16 in 13 16
14 Accounts
Department, then the 15 Personnel
DIDs for John Smith and
Mark Jones also change Employee
• If Accounts is deleted
EID EName DID
then so is Mary Brown
15 John Smith 13 16
16 Mary Brown 14
ON DELETE CASCADE is used to 17 Mark Jones 13 16
automatically remove the matching 18 Jane Smith
NULL
records from the child table when we
delete the rows from the parent
table.

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
Example: ON DELETE CASCADE

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

 NULLIFY

• NULLIFY sets problem values

to NULL Department
• If Marketing’s DID changes then DID DName
John Smith’s and Mark Jones’ Marketing
DIDs are set to NULL 13 16
14 Accounts
• If Accounts is deleted, Mary 15 Personnel
Brown’s DID becomes NULL
Employee
EID EName DID
ON DELETE SET NULL means that if a 15 John Smith 13 NULL
record in the parent table is deleted, then 16 Mary Brown 14 NULL
the corresponding records in the child table 17 Mark Jones 13 NULL
will have the foreign key fields set to null. 18 Jane Smith NULL
The records in the child table will not be
deleted.
The Relational Model
Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe
Possible violations for each operation
 INSERT may violate any 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 key value in the new tuple references a primary
key value that does not exist in the referenced relation
 Entity integrity:
 if the primary key value is null in the new tuple

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

Possible violations for each operation
 DELETE may violate only referential integrity:
 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, CASCADE,
SET NULL (see Chapter 6 for more details)
 RESTRICT option: reject the deletion
 CASCADE option: propagate the new primary key value into the
foreign keys of the referencing tuples
 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 © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 37

Possible violations for each operation
 UPDATE may violate domain constraint and NOT NULL
constraint on an attribute being modified
 Any of the other constraints may also be violated,
depending on the attribute being updated:
 Updating the primary key (PK):
 Similar to a DELETE followed by 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 © 2017 Ramez Elmasri and Shamkant B. Navathe Slide 5- 38

 Naming Conventions

• Naming conventions • Naming keys

• A consistent naming • Having a unique
convention can help number as the
to remind you of the primary key can be
structure useful
• Assign each table a • If the table prefix is
unique prefix, so a abc, call this abcID
student name may be • A foreign key to this
stuName, and a table is then also
module name called abcID
modName

Copyright © 2017 Ramez Elmasri and Shamkant B. Navathe

 Example

Student Enrolment Module

stuID stuName stuID modID modID modName

These entries are These entries are These entries are

clearly related to clearly related to clearly related to
the Student tables other than the Module table
table Enrolment

The
Copyright © 2017 Ramez Relational
Elmasri and Shamkant Model
B. Navathe
In-Class Exercise
(Taken from Exercise 5.15)
Consider the following relations for a database that keeps track of student
enrollment in courses and the books adopted for each course:
STUDENT(SSN, Name, Major, Bdate)
COURSE(Course#, Cname, Dept)
ENROLL(SSN, Course#, Quarter, Grade)
BOOK_ADOPTION(Course#, Quarter, Book_ISBN)
TEXT(Book_ISBN, Book_Title, Publisher, Author)
Draw a relational schema diagram specifying the foreign keys for this
schema.

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

References

• Fundamentals of Database Systems, Global

Edition, Ramez Elmasri, Shamkant B.
Navathe
• Connolly and Begg, Database Systems: A
Practical Approach To Design,
Implementation And Management, 4/E
• Database Systems Lecture Notes N.Alechina
• https://www.techonthenet.com/oracle/
foreign_keys/foreign_delete.php

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