UNIT – VI

Data Normalization

Functional Dependency:-
The functional dependency is a relationship that exists between two attributes. It typically
exists between the primary key and non-key attribute within a table. Symbolically
represent

X → Y

The left side of FD is known as a determinant, the right side of the production is known
as a dependent.

For example –

Assume we have an employee table with attributes: Emp_Id, Emp_Name, Emp_Address.

Here Emp_Id attribute can uniquely identify the Emp_Name attribute of employee table
because if we know the Emp_Id, we can tell that employee name associated with it.

Functional dependency can be written as:

Emp_Id → Emp_Name

We can say that Emp_Name is functionally dependent on Emp_Id.

 Types of Functional dependency

1. Trivial functional dependency

o A → B has trivial functional dependency if B is a subset of A.

o The following dependencies are also trivial like: A → A, B → B

For example

1. Consider a table with two columns Employee_Id and Employee_Name.

2. {Employee_id, Employee_Name} → Employee_Id is a trivial functional dependency
as
3. Employee_Id is a subset of {Employee_Id, Employee_Name}.
4. Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are
trivial dependencies too.
A ∩ B = NOT Φ
2. Non-trivial functional dependency

o A → B has a non-trivial functional dependency if B is not a subset of A.

o When A intersection B is NULL, then A → B is called as complete non-trivial.

1. ID → Name,
2. Name → DOB A∩B=Φ
 The Functional dependency has 6 types of inference rule:

1. Reflexive Rule (IR1)

In the reflexive rule, if Y is a subset of X, then X determines Y.

If X ⊇ Y then X → Y

1. X = {a, b, c, d, e}
2. Y = {a, b, c}

2. Augmentation Rule (IR2)

The augmentation is also called as a partial dependency. In augmentation, if X
determines Y, then XZ determines YZ for any Z.

1. If X → Y then XZ → YZ

Example:

1. For R(ABCD), if A → B then AC → BC C C

3. Transitive Rule (IR3)

In the transitive rule, if X determines Y and Y determine Z, then X must also determine
Z.

1. If X → Y and Y → Z then X → Z

4. Union Rule (IR4)

Union rule says, if X determines Y and X determines Z, then X must also determine Y
and Z.

1. If X → Y and X → Z then X → YZ

Proof:
 1. X → Y (given)
2. X → Z (given)
3. X → XY (using IR2 on 1 by augmentation with X. Where XX = X)
4. XY → YZ (using IR2 on 2 by augmentation with Y)
5. X → YZ (using IR3 on 3 and 4)

5. Decomposition Rule (IR5)

Decomposition rule is also known as project rule. It is the reverse of union rule.

This Rule says, if X determines Y and Z, then X determines Y and X determines Z

separately.

1. If X → YZ then X → Y and X → Z

Proof:

1. X → YZ (given)
2. YZ → Y (using IR1 Rule)
3. X → Y (using IR3 on 1 and 2)

6. Pseudo transitive Rule (IR6)

In Pseudo transitive Rule, if X determines Y and YZ determines W, then XZ determines
W.

1. If X → Y and YZ → W then XZ → W

Proof:

1. X → Y (given)
2. WY → Z (given)
3. WX → WY (using IR2 on 1 by augmenting with W)
4. WX → Z (using IR3 on 3 and 2)
Normalization
o Normalization is the process of organizing the data in the database.
o Normalization is used to minimize the redundancy from a relation or set of
relations. It is also used to eliminate the undesirable characteristics like
Insertion, Update and Deletion Anomalies.
o Normalization divides the larger table into the smaller table and links them using
relationship.
o The normal form is used to reduce redundancy from the database table.

Types of Normal Forms

First Normal Form (1NF)
o A relation will be 1NF if it contains an atomic value.
o It states that an attribute of a table cannot hold multiple values. It must hold only
single-valued attribute.
o First normal form disallows the multi-valued attribute, composite attribute, and
their combinations.

