Transactions and Concurrency Management

Introduction to Transaction
 A transaction is a logical unit of work that must be entirely completed
or entirely aborted; no intermediate states are acceptable.
 All of the SQL statements in the transaction must be completed
successfully. If any of the SQL statement fail, the entire transaction is
rolled back to the original database state that existed before the
transaction started.
 A successful transaction changes the database from one consistent
state to another. A consistent database state is one in which all data
integrity constraints are satisfied.
 To ensure consistency of the database, every transaction must begin
with the database in a known consistent state.
 If the database is not in a consistent state, the transaction will yield an
inconsistent database that violates its integrity and business rules.
 Improper or incomplete transaction can have a devastating effect on
database integrity.
 Integrity rules, such as referential and entity integrity, are enforced
automatically by the DBMS.
 For example, if a transaction inserts a new customer number into a
customer table and the customer number being inserted already
exists, the DBMS will end the transaction with an error code to indicate
a violation of the primary key integrity rule.

Properties of a Transaction (ACID Properties)

A transaction has four basic properties
1. Atomicity – It requires that all operations (SQL requests) of a
transaction be completed; if not, the transaction is aborted. If
transaction T1 has four SQL requests, all four requests must be
successfully completed’ otherwise the entire transaction is aborted. In
other words, a transaction is treated as a single, indivisible, logical unit
of work

2. Consistency – It indicates the database’s consistent state. A

transaction takes a database from one consistent state to another
consistent state. When a transaction is completed, the database must
be in a consistent state; if any of the transaction parts violates an
integrity constraint, the entire transaction is aborted.

3. Isolation – It means that the data used during the execution of the
transaction cannot be used by a second transaction until the first one
is completed. In other words, if a transaction T1 is being executed and
 is using the data item X, that data item cannot be accessed by any
other transaction (T2….Tn) until T1ends

4. Durability - It ensures that once transaction changes are done

(committed), they cannot be undone or lost, even in the event of a
system failure.

Serializability ensures that the schedule for the concurrent execution of the
transaction yields consistent results. This property is important in multiuser
and distributed database, where multiple transactions are likely to be
executed concurrently.

A single-user database system automatically ensures serializability and

isolation of the database because only one transaction is executed at a time.
The atomicity, consistency, and durability of transaction must be guaranteed
by the single-user DBMS.

Multiuser database are typically subject to multiple concurrent

transactions. Therefore, the multiuser DBMS must implement controls to
ensure serializability and isolation of transactions-in addition to atomicity
and durability –to guard the database’s consistency and integrity.

Concurrent Transactions
 The coordination of the simultaneous execution of transaction in a
multiuser database system is known as concurrency control or
concurrent transaction.
 The objective of the concurrency control is to ensure the serializability
of transactions in a multiuser database environment.
 Concurrency control is important because the simultaneous execution
of transactions over a shared database can create several data
integrity and consistency problems.

The three main problems occur due to concurrent transactions are lost
updates, uncommitted data, and inconsistent retrievals.

1. The lost update

The lost update problem occurs when two concurrent transactions, T1 and
T2, are updating the same data element and one of the updates is lost.
(T1) has not yet been committed when the second transaction T2 is
executed. Therefore, T2 still operates on the value 35, and subtraction
yields 5 in memory. In the meantime, T1 writes the value 135 to the disk,
which is promptly overwritten by T2. In short, the addition of 100 units is
“lost” during the process.
 Serial execution

Time Transaction Step value

1 T1 Read X 35
2 T1 X=35+100
3 T1 Write X 135
4 T2 Read X 135
5 T2 X=135-30
6 T2 Write X 105

Lost Update Problem

Time Transaction Step value

1 T1 Read X 35
2 T2 Read X 35
3 T1 X=35+100
4 T2 X=35-30
5 T1 Write X 135
6 T2 Write X 5

2. Uncommitted data
The phenomenon of uncommitted data occurs when two transactions ,T1
and T2,are executed concurrently and the first transaction (T1) is rolled
back after the second transaction (T2) has already accessed the
uncommitted data, thus violating the isolation property of transactions.T1
is forced to roll back due to an error during the update.T1 transaction is
rolled back to eliminate the addition of the 100 units(ref table) because
T2 subtracts 30 from the original 35 units, the correct answer should be 5.

Serial execution

Time Transaction Step value

