Database Management Systems

The Relational Data Model and

Relational Database Constraints

First Semester 2020-2021

Dr. Ghazi Al-Naymat
 Lecture Outline
 Relational Model Concepts
 Relational Model Constraints
 Relational Database Schemas
 Update Operations
 Dealing with Constraint Violations
 Relational Model Concepts

 The relational Data Model is based on the concept of a Relation.

 A Relation is a mathematical concept based on the ideas of sets.
 The strength of the relational approach to data management
comes from the formal foundation provided by the theory of
relations.

 The model was first proposed by Dr.Ted Codd of IBM in 1970

 The relational model represent the database as a collection of
relations
 Domains, Attributes, Tuples, and Relation

 A domain D is a set of atomic values.

 A domain has a logical definition: e.g.,
“USA_phone_numbers” are the set of 10 digit phone numbers
valid in the U.S.

 A domain may have a name, 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.
 Domains, Attributes, Tuples, and Relation
– Dates have various formats such as

• month-name, day, year or

• yyyy-mm-dd, or

• dd mm,yyyy etc.

 An attribute designates the role played by the domain. E.g., the

domain Date may be used to define attributes “Invoice-date” and
“Payment-date”.
 Domains, Attributes, Tuples, and Relation
 A relation schema is used to describe the structure of a relation.
 The degree of a relation is the number of attributes of its relation
schema.

 RELATION: A table of values

– A relation (or relation state) may be thought of as a set of rows.
– A relation may alternately be though of as a set of columns.
– Each row represents a fact that corresponds to a real-world
entity or relationship.
 INFORMAL DEFINITIONS
– Each row has a value of an item (attribute) or set of items that
uniquely identifies that row in the table.
– Sometimes row-ids or sequential numbers are assigned to
identify the rows in the table.
– Each column typically is called by its column name or column
header or attribute name.
INFORMAL DEFINITIONS
 FORMAL DEFINITIONS

 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
For Example -