Example: Relation EMPLOYEE is not in 1NF because of multi-valued attribute

EMP_PHONE.
EMPLOYEE table:

EMP_ID EMP_NAME EMP_PHONE EMP_STATE

14 John 7272826385, UP
9064738238

20 Harry 8574783832 Bihar

12 Sam 7390372389, Punjab

8589830302

The decomposition of the EMPLOYEE table into 1NF has been shown as:

EMP_ID EMP_NAME EMP_PHONE EMP_STATE

14 John 7272826385 UP

14 John 9064738238 UP

20 Harry 8574783832 Bihar

12 Sam 7390372389 Punjab

12 Sam 8589830302 Punjab

Second Normal Form (2NF)
o In the 2NF, relational must be in 1NF.
o In the second normal form, all non-key attributes are fully functional dependent on
the candidate key OR
o These should be No Partial Dependency in the relation.

For example –

Customer

CUSTOMER_ID STORE_ID LOCATION

1 1 DELHI
1 3 MUMBAI
2 1 DELHI
3 2 BANGLORE
4 3 MUMBAI

Candidate key : (Customer_id,Store_id)

Prime Attribute : (Customer_id , Store_id)

Non Prime Attribute : Location

Customer_id Store_id

1 1

1 3

2 1

3 2

4 3
Store_id Location

1 Delhi

2 Bangalore

3 Mumbai

Q :- R(ABCDEF)

FD = {C F NOT IN 2NF

E A NOT IN 2NF

EC D IN 2NF

A B} NOT IN 2NF

1) CK = EC (E)+ = EFADB ©+ = CF (EC)+ = ECFABD

2) Prime Attribute : {E,C}

3) Non Prime Attribute: {A,B,D,F}

FOR Partially dependence check

Rule -> LHS should be Proper subset of CK AND RHS be a Non Prime Attribute

1) T & T = T NOT IN 2 NF
2) T & T = T NOT IN 2 NF
3) F & T =F IN 2 NF
1. NOT IN 2 NF
Third Normal Form (3NF)
o A relation will be in 3NF if it is in 2NF and not contain any transitive partial
dependency.
o 3NF is used to reduce the data duplication. It is also used to achieve the data
integrity.
o If there is no transitive dependency for non-prime attributes, then the relation must
be in third normal form.

ROLL_NO STATE CITY

1 PANJAB MOHALI
2 HARYANA AMBALA
3 PANJAB MOHALI
4 HARYANA AMBALA
5 BIHAR PATNA

CK = {ROLL_NO}

FD = {ROLL_NO -> STATE, STATE ->CITY}

PA = {ROLL_NO}

NPA = {STATE,CITY}

ROLL_NO STATE

1 PANJAB

2 HARYANA

3 PANJAB

4 HARYANA

5 BIHAR
STATE CITY

PANJAB MOHALI

HARYANA AMBALA

BIHAR PATNA

Q : R(ABCD)

FD = { AB -> CD , D -> A }

CK= {AB,DB} (B)+ = B/ (AB)+ = ABCD

PA = {A,B,D} (DB)+ =DBAC

NPA = {C}

FOR each FD

RULE -: LHS must be a CK or SK OR RHS is a Prime Attribute

IN 3 NF

Boyce Codd normal form (BCNF)

 o BCNF is the advance version of 3NF. It is stricter than 3NF.
o A table is in BCNF if every functional dependency X → Y, X is the super key of
the table and CK.
o For BCNF, the table should be in 3NF, and for every FD, LHS is super key.

Example: Let's assume there is a company where employees work in more than one
department.

EMPLOYEE table:

EMP_ID EMP_COUNTRY EMP_DEPT DEPT_TYPE EMP_DEPT_NO

264 India Designing D394 283

264 India Testing D394 300

364 UK Stores D283 232

364 UK Developing D283 549

In the above table Functional dependencies are as follows:

1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

