Transaction Processing and Concurrency Control: OLTP environments,

Concurrency issues, need for transactions, Necessary properties of transactions

(ACID properties), Transaction states,
serializability, Serial schedules, Conflict
serializability, View serializability, Recoverable and non-recoverable schedules,
Cascading rollbacks, Cascadeless schedules
Serialized and non-serialized schedules, Testing for serializability,
Locking,
Lock compatibility matrix, Locking and serializability, Deadlocks and
starvation, Two-phase locking (2PL) protocol, Conservative, strict and rigorous
2PL, 2PL with lock conversions, Timestamp-ordering based protocol,

Schedules (Histories) of Transactions

A schedule (or history) S of n transactions T1, T2, , Tn is an
ordering of the operations of the transactions. Operations from
different transactions can be interleaved in the schedule S.
However, for each transaction Ti that participates
in the schedule S, the operations of Ti in S must appear in the same
order in which they occur in Ti.
The order of operations in S is considered to be a total
ordering, meaning that for any two operations in the schedule, one
must occur before the other. It is possible theoretically to deal with
schedules whose operations form partial orders, but we will assume
for now total ordering of the operations in a schedule.

Conflicting Operations in a Schedule. Two operations in a schedule

are said to conflict if they satisfy all three of the following conditions:
(1) they belong to different transactions;
(2) they access the same item X; and
(3) at least one of the operations is a write_item(X).

For example, in schedule Sa, the operations r1(X) and w2(X)

conflict, as do the operations r2(X) and w1(X), and the operations
w1(X) and w2(X).

However, the operations r1(X) and r2(X) do not conflict, since they
are both read operations; the operations w2(X) and w1(Y) do not
conflict because they operate on distinct data items X and Y; and the
operations r1(X) and w1(X) do not conflict because they belong to the
same transaction.
760

First, we would like to ensure that, once a transaction T is committed,

it should never be necessary to roll back T. This ensures that the
durability property of transactions is not violated The schedules
that theoretically meet this criterion are called recoverable schedules.

A schedule where a committed transaction may have to be rolled

back during recovery is called nonrecoverable and hence should not
be permitted by the DBMS.

The condition for a recoverable schedule is as follows:

In a recoverable schedule, no committed transaction ever needs to be

rolled back, and so the definition of a committed transaction as
durable is not violated.

However, it is possible for a phenomenon known as cascading

rollback (or cascading abort) to occur in some recoverable
schedules, where an uncommitted transaction has to be rolled back
because it read an item from a transaction that failed.

A schedule is said to be cascadeless, or to avoid cascading rollback,

if every transaction in the schedule reads only items that were
written by committed transactions.

In the previous section, we characterized schedules based on their

recoverability properties.

Now we characterize the types of schedules that are always

considered to be correct when concurrent transactions are executing.
Such schedules are known as serializable schedules. Suppose that two
usersfor example, two airline reservations
agentssubmit to the DBMS transactions T1 and T2 in Figure 20.2 at
approximately the same time.

If no interleaving of operations is permitted, there are only

two possible outcomes:
1. Execute all the operations of transaction T1 (in sequence) followed
by all the operations of transaction T2 (in sequence).
2. Execute all the operations of transaction T2 (in sequence) followed
by all the operations of transaction T1 (in sequence).

These two schedulescalled serial schedulesare shown in Figures

20.5(a) and (b),
respectively.

If interleaving of operations is allowed, there will be many possible

orders in which the system can execute the individual operations of
the transactions.
No interleaving occurs in a serial schedule

Two possible schedules are shown in Figure 20.5(c). The concept of

serializability of schedules is used to identify which schedules are
correct when transaction executions have interleaving of their
operations in the schedules
View-serializability of a schedule is defined by equivalence to a serial schedule
(no overlapping transactions) with the same transactions, such that respective
transactions in the two schedules read and write the same data values ("view"
the same data values).
Conflict-serializability is defined by equivalence to a serial schedule (no
overlapping transactions) with the same transactions, such that both schedules
have the same sets of respective chronologically ordered pairs of conflicting
operations (same precedence relations of respective conflicting operations).

The typical method of enforcing discretionary access control in a database system

is based on the granting and revoking of privileges.
The account level. At this level, the DBA specifies the particular privileges
that each account holds independently of the relations in the database.
The relation (or table) level. At this level, the DBA can control the privilege
to access each individual relation or view in the database.
SELECT (retrieval or read) privilege on R. Gives the account retrieval privilege.
In SQL, this gives the account the privilege to use the SELECT statement
to retrieve tuples from R.
Modification privileges on R. This gives the account the capability to modify
the tuples of R. In SQL, this includes three privileges: UPDATE, DELETE,
and INSERT. These correspond to the three SQL commands (see Section
7.4) for modifying a table R. Additionally, both the INSERT and UPDATE
privileges can specify that only certain attributes of R can be modified by the
account.
References privilege on R. This gives the account the capability to reference
(or refer to) a relation R when specifying integrity constraints. This privilege
can also be restricted to specific attributes of R.
GRANT CREATETAB TO A1;

Mandatory Access Control and Role-Based

Access Control for Multilevel Security
The discretionary access control technique of granting and revoking privileges on
relations has traditionally been the main security mechanism for relational database
systems. This is an all-or-nothing method: A user either has or does not have a
certain privilege. In many applications, an additional security policy is needed that
classifies data and users based on security classes. This approach, known as
mandatory access control (MAC), would typically be combined with the discretionary
access control mechanisms described in Section 30.2. It is important to note
that most mainstream RDBMSs currently provide mechanisms only for discretionary
access control. However, the need for multilevel security exists in government, military,
and intelligence applications, as well as in many industrial and corporate
applications. Because of the overriding concerns for privacy, in many systems the
levels are determined by who has what access to what private information (also
called personally identifiable information). Some DBMS vendorsfor example,
Oraclehave released special versions of their RDBMSs that incorporate mandatory
access control for government use.
Typical security classes are top secret (TS), secret (S), confidential (C), and unclassified
(U), where TS is the highest level and U the lowest. Other more complex
security classification schemes exist, in which the security classes are organized in
a lattice. For simplicity, we will use the system with four security classification levels,
where TS S C U, to illustrate our discussion. The commonl

Introduction to Statistical
Database Security
Statistical databases are used mainly to produce statistics about various populations.
The database may contain confidential data about individuals; this information
should be protected from user access. However, users are permitted to retrieve
statistical information about the populations, such as averages, sums, counts, maximums,
minimums, and standard deviations. The techniques that have been developed
to protect the privacy of individual information are beyond the scope of this
text

==========
++++++

1 LOGICAL DATABASE DESIGN

Logical database design is the process of deciding how to arrange the
attributes of the entities in a given business environment into database
structures, such as the tables of a relational database. The goal of logical
database design is to create well structured tables that properly reflect the
company's business environment. The tables will be able to store data about
the company's entities in a non-redundant manner and foreign keys will be
placed in the tables so that all the relationships among the entities will be
supported.

Distributed Database

Query Processing and Optimization: Translating SQL into relational

algebra,
Basic query operations, Heuristics in query optimization, Selectivity and
cost
estimates in query optimization

687