1 T1 Read X 35
2 T1 X=35+100
3 T1 Write X 135
4 T1 Rollback 35
5 T2 Read X 35
6 T2 X=35-30
7 T2 Write X 5

Uncommitted data

Time Transaction Step value

 1 T1 Read X 35
2 T1 X=35+100
3 T1 Write X 135
4 T2 Read X 135
( Read uncommitted
data)
5 T2 X = 135-30
6 T1 Rollback 35
7 T2 Write X 105

3. Inconsistent Retrievals
Inconsistent Retrievals occur when a transaction access data before and
after another transaction(s) finish working with such data. For
example ,an inconsistent retrieval would occur if transaction T1 calculates
some summary(aggregate) function over a set of data while another
transaction (T2) is updating the same data. The problem is that the
transaction might read some data before they are changed and other
data after they are changed, thereby yielding inconsistent results.

The Scheduler
 Severe problems may rise when two or more concurrent transaction are
executed. A database transaction involves a series of database I/O
operations that take the database from one consistent state to another.
 The operations within a transaction were executed in an arbitrary order,
as long as two transaction, T1 and T2, access unrelated data, there is no
 conflict and the order of execution is irrelevant to the final outcome. But
if the transactions operate on related data or same data, conflict is
possible among the transaction components and the selection of one
execution order over another might have some undesirable
consequences.
 The scheduler is a special DBMS process that establishes the order in
which the operations within concurrent transactions are executed .The
scheduler interleaves the execution of database operations to ensure
serializability and isolation of transactions .To determine the appropriate
order, the scheduler bases its actions on concurrency control algorithms,
such as locking or time stamping methods.

The DBMS determines what transactions are serializable and proceeds to

interleave the execution of transaction’s operations .Generally transactions
that are not serializable are executed on a first come, first serve basis by the
DBMS. The scheduler’s main job is to create a serializable schedule of a
transaction’s operations.

Locking Protocols
 A lock guarantees exclusive use of data item to a current transaction.
In other words transaction T2 does not have access to a data item that
is currently being used by transaction T1.
 A transaction requires a lock prior to data access; the lock is released
(unlocked) when the transaction is completed so that another
transaction can lock the data item for its exclusive use. The database
might be in a temporary inconsistent state when several updates are
executed. Therefore locks are required to prevent another transaction
from reading inconsistent data. Most multiuser DBMSs automatically
initiate and enforce locking procedures. All lock information is
managed by a lock manager, which is responsible for assigning and
policing the locks used by the transactions.

The scheduler facilitates data isolation to ensure that two transactions do not
update the same data element at the same time. Database operations might
require READ and/or WRITE action that produce conflicts.
Transactions
T1 T2 RESULT
OPERATIONS Read Read No Conflict
Read Write Conflict
Write Read Conflict
 Write Write Conflict

LOCK TYPES
Regardless of the level of locking, the DBMS may use different lock types:
binary or shared/exclusive.
Binary Locks
 A binary lock has only two states: locked (1) or unlocked (0). If an object--that
is, a database, table, page, or row--is locked by a transaction, no other
transaction can use that object.
 If an object is unlocked, any transaction can lock the object for its use. Every
database operation requires that the affected objects be locked.
 As a rule, a transaction must unlock the objects after its termination. There-
fore, every transaction requires a lock and unlocks operation for each data
item that is accessed.
 Such operations are automatically managed and scheduled by the DBMS; the
user does not need to be concerned about locking or unlocking data items.
 The lock and unlock features eliminate the lost update problem because the
lock is not release until the WRITE statement is completed.
 Therefore, a value cannot be used until it has been properly updated. The
DBMS will not allow two transactions to read the same database objects even
though neither transaction updates the database, nor therefore, no
concurrency problems can occur.
Time Transaction Step value
1 T1 Lock product
2 T1 Read X 15
3 T1 X=15+10
4 T1 Write X 25
5 T1 Unlock product
6 T2 Lock product
7 T2 Read X 25
8 T2 X=25-10
9 T2 Write X 15
10 T2 Unlock product

Shared / Exclusive Locks

 The labels "shared" and "exclusive" indicate the nature of the lock. An
exclusive lock exits when access is reserved specifically for the transaction
that locked the object.
 The exclusive lock must be used when the potential for conflict exists. A