Candidate key: {EMP-ID, EMP-DEPT}

The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.

To convert the given table into BCNF, we decompose it into three tables:

EMP_COUNTRY table:
 EMP_ID EMP_COUNTRY

264 India

264 India

EMP_DEPT table:

EMP_DEPT DEPT_TYPE EMP_DEPT_NO

Designing D394 283

Testing D394 300

Stores D283 232

Developing D283 549

EMP_DEPT_MAPPING table:

EMP_ID EMP_DEPT

D394 283

D394 300

D283 232

D283 549

Functional dependencies:

1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

Candidate keys:
For the first table: EMP_ID
For the second table: EMP_DEPT
For the third table: {EMP_ID, EMP_DEPT}

Now, this is in BCNF because left side part of both the functional dependencies is a key.

Q) - R(ABCDEF) Highest NF ?
FD = { AB → C , C → DE , E →F , F → A}
STEP 1- Find all CK Key in a Given Relation

CK = {AB, FB, EB, CB}

(AB)+ = ABCDEF
(FB)+ = FBACDE
(EB)+ = EBFACD
(CB)+ = CBDEFA
STEP 2 – Prime Attribute

{ A,B,C,E,F}

STEP 3 – NPA

{D}
 NF AB → C C → DE E →F F →A
TEST

BCNF YES NO NO NO

3NF YES NO YES YES

2NF YES NO YES YES

1NF YES YES YES YES

Q) :- R(ABCDEF) CONVERT IN HIGHEST NF ?
FD = { AB → C , C →D ,C →E E →F , F → A}
NF AB → C C →D C →E E →F F →A
TEST

BCNF YES NO NO NO NO

3NF YES NO YES YES YES

2NF YES NO YES YES YES

1NF YES YES YES YES YES

AB → C , C →D ,C →E E →F , F →A
(AB)+ = ABCDEF
(FB)+ = FBACDE
(EB)+ = EBFACD
(CB)+ = CBEADF
1) CK = { AB,FB,EB,CB}
2) PA = { A,B,C,E,F}
3) NPA = {D}

ABCDEF
R

ABCEF CD
R1 R2
R1 (ABCEF)
FD = { AB → C, C →E E →F , F → A}
R2(CD)
FD = { C → D}

TAKE R2
1) CK = {C}
2) PA ={C}
3) NPA = {D}
TEST FOR NF
FOR BCNF - YES

R1 (ABCEF)
FD = { AB → C, C →E E →F , F → A}
1) CK={AB,FB,EB,CB}
2) PA = {A,B,C,E,F}
3) NPA = {}
FOR – R1
NF AB → C C →E E →F F →A
TEST

BCNF YES NO NO NO

3NF YES YES YES YES

2NF YES YES YES YES

1NF YES YES YES YES

 R1 ABCEF

ABC
R CE EF FA

R3 - AB → C
CK = {AB}
PA = {A,B}
NPA = {C}
FOR BCNF - YES

R4 - C →E
CK = {C}
PA = {C}
NPA = {E}
FOR BCNF = YES
R5 - E → F
CK = {E}
PA = {E}
NPA = {F}
FOR BCNF = YES

R6 - F → A
CK = {F}
PA = {F}
NPA = {A}
FOR BCNF = YES
4 NF - A table is in the fourth normal form if
1) It is in BCNF
2) It does not have any independent multi valued parts of the primary key
3) For a dependency A → B, if for a single value of A, multiple values of B
exists, then the relation will be a multi-valued dependency.

Lets say we have table Teacher which give information about

1) A Teacher can teach many subjects

2) A Teacher may Know many language

Teacher-

Teacher_Name Teacher_Subject Teacher_Language

Narendra Science Hindi
Narendra Maths Hindi
Narendra Science English
Narendra History English
Alok Science Hindi
Alok Physical Education English

We can see that Narendra is teaching three subject & know two language thus
there are two independent multivalued dependence. We can split the table into
two table.
 Teacher_Subject-

