Unit 5.

Database Security and Transaction Processing

Database security refers to the collective measures used to protect and secure a database or
database management software from illegitimate use and malicious cyber threats and attacks.
Database security procedures are aimed at protecting not just the data inside the database, but the
database management system and all the applications that access it from intrusion, misuse of
data, and damage.
It is a broad term that includes a multitude of processes, tools and methodologies that ensure
security within a database environment.
Database security covers and enforces security on all aspects and components of databases. This
includes:

 Data stored in database.

 Database server.
 Database management system (DBMS).
 Other database workflow applications.

Database security is generally planned, implemented and maintained by a database administrator

and or other information security professional.

Database security Requirements

Database security
Database security refers to the collective measures used to protect and secure a database or
database management software from illegal use and malicious threats and attacks.
Requirements of Database Security:
1. For prevention of data theft such as bank account numbers, credit card information,
passwords, work related documents or sheets, etc.
2. To make data remain safe and confidential.
3. To provide confidentiality which ensures that only those individuals should ever be able to
view data they are not entitled to.
4. To provide integrity which ensures that only authorized individuals should ever be able
change or modify information.
5. To provide availability which ensure that the data or system itself is available for use when
authorized user wants it.
6. To provide authentication which deals with the desire to ensure that an authorized individual.
7. To provide non-repudiation which deals with the ability to verify that message has been sent
and received by an authorized user.

OR

1. Confidentiality: The principle of confidentiality specifies that only sender and intended
recipients should be able to access the contents of a message. Confidentiality gets compromised
if an unauthorized person is able to access the contents of a message.
2. Integrity: when the contents of the message are changed after the sender sends it, but before it
reaches the intended recipient, we say that the integrity of the message is lost.
3. Authentication: Authentication helps to establish proof of identities. The Authentication
process ensures that the origin of a message is correctly identified.
4. Availability: The goal of availability s to ensure that the data, or the system itself, is available
for use when the authorized user wants it.

Database Users
List of DBMS user:
a) Naive users
Naïve users are unsophisticated users. They interact with the system through the application
program. They give data as input through application program or get output data which is
generated by application programs.
b) Application programmers:
Application programmers are the users who write the application programs. These programmers
use programming tools to develop the program. RAD technology is used to write the program.
c) Sophisticated users:
Sophisticated users interact with the system by making the requests in the form of query
language. These queries are then submitted to the query processor. Query processor converts the
DML statements into lower level interactions which are understandable by storage manager.
d) Specialized users:
These users are not traditional. They write some special application programs which are not
regular applications like CAD, knowledge based and expert system.
e) Database administrator:
Responsible for managing whole database system, create and maintains database. Manages users
who can access the database and manages integrity issue. Manages performance of system as and
when required.

Describe database privileges. Write down the procedure for granting & revoking privileges
in database objects to the users.

https://www.youtube.com/watch?v=d5-4wt2dEzo

Database privileges:
When multiple users can access database objects, authorization can be controlled to these objects
with privileges. Every object has an owner. Privileges control if a user can modify an object
owned by another user. Privileges are granted or revoked either by the instance administrator, a
user with the ADMIN privilege or, for privileges to a certain object, by the owner of the object.
1) System Privileges:
System privileges are privileges given to users to allow them to perform certain functions that
deal with managing the database and the server
e.gCreate user, Create table, Drop table etc.
2) Object Privileges:
Object privileges are privileges given to users as rights and restrictions to change contents of
database object – where database objects are things like tables, stored procedures, indexes, etc.
Ex. Select,insert,delete,update,execute,references etc

Procdure for granting privileges

Grant: This command is used to give permission to user to do operations on the other user’s
object.
Syntax: Grant<object privileges>on<object
name>to<username>[with grant option] ;
Example: Grant select, update on emp to user1;

Procedure for revoking privileges

Revoke: This command is used to withdraw the privileges that has been granted to a user.
Syntax: Revoke <object privileges>on<object name>from
<username> ;
Example: Revoke select, update on emp from user1;

Write SQL command for following

i) Create user
CREATE USER <username> IDENTIFIED BY <password>;
(OR)
CREATE USER RAJ2 IDENTIFIED BY RAJ123;

ii) Grant privileges to user.

GRANT <privilege list> ON <relation name or view name>
TO<user list>;
(OR)
(assuming table CUSTOMERS for granting permissions to user ‘RAJ2’
for select, insert, update and delete privilege)
GRANT SELECT, INSERT,UPDATE,DELETE ON CUSTOMERS TO RAJ2;

iii) Remove privileges from user.

REVOKE <privilege list> ON <relation name or view name >
FROM <user list>;
(OR)
(assuming table CUSTOMERS for revoking permissions to user ‘RAJ2)
REVOKE SELECT, INSERT,UPDATE,DELETE ON CUSTOMERS FROM RAJ2;

Practical:
Step 1: After creating and granting access to user Raj2 with password Raj123 from SYTSEM
user, logout from SYSTEM user.
Step 2: Login using UID Raj2 and PASSWORD Raj123
Step 3: Check the current user, it should be Raj2 as shown below
Step 5: Perform Select * from SYSTEM.CUSTOMERS;
Step 6: INSERT INTO SYSTEM.CUSTOMERS VALUES(7,'Naresh',45,'Luknow',50000)
Step7: Go back to SYSTEM user and Revoke Insert permission from Raj2 on CUSTOMERS
table.