CUSTOMER (Cust-id, Cust-name, Address, Phone#)

 Here,
• CUSTOMER is a relation 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.
 FORMAL DEFINITIONS

 A tuple is an ordered set of values

 Each value is derived from an appropriate domain.
 Each row in the CUSTOMER table may be referred to as a tuple
and would consist of four values.
• <632895, "John Smith", "101 Main St. Atlanta, GA 30332", "(404) 894-2000">

is a tuple belonging to the CUSTOMER relation.

 A relation may be regarded as a set of tuples (rows).

 Columns in a table are also called attributes of the relation.
 FORMAL DEFINITIONS

 Given R(A , A , .........., A ), then a relation r of R is defined as:

1 2 n

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, …, 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 (rows)
• r(R) = {t1, t2, …, tn} where each ti is an n-tuple

• ti = <v1, v2, …, vn> where each vj element-of dom(Aj)

 FORMAL DEFINITIONS
 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: 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-tuples: <0,a> , <0,b> , <1,c>
 DEFINITION SUMMARY

Informal Terms Formal Terms

Table Relation
Column Attribute
Row Tuple
Values in a column Domain
Table Definition Schema of a Relation
Populated Table Extension
Example The attributes and tuples of a relation
 CHARACTERISTICS OF RELATIONS

 Ordering of tuples in a relation r(R):

‒ The ordering of tuples is not important.
 Ordering of values within a Tuple, and alternative definition of
a Relation.
– At a logical level, the order of attributes and their values is not
important as long as the correspondence between attributes and
values is maintained.
 CHARACTERISTICS OF RELATIONS (Cont.)

 Values in a tuple: All values are considered atomic (indivisible).

 A special null value is used to represent values that are unknown or
inapplicable to certain tuples.
 RELATIONAL MODEL NOTATION
 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 not available or inapplicable in certain tuples.
 Relational Model Constraints and
Relational Database Schema
 Constraints determine which values are permissible and which are
not in the database.
 They are of three main types:
1. Inherent or Implicit Constraints: These are based on the data
model itself. (E.g., relational model does not allow a list as a
value for any attribute)
2. Schema-based or Explicit Constraints: They are expressed in
the schema by using the facilities provided by the model. (E.g.,
max. cardinality ratio constraint in the ER model)
3. Application based or semantic constraints: These are beyond
the expressive power of the model and must be specified and
enforced by the application programs.
 Relational Model Constraints and
Relational Database Schema
 Constraints are conditions that must hold on all valid relation
instances.
 There are four main types of constraints:

1. Domain constraints
2. Key constraints
3. Entity integrity constraints
4. Referential integrity constraints
 Domain constraints
1. Domain constraints specify that within each tuple,
– the value of each attribute A must be an atomic value from the
domain dom(A), or
– It could be NULL if it is allowed for that attribute.
 Key Constraints and Constraints on Null values

 Each relation must have a key.

 If a relation has more than one key, each of the key is called
candidate key.
 Example: The CAR relation schema:
CAR(State, Reg#, SerialNo, Make, Model, Year)
has two keys:
• Key1 = {State, Reg#}, and
• Key2 = {SerialNo},
 Key Constraints and Constraints on Null values

 Each relation must have a key.

 If a relation has more than one key, each of the key is called
 Key Constraints

 Each relation must have a key.

 If a relation has more than one key, each of the key is called a
candidate key.
 One of the candidate keys will be selected to become a primary
key.

• There should be only one primary key in the relation.

• The primary key attributes are underlined.
 Key Constraints

 Example: Consider the CAR relation schema:

– CAR(State, Reg#, SerialNo, Make, Model, Year)
– We chose SerialNo as the primary key
 The primary key value is used to uniquely identify each tuple in a
relation which provides the tuple identity
 Also used to reference the tuple from another tuple
– General rule: Choose as primary key the smallest of the candidate
keys (in terms of size)
– Not always applicable – choice is sometimes subjective
 Key Constraints

 Foreign key: is an attribute in a relation that is also a primary key

in another relation.
• This foreign key-primary key match allows references (links)
between relations in order to locate relevant information.
Key Constraints
 Relational databases and Relational schemas

 Relational database schema S:

– Is a set of relation schemas S = {R1, R2, …, Rm}, and

– a set of integrity constraints IC.

 Relational database state DB of S:

– Is a set of relation states DB {r1, r2, …,rm} such that

each ri is a state of Ri and such that the ri relation

states satisfy the integrity constraints specified in IC.
A Database Schema
 Entity Integrity

 Entity Integrity: The primary key attributes PK of each relation

schema R in S cannot have null values in any tuple of the relation.
• This is because primary key values are used to identify the
individual tuples:

t[PK]  null for any tuple t in r(R)

  Note: Other attributes of R may be similarly constrained to

disallow null values, even though they are not members of the
primary key.
 Referential Integrity

 This constraint involves two relations (the previous constraints

involve a single relation).

 Referential integrity states that a given non null foreign key value
must have a matching primary key value somewhere in the
referenced relation.

 A tuple t 1 in R1 is said to reference a tuple t2 in R2 if t1[FK] =

t2[PK].
 Referential Integrity - continued

 Tuples in the referencing relation R1 have attributes FK (foreign

key attributes) that reference the primary key attributes PK of the
referenced relation R2.

 A referential integrity constraint can be displayed in a relational

database schema .as a directed arc from R1.FK to R2.PK
 Referential Integrity Constraint
Statement of the constraint
 The value in the foreign key column (or columns) FK of the
referencing relation R1 can be either:

1. a value of an existing primary key value of the corresponding

primary key PK in the referenced relation R2,, or..

2. a null.
Referential
5.7 Integrity Constraint
 Other Types of Constraints

 Semantic (user-defined) Integrity Constraints:

• based on application semantics and cannot be expressed by the

model.
• E.g., “the max. no. of hours per employee for all projects he
or she works on is 56 hrs per week”
 INSERT Operations and Constraints Violations

 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
Example#2: The insert operation
 DELETE Operations and Constraints Violations

 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
 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
DELETE Operations and Constraints Violations
 Update Operations and Constraints Violations
 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
Examples: Update Operations and Constraints Violations
Exercise
Exercise
 Exercise Solution
Answers
a) Insert < 'Robert', 'F', 'Scott', '943775543',
'21-JUN-42', '2365 Newcastle Rd, Bellaire,
TX', M, 58000, '888665555', 1 > into
EMPLOYEE.
Answer: No constraint violations.
b) Insert < 'ProductA', 4, 'Bellaire', 2 > into
PROJECT.
Answer:
• Violates referential integrity because
DNUM=2 and there is no tuple in the
DEPARTMENT relation with
DNUMBER=2.
• We may enforce the constraint by:
(i) rejecting the insertion of the new
PROJECT tuple,
(ii) changing the value of DNUM in the new
PROJECT tuple to an existing DNUMBER
value in the DEPARTMENT relation, or
(iii) inserting a new DEPARTMENT tuple
with DNUMBER=2.
 Exercise Solution
Answers
c) Insert < 'Production', 4, '943775543', '01-
OCT-88' > into DEPARTMENT.
Answer:
• Violates both the key constraint and referential
integrity:
• Violates the key constraint because there
already exists a DEPARTMENT tuple with
DNUMBER=4. We may enforce this constraint
by:
(i) rejecting the insertion, or
(ii) changing the value of DNUMBER in the
new DEPARTMENT tuple to a value that
does not violate the key constraint.
• Violates referential integrity because
MGRSSN='943775543' and there is no tuple in
the EMPLOYEE relation with
SSN='943775543'. We may enforce the
constraint by:
(i) rejecting the insertion,
(ii) changing the value of MGRSSN to an
existing SSN value in EMPLOYEE, or
(iii) inserting a new EMPLOYEE tuple with
SSN='943775543'.
 Exercise Solution
Answers
d) Insert < '677678989', null, '40.0' > into
WORKS_ON.
Answer:
• Violates both the entity integrity and
referential integrity:
• Violates entity integrity because PNO, which is
part of the primary key of WORKS_ON, is
null. We may enforce this constraint by: (i)
rejecting the insertion, or (ii) changing the
value of PNO in the new WORKS_ON tuple
to a value of Pnumber that exists in the
PROJECT relation.
• Violates referential integrity because
ESSN='677678989' and there is no tuple in the
EMPLOYEE relation with SSN='677678989'.
We may enforce the constraint by: (i) rejecting
the insertion, (ii) changing the value of ESSN
to an existing SSN value in EMPLOYEE, or
(iii) inserting a new EMPLOYEE tuple with
SSN='677678989'.
 Exercise Solution
