The document discusses maintaining data integrity in a relational database through the use of constraints. It describes several types of constraints including NOT NULL, PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK, and ASSERTION constraints. These constraints ensure accuracy and consistency of data by restricting what values can be inserted into columns and defining relationships between tables. The document also discusses database security, authorization, and triggers.

1. Integrity and security
Introduction
Integrity constraints ensure that changes made to the database by authorized users don’t result in a loss
of data consistency. Thus, integrity constraints guard against accidental damage to the database. In
addition to protecting data against accidental introduction of inconsistency, the data stored in the
database need to be protected from unauthorized access and malicious destruction or alteration.
A constraint is an object in a RDBMS that places rules on data inserted into a column of a table. There
are several different types of constraints in SQL.
Data integrity
Constraints are used to ensure accuracy and consistency of data in a relational database. Data integrity
is this assurance of accurate and consistent data in the database. Data integrity is handled in a relational
database through the use of constraints on the tables. Any time humans are entering data into a
database, mistakes are made that may violate the accuracy.
Data integrity involves making sure data is entered consistently and stored consistently in the database.
You don’t want one data entry clerk to enter somebody’s phone number as
3178889222
And another to enter the phone number as
(317)888-9222
Data must be accurate and stored consistently in the database to allow accurate data to be retrieved
from the database.
Why use constraints?
Why use constraints? To answer that question, let’s look at the basic components of data integrity (data
accuracy and consistency) and how you would enforce data integrity in the database through the use of
constraints.
Accuracy of data involves placing rules (constraints) on table columns so that the database only allows
certain types of data to be inserted into these columns. For example, you may want only numeric data
inserted into a column containing employee’s pay rates. You want to make sure that the NAME column
of the table accepts alphanumeric values. You may want to make sure that STATE_CODE contains values
that consist of only two characters.

2. There are different ways to ensure data is entered correctly. The first thing you want to do is place
constraints on your table columns that allow only certain types of data and lengths of data to be
inserted.
Database normalization can help provide data consistency since the occurrence of redundant data is
being reduced in the database.
Exploring types of constraints
Now, you study the different types of constraints that can be created in the database tables. Following is
a list of those constraints.
NOT NULL
PRIMARY KEY
UNIQUE
FOREIGN KEY
CHECK
NOT NULL constraints
When you initially create a table, you must assign a data type to each column in a table. The data type
assigned to a column tells the database what kind of data can be inserted into a column in a table. If you
don’t insert a value in a column when you insert a row of data into a table, the value of that column is
NULL. If you specify a column as NOT NULL, that means that NULL values are not allowed in the column.
NOT NULL means that column is required.
Example
Create table whist
(
Std_id varchar2(10) NOT NULL,
Std_name varchar2(15) NOT NULL,
Phone varchar2(11)
);
Here, you must enter the values of std_id and std_name as they have constraints NOT NULL but you can
skip entering the value for phone column.
PRIMARY KEY constraints

3. A primary key is the term that is used to identify one or more columns in a table that make a row of data
unique. Although the primary key typically consists of one column in a table, more than one column can
comprise the primary key also. For example, the primary key for an employee table would be employee
id number as it is unique for all the employees.
The primary key is assigned upon the table creation.
Example
Create table emp
(
Empid varchar2(3) PRIMARY KEY,
Address varchar2(20) NOT NULL
Zip number (5) NOT NULL,
Phone number (10)
);
OR
Create table emp
(
Empid varchar2(3),
Address varchar2(20) NOT NULL,
Zip number(5) NOT NULL,
Phone number(10),
Primary key(empid)
);
You can also use the ALTER TABLE statement to specify a primary key on a table after the table has been
created as follows.
ALTER TABLE emp
ADD PRIMAY KEY(empid);
Or