shared lock exists when concurrent transactions are granted read access
on the basis of a common lock. A shared lock procedure no conflict as long
 as all the concurrent transaction is read only.
 A shared lock is issued when a transaction wants to read data from the
database and no exclusive lock is held on that data item. An exclusive lock
is issued when a transaction wants to update (write) a data item and no
locks are currently held on that data item by any other transaction.
 Using the shared/exclusive locking concept, a lock can have three states:
unlocked, shared (read), and exclusive (write). Two transactions conflict
only when at least one of them is a WRITE transaction. Because the two
READ transactions can be safely executed at once, shared locks allow
several READ transactions to read the same date item concurrently.
 For example, if transaction T1 has a shared lock on data item X and
transaction T2 wants to read data item X, T2 may also obtain a shared lock
on data item X.
 If the transaction T2 updates data item X, an exclusive lock is required by
T2 over data item X. The exclusive lock is granted if and only if no other
locks are held on the data item.
 Therefore, if a shared or exclusive lock is already held on data item X by
transaction T1, an exclusive lock cannot be granted to transaction T2 and
T2 must wait to begin until T1 commits. This condition is known as the
mutual exclusion rule: only one transaction at a time can own an exclusion
lock on the same object.

Although locks prevent serious data inconsistencies, they can lead to two major
problems:
 The
resulting transaction schedule might not be serializable.

 The
schedule might create deadlocks.

TWO-PHASE LOCKING TO ENSURE SERIALIZABILITY

Two-phase locking defines how transaction acquires and relinquishes locks. Two-
phase locking guarantees serializability, but it does not prevent deadlocks. The
two phases are:
1. A growing phase, in which a transaction acquires all required locks without
unlocking any data. Once all locks have been acquired, the transaction is in
its locked point.

2. A shrinking phase, in which a transaction releases all locks and cannot

obtain any new lock.

The two-phase locking protocol is governed by the following rules:

 Two transactions cannot have conflicting locks.
  No unlock operations can precede a lock operation in the same transaction.

 No data are affected until all locks are obtained -- that is, until the
transaction is in its locked point.

The transaction acquires all of the locks it needs until it reaches its locked
point. Two-phase locking increases the transaction processing cost and
might cause additional undesirable effects. One undesirable effect is the
possibility of creating deadlocks.

DEADLOCKS
A deadlock occurs when two transactions wait indefinitely for each other to
unlock data. For example, a deadlock occurs when two transactions, T1 and T2,
exist in the following mode:
T1= access data items X and Y
T2= access data items Y and X
If T1 has not unlocked data item Y, T2 cannot begin; if T2 has unlocked data item
X, T1 cannot continue. Consequently, T1 and T2 each wait for the other to unlock
the required data item. Such a deadlock is also known as a deadly embrace.
Time Transaction Reply Lock status
0 Data X Data Y
1 T1:Lock (X) OK Unlocked Unlocked
2 T2:Lock (Y) OK Locked Unlocked
3 T1:Lock (Y) WAIT Locked Locked
4 T2:Lock (X) WAIT Locked Locked
D
5 T1:Lock (Y) WAIT Locked Locked
E
6 T2:Lock (X) WAIT Locked A
Locked
7 T1:Lock (Y) WAIT Locked D Locked
8 T2:Lock (X) WAIT Locked L Locked
9 T1:Lock (Y) WAIT Locked O Locked
C
……………. ……………. ……………. ……………. K …………….
……………. ……………. ……………. ……………. …………….

The preceding example used only two concurrent transactions to demonstrate a

deadlock condition. In a real-world DBMS, many more transactions can be
executed simultaneously, thereby increasing the probability of generating
deadlocked. Note that deadlocks are possible only when one of the transactions
wants to obtain an exclusion lock on a data item; no deadlock condition can exist
among shared locks.
The three basic techniques to control deadlocks are:
 Deadlock prevention: A transaction requesting a new lock is aborted
when there is the possibility that a deadlock can occur. If the transaction is
aborted, all changes made by this transaction are rolled back and all locks
obtained by the transaction are released. The transaction is then
rescheduled for execution. Deadlock prevention works because it avoids
the conditions that lead to deadlocking.

 Deadlock detection: The DBMS periodically tests the database for

deadlocks. If a deadlock is found, one of the transactions (the "victim") is
aborted (rolled back and restarted) and the other transaction continues.

 Deadlock avoidance: The transaction must obtain all of the locks it needs
