Chapter 3

Relational Model Concepts

Relational Model Concepts
 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

 The above paper caused a major revolution in the
field of database management and earned Dr. Codd
the coveted ACM Turing Award
Outline
 Relational Model Concepts
 Domains, Attributes, and Relations
 Characteristics of Relations
 Relational Model Constrains and
Relational Database Schemas
 Update Operations, Transactions, and
Dealing with Constrain Violations
Relational Model Concepts
 The relational model represents the database
as a collection of relations

 Each relation resembles a table of values

 When a relation is thought of as a table of

values, each row in the table represents a
collection of related data values
Formal Terminology
 A row is called a tuple
 A column header is called an attribute
 The table is called relation
Domain
 A Domain D is a set of atomic values.

 Atomic means that each value in the domain is

indivisible as far as the relational model is concerned

 It means that if we separate an atomic value, the

value itself become meaningless, for example:
 SSN
 Local_phone_number
 Names
 Employee_ages
Formal Definitions
 Formally,
 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, …, An are the attributes of the relation

FORMAL DEFINITIONS
 A Relation may be defined in multiple ways.
 The Schema of a Relation: R (A1, A2, .....An)
Relation schema R is defined over 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
of which has a domain or a set of valid values. For
example, the domain of Cust-id is 6 digit numbers.
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
 DEFINITION SUMMARY
Informal Terms Formal Terms

Table Relation
Column Attribute/Domain
Row Tuple
Values in a column Domain
Table Definition Schema of a Relation
Populated Table Extension

Chapter 5-10
Outline
 Relational Model Concepts
 Domains, Attributes, and Relations
 Characteristics of Relations
 Relational Model Constrains and
Relational Database Schemas
 Update Operations, Transactions, and
Dealing with Constrain Violations
Ordering
 Ordering of Tuples in a Relation
 a relation is defined as a set of tuples.
 Mathematically, elements of a set have NO
order among them and hence ordering of
tuples in a relation is of no concern.
 The ordering indicates first, second, ith,
and last records in the file.
Ordering
 Ordering of values within a tuple
 The values written within a tuple must be ordered.
 The ordering of values in a tuple—and hence of attributes in a relation
schema– is important.
 NOTE: An alternate definition of a relation can be given ,making the
ordering of values in a tuple unnecessary. According to the definition of
tuple as a mapping a tuple can be considered as a set of
(<attribute>,<value>)pairs. Here ordering is not important since
attribute name appears with its value.

 Hence, the following two relations are identical since ordering

of tuple is not necessary.
Identical Relations
Values in the Tuples
 Each value in a tuple is an atomic value

 Hence, composite and multi-valued attributes are

not allowed.
 Multivalued are represented as separate relations.
 Composite attributes are represented by their simple
component attributes.

 This model is sometimes called the flat relational

model

 Much of the theory behind the relational model was

developed with this assumption, which is called first
normal form assumption.
Null in tuples
 An important concept is that if NULL
values, which are used to represent the
values of attributes that may be
unknown or may not apply to a tuple
Relational Model Notation
 An attribute A can be qualified with the
relation name R to which it belongs by
using the dot notation R.A

 For example, STUDENT.Name or

STUDENT.Age
Outline
 Relational Model Concepts
 Domains, Attributes, and Relations
 Characteristics of Relations
 Relational Model Constrains and
Relational Database Schemas
 Update Operations, Transactions, and
Dealing with Constrain Violations
Domain Constrains
 Each attribute A must be an atomic value
from the dom(A)

 The data types associated with domains

typically include standard numeric data type
for integers, real numbers, Characters,
Booleans, fix-length strings, time, date,
money or some special data types
Key Constrains
 A relation is defined as a set of tuples
 By definition, all elements of a set are distinct
 This means that no two tuples can have the
same combination of values for all their
attributes
 Superkey: a set of attributes that no two
distinct tuples in any state r of R have the
same value
 Every relation has at least one default
superkey – the set of all its attributes
Key Constrains
 A super-key can have redundant
attributes, so a more useful concept is
that of a KEY which has no redundancy
 Key satisfied two constrains:
 Two distinct tuple in any state of the
relation cannot have identical values for
the attributes in the key
 It is a minimal super-key
 Key Constraints
 Superkey of R: A set of attributes SK of R such that
