Database Management System | Gate Vidyalay

Category: Database Management System

ACID Properties | ACID Properties in DBMS

Transaction in DBMS-

Before you go through this article, make sure that you have gone through the previous article on Transactions in DBMS.

We have discussed-

A transaction is a set of logically related operations.
A transaction goes through different states throughout its life cycle.
The life cycle of a transaction is-

In this article, we will discuss ACID properties of a transaction.

ACID Properties-

It is important to ensure that the database remains consistent before and after the transaction.
To ensure the consistency of database, certain properties are followed by all the transactions occurring in the system.
These properties are called as ACID Properties of a transaction.

1. Atomicity-

This property ensures that either the transaction occurs completely or it does not occur at all.
In other words, it ensures that no transaction occurs partially.
That is why, it is also referred to as “All or nothing rule“.
It is the responsibility of Transaction Control Manager to ensure atomicity of the transactions.

2. Consistency-

This property ensures that integrity constraints are maintained.
In other words, it ensures that the database remains consistent before and after the transaction.
It is the responsibility of DBMS and application programmer to ensure consistency of the database.

3. Isolation-

This property ensures that multiple transactions can occur simultaneously without causing any inconsistency.
During execution, each transaction feels as if it is getting executed alone in the system.
A transaction does not realize that there are other transactions as well getting executed parallely.
Changes made by a transaction becomes visible to other transactions only after they are written in the memory.
The resultant state of the system after executing all the transactions is same as the state that would be achieved if the transactions were executed serially one after the other.
It is the responsibility of concurrency control manager to ensure isolation for all the transactions.

4. Durability-

This property ensures that all the changes made by a transaction after its successful execution are written successfully to the disk.
It also ensures that these changes exist permanently and are never lost even if there occurs a failure of any kind.
It is the responsibility of recovery manager to ensure durability in the database.

Next Article- Concurrency Problems in DBMS

Get more notes and other study material of Database Management System (DBMS).

Watch video lectures by visiting our YouTube channel LearnVidFun.

ER Diagrams to Tables | Practice Problems

Database Management System

ER Diagrams to Tables-

Before you go through this article, make sure that you have gone through the previous article on ER Diagrams to Tables.

After designing an ER Diagram,

ER diagram is converted into the tables in relational model.
This is because relational models can be easily implemented by RDBMS like MySQL , Oracle etc.
The rules used for converting an ER diagram into the tables are already discussed.

In this article, we will discuss practice problems based on converting ER Diagrams to Tables.

PRACTICE PROBLEMS BASED ON CONVERTING ER DIAGRAM TO TABLES-

Problem-01:

Find the minimum number of tables required for the following ER diagram in relational model-

Solution-

Applying the rules, minimum 3 tables will be required-

MR1 (M1 , M2 , M3 , P1)
P (P1 , P2)
NR2 (P1 , N1 , N2)

Problem-02:

Find the minimum number of tables required to represent the given ER diagram in relational model-

Solution-

Applying the rules, minimum 4 tables will be required-

AR1R2 (a1 , a2 , b1 , c1)
B (b1 , b2)
C (c1 , c2)
R3 (b1 , c1)

Problem-03:

Find the minimum number of tables required to represent the given ER diagram in relational model-

Solution-

Applying the rules, minimum 5 tables will be required-

BR1R4R5 (b1 , b2 , a1 , c1 , d1)
A (a1 , a2)
R2 (a1 , c1)
CR3 (c1 , c2 , d1)
D (d1 , d2)

Problem-04:

Find the minimum number of tables required to represent the given ER diagram in relational model-

Solution-

Applying the rules, minimum 3 tables will be required-

E1 (a1 , a2)
E2R1R2 (b1 , b2 , a1 , c1 , b3)
E3 (c1 , c2)

Problem-05:

Find the minimum number of tables required to represent the given ER diagram in relational model-

Solution-

Applying the rules that we have learnt, minimum 6 tables will be required-

Account (Ac_no , Balance , b_name)
Branch (b_name , b_city , Assets)
Loan (L_no , Amt , b_name)
Borrower (C_name , L_no)
Customer (C_name , C_street , C_city)
Depositor (C_name , Ac_no)

Next Article- Constraints in DBMS

Get more notes and other study material of Database Management System (DBMS).

Watch video lectures by visiting our YouTube channel LearnVidFun.

Attributes in ER Diagram-

Before you go through this article, make sure that you have gone through the previous article on Introduction to ER Diagrams.

Attributes are the descriptive properties which are owned by each entity of an Entity Set.
There exist a specific domain or set of values for each attribute from where the attribute can take its values.

Types of Attributes-

In ER diagram, attributes associated with an entity set may be of the following types-

Simple attributes
Composite attributes
Single valued attributes
Multi valued attributes
Derived attributes
Key attributes

1. Simple Attributes-

Simple attributes are those attributes which can not be divided further.

Example-

Here, all the attributes are simple attributes as they can not be divided further.

2. Composite Attributes-

Composite attributes are those attributes which are composed of many other simple attributes.

Example-

Here, the attributes “Name” and “Address” are composite attributes as they are composed of many other simple attributes.

3. Single Valued Attributes-

Single valued attributes are those attributes which can take only one value for a given entity from an entity set.

Example-

Here, all the attributes are single valued attributes as they can take only one specific value for each entity.

4. Multi Valued Attributes-

Multi valued attributes are those attributes which can take more than one value for a given entity from an entity set.