before it can be executed. This technique avoids the rollback of conflicting
transactions by requiring that locks be obtained in succession.

Concurrency Control with Time Stamping Methods

The time stamping approach to scheduling concurrent transactions assigns a
global, unique time stamp to each transaction. The time stamp value
produces an explicit order in which transactions are submitted to the DBMS.
Time stamps must have two properties: uniqueness and monotonicity.
Uniqueness ensures that no equal time stamp values can exist, and
monotonicity ensures that time stamp always increases.
 All database operations (READ and WRITE) within the same transaction
must have the same time stamp.
 If two transactions conflict, one is stopped, rolled back, rescheduled,
and assigned a new time stamp value.
 The disadvantage of the time stamping approach is that each value
stored in the database requires two additional time stamp fields: one
for the last time the field was read and one for the last update.
 Time stamping demands a lot of system resources because many
transactions might have to stopped, rescheduled, and reshaped.

Wait/Die and Wound/Wait Schemes

Time stamping methods are used to manage concurrent transaction
execution. Two schemes are used to decide which transaction is rolled back
and which continues executing: the wait/die scheme and the wound/wait
scheme. Assume two conflicting transactions: T1 and T2, each with a unique
time stamp. Suppose T1 has a time stamp of 115 and T2 has a time stamp of
195. Given that scenario, the four possible outcomes are possible.

Using the wait/die scheme:

 If the transaction requesting the lock is the older of two transactions, it

will wait until the other transaction is completed and the locks are
released.

 If the transaction requesting the lock is the younger of the two

transactions, it will die (roll back) and is rescheduled using the same
time stamp.

In short, in the wait/die scheme, the older transaction waits for the younger
to complete and release its locks.
In the wound/wait scheme:
 If the transaction requesting the lock is the older of two transactions, it
will preempt (would) the younger transaction (by rolling it back). T1
preempts T2 when T1 rolls back T2. The younger, preempted
transaction is rescheduled using the same time stamp.
  If the transaction requesting the lock is the younger of the two
transactions, it will wait until the other transaction is completed and
the locks are released.

In short, in the wound/wait scheme, the older transaction roll backs the
younger transaction and reschedules it.
In both schemes, one of the transactions waits for the other transaction to
finish and release the locks. However, in many cases, a transaction requests
multiple locks. That scenario can cause some transactions to wait
indefinitely, causing a deadlock. To prevent that type of deadlock, each lock
request has an associated timeout value. If the lock is not granted before the
time-out expires, the transaction is rolled back.

Concurrency Control with Optimistic Methods

The optimistic approach is based on the assumption that the majority of the
database operations do not conflict. The optimistic approach requires neither
locking nor time stamping techniques. Instead, a transaction is executed
without restrictions until it is committed.
Using an optimistic approach, each transaction moves through two or three
phases, referred to as

 Read phase
 Validation Phase
 Write Phase

 During the read phase, the transaction reads the database, executes
the needed computations, and makes the updates to a private copy of
the database values. All update operations of the transaction are
recorded in a temporary update file, which is not accessed by the
remaining transactions.
 During the validation phase, the transaction is validated to ensure
that the changes made will not affect the integrity and consistency of
the database. If the validation test is positive, the transaction goes to
the write phase. If the validation test is negative, the transaction is
restarted and the changes are discarded.
 During the write phase, the changes are permanently applied to the
database.

The optimistic approach is acceptable for the most read or query database
systems that require few update transactions.
Database Recovery and Security
Database Recovery Meaning
 Database recovery restores a database from a given state (usually
inconsistent) to a previously consistent state.
 Recovery techniques are based on atomic transaction property: all
portions of the transaction must be treated as a single, logical unit of
work in which all operations are applied and completed to produce a
consistent database.
 If, for some reason, any transaction operation cannot be completed,
the transaction must be aborted and any changes to the database
must be rolled back (undone).
 In short, transaction recovery receives all the changes that the
transaction made to the database before the transaction was aborted.

Critical events can cause a database to become non-operations and

compromise the integrity of the data.
Kinds of Failures
 Hardware/Software failures: Failure of this type could be hard disk
media failure, a bad capacitor on a mother board, or a failing memory
bank. Other causes of errors under this category include application
program or operating system errors that cause data to be overwritten,
deleted or lost. Some database administrators argue that this is one of
the most common sources of database problems.

 Human-Caused incidents: This type of event can be recognized as