Teacher_Name Teacher_Subject
Narendra Science
Narendra Maths
Narendra History
Alok Science
Alok Physical Education

Teacher_Language-

Teacher_Name Teacher_Language
Narendra Hindi
Narendra English
Alok Hindi
Alok English
Relational Decomposition
o When a relation in the relational model is not in appropriate normal form
then the decomposition of a relation is required.
o In a database, it breaks the table into multiple tables.
o If the relation has no proper decomposition, then it may lead to problems
like loss of information.
o Decomposition is used to eliminate some of the problems of bad design
like anomalies, inconsistencies, and redundancy.

Types of Decomposition

Dependency Preserving -
o It is an important constraint of the database.
o In the dependency preservation, at least one decomposed table must
satisfy every dependency.
o If a relation R is decomposed into relation R1 and R2, then the
dependencies of R either must be a part of R1 or R2 or must be derivable
from the combination of functional dependencies of R1 and R2.
 o For example, suppose there is a relation R (A, B, C, D) with functional
dependency set (A->BC). The relational R is decomposed into R1(ABC)
and R2(AD) which is dependency preserving because FD A->BC is a
part of relation R1(ABC).

Dependency Preserving Decompositions

Let R(ABCD) with functional dependence
FD = { A -> B,
B -> C,
C -> D,
D -> B }
R is decomposition into R1(AB) , R2(BC) ,R3(BD).

R1(AB)
A - >A not need because trivial dependency
B - >B not need because trivial dependency
A - >B A+ = AB
B ->A
 R2(BC)
B->B not need because trivial dependency
B -> C
C -> B
C -> C not need because trivial dependency

R3(BD)
B ->B not need because trivial dependency
B ->D
D ->D not need because trivial dependency
D ->B

R1(AB) FD = {A ->B}
R2(BC) FD = {B ->C , C ->B}
R3(DB) FD = { B ->D , D ->B }
NOW UNION OF ALL RELATION FUNCTION DEPENDENCE
FDALL = {A ->B , B ->C , C ->B , B ->D , D ->B}
{A -> B , B ->C , C -> D => (C ->B , B ->D) , D ->B}
Lossless Decomposition

o If the information is not lost from the relation that is decomposed, then
the decomposition will be lossless.
o The lossless decomposition guarantees that the join of relations will
result in the same relation as it was decomposed.
o The relation is said to be lossless decomposition if natural joins of all the
decomposition give the original relation. i.e. R = R1 R2

Lossy Decomposition - Contain extra tuples

For eg-
1) R(ABC) Decomposition in R1(AB) and R2(BC) Check whether lossless
& lossy .
Give FD of R { A -> B}
R1 ∩ R2 = B IS not a key in either R1 or R2
So it is lossy Decomposition

2) R(ABC) FD = (A -> B) Decomposition of R1(AB) and R2(AC) is

lossless or lossy
R1 ∩ R2 = A is a key in Relation R1
So it is Lossless Decomposition

3) R(ABCD) FD = {A ->B , A -> C , C -> D} Decomposition

Into R1(ABC) & R2(CD) is Lossless and lossy.
A B C D
R1 @ @ @ @
R2 @ @
It is lossless decomposition because C declare as a key in both (R1,R2)relation.
Q) R(ABCDE)
FD = {AB -> CD , A ->E , C ->D}
R1(ABC)
R2(BCD)
R3(CDE)

A B C D E
R1 @ @ @ @
R2 @ @ @
R3 @ @ @

It is lossy decomposition

Q) R(ABCDEG)
FD = {AD -> E, B -> D, E ->G}
R1 (AB)
R2 (BC)
R3 (ABDE)
R4 (EG)
A B C D E G
R1 @ @ @ @ @
R2 @ @ @
R3 @ @ @ @ @
R4 @ @