4. ALTER TABLE emp ADD CONSTRAINT emp_pk PRIMARY KEY(empid);
UNIQUE constraints
A UNIQUE constraint is similar to the primary key in the sense that every value in that column must be
unique. While a primary key constraint is placed on one column, you can place a unique constraint on
any number of columns and it can be kept NULL either.
Example
Create table emp
(
Empid varchar2(3) PRIMARY KEY,
Ename varchar2(19) UNIQUE
);
CHECK constraints
Check constraints can be utilized to check the validity of data entered into particular columns of a table.
Example (checks if the person is from palpa or not)
Create table emp
(
Empid varchar2(3) PRIMARY KEY,
Address varchar2(19) NOT NULL,
Check (address=’palpa’)
);
Example (checks if person is from ktm or bkt or patan)
Create table emp
(
Empid varchar2(3) PRIMARY KEY,
Address varchar2(19) NOT NULL,
Check (address in(‘ktm’,’bkt’,’patan’))

5. );
Example (checks if emp id is between 100 and 1000)
Create table emp
(
Empid varchar2(3) PRIMARY KEY,
Address varchar2(19) NOT NULL,
Check(empid between 100 and 1000)
);
FOREIGN KEY constraints (REFERENCIAL INTEGRITY)
Foreign key represents relationships between two or more tables. A foreign key is a column or a group
of columns whose values are derived from the primary key of any other table. The table in which the
foreign key is defined is called the foreign table (child table). The table that defines the primary key and
referred by the foreign key is called master table.
A foreign key is a column in a child table that references a column in the parent table. The foreign key
constraint is the mechanism used to enforce referential integrity between tables in the relational
database. A column defined as a foreign key is used to reference a column defined as primary key in
another table.
Syntax
The syntax for foreign key definition is as given below.
[CONSTRAINT constrant-name]
FOREIGN KEY (column-comma-list) references-definition
Here the column-comma-list is the name of the column(s) separated by commas that form the foreign
key and the refernces-definition takes the following form.
REFERNCES base-table-name [(column-comma-list)]
[MATCH {FULL|PARTIAL}]
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

6. The optional MATCH clause has no effect and can safely be ignored, if either the foreign key consists of
single column or if every component column of foreign key has null not allowed specification. But if any
of these conditions are not true then MATCH will have significance. The MATCH FULL option requires
the foreign keys in a child table fully match a primary key in the parent table. The MATCH PARTIAL
option allows null values in parts of the foreign key as long as the non-null values match the
corresponding parts to some primary key in the parent table.
The option ON DELETE and ON UPDATE clauses denote the referential actions. The idea behind the
referential actions is the it might sometimes be possible to maintain referential integrity, not simply by
rejecting an update that would violate it, but rather performing another compensating action in addition
to the one that is requested.
Specifying the NO ACTION option is equivalent to omitting the ON DELETE/ON UPDATE entirely.
ON DELETE CASCADE tells the RDBMS that when a parent row is deleted, all the child rows should also
be automatically deleted from the child table
ON UPDATE CASCASE tells the RDBMS that when a primary key value is changed in the parent row, the
corresponding foreign key values in all its child rows should also automatically changed in the child
table.
Similar explanations are for other options.
Example
Create table emp_pay
(
Emp_id char (9) NOT NULL,
Position varchar2(15) NOT NULL,
Pay_rate number(4,2) NOT NULL,
Foreign key(emp_id) references emp (emp_id)
);
In this example, the emp_id column has been designated as the foreign key for the emp_pay table. This
foreign key, as you can see, references the emp_id column in the emp table. This foreign key ensures
that for every emp_id in the emp_pay table, there is corresponding emp_id in the emp table.
EMP
Emp_id
Name Parent table
EMP_PAY

7. Emp_id Child table
Salary
The emp_id column in the child table references emp_id column in the parent table. In order for a value
to be inserted into emp_id in the child table, there must first exist a value in emp_id in the parent table.
Likewise, in order for a value to be removed from emp_id in the parent table, all corresponding values of
emp_id must first be removed from the child table. This is how referential integrity works.
As with primary keys, a foreign key can be added to a table using a ALTER TABLE command.
Alter table emp_pay
Add foreign key (emp_id) references emp (emp_id);
ASSERTION
An assertion is a predicate expressing a condition that we wish the database always to satisfy. Domain
constraints and referential integrity constraints are special forms of assertions.
An assertion in SQL takes the form.
Create assertion <assertion_name> check <predicate>
TRIGGER
A trigger is a statement that the system executes automatically as a side effect of a modification to the
database. To design a trigger mechanism, we must meet two requirements.
Specify when a trigger is to be executed. This is broken up into an event that causes the trigger
to be checked and a condition that must be satisfied for trigger execution to proceed.
Specify the actions to be taken when the trigger executes.
Security and authorization
The data stored in the database need protection from unauthorized access and malicious destruction or
alteration, in addition to the protection against accidental introduction of inconsistency that integrity
constraints provide.
Among the forms of malicious access are:
Unauthorized reading of data
Unauthorized modification of data
Unauthorized destruction of data