unintentional or intentional.

i. An unintentional is caused by carelessness by end-users. Such errors

include deleting the wrong rows from a table, pressing the wrong key
on the keyboard, or shutting the main database server by accident.

ii. Intentional events are of a more severe nature and normally indicate
that the company data are at serious risk. Under this category are
security threats caused by hackers trying to gain unauthorized access
to data resources and virus attacks by disgruntled employees trying to
compromise the database operation and damage the company.

 Natural disasters: This category include fires, earthquakes, floods

and power failures.
Failure Controlling Methods
The recovery techniques are somewhat expensive both in terms of time and
in memory space for small systems. In such a case it is more beneficial to
better avoid the failure by some checks instead of deploying recovery
technique to make database consistent. Also, recovery from failure involves
manpower that can be used in some other productive work if failure can be
avoided. It is, therefore, important to find out some general precautions that
help in controlling failure.
Some of these precautions may be:
 Having a regulated power supply.
 Having a better secondary storage system
 Taking periodic backup of database states and keeping track of
transactions after each recorded state.
 Properly testing the transaction programs prior to use.
 Setting important integrity checks in the databases as well as user
interfaces etc.

Database Errors
An error is said to have occurred if the execution of a command to
manipulate the database cannot be successfully completed either due to
inconsistent data or due to state of program.
For example, there may be a command in program to store data in
database. On the execution of command, it is found that there is no
space/place in database to accommodate that additional data. Then it can be
said that an error has occurred. This error is due to the physical state of
database storage.
Broadly errors are classified into the following categories:
1) User error: This includes errors in the program (e.g., Logical errors) as
well as errors made by online users of database. These types of errors can
be avoided by applying some check conditions in programs or by limiting the
access rights of online users e.g., read only. So only updating or insertion
operation require appropriate check routines that perform appropriate
checks on the data being entered or modified. In case of an error, some
prompts can be passed to user to enable him/her to correct that error.
2) Consistency error: These errors occur due to the inconsistent state of
database caused may be due to wrong execution of commands or in case of
a transaction abort. To overcome these errors the database system should
include routines that check for the consistency of data entered in the
database.
3) System error: These include errors in database system or the OS, e.g.,
deadlocks. Such errors are fairly hard to detect and require reprogramming
the erroneous components of the system software. Database errors can
result from failure or can cause failure and thus will require recovery.
However, one of the main tasks of database system designers is to make
sure that errors minimized.

Backup and Recovery Techniques

Recovery can be done using/restoring the previous consistent state
(backward recovery) or by moving forward to the next consistent state as
per the committed transactions (forward recovery) recovery.
The log may also keep images of records before a change is made to the
data (Before Image) and after a change is made to the data (After Image).
1. Backward Recovery (UNDO)

In this scheme the uncommitted changes made by a transaction to a

database are undone. Instead the system is reset to the previous consistent
state of database that is free from any errors.

2. Forward Recovery (REDO)

In this scheme the committed changes made by a transaction are reapplied
to an earlier copy of the database.

3. Log Based Recovery

Transaction Log
A RDBMS uses a transaction log to keep track of all transactions that
update the database. The information stored in this log is used by the
DBMS for a recovery requirement triggered by a ROLLBACK statement
 After a severe failure, for example, system automatically rolls back
uncommitted transactions and rolls forward transactions that were
committed but not yet written to the physical database.
The transaction log stores:

 A record for the beginning of the transaction

 For each transaction component (SQL statement):
o The type of operation being performed(update, delete, insert)
o The names of the objects affected by the transaction (name of
the table)
o The “before” and “after” values for the fields being updated
o Pointers to the previous and next transactions log entries for the
same transaction.
 The ending (COMMIT) of the transaction

For Example
 The log is kept on disk start_transaction (T): This log entry records
that transaction T starts the execution.
 read_item(T, X): This log entry records that transaction T reads the
value of database item X.
 write_item(T, X, old_value, new_value): This log entry records that
transaction T changes the value of the database item X from old_value
 to new_value. The old value is sometimes known as a before an image
of X, and the new value is known as an afterimage of X.
 commit(T): This log entry records that transaction T has completed all
