P.

QBE Example 4: Find the names of all customers who have both an account and a loan at
the bank.

Introduction of Database
 Domain constraints
 Referential constraints
 Triggers
 Assertion

Integrity constraints are conditions applied to the database that ensures 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. Integrity constraints in database
management systems can be categorized as below:
 Domain Constraints
 Referential integrity Constraints
 Assertions
 Triggers
Domain constraint
Domain constraints define the set of values permitted in attribute of a relation. In
simplest form domain constraints can be applied to the database columns by defining their data
types. Domain constraints are the most elementary form of integrity constraint. They are tested
essentially by the system whenever a new data item is entered into the database. Domain
integrity means the definition of a valid set of values for an attribute. We can define
 data type
 Length or size
 Is null value allowed
 Is the value unique or not for an attribute etc.
 D1 D2 Dn

Student
A1 A2 …………… An

In the above student table, the attribute A1 draws value from domain D1, A2 from D2 and so on.
SQL allows us to create new domains from existing data types by using create domain clause
as below:
create domain Dollars numeric(12, 2)
create domain Pounds numeric(12,2)
Once the domains are created we can use them as data types of attributes while creating
relations as below:
Create table employee
(
eid varchar(5),
ename varchar(10),
Salary dollars
)
CHECK Constraint:
SQL allows us to use CHECK clause to restrict domain values of attributes. CHECK
constraints allow users to prohibit an operation on a table that would violate the constraint.
Example: To ensure that rating must be an integer in the range 1 to 10, we could use:
Create table Sailors (sid integer, sname varchar(10), rating integer, age integer,
check( rating>=1 and rating <= 10))
In sailors table if we are trying to insert a new record as
INSERT INTO Sailors
VALUES (5, ―Bhupi‖, 15, 27);
We get insertion is rejected message since value of rating attribute violated the check condition.
Note: The entity integrity constraint ensures that the primary key of a relation must be unique
and not null.
Referential Integrity
In relational model we use primary key and foreign key to establish relationships between two
relations. Table containing primary key attribute is called master table and the table containing
foreign key attribute is called child table. Referential integrity ensures that value appeared in
foreign key attribute of child table must also appear in primary key attribute of corresponding
master table. Defining referential integrity restricts database modification operations such as
insert, delete, and update. To illustrate this consider following two relations:
Employee Department
Eid Ename Salary DNO
E01 Ramesh 26000 D01
E02 Sohan 19000 D01
 DNO Dname Location
DBMS
D01 IT Gwarko
D02 Finance Satdobato
E03 Renuka 25000 D02 D03 HR Balkumari
E04 Dina 22000 D03
Insert: We cannot insert new tuples containing value of foreign key attribute that do not appear
in primary key attribute of related table. For example, we cannot insert new employee that
works in D04 department because the department D04 does not exists in department table.
Delete: We cannot delete tuples containing values of primary key attribute that also appear
foreign key attribute of related table. For example, we cannot delete tuple containing value D02
of DNO from department table because there are employees working in department D02.
Update: There are two cases of update operation
Case1: We cannot change the value of primary key attribute if the child table contains related
values. For example, we cannot change value of DNO from D01 to D05 in department table
because employee table contains employees working in department D01.
Case 2: We cannot change value of foreign key attribute without modifying value of
corresponding primary key attribute. For example, we cannot change value of DNO from D01
to D05 in department table
Thus for referential integrity a foreign key can have only two possible values- either the
relevant primary key or a null value. No other values are allowed.

Referential Integrity in SQL

Primary and candidate keys and foreign keys can be specified as parts of the SQL create table
statement:
Example: CREATE TABLE Sailors
( CREATE TABLE Boats
sid integer not null, (
sname varchar(20), bid integer not null,
rating integer, bname varchar(20),
age integer, color varchar(10),
primary key (sid) primary key (bid)
) )
CREATE TABLE Reserve
(
sid integer,
bid integer,
rdate date,
foreign key (sid) references Sailors,
foreign key (bid) references Boats,
)

