Information Technology Reference
In-Depth Information
the logical database conforms to the relational data model extended with features
from the object data model, with
SQL
as the data definition and manipulation
language.
The logical databases that we consider in this topic are assumed to be purely
relational, if not explicitly stated otherwise. Thus, the logical database is a collection
of
relations
or
tables
, which are multisets of
tuples
or
rows
.A
multiset
or
bag
is
an unordered set where the same element can occur multiple times. All tuples of
a relation conform to the same schema, that is, are of the same type. A
relation
schema
r.Z/ consists of the name r of the relation and the names and types Z
of its attributes, along with possible integrity constraints defined on the relation
(uniqueness of keys, referential integrity, etc.).
The operations of the relational model take relations as arguments and return a
relation as a result. For example, the
SQL
statement
delete from
r
where
A
D
a
means the same as the assignment
r
r
n
ADa
.r/,
where “
n
” denotes the relational difference operation and “ ” denotes the relational
selection operation, that is,
ADa
.r/
Df
t
2
r
j
tŒA
D
a
g
.
However, for the purpose of transaction management, this view of operations is
too coarse grained. For one thing, as we will see shortly, we have to see a database
transaction as a sequence of actions where each update action can be rolled back,
that is, undone, if so desired. This requirement imposes a strong restriction on the
complexity of actions: any single update action must be simple enough so that its
undo action (inverse action) is easily defined and implemented. For another thing,
modern database management requires that as much concurrency as possible be
allowed among transactions active at the same time. This means that the granularity
of data items used to synchronize transaction execution should be as small as
possible. For example, we must allow several transactions to update a relation
simultaneously, as long as the updates affect different tuples.
The usual solution (and the solution we adopt here) is to view the actions on the
logical database as
tuple-wise actions
, so that each action always reads or updates
(inserts or deletes) a single tuple only. Accordingly, in our view, the above
delete
statement is regarded as a sequence of tuple-wise actions:
delete t
1
from r ; delete t
2
from r ; :::
I
delete t
n
from r ,
where
f
t
1
;t
2
;:::;t
n
g
is the bag of tuples with A
D
a. For the deletion of a single
tuple t , it is easy to define its undo action: it is the insertion of the same tuple.
Thus, for the purpose of transaction management, we assume that the collection
of logical database actions consists of tuple-wise actions such as the following:
1. Reading a tuple t of relation r .The
SQL
query
select
from
r
where
C generates
a sequence of such read actions, one for each tuple satisfying the selection
condition C .