8. Database security refers to protection from malicious access. To protect the database, we must take
security measures at several levels.
Database system: Some database users may be authorized to access only a limited portion of
the database. Other users may be allowed to issue queries, but may be forbidden to modify the
data. It is the responsibility of database system to ensure that these authorization restrictions
are not violated.
Operating system: No matter how secure the database system is, weakness in operating system
security may serve as a means of unauthorized access to the database.
Network:
Physical: Sites with computer systems must be physically secured against armed or surreptitious
entry by intruders.
Human: Users must be authorized carefully to reduce the chance of any user giving access to an
intruder in exchange for a bribe or other favors.
Security at all these levels must be maintained if database security is to be ensured. A weakness at a low
level of security (physical or human) allows circumvention of strict high level (database) security
measures.
AUTHORISATION
We may assign a user several forms of authorization on parts of the database. For example,
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
In addition to these forms of authorization for access to data, we may grant a user authorization to
modify the dataset schema.
Index authorization: allows the creation and deletion of indices.
Resource authorization: allows the creation of new relations.
Alteration authorization: allows the addition or deletion of attributes in the relation
Drop authorization: allows the deletion of relations.
PRIVILEGES AND ROLES
a) To grant system privileges to user
Syntax:
GRANT system-privileges TO username;
System privileges are used to permit access to various features like connecting to the database,
ability to create new database objects. Eg CONNECT, CREATE SESSION, RESOURCE etc
To view all the system privileges you can execute, we use SQL statement as:

9. SELECT * FROM DBA_SYS_PRIVS;
Example
GRANT CONNECT TO ram;
For this, there must be a user called ram.
To create a user, we use the syntax as;
CREATE USER username IDENTIFIED BY password;
Eg
CREATE USER ram IDENTIFIED BY sita;
Similarly, to alter the user we use:
ALTER USER username IDENTIFIED BY new_password;
Eg
ALTER USER ram IDENTIFIED BY hari;
To drop the existing user, we use:
DROP USER username;
Eg;
DROP USER ram;
b) To grant object privileges to user
Syntax:
GRANT object-privilege ON object_name TO username [WITH GRANT OPTION]
Object privileges are used to control access to specific database objects (tables, procedures etc).
Most frequently used object privileges are SELECT, INSERT, UPDATE, ALTER etc.
To view all the object privileges, we use SQL statement as:
SELECT * FROM ROLE_TAB_PRIVS;
ROLES
With the role command, you can create a named role or set of privileges. When you grant the role to a
user, you grant to the user all the privileges of that role. The role is first created with CREATE ROLE and
then privileges are granted to the role using the GRANT command.
Example
CREATE ROLE student;
GRANT CONNECT, RESOURCE TO student;
CREATE USER student1 IDENTIFIED BY pass1;
CREATE USER student2 IDENTIFIED BY pass2;

10. If we create a role and then define what privileges are required for a particular role, we can grant that
role to a number of users who play the same role. Instead of granting privileges to each of the student
users individually, we can grant the role student to these two users jointly.
GRANT student TO student1, student1;
The privileges that are granted to users or roles can be revoked using the REVOKE command.
Eg
REVOKE CONNECT, RESOURCE FROM student;
ENCRYPTION AND DECRYPTION
Whenever the data that is transmitted over the network is sensitive and needs protection from the
unauthorized users, it is transformed to another form. The message/data before encryption is called
plaintext and after encryption is called the cipher text. So encryption algorithm transforms the plain text
to cipher text and decryption algorithm transforms the cipher text back to the plain text. The sender
uses the encryption and receiver uses the decryption algorithm.
sender receiver
encryption network decryption
Pliaintext ciphertext ciphertext plaintext
This is not to say that every sender receiver pair needs its very own unique algorithm for a secure
communication. Instead, through the use of public algorithms with secret key, one algorithm can serve
millions of communication pairs. A key is a number (value) that the algorithm operates on. To encrypt
the message, we need an encryption algorithm, encryption key and the plain text. To decrypt the
message, we need a decryption algorithm, a decryption key and the ciphertext.
Encryption
key
plaintext Encryption cipher text
algorithm