Assertions:
Table constraints are associated with a single table, although the conditional expression in the
CHECK clause can refer to other tables. Table constraints are required to hold only if the
associated table is nonempty. Thus, when a constraint involves two or more tables, the table
constraint mechanism is sometimes cumbersome and not quite what is desired. To cover such
situations, SQL supports the creation of assertions, which are constraints, not associated with
any one table.
Assertion in the SQL takes the form
CREATE ASSERTION <assertion_name> CHECK<predicate>
Example, suppose that we wish to enforce the constraint that the number of boats plus the
number of sailors should be less than 100.
CREATE ASSERTION SailorCheck
CHECK ((SELECT COUNT (S.sid) FROM Sailors S)
+ (SELECT COUNT (B.bid) FROM Boats B) < 100);

Trigger:
A trigger is a procedure (statement) that is automatically invoked by the DBMS in response to
specified changes to the database, and is typically specified by the DBA. A database that has a
set of associated triggers is called an active database. To design a trigger mechanism, we must
meet following three requirements:
1. Event: A change to the database that activates the trigger.
2. Condition: A query or test that is run when the trigger is activated.
3. Action: A procedure that is executed when the trigger is activated and its condition is true.
Triggers are useful mechanisms for alerting humans or for starting certain tasks automatically
when certain conditions are met. As an illustration, suppose that, instead of allowing negative
account balances, the bank deals with overdrafts by setting the account balance to zero, and
creating a loan in the amount of the overdraft. The bank gives this loan a loan number identical
to the account number of the overdrawn account.
Types of triggers:
Type Values Description
Statement INSERT, DELETE, UPDATE Define statement that causes trigger to fire
Timing BEFORE, AFTER Define whether trigger fires before or
after statement is executed
Level ROW, STATEMENT Define whether trigger fires once for each
triggering statement or one for each row
affected by the triggering statement.
They consist of two parts: a condition and an action: action is executed when condition becomes
true.
General form:
DEFINE TRIGGER <trigger-name>
<time events>
ON <list-of-tables>
WHEN <Predicate>
<action-name>
 time: before or after
 events: Insert, Delete Update
 action: Rollback, Delete, multiple Updates, stored procedure, etc

Example:
create trigger overdraft after update on pre-paid
referencing new row as nrow
 for each row
when nrow.balance <= 0
update pre-paid
set BLOCKED = ‗T‖;
For every pre-paid account whose balance is less than or equal to 0, the account is automatically
marked as ―blocked‖.

Event-Condition-Action (ECA) rules

 Automatically triggered by the DBMS
 Rule-writer‘s responsibility to ensure termination
 Rule-writer‘s responsibility to prevent cascading triggers
 Cyclic rules possible
 Termination and infinite cycles handled by stopping rule-based updates (and rolling
back) after a preset number of actions.

Dropping a Trigger
Syntax:
DROP TRIGGER <trigger-name>;
Example:-
DROP TRIGGER overdraft;

Assertions and Checks Vs. Triggers

 Assertions and Checks support the declarative approach of supporting Integrity
Constraints
 Triggers combine the declarative and procedural approach of implementing integrity
constraints

Authorization and privileges

 Users in an SQL-based system can enjoy certain ―privileges‖ that grants them certain
―authorizations‖
 Kinds of authorizations
 Read authorization allows reading, but not modification, of data.
 Insert authorization allows insertion of new data, but not modification of existing data.
 Update authorization allows modification, but not deletion, of data.
 Delete authorization allows deletion of data.
 Index authorization allows the creation and deletion of indices.
 Alteration authorization allows the addition or deletion of attributes in a relation.
 Drop authorization allows the deletion of relations.

GRANT and REVOKE authorization

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>
The privilege list allows the granting of several privileges in one command.
 Privileges: SELECT, DELETE, INSERT, UPDATE, ALTER, DROP, REFERENCE
(with CREATE TABLE), and USAGE (tables, views, domains)
Example: The following grant statement grants users U1, U2, and U3 select authorization on
the account relation:
grant select on account to U1, U2, U3

The following grant statement gives users U1, U2, andU3 update authorization on the amount
attribute of the loan relation:
grant update (amount) on loan to U1, U2, U3

The following grant statement allows user U1 to create relations that reference the key branch-
name of the branch relation as a foreign key:
grant references (branch-name) on branch to U1

To revoke an authorization, we use the revoke statement. It takes a form almost identical to that
of grant:
revoke <privilege list> on <relation name or view name>
from <user/role list> [restrict | cascade]
Thus, to revoke the privileges that we granted previously, we write
revoke select on branch from U1, U2, U3
revoke update (amount) on loan from U1, U2, U3
revoke references (branch-name) on branch from U1