no two tuples in any valid relation instance 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 superkey K
such that removal of any attribute from K results in a
set of attributes that is not a superkey.
Example: The CAR relation schema:
CAR(State, Reg#, SerialNo, Make, Model, Year)
has two keys Key1 = {State, Reg#}, Key2 = {SerialNo}, which are
also superkeys. {SerialNo, Make} is a superkey but not a key.
 If a relation has several candidate keys, one is
chosen arbitrarily to be the primary key. The primary
key attributes are underlined.

Chapter 5-22
Key Constrains
 For example, consider STUDENT
relation
 The attribute set {SSN} is a key of
STUDENT because no two student can
have the same value for SSN
 Any set of attributes that includes SSN
– for example {SSN, Name, Age} – is a
superkey
Key Constrains
 In general, a relation schema may have more
than one key, in this case, each of the key is
called a candidate key

 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
(because it is not minimum).
CAR table with two candidate keys –
LicenseNumber chosen as Primary Key
Key Constrains
 If a relation has several candidate keys, one is chosen arbitrarily to
be the primary key.

 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
 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
COMPANY 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 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)
 If PK has several attributes, null is not allowed in any of
these attributes
 Note: Other attributes of R may be constrained to
disallow null values, even though they are not
members of the primary key.
Referential Integrity
Constraint
 Referential Integrity Constraint is specified between
two relations and is used to maintain the consistency
among tuples in the two relations

 Informally define the constrain: a tuple in one

relation must refer to an existing tuple in that
relation

 For example, the Dno in EMPLOYEE gives the

department number for which each employee works,
this number must match the Dnumber value in
DEPARTMENT
Other Types of Constraints
Semantic Integrity Constraints:
 based on application semantics and cannot be

expressed by the model per se

 E.g., “the max. no. of hours per employee for

all projects he or she works on is 56 hrs per

week”
 A constraint specification language may have

to be used to express these

 SQL-99 allows triggers and ASSERTIONS to

allow for some of these

Chapter 5-30
Referential Integrity Constraints for COMPANY database
Outline
 Relational Model Concepts
 Domains, Attributes, and Relations
 Characteristics of Relations
 Relational Model Constrains and
Relational Database Schemas
 Update Operations, Transactions, and
Dealing with Constrain Violations
Modification and Updates
 In this section, we concentrate on the
database Updates and Modification

 There are threee basic operation: Insert,

Delete and Modify
 Insert is used to insert a new tuple or tuples in a
relation
 Delete is used to delete tuples
 Update (or Modify) is used to change the values
of some attributes
Modification and Updates
 Insert: insert new element with specify all
related attributes

 Delete: delete an element by giving Relation

name and key of the tuple

 Modify: modify a value by giving a relation

name, Key of the target tuple and attribute to
modify
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
Insert Example
 Insert <‘Cecilia’, ‘F’, ‘Kolonsky’, NULL, ‘1960-04-05’,
‘6357 Windy lane,Kate,TX’, F, 28000, NULL, 4> into
EMPLOYEE

 Insert < ‘Cecilia’, ‘F’, ‘Kolonsky’, 999887777, ‘1960-

04-05’, ‘6357 Windy lane,Kate,TX’, F, 28000, NULL, 4
>

 Insert < ‘ Cecilia’, ‘F’, ‘Kolonsky’, 667788999, ‘1960-

04-05’, ‘6357 Windy lane,Kate,TX’, F, 28000, NULL,
7>
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
 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 Example
 Delete the EMPLOYEE tuple with
Ssn=‘999887777’

 Delete the EMPLOYEE tuple with

Ssn=‘333445555’

 Delete the EORKS_ON tuple with

Essn=‘999887777’ and Pno=10 (accepted)
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

Update Example
 Update the salary of EMPLOYEE tuple with
Ssn=‘999887777’ to 2800 (Accept)

 Update the Dno of the EMPLOYEE tuple with

Ssn=‘999887777’ to 1 (Accept)

 Update the Dno of the EMPLOYEE tuple with

Ssn=‘999887777’ to 7

 Update the Ssn of the EMPLOYEE tuple with

Ssn=‘999887777’ to ‘987654321’