Answers
e) Insert < '453453453', 'John', M, '12-DEC-60',
'SPOUSE' > into DEPENDENT.
Answer: No constraint violations.
f) Delete the WORKS_ON tuples with ESSN=
'333445555'.
Answer: No constraint violations.

g) Delete the EMPLOYEE tuple with SSN=

'987654321'.
Answer:
• Violates referential integrity because several
tuples exist in the WORKS_ON,
DEPENDENT, DEPARTMENT, and
EMPLOYEE relations that reference the tuple
being deleted from EMPLOYEE.
• We may enforce the constraint by: (i) rejecting
the deletion, or (ii) deleting all tuples in the
WORKS_ON, DEPENDENT,
DEPARTMENT, and EMPLOYEE relations
whose values for ESSN, ESSN, MGRSSN, and
SUPERSSN, respectively, is equal
to'987654321'.
 Exercise Solution
Answers
h) Delete the PROJECT tuple with PNAME=
'ProductX'.
Answer:
• Violates referential integrity because two
tuples exist in the WORKS_ON relations that
reference the tuple being deleted from
PROJECT. We may enforce the constraint by:
(i) rejecting the deletion, or
(ii) deleting the tuples in the WORKS_ON
relation whose value for PNO=1 (the value for
the primary key Pnumber for the tuple being
deleted from PROJECT).

i) Modify the MGRSSN and Mgr_start>_date of

the DEPARTMENT tuple with Dnumber=5 to
'123456789' and '01-OCT-88', respectively.
Answer: No constraint violations.
 Exercise Solution
j) Modify the SUPERSSN attribute of the
EMPLOYEE tuple with SSN= '999887777' to
'943775543'.
Answer:
• Violates referential integrity because the new
value of Super_ssn='943775543' and there is no
tuple in the EMPLOYEE relation with
SSN='943775543'. We may enforce the
constraint by:
(i) rejecting the deletion, or
(ii) inserting a new EMPLOYEE tuple with
SSN='943775543'.

k) Modify the Hours attribute of the WORKS_ON

tuple with ESSN= '999887777' and PNO= 10 to
'5.0'.
Answer: No constraint violations.