Example-

Here, the attributes “Mob_no” and “Email_id” are multi valued attributes as they can take more than one values for a given entity.

5. Derived Attributes-

Derived attributes are those attributes which can be derived from other attribute(s).

Example-

Here, the attribute “Age” is a derived attribute as it can be derived from the attribute “DOB”.

6. Key Attributes-

Key attributes are those attributes which can identify an entity uniquely in an entity set.

Example-

Here, the attribute “Roll_no” is a key attribute as it can identify any student uniquely.

Next Article- Converting ER Diagrams to Tables

Get more notes and other study material of Database Management System (DBMS).

Watch video lectures by visiting our YouTube channel LearnVidFun.

Recoverability in DBMS | Recoverable Schedule

Database Management System

Schedules in DBMS-

Before you go through this article, make sure that you have gone through the previous article on Schedules in DBMS.

We have discussed-

A schedule is the order in which the operations of multiple transactions appear for execution.
Non-serial schedules may be serializable or non-serializable.

In this article, we will discuss about Non-Serializable Schedules.

Also read- Serializability in DBMS

Non-Serializable Schedules-

A non-serial schedule which is not serializable is called as a non-serializable schedule.
A non-serializable schedule is not guaranteed to produce the the same effect as produced by some serial schedule on any consistent database.

Characteristics-

Non-serializable schedules-

may or may not be consistent
may or may not be recoverable

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.

Example-

Consider the following 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.

Example-

Consider the following schedule-

Here,

T2 performs a dirty read operation.
The commit operation of T2 is delayed till T1 commits or roll backs.
T1 commits later.
T2 is now allowed to commit.
In case, T1 would have failed, T2 has a chance to recover by rolling back.

Checking Whether a Schedule is Recoverable or Irrecoverable-

Method-01:

Check whether the given schedule is conflict serializable or not.

If the given schedule is conflict serializable, then it is surely recoverable. Stop and report your answer.
If the given schedule is not conflict serializable, then it may or may not be recoverable. Go and check using other methods.

Thumb Rules

All conflict serializable schedules are recoverable.
All recoverable schedules may or may not be conflict serializable.

Method-02:

Check if there exists any dirty read operation.

(Reading from an uncommitted transaction is called as a dirty read)

If there does not exist any dirty read operation, then the schedule is surely recoverable. Stop and report your answer.
If there exists any dirty read operation, then the schedule may or may not be recoverable.

If there exists a dirty read operation, then follow the following cases-

Case-01:

If the commit operation of the transaction performing the dirty read occurs before the commit or abort operation of the transaction which updated the value, then the schedule is irrecoverable.

Case-02:

If the commit operation of the transaction performing the dirty read is delayed till the commit or abort operation of the transaction which updated the value, then the schedule is recoverable.

Thumb Rule

No dirty read means a recoverable schedule.

Next Article- Cascading Schedule | Cascading Rollback | Cascadeless Schedule

Get more notes and other study material of Database Management System (DBMS).

Watch video lectures by visiting our YouTube channel LearnVidFun.

Schedules in DBMS-

Before you go through this article, make sure that you have gone through the previous article on Serializability in DBMS.

We have discussed-

The concept of serializability helps to identify the correct non-serial schedules that maintains the consistency of the database.
There are two types of serializability-

In this article, we will discuss about View Serializability.

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.

Also read- Schedules in DBMS

View Equivalent Schedules-

Consider two schedules S1 and S2 each consisting of two transactions T1 and T2.

Schedules S1 and S2 are called view equivalent if the following three conditions hold true for them-

Condition-01:

For each data item X, if transaction T_i reads X from the database initially in schedule S1, then in schedule S2 also, T_imust perform the initial read of X from the database.

Thumb Rule

“Initial readers must be same for all the data items”.

Condition-02:

If transaction T_i reads a data item that has been updated by the transaction T_j in schedule S1, then in schedule S2 also, transaction T_i must read the same data item that has been updated by the transaction T_j.

Thumb Rule

“Write-read sequence must be same.”.

Condition-03:

For each data item X, if X has been updated at last by transaction T_i in schedule S1, then in schedule S2 also, X must be updated at last by transaction T_i.

Thumb Rule

“Final writers must be same for all the data items”.

Checking Whether a Schedule is View Serializable Or Not-

Method-01:

Check whether the given schedule is conflict serializable or not.

If the given schedule is conflict serializable, then it is surely view serializable. Stop and report your answer.
If the given schedule is not conflict serializable, then it may or may not be view serializable. Go and check using other methods.

Thumb Rules

All conflict serializable schedules are view serializable.
All view serializable schedules may or may not be conflict serializable.

Method-02:

Check if there exists any blind write operation.

(Writing without reading is called as a blind write).

If there does not exist any blind write, then the schedule is surely not view serializable. Stop and report your answer.
If there exists any blind write, then the schedule may or may not be view serializable. Go and check using other methods.

Thumb Rule

No blind write means not a view serializable schedule.

Method-03:

In this method, try finding a view equivalent serial schedule.

By using the above three conditions, write all the dependencies.
Then, draw a graph using those dependencies.
If there exists no cycle in the graph, then the schedule is view serializable otherwise not.

Next Article- Practice Problems On View Serializability

Get more notes and other study material of Database Management System (DBMS).

Watch video lectures by visiting our YouTube channel LearnVidFun.

← Older Posts

Newer Posts →