11. .
decryption
key
ciphertext decryption plaintext
algorithm
fig: decryption
In cryptography ( the science of transforming message to make them secure and immune to attacks),
the encryption and decryption algorithm are public whereas the keys are secret.
It is customary to introduce three characters in cryptography: we use Alice, Bob and Eve. Alice is the
person who needs to send secure data. Bob is the recipient of the data. Eve is the person who somehow
disturbs the communication between Alice and Bob by intercepting messages or sending her own
disguised messages.
We divide the cryptography algorithms into two groups.
Symmetric key (secret key or private key) algorithms
Asymmetric key (public key) algorithms
Symmetric key algorithms
In symmetric key cryptography, the same key is used by both sender and receiver. The sender uses this
key and an encryption algorithm to encrypt the data, the receiver uses the same key and the
corresponding decryption algorithm to decrypt the data.
Symmetric key algorithms are efficient. It takes less time to encrypt the message. The reason is that the
key size is smaller so used to encrypt and decrypt longer messages.
The disadvantage is that each pair of users must have a unique symmetric key. This means if N people in
the world want to use this method, there needs to be N(N-1)/2 symmetric keys.

12. Shared key
sender receiver
encryption network decryption
Pliaintext ciphertext ciphertext plaintext
PUBLIC KEY ALGORITHMS
In public key cryptography, there are two keys: a private key and a public key. The private keys are kept
by the receiver and the public keys are announced to the public.
Image the Alice as shown in figure below, wants to send a message to Bob. Alice uses the public key to
encrypt the message. When the message is received by Bob, the private key is used to decrypt the
message.
The advantage is number of keys needed is reduced tremendously
The disadvantage is the complexity of the algorithm. Since key size is larger, calculating the ciphertext
from the plaintext using the long keys takes a lot of time. So it is not recommended for longer messages.
Public
Bob’s
key
private key
sender receiver
encryption network decryption
Pliaintext ciphertext ciphertext plaintext

13. AUTHENTICATION
It refers to the task of verifying the identity of a person/software connecting to the database. The
simplest form of authentication consists of a secret password which must be presented when a
connection is opened to a database.
Password based authentication is used widely by operating systems as well as databases. However, the
use of passwords has some drawbacks, especially over a network. If an eavesdropper is able to sniff the
data being sent over the network, he/she may be able to find the password as it is being sent across the
network. Once the eavesdropper has a user name and password, she can connect to the database,
pretending to be the legitimate user.
So other approaches like DIGITAL SIGNATURE (not in scope of this course) is used.
CONCURRENCY CONTROL
Transaction
A collection of several operations on the database appears to be a single unit from the point of view of
the database user. For example, a transfer of fund from a checking account to a saving account is a
single operation from the customer’s standpoint; within the database system, however, it consists of
several operations. Collections of operations that form a single logical unit of work are called
transactions.
Properties of transaction
To ensure the integrity of data, we require that the database system maintain the following properties
of transactions.
Atomicity: Either all operations of the transaction are reflected properly in the database or none
are.
Consistency: Execution of a transaction in isolation ( that is, with no other transaction executing
concurrently) preserves the consistency of the database.
Isolation: Even though multiple transactions may execute concurrently, the system guarantees
that, for every pair of transactions Ti and Tj, it appears to Ti that either Tj finished execution
before Ti started, or TJ started execution after Ti finished. Thus, each transaction is unaware of
other transactions executing concurrently in the system.
Durability: After a transaction completes successfully, the changes it has made to the database
persist, even if there are system failures.
ACID properties explanation

14. To understand ACID properties, consider a simplified banking system consisting of several accounts and
a set of transactions that access and update those accounts. Transactions access data using two
operations.
Read (x): reads data item x from the database
Write (x): writes data item x into the database
Let Ti be the transaction that transfers 50 from account A to account B. This transaction can be defined
as:
Ti:
Read(A);
A:=A-50;
Write (A);
Read (B);
B:=B+50;
Write (B);
Consistency
The consistency requirement here is that the sum of A and B be unchanged by the execution of the
transaction. It can be verified easily that, if the database is consistent before an execution of the
transaction, the database remains consistent after the execution of the transaction.
Atomicity
Suppose that, just before the execution of transaction Ti, the values of accounts A and B are 1000 and
2000, respectively. Now suppose that, during the execution of transaction Ti, a failure occurs that
prevents Ti from completing its execution successfully. Examples of such failures include power failures,
hardware failures and software errors. Further, suppose that the failure happened after the write (A)
operation but before the Write (B) operation. In this case, the values of a account A and B reflected in
the database are 950 and 2000. The system destroyed 50 as a result of this failure. In particular, we
notice that the sum A+B is not preserved.
So the transaction brought the system into inconsistent state. So transaction should guarantee that,
after the completion of transaction, the system must be in consistent state. That is, either all the
operations of transaction must execute completely or none.
Durability