It is lossy decomposition.
Transaction
o The transaction is a set of logically related operation. It contains a group of tasks.
o A transaction is an action or series of actions. It is performed by a single user to
perform operations for accessing the contents of the database.
o Only once the database is committed the state is changed from one consistent state
to another.

Operations of Transaction:
Following are the main operations of transaction:

Read(X): Read operation is used to read the value of X from the database and stores it in
a buffer in main memory.

Write(X): Write operation is used to write the value back to the database from the buffer .

Transaction property
The transaction has the four properties. These are used to maintain consistency in a
database, before and after the transaction.

Property of Transaction

1. Atomicity
2. Consistency
3. Isolation
4. Durability
Atomicity

o It states that all operations of the transaction take place at once if not, the
transaction is aborted.
o There is no midway, i.e., the transaction cannot occur partially. Each transaction is
treated as one unit and either run to completion or is not executed at all.

Atomicity involves the following two operations:

Abort: If a transaction aborts then all the changes made are not visible.

Commit: If a transaction commits then all the changes made are visible.
Consistency

o The integrity constraints are maintained so that the database is consistent before
and after the transaction.
o The execution of a transaction will leave a database in either its prior stable state or
a new stable state.
o The consistent property of database states that every transaction sees a consistent
database instance.
o The transaction is used to transform the database from one consistent state to
another consistent state.

For example: The total amount must be maintained before or after the transaction.

Before transaction of amount

And

After transaction of amount

The money value should be same

Eg - A = 3000
B = 2000 A + B = 3000+2000 = 5000
OPERATION A - > B = 1000
T1
R(A)
A = A-1000
W(A) = 2000 SAVE (IN SHARED MEMORY –RAM)
R(B)
B = B+1000
W(B) = 3000
COMMIT

A+B = 2000 + 3000 = 5000

Isolation

o It shows that the data which is used at the time of execution of a transaction cannot
be used by the second transaction until the first one is completed.
o In isolation, if the transaction T1 is being executed and using the data item X, then
that data item can't be accessed by any other transaction T2 until the transaction T1
ends.
o The concurrency control subsystem of the DBMS enforced the isolation property.

Remove Parallel transaction

T1 AND T2

T1 -> T2 OR T2 -> T1

Durability

o The durability property is used to indicate the performance of the database's

consistent state. It states that the transaction made the permanent changes.
o They cannot be lost by the erroneous operation of a faulty transaction or by the
system failure. When a transaction is completed, then the database reaches a state
known as the consistent state. that consistent state cannot be lost, even in the event
of a system's failure.
o The recovery subsystem of the DBMS has the responsibility of Durability
property.
 Transaction States
A transaction goes through many different states throughout its life cycle.
These states are called as transaction states.
Transaction states are as follows-
1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Aborted state
6. Terminated state
 1. Active State-

 This is the first state in the life cycle of a transaction.

 A transaction is called in an active state as long as its instructions are getting executed.
 All the changes made by the transaction now are stored in the buffer in main memory.

2. Partially Committed State-

 After the last instruction of transaction has executed, it enters into a partially
committed state.
 After entering this state, the transaction is considered to be partially committed.
 It is not considered fully committed because all the changes made by the transaction are
still stored in the buffer in main memory.

3. Committed State-

 After all the changes made by the transaction have been successfully stored into the
database, it enters into a committed state.
 Now, the transaction is considered to be fully committed.

4. Failed State-

 When a transaction is getting executed in the active state or partially committed state
and some failure occurs due to which it becomes impossible to continue the execution,
it enters into a failed state.

5. Aborted State-

 After the transaction has failed and entered into a failed state, all the changes made by it
have to be undone.
 To undo the changes made by the transaction, it becomes necessary to roll back the
transaction.
 After the transaction has rolled back completely, it enters into an aborted state.
 6. Terminated State-

 This is the last state in the life cycle of a transaction.

 After entering the committed state or aborted state, the transaction finally enters into