Step 8: Login to Raj2 with Password Raj123 and perform

Step 9: INSERT INTO SYSTEM.CUSTOMERS VALUES(8,'Nalini',32,'Banglore',4500)
Step 10: Since we have removed INSERT permission from Raj2, it is showing insufficient
privilege.
 States of Transaction

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: when the 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 successful completion. The state diagram corresponding to a transaction is
shown in Figure.
A transaction has committed only if it has entered the committed state. Similarly, a transaction
has aborted only if it has entered the aborted state. A transaction is said to have terminated if has
either committed or aborted.
A transaction starts in the active state. When it finishes its final statement, it enters the partially
committed state. At this point, the transaction has completed its execution, but it is still possible
that it may have to be aborted, since the actual output may still be temporarily hiding in main
memory and thus a hardware failure may preclude its successful completion.

ACID properties of Transaction

A transaction is a single unit of execution. It can have different steps. Every transaction in the
DBMS must follow the ACID properties. The ACID properties are:
Atomicity- This property states that every transaction should be treated as an atomic unit that is,
either the entire transaction should be completed totally or it should not be done at all. It also
states that under no condition should a transaction be partially completed.
Consistency- The database must remain in consistent state after any transaction. The execution
of a transaction should not result in inconsistency of the database.
Isolation-in systems where more than one transaction execute simultaneously and in parallel, all
transaction will be carried out and each transaction should feel that it is the only transaction
happening. If Ti,Tj are two transactions, then Ti should feel that it is the only transaction
happening while it is executing, either Tj should have completed execution or will execute once
Ti completes.
Durability- The database should be durable enough to hold all its latest updates even if the
system fails or restarts. If a transaction updates data in a database and commits, then the database
will hold the modified data. If a transaction commits but the system fails before the data could be
written on to the disk, then that data will be updated once the system starts.

Database Backups with its types

https://www.youtube.com/watch?v=o-83E6levzM

Regular backups are required to protect database and ensure its restoration in case of failure.
Various backup types provide different protection to our database. Backing up and restoring data
is one of the most important responsibilities of IT professionals Three common types of database
backups can be run on a desired system: normal (full), incremental and differential.
i) Normal or Full Backups:
When a normal or full backup runs on a selected drive, all the files on that drive are backed up.
This, of course, includes system files, application files, user data — everything. Those files are
then copied to the selected destination (backup tapes, a secondary drive or the cloud), and all the
archive bits are then cleared. Normal backups are the fastest source to restore lost data because
all the data on a drive is saved in one location.
ii) Incremental Backups:
A common way to deal with the long running times required for full backups is to run them only
on weekends. Many businesses then run incremental backups throughout the week since they
take far less time. An incremental backup will grab only the files that have been updated since
the last normal backup. Once the incremental backup has run, that file will not be backed up
again unless it changes or during the next full backup.
iii) Differential Backups:
An alternative to incremental database backups that has a less complicated restore process is a
differential backup. Differential backups and recovery are similar to incremental in that these
backups grab only files that have been updated since the last normal backup.
However, differential backups do not clear the archive bit. So a file that is updated after a
normal backup will be archived every time a differential backup is run until the next normal
backup runs and clears the archive bit.

**For Reference
ii) Incremental Backups:
Incremental backups copy all of the files that have changed since the last backup was made.
They do this whether the last backup was a full one or an incremental copy. So if a full backup
was done on Day 1, Day 2’s incremental will back up all of the files that have changed since Day
1. Likewise, Day 3’s incremental backup will only copy those files that have changed since Day
2’s incremental took place.

The main advantage to incremental backups is that fewer files are copied in the period between
full backups, which means you will get a shorter backup window. The main disadvantage is that
when you want to carry out a complete restore, the most recent full backup and all of the
subsequent incremental copies must be restored. This can make the restore process a lengthier
one than when using a full backup plus the most recent differential copies only.

iii) Differential Backups:

Differential backups copy those files that have been changed since the last full backup took
place. So if a full backup was done on Day 1, Day 2’s differential will copy all of the files that
have changed since Day 1’s backup copied everything. Day 3’s differential backup will also
copy all of the files that have changed since Day 1’s full copy was made.

The key advantage of differential backups comes when data needs to be restored. Because a full
backup was taken and the differentials copied everything that subsequently changed, only the full
backup and the latest differential need to be restored.

The main disadvantage is that the size of the differential copy increases each time a backup is
taken until the next full version is made, which can begin to impinge on backup window
duration.

Database Recovery
When recovering the database, it is must redo the effects of the previous transactions. This is
called Rolling Forward or simple Forward Recovery. Not all but some active transaction that
didn’t complete successfully needs to rollback, when the disk drive crashed. Such kind of
rollback is called Backward Recovery.

The Redo Log and Rolling Forward (REDO operation)