15. Once the execution of the transaction completes successfully, and the user who initiated the transaction
has been notified that the transfer of funds has taken place, it must be the case that not system failure
will result in a loss of data corresponding to this transfer of funds.
Isolation
Even if the consistency and atomicity properties are ensured for each transaction, if several transactions
are executed concurrently, their operations may interleave in some undesirable way, resulting in an
inconsistent state.
For example, as we saw earlier, the database is temporarily inconsistent while the transaction to
transfer fund from A to B is executing, with the deducted total written to A and the increased total yet
to be written to B. if a second concurrently running transaction reads A and B at this intermediate point
and computes A+B, it will observe an inconsistent state.
A way to avoid the problem of concurrently executing transactions is to execute transactions serially,
that is, one after the other.
TRANSACTION STATE
A transaction must be in one of the following states.
Active: the initial state, the transaction stays in this state while it is executing
Partially committed: after the final statement has been executed.
Failed: after the discovery that normal execution can no longer proceed
Aborted: after the transaction has been rolled back and the database has been restored to its
state prior to the start of the transaction.
Committed: after the successful transaction.
Partially committed
committed
Active
failed aborted

16. Concurrency
Transaction processing systems usually allow multiple transactions to run concurrently. Allowing
multiple transactions to update data concurrently causes several complications with consistency of the
data, as we saw earlier. Ensuring consistency in spite of concurrent execution of transactions requires
extra work, it is far easier to insist that transactions run serially, that is, each starting only after the
pervious one has completed. However, there are two good reasons for allowing concurrency.
Improved throughput and resource utilization
Reduced waiting time
Consider a transaction T1 that transfers 50 from account A to B.
Read (A);
A:=A-50;
Write (A);
Read (B);
B:=B+50;
Write (B);
Consider an another transaction T2 that transfers 10% of the balance from account A to B.
Read (A);
Temp:=A*0.1;
A:=A-temp;
Write (A);
Read (B);
B:=B+temp;
Write (B);
Suppose the current values of accounts A and B are 1000 and 2000 respectively. Suppose also that two
transactions are executed one at a time in the order T1 followed by T2.
T1 T2
Read (A);
A:=A-50;
Write (A);

17. Read (B);
B:=B+50;
Write (B);
Read (A);
Temp:=A*0.1;
A:=A-temp;
Write (A);
Read (B);
B:=B+temp;
Write (B);
The final values of accounts A and B, after above execution are 855 and 2145, and A+B is preserved.
Similarly if the transactions are executed one at a time in the order T2 followed by T1, then A+B is also
preserved with account A having 850 and B having 2150.
T1 T2
Read (A);
Temp:=A*0.1;
A:=A-temp;
Write (A);
Read (B);
B:=B+temp;
Write (B);
Read (A);
A:=A-50;
Write (A);
Read (B);
B:=B+50;
Write (B);
Above two are the examples of serial execution. When the database system executes several
transactions concurrently, the corresponding schedule no longer needs to be serial. It two transactions
are running concurrently, the operating system may execute one transaction for a little while, then
perform a switch, execute the second transaction for some time and then switch back to the first
transaction for some time and so on. With multiple transactions, the CPU time is shared among all the
transactions and the performance of CPU in increased.
The two example of concurrent execution are as follows.
T1 T2
Read (A)
A:=A-50
Write (A)
Read (A)
Temp:=A*0.1

18. A:=A-temp
Write (A)
Read (B)
B:=B+50
Write (B)
Read (B)
B:=B+temp
Write (B)
Another concurrent schedule is:
T1 T2
Read (A)
A:=A-50
Read (A)
Temp:=A*0.1
A:=A-temp
Write (A)
Read (B)
Write (A)
Read (B)
B:=B+50
Write (B)
B:=B+temp
Write (B)
SERIALIZABILTIY
Study self
SQL