a terminated state where its life cycle finally comes to an end.
Schedules
The order in which the operations of multiple transactions appear for
execution is called as a schedule.

T1 , T2,T3,T4,…………….TN.

Types of Schedules-
 Serial Schedules-

In serial schedules,
 All the transactions execute serially one after the other.
 When one transaction executes, no other transaction is allowed to execute.

Characteristics-

Serial schedules are always-

 Consistent
 Recoverable
 Cascadeless
 Strict

Eg. –

In this schedule,
 There are two transactions T1 and T2 executing serially one after the other.
 Transaction T1 executes first.
 After T1 completes its execution, transaction T2 executes.
 So, this schedule is an example of a Serial Schedule.
 Serializability in DBMS-

 Some non-serial schedules may lead to inconsistency of the database.

 Serializability is a concept that helps to identify which non-serial schedules are correct
and will maintain the consistency of the database.

Serializable Schedules-

If a given non-serial schedule of ‘n’ transactions is equivalent to some serial schedule of

‘n’ transactions, then it is called as a serializable schedule.
Characteristics-
Serializable schedules behave exactly same as serial schedules.
Thus, serializable schedules are always-
 Consistent
 Recoverable
 Casacadeless

Serial Schedules Vs Serializable Schedules-

Serial Schedules Serializable Schedules

No concurrency is allowed. Concurrency is allowed.

Thus, all the transactions necessarily execute Thus, multiple transactions can execute
serially one after the other. concurrently.

Serial schedules lead to less resource Serializable schedules improve both resource
utilization and CPU throughput. utilization and CPU throughput.

Serial Schedules are less efficient as compared Serializable Schedules are always better than
to serializable schedules. serial schedules.

(due to above reason) (due to above reason)

 Types of Serializability-

1. Conflict Serializability
2. View Serializability

Conflict Serializability-

If a given non-serial schedule can be converted into a serial schedule by swapping its
non-conflicting operations, then it is called as a conflict serializable schedule.

Conflicting Operations-

Two operations are called as conflicting operations if all the following conditions hold
true for them-
 Both the operations belong to different transactions
 Both the operations are on the same data item
 At least one of the two operations is a write operation
Conflict Serializability-Check conflict pair in other transaction and draw edge.

T1 T2 T3
R(x)
R(y)
R(x)
R(y)
R(z)
W(y)
W(z)
R(z)
W(x)
W(z)

Conflict Pair - R–W draw precedence graph

W–R
W-W
View Serializability-
If a given schedule is found to be view equivalent to some
serial schedule, then it is called as a view serializable schedule.

T1 T2 T3

R(A)

W(A)

W(A)

W(A)
 Irrecoverable Schedules-

If in a schedule,
 A transaction performs a dirty read operation from an uncommitted transaction
 And commits before the transaction from which it has read the value
then such a schedule is known as an Irrecoverable Schedule.

Here,
 T2 performs a dirty read operation.
 T2 commits before T1.
 T1 fails later and roll backs.
 The value that T2 read now stands to be incorrect.
 T2 can not recover since it has already committed.
 Recoverable Schedules-

If in a schedule,
 A transaction performs a dirty read operation from an uncommitted transaction
 And its commit operation is delayed till the uncommitted transaction either commits or
roll backs
then such a schedule is known as a Recoverable Schedule.

Here,
 The commit operation of the transaction that performs the dirty read is delayed.
 This ensures that it still has a chance to recover if the uncommitted transaction fails
later.
 Cascading Schedule-

 If in a schedule, failure of one transaction causes several other dependent transactions

to rollback or abort, then such a schedule is called as a Cascading
Schedule or Cascading Rollback or Cascading Abort.
 It simply leads to the wastage of CPU time.

Here,
 Transaction T2 depends on transaction T1.
 Transaction T3 depends on transaction T2.
 Transaction T4 depends on transaction T3.
 In this schedule,
 The failure of transaction T1 causes the transaction T2 to rollback.
 The rollback of transaction T2 causes the transaction T3 to rollback.
 The rollback of transaction T3 causes the transaction T4 to rollback.