accesses to the database successfully and its effect can be committed
(recorded permanently) to the database.
 abort(T): This records that transaction T has been aborted.

4. Checkpoint

When more than one transaction are being executed in parallel, the logs are
interleaved. At the time of recovery, it would become hard for the recovery
system to backtrack all logs, and then start recovering. To ease this
situation, most modern DBMS use the concept of 'checkpoints'.
Checkpoint is a mechanism where all the previous logs are removed from the
system and stored permanently in a storage disk.
Checkpoint declares a point before which the DBMS was in consistent state,
and all the transactions were committed.

Depending on the type of failure the generalized strategies can be used to

restore the database.
 The write-ahead-log protocol ensures that transaction logs are
always written before any database data are actually updated. This
protocol ensures that, in case of a failure, the database can later be
recovered to a consistent state, using the data in the transaction log.
  When the recovery procedure uses a deferred-write technique (also
called as referred update), the transaction operations do not
immediately update the physical database. Instead, only the
transaction log is updated.
 When the recovery procedure uses a write - through technique
(also called an immediate update) by transaction operations during the
transaction's execution, even before the transaction reaches its
commit point.

Security and Integrity

Information security is the protection of information against unauthorized

disclosure, alteration or destruction. Database security is the protection of
information that is maintained in a database.

It deals with ensuring only the “right people” get the right to access the
“right data”. By right people we mean those people who have the right to
access/update the data that they are requesting to access/update with the
database. This should also ensure the confidentiality of the data.

Security - Protecting the database from unauthorized access, alteration or

deletion.

Integrity - It refers to accuracy or validation of the data.

Authentication

User authentication is to make sure that the person accessing the database
is who he claims to be. Authentication can be done at the operating system
level or even the database level itself.

Authorization

Authorization is a privilege provided by the Database Administer. Users of

the database can only view the contents they are authorized to view. The
rest of the database is out of bounds to them.

To protect database several levels of security measures are maintained:

1) Physical: The site or sites containing the computer system must be

physically secured against illegal entry of unauthorized persons

2) Human: An Authorization is given to a user to reduce the chance of any

information leakage and unwanted manipulations
 3) Operating System: Even though foolproof security measures are taken
to secure database systems, weakness in the operating system security may
serve as a means of unauthorized access to the database

4) Network: Since databases allow distributed or remote access through

terminals or network, software level security within the network software is
an important issue

5) Database system: The data items in a database need a fine level of

access control. For example, a user may only be allowed to read a data item
and is allowed to issue queries but would not be allowed to deliberately
modify the data.

Database Security

Database security is the technique that protects and secures the database
against intentional or accidental threats. Security concerns will be relevant
not only to the data resides in an organization's database: the breaking of
security may harm other parts of the system, which may ultimately affect
the database structure. Consequently, database security includes hardware
parts, software parts, human resources, and data. To efficiently do the uses
of security needs appropriate controls, which are distinct in a specific
mission and purpose for the system. The requirement for getting proper
security while often having been neglected or overlooked in the past days; is
now more and more thoroughly checked by the different organizations.
We consider database security about the following situations:

 Theft and fraudulent

 Loss of confidentiality or secrecy
 Loss of data privacy
 Loss of data integrity
 Loss of availability of data

The Security issues can be solved using computer based controls

 Access authorization
 Access controls
 Views
 Backup and recovery of data
 Data integrity
 Encryption of data

Authorization

Authorization is the culmination of the administrative policies of the

organization. As the name specifies, authorization is a set of rules that can
be used to determine which user has what type of access to which portion of
the database.
The following forms of authorization are permitted on database items:
1) READ: it allows reading of data object, but not modification, deletion or
insertion of data object.
2) INSERT: allows insertion of new data, but not the modification of existing
data, e.g., insertion of tuple in a relation.
3) UPDATE: allows modification of data, but not its deletion. But data items
like primary-key attributes may not be modified.
4) DELETE: allows deletion of data only. A user may be assigned all, none or
a combination of these types of Authorization, which are broadly called
access authorizations’.
In addition to these manipulation operations, a user may be granted control
operations like
1) Add: allows adding new objects such as new relations.
2) Drop: allows the deletion of relations in a database.
3) Alter: allows addition of new attributes in a relations or deletion of
existing attributes from the database.
4) Propagate Access Control: this is an additional right that allows a user
to propagate the access control or access right which he already has to some
other.