Transactions

• Transactions
• A transaction consists of a sequence of query and/or update
statements. The SQL standard specifies that a transaction
begins implicitly when an SQL statement is executed. One of
the following SQL statements must end the transaction:
• Commit work commits the current transaction; that is, it makes
the updates performed by the transaction become permanent
in the database. After the transaction is committed, a new
transaction is automatically started.
• Rollback work causes the current transaction to be rolled back;
that is, it undoes all the updates performed by the SQL
statements in the transaction. Thus, the database state is
restored to what it was before the first statement of the
transaction was executed.
• Transaction rollback is useful if some error condition is
detected during execution of a transaction. Commit is
similar, in a sense, to saving changes to a document that
is being edited, while rollback is similar to quitting the
edit session without saving changes. Once a transaction
has executed commit work, its effects can no longer be
undone by rollback work.
• The database system guarantees that in the event of
some failure, such as an error in one of the SQL
statements, a power outage, or a system crash, a
transaction’s effects will be rolled back if it has not yet
executed commit work. In the case of power outage or
other system crash, the rollback occurs when the system
restarts.
• Banking example,University Credit system
 Integrity Constraints

• Integrity constraints ensure that changes made to

the database by authorized users do not result in a
loss of data consistency. Thus, integrity constraints
guard against accidental damage to the database.
• Examples of integrity constraints are:
• An instructor name cannot be null.
• No two instructors can have the same instructor ID.
• Every department name in the course relation must
have a matching department name in the
department relation.
• The budget of a department must be greater than
$0.00.
• Constraints on a Single Relation
The create table command may also include
integrity-constraint statements. In addition to
the primary-key constraint, there are a
number of other ones that can be included in
the create table command. The allowed
integrity constraints include
• not null
• unique
• check(<predicate>)
• Not Null Constraint
• name varchar(20) not null
• budget numeric(12,2) not null
• Unique Constraint
• SQL also supports an integrity constraint:
• unique (Aj1 , Aj2, . . . , Ajm )

• The check Clause

• When applied to a relation declaration, the clause check(P) specifies a
predicate P that must be satisfied by every tuple in a relation.
• A common use of the check clause is to ensure that attribute values
satisfy specified conditions, in effect creating a powerful type system.
For instance, a clause check (budget > 0) in the create table command
for relation department would ensure that the value of budget is
nonnegative.
• As another example, consider the following:
• create table section
(course id varchar (8),
sec id varchar (8),
semester varchar (6),
year numeric (4,0),
building varchar (15),
room number varchar (7),
time slot id varchar (4),
primary key (course id, sec id, semester, year),
check (semester in (’Fall’, ’Winter’, ’Spring’, ’Summer’)));
• Here, we use the check clause to simulate an enumerated
type, by specifying that semester must be one of ’Fall’,
’Winter’, ’Spring’, or ’Summer’. Thus, the check clause permits
attribute domains to be restricted in powerful ways that most
programming-language type systems do not permit.
 Referential integrity
 Often, we wish to ensure that a value that ppears in
one relation for a given set of attributes also appears for
a certain set of attributes in another relation. This
condition is called referential integrity.
create table department
(dept name varchar (20),
building varchar (15),
budget numeric (12,2) check (budget > 0),
primary key (dept name))
create table instructor
(ID varchar (5),
name varchar (20), not null
dept name varchar (20),
salary numeric (8,2), check (salary > 29000),
primary key (ID),
foreign key (dept name) references department)
 SQL Data Types and Schemas
Date and Time Types in SQL
In addition to the basic data types we introduced in Section 3.2, the SQL standard
supports several data types relating to dates and times:
• date: A calendar date containing a (four-digit) year, month, and day of the
month.
• time: The time of day, in hours, minutes, and seconds. A variant, time(p),
can be used to specify the number of fractional digits for seconds (the default
being 0). It is also possible to store time-zone information along with the time
by specifying time with timezone.
• timestamp: A combination of date and time. A variant, timestamp(p), can be
used to specify the number of fractional digits for seconds (the default here
being 6). Time-zone information is also stored if with timezone is specified.