Such a rollback is called as a Cascading Rollback.

Cascadeless Schedule-

If in a schedule, a transaction is not allowed to read a data item until the last transaction
that has written it is committed or aborted, then such a schedule is called as
a Cascadeless Schedule.
In other words,
 Cascadeless schedule allows only committed read operations.
 Therefore, it avoids cascading roll back and thus saves CPU time.
 Strict Schedule-

If in a schedule, a transaction is neither allowed to read nor write a data item until the last
transaction that has written it is committed or aborted, then such a schedule is called as
a Strict Schedule.
In other words,
 Strict schedule allows only committed read and write operations.
 Clearly, strict schedule implements more restrictions than cascadeless schedule.

 Strict schedules are more strict than cascadeless schedules.

 All strict schedules are cascadeless schedules.
 All cascadeless schedules are not strict schedules.
Recovery:
Database recovery from failure such as system crashes, transaction errors etc.

A database may be in inconsistent state when:

(i) Dead lock has occurred.

(ii) A transaction is aborted after updating the database
(iii) Software or hardware errors are occurred.
(iv) Incorrect updates have been applied to the database.

If the database is in inconsistent state, it should be recovered to a consistent state.

This basis of recovery is to have backups of the data in the database.

Types of recovery:

Dump: A full backup of the database. In this method .

· The entire contents of the database is backed up in an a auxiliary storage
· Backup is taken only at the consistent state of the database
· Dumping takes a long time to perform
· Dumping is expensive and can be performed repeatedly
Transaction log: (Journal)

 A log is a sequence of log records recording all the update activities in the database
since the last consistent state.
 Database can have state before and after each transaction (information)
 When the database is returned to a consistent state, the log may be truncated to
remove committed transaction.
 When the database is returned to a consistent state the process is often referred to
as check pointing.

Checkpoint: Checkpoint is a scheme, which is used to limit the volume of log

 information that has to be handed and process in the event of a system failure
 involving loss of volatile information.
 It is performed periodically. It performs the following sequence of actions to
take place.
 Output all log records currently residing in main memory into stable storage.
  Output all modified buffer blocks to the disk
 Write a log record <check point> on to stable storage.

Recovery using check point:

 During recovery we need to consider only the most recent transaction Ti that
started
 before the check point and transaction that started after Ti.
 Same backwards from end of log to find the most recent <check point> record.
 Continue scanning backwards to a record <Ti start> is found
 Need only consider the part of log following above start record.
 Earlier part of part of log can be ignored during recovery and can be erased
whenever desired.
 For all transactions (starting form Ti or latter) with no <Ti commit>, execute undo
Ti. Done only in case of immediate modification.
 Canning forward in the log, for all transactions starting form Ti or later with a <Ti
commit> execute redo (Ti)

IF the DBMS fails and restarted:

 The disks are physically or logically damaged then the recovery form log is
impossible and instead a restore from a dump is needed.
 If the disks are ok then the database consistency must be maintained. Writes to
disk which was in progress at the time of failure may have only been partially
done .
 Parse the log file and where a transaction has been ended, with commit apply
the new data part of the log to the database.
 IF a log entry for a transaction ends with any thing other than commit, apply the
old data party the log to the database.
 Flush the data to the disk and then truncate the log to Zero.
Roll Back

The process of undoing changes done to the disk under immediate update is frequently
referred to as rollback.
 Where the DBMS does not prevent one transaction from reading un committed
modifications (a dirty read) of another transaction (i.e. the uncommitted
dependency problem,) then aborting the first transaction also means aborting all
transactions which have performed their dirty reads.
 As a transaction is aborted it can therefore cause aborts in other dirty reader
transactions, which in turn can cause other aborts in other dirty reader transaction.
This is refereed to as cascade roll back.