The Relational Data Model and

Relational Database Constraints

Relational Model Concepts
 The relational model of data is based on the concept
of a relation
 A relation is a mathematical concept based on the
ideas of sets
 The model was first proposed by Dr. E.F. Codd of
IBM in 1970 in the following paper:
 "A Relational Model for Large Shared Data Banks,"
Communications of the ACM, June 1970
 This paper caused a major revolution in the field of
database management and earned Ted Codd the
coveted ACM Turing Award
Slide 3- 2
Informal Definitions
 Informally, a relation looks like a table of values
 A relation typically contains a set of rows
 A relation may alternately be thought of as a set of
columns
 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)
Slide 3- 3
Example of a Relation

Slide 3- 4
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

Slide 3- 5
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

Slide 3- 6
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">
 A relation is a set of such tuples (rows)

Slide 3- 7
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.
 The attribute name designates the role played by
a domain in a relation:
 Example: The domain Date may be used to define two
attributes named “Invoice-date” and “Payment-date”
with different meanings
Slide 3- 8
Formal Definitions - State
 The relation is formed over the Cartesian
product of the sets; each set has values
from a domain; that domain is used in a
specific role which is conveyed by the
attribute name
 Formally, given R(A1, A2, .........., An)
r(R)  dom (A1)  dom (A2)  ...  dom(An)
 R: schema of the relation
 r of R: a specific "value" or population of R
Slide 3- 9
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)  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)  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>

Slide 3- 10
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

Slide 3- 11
Ordering of Tuples & Attributes
 Ordering of tuples in a relation r(R): The tuples
are not considered to be ordered, even though
they appear to be in the tabular form
 Ordering 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
 However, a more general alternative definition of
relation does not require this ordering

Slide 3- 12
Same State as Previous Figure (But with
Different Order of Tuples)

Slide 3- 13
Two Identical Tuples (But with Different
Order of Attribute Values)

Slide 3- 14
Definitions of a Relation
 (Original) definition of a relation
 R(A1, A2, ..., An)
 r = {t1, t2, ..., tm}
 r(R)  dom(A1)  dom(A2)  ...  dom(An)
 Alternative definition of a relation
 R{A1, A2, ..., An}
 r = {t1, t2, ..., tm}
 D = dom(A1) U dom(A2) U ... U dom(An)
 A tuple ti is a mapping from R to D
 A tuple can be also considered as a set of
(<attribute>, <value>) pairs
Slide 3- 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 of certain
tuples that are
 Missing
 Unknown
 Not applicable

Slide 3- 16
Characteristic of Relations
 We refer to component values of a tuple t by
t[Ai] = vi (the value 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

Slide 3- 17
Constraints on Databases
 Inherent model-based constraints
 E.g., a relation cannot have duplicate tuples
 Schema-based constraints
 Constraints that can be expressed in the schemas via
the DDL (will be further discussed)
 Application-based constraints
 Constraints that cannot be directly expressed in the
schemas and hence must be expressed and enforced
by application programs

Slide 3- 18
Schema-based Constraints
 Constraints are conditions that must hold on all
valid relation instances
 There are three main types of constraints:
 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)
Slide 3- 19
Key Constraints
 Superkey 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 SK such that removal
of any attribute from SK results in a set of
attributes that is not a superkey
Slide 3- 20
Key Constraints
 Example: 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 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

Slide 3- 21
Key Constraints
 If a relation has several candidate keys, one is chosen
arbitrarily to be the primary key
 The primary key attributes are underlined

 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
 General rule: Choose as primary key the smallest of

the candidate keys (in terms of size)

 Not always applicable - choice is sometimes subjective

Slide 3- 22
CAR with Two Candidate Keys –
License_number Chosen as Primary Key

Slide 3- 23
Entity Integrity Constraints
 Relational Database Schema: A set S of relation