Date and time values can be specified like this:

date ’2001-04-25’
time ’09:30:00’
timestamp ’2001-04-25 10:29:01.45’
 Default Value

SQL allows a default value to be specified for an attribute as

illustrated by the following create table statement:
create table student
(ID varchar (5),
name varchar (20) not null,
dept name varchar (20),
tot cred numeric (3,0) default 0,
primary key (ID));
The default value of the tot cred attribute is declared to be 0. As a
result, when a tuple is inserted into the student relation, if no
value is provided for the tot cred attribute, its value is set to 0. The
following insert statement illustrates how an
insertion can omit the value for the tot cred attribute.
insert into student(ID, name, dept name)
values (’12789’, ’Newman’, ’Comp. Sci.’);
• Index Creation
Many queries reference only a small proportion
of the records in a file. For example, a query
like “Find all instructors in the Physics
department” or “Find the tot cred value of the
student with ID 22201” references only a
fraction of the student records. It is inefficient
for the system to read every record and to
check ID field for the ID “32556,” or the
building field for the value “Physics”.
create index studentID index on student(ID);
• Large-Object Types
Many current-generation database applications need to
store attributes that can be large (of the order of many
kilobytes), such as a photograph, or very large (of the
order of many megabytes or even gigabytes), such as a
high-resolution medical image or video clip. SQL
therefore provides large-object data types for
character data (clob) and binary data (blob). The
letters “lob” in these data types stand for “Large
OBject.” For example, we may declare attributes
book review clob(10KB)
image blob(10MB)
movie blob(2GB)
 Authorization
• We may assign a user several forms of authorizations on
parts of the database.
• Authorizations on data include:
• Authorization to read data.
• Authorization to insert new data.
• Authorization to update data.
• Authorization to delete data.
• Each of these types of authorizations is called a
privilege. We may authorize the
• user all, none, or a combination of these types of
privileges on specified parts of a database, such as a
relation or a view.
 Granting and Revoking of Privileges
• The SQL data-definition language includes commands to grant
and revoke privileges. The grant statement is used to confer
authorization. The basic form of this statement is:
grant <privilege list>
on <relation name or view name>
to <user/role list>;
grant select on department to Amit, Satoshi;
• This grant statement gives users Amit and Satoshi update
authorization on the budget attribute of the department
relation:
• grant update (budget) on department to Amit, Satoshi;
 Roles
• Consider the real-world roles of various people in a university. Each
instructor must have the same types of authorizations on the same set of
relations. Whenever a new instructor is appointed, she will have to be
given all these authorizations individually.
• create role instructor;
• Roles can then be granted privileges just as the users can, as illustrated in
this
• statement:
• grant select on takes
• to instructor;
• Roles can be granted to users, as well as to other roles, as these
statements show:
• grant dean to Amit;
• create role dean;
• grant instructor to dean;
• grant dean to Satoshi;
 Authorizations on Schema
• However, SQL includes a references privilege
that permits a user to declare foreign keys
when creating relations. The SQL references
privilege is granted on specific attributes in a
manner like that for the update privilege. The
following grant statement allows user Mariano
to create relations that reference the key
branch name of the branch relation as a
foreign key:
• grant references (dept name) on department
to Mariano;
 Transfer of Privileges
• A user who has been granted some form of
authorization may be allowed to pass on this
authorization to other users. By default, a user/role that
is granted a privilege is not authorized to grant that
privilege to another user/role. Ifwe wish
• to grant a privilege and to allow the recipient to pass
the privilege on to other users, we append the with
grant option clause to the appropriate grant command.
• For example, ifwewish to allowAmit the select privilege
on department and allow Amit to grant this privilege to
others, we write:
• grant select on department to Amit with grant option;