The redo log is a set of operating system files that record all changes made to any database
buffer, including data, index, and rollback segments, whether the changes are committed or
uncommitted. The redo log protects changes made to database buffers in memory that have not
been written to the data files. The first step of recovery from an instance or disk failure is to roll
forward, or reapply all of the changes recorded in the redo log to the data files. Because rollback
data is also recorded in the redo log, rolling forward also regenerates the corresponding rollback
segments.
Rolling forward proceeds through as many redo log files as necessary to bring the database
forward in time. Rolling forward usually includes online redo log files and may include archived
redo log files. After roll forward, the data blocks contain all committed changes as well as any
uncommitted changes that were recorded in the redo log.

Rollback Segments and Rolling Back (UNDO operation)

Rollback segments record database actions that should be undone during certain database
operations. In database recovery, rollback segments undo the effects of uncommitted transactions
previously applied by the rolling forward phase. After the roll forward, any changes that were
not committed must be undone. After redo log files have reapplied all changes made to the
database, then the corresponding rollback segments are used. Rollback segments are used to
identify and undo transactions that were never committed, yet were recorded in the redo log and
applied to the database during roll forward. This process is called rolling back.

Transactional Control Commands

Transactional control commands are only used with the DML Commands such as -
INSERT, UPDATE and DELETE only. They cannot be used while creating tables or
dropping them because these operations are automatically committed in the database.

The COMMIT Command

The COMMIT command is the transactional command used to save changes invoked
by a transaction to the database.
The COMMIT command is the transactional command used to save changes invoked
by a transaction to the database. The COMMIT command saves all the transactions to
the database since the last COMMIT or ROLLBACK command.
The syntax for the COMMIT command is as follows.
COMMIT;
SQL> DELETE FROM CUSTOMERS
 WHERE AGE = 25;
SQL> COMMIT;

The ROLLBACK Command

The ROLLBACK command is the transactional command used to undo transactions

that have not already been saved to the database. This command can only be used to
undo transactions since the last COMMIT or ROLLBACK command was issued.
The syntax for a ROLLBACK command is as follows –
Following is an example, which would delete those records from the table which have
the age = 25 and then ROLLBACK the changes in the database.
SQL> DELETE FROM CUSTOMERS
WHERE AGE = 25;
SQL> ROLLBACK;

The SAVEPOINT Command

A SAVEPOINT is a point in a transaction when you can roll the transaction back to a
certain point without rolling back the entire transaction.
The syntax for a SAVEPOINT command is as shown below.
SAVEPOINT SAVEPOINT_NAME;
This command serves only in the creation of a SAVEPOINT among all the
transactional statements. The ROLLBACK command is used to undo a group of
transactions.
The syntax for rolling back to a SAVEPOINT is as shown below.
ROLLBACK TO SAVEPOINT_NAME;
Following is an example where you plan to delete the three different records from the
CUSTOMERS table. You want to create a SAVEPOINT before each delete, so that you
can ROLLBACK to any SAVEPOINT at any time to return the appropriate data to its
original state.
Example
Consider the CUSTOMERS table having the following records.
+----+----------+-----+-----------+----------+
| ID | NAME | AGE | ADDRESS | SALARY |
+----+----------+-----+-----------+----------+
| 1 | Ramesh | 32 | Ahmedabad | 2000.00 |
| 2 | Khilan | 25 | Delhi | 1500.00 |
| 3 | kaushik | 23 | Kota | 2000.00 |
| 4 | Chaitali | 25 | Mumbai | 6500.00 |
| 5 | Hardik | 27 | Bhopal | 8500.00 |
| 6 | Komal | 22 | MP | 4500.00 |
| 7 | Muffy | 24 | Indore | 10000.00 |
+----+----------+-----+-----------+----------+
The following code block contains the series of operations.
SQL> SAVEPOINT SP1;
Savepoint created.
SQL> DELETE FROM CUSTOMERS WHERE ID=1;
1 row deleted.
SQL> SAVEPOINT SP2;
Savepoint created.
SQL> DELETE FROM CUSTOMERS WHERE ID=2;
1 row deleted.
SQL> SAVEPOINT SP3;
Savepoint created.
SQL> DELETE FROM CUSTOMERS WHERE ID=3;
1 row deleted.
Now that the three deletions have taken place, let us assume that you have changed
your mind and decided to ROLLBACK to the SAVEPOINT that you identified as SP2.
Because SP2 was created after the first deletion, the last two deletions are undone −
SQL> ROLLBACK TO SP2;
Rollback complete.

The RELEASE SAVEPOINT Command

The RELEASE SAVEPOINT command is used to remove a SAVEPOINT that you have
created.
The syntax for a RELEASE SAVEPOINT command is as follows.
RELEASE SAVEPOINT SAVEPOINT_NAME;
Once a SAVEPOINT has been released, you can no longer use the ROLLBACK
command to undo transactions performed since the last SAVEPOINT.

The SET TRANSACTION Command

The SET TRANSACTION command can be used to initiate a database transaction.

This command is used to specify characteristics for the transaction that follows. For
example, you can specify a transaction to be read only or read write.
The syntax for a SET TRANSACTION command is as follows.
SET TRANSACTION [ READ WRITE | READ ONLY ];