schemas that belong to the same database. S is the
name of the database
S = {R1, R2, ..., Rn}
 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
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
Slide 3- 24
COMPANY Database Schema

Slide 3- 25
One Possible Database
State for COMPANY

Slide 3- 26
Referential Integrity Constraints
 A constraint involving two relations
 Tuples in the referencing relation R1 have
attributes FK (called foreign key attributes) that
reference the primary key 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 integrity constraint can be displayed
in a relational database schema as a directed arc
from R1.FK to R2.PK

Slide 3- 27
Referential Integrity Constraints
 The value in the foreign key column(s) 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
 In case (2), the FK in R1 should not be a part of
its own primary key
 A foreign key can refer to its own relation
 For example, the attribute Super_ssn in EMPLOYEE
refers to the supervisor of an employee

Slide 3- 28
Referential Integrity Constraints for
COMPANY Database

Slide 3- 29
Other Types of Constraints
 Semantic Integrity Constraints:
 Based on application semantics and cannot be expressed
by the data model
 Examples:
 “The salary of an employee should not exceed the salary of
the employee’s supervisor.”
 “The maximum number of hours per employee for all projects
he or she works on is 56 hours per week.”
 Transition constraints (vs. state constraints)
 For example, “the salary of an employee can only increase.”
 Application programs that update the database should
specify and enforce the semantic constraints
Slide 3- 30
Update Operations on Relations
 Each relation will have many tuples in its current
relation state
 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
 UPDATE (or MODIFY) an attribute of an existing tuple

Slide 3- 31
Update Operations on Relations
 Integrity constraints should not be violated by the
update operations
 INSERT operation can violate any of the four types of
constraints
 DELETE operation can violate only referential integrity

Slide 3- 32
Examples of INSERT Operations

 INSERT <‘Cecilia’, ‘F’, ‘Kolonsky’, NULL, ‘1960-04-05’, ‘6357 Windy

Lane, Katy, TX’, F, 28000, NULL, 4>  Rejected (∵Ssn is NULL)
 INSERT <‘Alicia’, ‘J’, ‘Zelaya’, ‘999887777’, ‘1960-04-05’, ‘6357
Windy Lane, Katy, TX’, F, 28000, ‘987654321’, 4>  Rejected (∵Ssn exists)
 INSERT <‘Cecilia’, ‘F’, ‘Kolonsky’, ‘677678989’, ‘1960-04-05’, ‘6357
Windy Lane, Katy, TX’, F, 28000, ‘987654321’, 7>  Rejected (∵Dno=7)
 INSERT <‘Cecilia’, ‘F’, ‘Kolonsky’, ‘677678989’, ‘1960-04-05’, ‘6357
Windy Lane, Katy, TX’, F, 28000, NULL, 4>  Accepted
Slide 3- 33
Examples of DELETE Operations

 DELETE the WORKS_ON tuple with Essn=‘999887777’

and Pno=10
 Accepted
 DELETE the EMPLOYEE tuple with Ssn=‘999887777’
 Rejected (∵referenced by WORKS_ON tuples)

 DELETE the EMPLOYEE tuple with Ssn=‘333445555’

 Rejected (∵referenced by EMPLOYEE,
DEPARTMENT, WORKS_ON, DEPENDENT tuples)

Slide 3- 34
Examples of UPDATE Operations

 UPDATE Salary=28000 for EMPLOYEE tuple

with Ssn=‘999887777’  Accepted
 UPDATE Dno=1 for EMPLOYEE tuple with
Ssn=‘999887777’  Accepted
 UPDATE Dno=7 for EMPLOYEE tuple with
Ssn=‘999887777’  Rejected
 UPDATE Ssn=‘987654321’ for EMPLOYEE
tuple with Ssn=‘999887777’  Rejected

Slide 3- 35
Update Operations on Relations
 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
 In case of integrity violation, several actions can be taken:
 Cancel the operation that causes the violation (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
Slide 3- 36