Data encryption (basic and concept only)

The various provisions that a database system may make for authorization may still not provide
sufficient protection for highly sensitive data. In such cases, data may be stored in encrypted
form. It is not possible for encrypted data to be read unless the reader knows how to decipher
(decrypt) them. Encryption also forms the basis of good schemes for authenticating users to a
database.
There are a vast number of techniques for the encryption of data. Simple encryption techniques
may not provide adequate security, since it may be easy for an unauthorized user to break the
code. As an example of a weak encryption technique, consider the substitution of each character
with the next character in the alphabet. Thus,
Perryridge
becomes
Qfsszsjehf
If an unauthorized user sees only ―Qfsszsjehf,‖ she probably has insufficient information to
break the code. However, if the intruder sees a large number of encrypted branch names, she
could use statistical data regarding the relative frequency of characters to guess what
substitution is being made (for example, E is the most common letter in English text, followed
by T, A, O, N, I and so on). A good encryption technique has the following properties:
 It is relatively simple for authorized users to encrypt and decrypt data.
 It depends not on the secrecy of the algorithm, but rather on a parameter of the algorithm
called the encryption key.
 Its encryption key is extremely difficult for an intruder to determine.
One approach, the Data Encryption Standard (DES)
-------------------------------------------------------------------------------------------------------------------

Exercise: Consider the following relational database:

employee (employee-name, street, city)
works (employee-name, company-name, salary)
company (company-name, city)
manages (employee-name, manager-name)
Give an SQL DDL definition of this database. Identify referential-integrity constraints that
should hold, and include them in the DDL definition.
Answer:
create table works
create table employee
(
(
person-name char(20),
person-name char(20),
street char(30), company-name char(15),
salary integer,
city char(30),
primary key (person-name),
primary key (person-name)
foreign key (person-name) references employee,
)
foreign key (company-name) references company)

create table company

( create table manages
company-name char(15), (
city char(30), person-name char(20),
primary key (company-name) manager-name char(20),
) primary key (person-name),
foreign key (person-name) references employee,
foreign key (manager-name) references employee
)

Example 2: Write an SQL trigger to carry out the following action: On delete of an account, for
each owner of the account, check if the owner has any remaining accounts, and if she does not,
delete her from the depositor relation.
Answer:
create trigger check-delete-trigger after delete on account
referencing old row as orow
for each row
delete from depositor
where depositor.customer-name not in
( select customer-name from depositor
where account-number <> orow.account-number )
end

Example 3:- Make a list of security concerns for a bank. For each item on your list, state
whether this concern relates to physical security, human security, operating system security, or
database security.
Answer:
Let us consider the problem of protecting our sample bank database. Some security measures at
each of the four levels are mentioned below –

a. Physical level - The system from which the relations can be accessed and modified should be
placed in a locked, well-guarded, and impregnable room.

b. Human level - A proper key transfer policy should be enforced for restricting access to the
―system room‖ mentioned above. Passwords for gaining access to the database should be known
only to trusted users.

c. Operating System level - Login passwords should be difficult to guess and they should be
changed regularly. No user should be able to gain unauthorized access to the system due to a
software bug in the operating system.

d. Database System level - The users should be authorized access only to relevant parts of the
database. For example, a bank teller should be allowed to modify values for the customer‘s
balance, but not for her own salary.

Example 3:- Database systems that store each relation in a separate operating-system file may
use the operating system‘s security and authorization scheme, instead of defining a special
scheme themselves. Discuss an advantage and a disadvantage of such an approach.

Answer: Database systems have special requirements which are typically more refined than
most operating systems. For example, a single user may have different privileges on different
files throughout the system, including changing indices and attributes which file systems
typically don‘t monitor. The advantage of using the operating system‘s security mechanism is
that it simplifies the database system and can be used for simple (read/write) security measures.

2. What are two advantages of encrypting data stored in the database?

Answer:
a. Encrypted data allows authorized users to access data without worrying about other users or
the system administrator gaining any information.

b. Encryption of data may simplify or even strengthen other authorization mechanisms. For
example, distribution of the cryptographic key amongst only trusted users is both, a simple way
to control read access, and an added layer of security above that offered by views.