Fundamentals of Database systems

Chapter 2

The Relational Data Model and

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

2
 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 relations is physically represented as a table.
 Relational database is a collection of normalized
relations with distinct relation names.

3
 Terminologies
 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).

4
 Terminologies…

Example of a Relation

5
 Terminologies…
 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

6
 Terminologies…
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.

7
 Terminologies…
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)
8
 Terminologies…
Domain:
 A domain has a logical definition:
 Example: “Ethiopian phone_numbers” are the set of 10 digit
phone numbers valid in the country.
 A domain also has a data-type or a format defined for it.
 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:
 Used to interpret the meaning of the data elements
corresponding to that attribute
 Example: The domain Date may be used to define two attributes
named “Invoice-date” and “Payment-date” with different
meanings
9
 Terminologies…
State:
 The relation state is a subset of the Cartesian
product of the domains of its attributes
 each domain contains the set of all 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)
 The role these strings play in the CUSTOMER
relation is that of the name of a customer.

10
 Terminologies…
 Base relation
o A named relation of an entity in conceptual schema.
o Tuples stored in physical database.
 View
o Virtual relation
o Dynamically generated for end user
o Not stored in physical database
o Uses of views:
o Security
o User friendly report
 Performance
11
 Termonologies 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

12
 Characteristics Of Relations
 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).

13
 Characteristics Of Relations

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

14
 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.

15
 Characteristics Of Relations
 Notation:
 We refer to component values of a tuple t by:
 t[Ai] or [Link]
 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.

16
 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:
 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)

17
 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]
 This condition must hold in any valid state r(R)
 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)

18
 Key Constraints (continued)
 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
19
 Key Constraints (continued)
 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
 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
20
 Key Constraints (continued)
CAR table with two candidate keys – LicenseNumber
chosen as Primary Key

21
 Relational Database Schema
 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, …, Rn are the names of the individual
relation schemas within the database S
 Following slide shows a COMPANY database
schema with 6 relation schemas

22
 COMPANY Database Schema

23
 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.
24
 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.

25
 Referential Integrity
 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 [Link] to R2.

26
 Referential Integrity (or foreign key)
Constraint
 Statement of the constraint
 The value in the foreign key column (or columns)
FK of the the referencing relation R1 can be
either:
 (1) a value of an existing primary key value of a
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.

27
 Displaying a relational database
schema and its constraints
 Each relation schema can be displayed 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 the the primary key of the referenced
relation for clarity.
 Next slide shows the COMPANY relational schema
diagram

28
Referential Integrity Constraints for COMPANY database

29
 Populated database state
 Each relation will have many tuples in its current
relation state
 The relational database state is a union of all the
individual relation 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 tuple
 Next slide shows an example state for the COMPANY
database

30
Populated database state for COMPANY

31
 Update Operations on Relations
 Update operations in Relation include:
 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.

32
 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

33
 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

34
 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

35
 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

36
 Questions?

37