DBMS QUESTIONS

10 MARK

11. DBMS Architecture

o The DBMS design depends upon its architecture. The basic client/server architecture
is used to deal with a large number of PCs, web servers, database servers and other
components that are connected with networks.
o The client/server architecture consists of many PCs and a workstation which are
connected via the network.
o DBMS architecture depends upon how users are connected to the database to get
their request done.

Types of DBMS Architecture

Database architecture can be seen as a single tier or multi-tier. But logically, database
architecture is of two types like: 2-tier architecture and 3-tier architecture.

1-Tier Architecture

o In this architecture, the database is directly available to the user. It means the user
can directly sit on the DBMS and uses it.
o Any changes done here will directly be done on the database itself. It doesn't provide
a handy tool for end users.
o The 1-Tier architecture is used for development of the local application, where
programmers can directly communicate with the database for the quick response.
2-Tier Architecture

o The 2-Tier architecture is same as basic client-server. In the two-tier architecture,

applications on the client end can directly communicate with the database at the
server side. For this interaction, API's like: ODBC, JDBC are used.
o The user interfaces and application programs are run on the client-side.
o The server side is responsible to provide the functionalities like: query processing
and transaction management.
o To communicate with the DBMS, client-side application establishes a connection
with the server side.

Fig: 2-tier Architecture

3-Tier Architecture

o The 3-Tier architecture contains another layer between the client and server. In this
architecture, client can't directly communicate with the server.
o The application on the client-end interacts with an application server which further
communicates with the database system.
o End user has no idea about the existence of the database beyond the application
server. The database also has no idea about any other user beyond the application.
o The 3-Tier architecture is used in case of large web application.
ER diagram is known as Entity-Relationship diagram. It is used to analyze to structure
of the Database. It shows relationships between entities and their attributes. An ER
model provides a means of communication.
ER diagram of Bank has the following description :

 Bank have Customer.

 Banks are identified by a name, code, address of main office.
 Banks have branches.
 Branches are identified by a branch_no., branch_name, address.
 Customers are identified by name, cust-id, phone number, address.
 Customer can have one or more accounts.
 Accounts are identified by account_no., acc_type, balance.
 Customer can avail loans.
 Loans are identified by loan_id, loan_type and amount.
 Account and loans are related to bank’s branch.
ER Diagram of Bank Management System :
This bank ER diagram illustrates key information about bank, including entities such as
branches, customers, accounts, and loans. It allows us to understand the relationships
between entities.
Entities and their Attributes are :

 Bank Entity : Attributes of Bank Entity are Bank Name, Code and Address.
Code is Primary Key for Bank Entity.
 Customer Entity : Attributes of Customer Entity are Customer_id, Name,
Phone Number and Address.
Customer_id is Primary Key for Customer Entity.
 Branch Entity : Attributes of Branch Entity are Branch_id, Name and
Address.
Branch_id is Primary Key for Branch Entity.
 Account Entity : Attributes of Account Entity are Account_number,
Account_Type and Balance.
Account_number is Primary Key for Account Entity.
 Loan Entity : Attributes of Loan Entity are Loan_id, Loan_Type and
Amount.
Loan_id is Primary Key for Loan Entity.
Relationships are :

 Bank has Branches => 1 : N

One Bank can have many Branches but one Branch can not belong to many
Banks, so the relationship between Bank and Branch is one to many
relationship.

 Branch maintain Accounts => 1 : N

One Branch can have many Accounts but one Account can not belong to
many Branches, so the relationship between Branch and Account is one to
many relationship.

 Branch offer Loans => 1 : N

One Branch can have many Loans but one Loan can not belong to many
Branches, so the relationship between Branch and Loan is one to many
relationship.

 Account held by Customers => M : N

One Customer can have more than one Accounts and also One Account can
be held by one or more Customers, so the relationship between Account and
Customers is many to many relationship.

 Loan availed by Customer => M : N

(Assume loan can be jointly held by many Customers).
One Customer can have more than one Loans and also One Loan can be
availed by one or more Customers, so the relationship between Loan and
Customers is many to many relationship.
12. Referential Integrity constraints in DBMS

A referential integrity constraint is also known as foreign key constraint. A foreign key is
a key whose values are derived from the Primary key of another table.

The table from which the values are derived is known as Master or Referenced Table and
the Table in which values are inserted accordingly is known as Child or Referencing Table,
In other words, we can say that the table containing the foreign key is called the child table,
and the table containing the Primary key/candidate key is called the referenced or parent
table. When we talk about the database relational model, the candidate key can be defined
as a set of attribute which can have zero or more attributes.

The syntax of the Master Table or Referenced table is:

1. CREATE TABLE Student (Roll int PRIMARY KEY, Name varchar(25) , Course
varchar(10) );

Here column Roll is acting as Primary Key, which will help in deriving the value of foreign
key in the child table.

Play Video

The syntax of Child Table or Referencing table is:

1. CREATE TABLE Subject (Roll int references Student, SubCode int, SubName va
rchar(10) );

In the above table, column Roll is acting as Foreign Key, whose values are derived using
the Roll value of Primary key from Master table.
Foreign Key Constraint OR Referential Integrity constraint.

There are two referential integrity constraint:

Insert Constraint: Value cannot be inserted in CHILD Table if the value is not lying in
MASTER Table

Delete Constraint: Value cannot be deleted from MASTER Table if the value is lying in
CHILD Table

Suppose you wanted to insert Roll = 05 with other values of columns in SUBJECT Table,
then you will immediately see an error "Foreign key Constraint Violated" i.e. on running
an insertion command as:

Insert into SUBJECT values(5, 786, OS); will not be entertained by SQL due to
Insertion Constraint ( As you cannot insert value in a child table if the value is not lying
in the master table, since Roll = 5 is not present in the master table, hence it will not be
allowed to enter Roll = 5 in child table )

Similarly, if you want to delete Roll = 4 from STUDENT Table, then you will immediately
see an error "Foreign key Constraint Violated" i.e. on running a deletion command as:

Delete from STUDENT where Roll = 4; will not be entertained by SQL due to Deletion
Constraint. ( As you cannot delete the value from the master table if the value is lying in
the child table, since Roll = 5 is present in the child table, hence it will not be allowed to
delete Roll = 5 from the master table, lets if somehow we managed to delete Roll = 5, then
Roll = 5 will be available in child table which will ultimately violate insertion constraint. )

ON DELETE CASCADE.

As per deletion constraint: Value cannot be deleted from the MASTER Table if the value is
lying in CHILD Table. The next question comes can we delete the value from the master
table if the value is lying in the child table without violating the deletion constraint? i.e. The
moment we delete the value from the master table the value corresponding to it should also
get deleted from the child table.

The answer to the above question is YES, we can delete the value from the master table if
the value is lying in the child table without violating the deletion constraint, we have to do
slight modification while creating the child table, i.e. by adding on delete cascade.

TABLE SYNTAX

1. CREATE TABLE Subject (Roll int references Student on delete cascade, SubCode
int, SubName varchar(10) );

In the above syntax, just after references keyword( used for creating foreign key), we have
added on delete cascade, by adding such now, we can delete the value from the master table
if the value is lying in the child table without violating deletion constraint. Now if you
wanted to delete Roll = 5 from the master table even though Roll = 5 is lying in the child
table, it is possible because the moment you give the command to delete Roll = 5 from the
master table, the row having Roll = 5 from child table will also get deleted.

The above two tables STUDENT and SUBJECT having four values each are shown, now
suppose you are looking to delete Roll = 4 from STUDENT( Master ) Table by writing a
SQL command: delete from STUDENT where Roll = 4;

The moment SQL execute the above command the row having Roll = 4 from SUBJECT(
Child ) Table will also get deleted, The resultant STUDENT and SUBJECT table will look
like:
From the above two tables STUDENT and SUBJECT, you can see that in both the table
Roll = 4 gets deleted at one go without violating deletion constraint.

Sometimes a very important question is asked in interviews that: Can Foreign Key have
NULL values?

The answer to the above question is YES, it may have NULL values, whereas the Primary
key cannot be NULL at any cost. To understand the above question practically let's
understand below the concept of delete null.

ON DELETE NULL.

As per deletion constraint: Value cannot be deleted from the MASTER Table if the value is
lying in CHILD Table. The next question comes can we delete the value from the master
table if the value is lying in the child table without violating the deletion constraint? i.e. The
moment we delete the value from the master table the value corresponding to it should also
get deleted from the child table or can be replaced with the NULL value.

The answer to the above question is YES, we can delete the value from the master table if
the value is lying in child table without violating deletion constraint by inserting NULL in
the foreign key, we have to do slight modification while creating child table, i.e. by
adding on delete null.

TABLE SYNTAX:

1. CREATE TABLE Subject (Roll int references Student on delete null, SubCode int
, SubName varchar(10) );

In the above syntax, just after references keyword( used for creating foreign key), we have
added on delete null, by adding such now, we can delete the value from the master table if
the value is lying in the child table without violating deletion constraint. Now if you wanted
to delete Roll = 4 from the master table even though Roll =4 is lying in the child table, it is
possible because the moment you give the command to delete Roll = 4 from the master
table, the row having Roll = 4 from child table will get replaced by a NULL value.
The above two tables STUDENT and SUBJECT having four values each are shown, now
suppose you are looking to delete Roll = 4 from STUDENT( Master ) Table by writing a
SQL command: delete from STUDENT where Roll = 4;

The moment SQL execute the above command the row having Roll = 4 from SUBJECT(
Child ) Table will get replaced by a NULL value, The resultant STUDENT and
SUBJECT table will look like:

From the above two tables STUDENT and SUBJECT, you can see that in table STUDENT
Roll = 4 get deleted while the value of Roll = 4 in the SUBJECT table is replaced by NULL.
This proves that the Foreign key can have null values. If in the case in SUBJECT Table,
column Roll is Primary Key along with Foreign Key then in that case we could not make a
foreign key to have NULL values.

13. Dynamic SQL is a programming technique that could be used to write SQL queries
during runtime. Dynamic SQL could be used to create general and flexible SQL queries.
Syntax for dynamic SQL is to make it string as below :
'SELECT statement';
To run a dynamic SQL statement, run the stored procedure sp_executesql as shown
below :
EXEC sp_executesql N'SELECT statement';
Use prefix N with the sp_executesql to use dynamic SQL as a Unicode string.

Steps to use Dynamic SQL :

1. Declare two variables, @var1 for holding the name of the table and @var 2
for holding the dynamic SQL :
2. DECLARE
3. @var1 NVARCHAR(MAX),
@var2 NVARCHAR(MAX);
 4. Set the value of the @var1 variable to table_name :
SET @var1 = N'table_name';
5. Create the dynamic SQL by adding the SELECT statement to the table name
parameter :
6. SET @var2= N'SELECT *
FROM ' + @var1;
7. Run the sp_executesql stored procedure by using the @var2 parameter :
EXEC sp_executesql @var2;

Example –
SELECT *
from geek;
Table – Geek
ID NAME CITY

1 Khushi Jaipur

2 Neha Noida

3 Meera Delhi

Using Dynamic SQL :

DECLARE
@tab NVARCHAR(128),
@st NVARCHAR(MAX);
SET @tab = N'geektable';
SET @st = N'SELECT *
FROM ' + @tab;
EXEC sp_executesql @st;
Table – Geek
ID NAME CITY

1 Khushi Jaipur

2 Neha Noida
 ID NAME CITY

3 Meera Delhi

Static or Embedded SQL are SQL statements in an application that do not change at
runtime and, therefore, can be hard-coded into the application. Dynamic SQL is SQL
statements that are constructed at runtime; for example, the application may allow users
to enter their own queries. Dynamic SQL is a programming technique that enables you to
build SQL statements dynamically at runtime. You can create more general purpose,
flexible applications by using dynamic SQL because the full text of a SQL statement may
be unknown at compilation. Static SQL are faster and more efficient while dynamic SQL
is less efficient since access plans for dynamic statements are generated at run-time so
they must be prepared in the application, and this is something you will never look at in
the static SQL, but these are not the only differences between them, so we can say that
dynamic SQL has only one advantage over static statements which can be clearly noticed
once the application is edited or upgraded, so with Dynamic statements there’s no need
for pre-compilation or re-building as long as the access plans are generated at run-time,
whereas static statements require regeneration of access plans if they were modified, in
addition to the fact that Dynamic SQL requires more permissions, it also might be a way
to execute unauthorized code, we don’t know what kind of users we’ll have, so for security
it can be dangerous if the programmer didn’t handle it. Below mentioned are the basic
differences between Static or Embedded and Dynamic or Interactive SQL:Limitation
of Dynamic SQL: We cannot use some of the SQL statements Dynamically. Performance
of these statements is poor as compared to Static SQL. Limitations of Static SQL: They
do not change at runtime thus are hard-coded into applications.

15. 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.
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.

16. Tuple Relational Calculus (TRC) is a non-procedural query language used in

relational database management systems (RDBMS) to retrieve data from tables. TRC is
based on the concept of tuples, which are ordered sets of attribute values that represent a
single row or record in a database table.
TRC is a declarative language, meaning that it specifies what data is required from the
database, rather than how to retrieve it. TRC queries are expressed as logical formulas
that describe the desired tuples.
The basic syntax of TRC is as follows:
{ t | P(t) }
where t is a tuple variable and P(t) is a logical formula that describes the conditions that
the tuples in the result must satisfy. The curly braces {} are used to indicate that the
expression is a set of tuples.
For example, let’s say we have a table called “Employees” with the following attributes:
EmployeeID
Name
Salary
DepartmentID
To retrieve the names of all employees who earn more than $50,000 per year, we can use
the following TRC query:
{ t | Employees(t) ∧ t.Salary > 50000 }
In this query, the “Employees(t)” expression specifies that the tuple variable t represents
a row in the “Employees” table. The “∧” symbol is the logical AND operator, which is
used to combine the condition “t.Salary > 50000” with the table selection.
The result of this query will be a set of tuples, where each tuple contains the Name
attribute of an employee who earns more than $50,000 per year.
TRC can also be used to perform more complex queries, such as joins and nested
queries, by using additional logical operators and expressions.
While TRC is a powerful query language, it can be more difficult to write and
understand than other SQL-based query languages, such as Structured Query Language
(SQL). However, it is useful in certain applications, such as in the formal verification of
database schemas and in academic research.
Tuple Relational Calculus is a non-procedural query language unlike relational
algebra. Tuple Calculus provides only the description of the query but it does not
provide the methods to solve it. Thus, it explains what to do but not how to do.
In Tuple Calculus, a query is expressed as
{t| P(t)}
where t = resulting tuples,
P(t) = known as Predicate and these are the conditions that are used to fetch t
Thus, it generates set of all tuples t, such that Predicate P(t) is true for t.
P(t) may have various conditions logically combined with OR (∨), AND (∧), NOT(¬).
It also uses quantifiers:
∃ t ∈ r (Q(t)) = ”there exists” a tuple in t in relation r such that predicate Q(t) is true.
∀ t ∈ r (Q(t)) = Q(t) is true “for all” tuples in relation r.
Example:
Table-1: Customer
Customer
name Street City

Saurabh A7 Patiala

Mehak B6 Jalandhar

Sumiti D9 Ludhiana

Ria A5 Patiala
Table-2: Branch
Branch name Branch city

ABC Patiala

DEF Ludhiana

GHI Jalandhar

Table-3: Account
Account number Branch name Balance

1111 ABC 50000

1112 DEF 10000

1113 GHI 9000

1114 ABC 7000

Table-4: Loan
Loan number Branch name Amount

L33 ABC 10000

L35 DEF 15000

L49 GHI 9000

L98 DEF 65000

Table-5: Borrower
Customer name Loan number

Saurabh L33

Mehak L49
Customer name Loan number

Ria L98

Table-6: Depositor
Customer name Account number

Saurabh 1111

Mehak 1113

Sumiti 1114

Queries-1: Find the loan number, branch, amount of loans of greater than or equal to
10000 amount.
{t| t ∈ loan ∧ t[amount]>=10000}

18. States of Transaction

In a database, the transaction can be in one of the following states -

Active state

o The active state is the first state of every transaction. In this state, the transaction is
being executed.
o For example: Insertion or deletion or updating a record is done here. But all the
records are still not saved to the database.
Partially committed

o In the partially committed state, a transaction executes its final operation, but the
data is still not saved to the database.
o In the total mark calculation example, a final display of the total marks step is
executed in this state.

Committed

A transaction is said to be in a committed state if it executes all its operations successfully.

In this state, all the effects are now permanently saved on the database system.

Failed state

o If any of the checks made by the database recovery system fails, then the transaction
is said to be in the failed state.
o In the example of total mark calculation, if the database is not able to fire a query to
fetch the marks, then the transaction will fail to execute.

Aborted

o If any of the checks fail and the transaction has reached a failed state then the
database recovery system will make sure that the database is in its previous
consistent state. If not then it will abort or roll back the transaction to bring the
database into a consistent state.
o If the transaction fails in the middle of the transaction then before executing the
transaction, all the executed transactions are rolled back to its consistent state.
o After aborting the transaction, the database recovery module will select one of the
two operations:
1. Re-start the transaction
2. Kill the transaction
o A transaction is a single logical unit of work that accesses and possibly modifies
the contents of a database. Transactions access data using read and write
operations.
In order to maintain consistency in a database, before and after the transaction,
certain properties are followed. These are called ACID properties.
o
o Atomicity:
o By this, we mean that either the entire transaction takes place at once or doesn’t
happen at all. There is no midway i.e. transactions do not occur partially. Each
transaction is considered as one unit and either runs to completion or is not
executed at all. It involves the following two operations.
—Abort: If a transaction aborts, changes made to the database are not visible.
—Commit: If a transaction commits, changes made are visible.
Atomicity is also known as the ‘All or nothing rule’.
o
o Consider the following transaction T consisting of T1 and T2: Transfer of 100
from account X to account Y.

o
o If the transaction fails after completion of T1 but before completion of T2.( say,
after write(X) but before write(Y)), then the amount has been deducted
from X but not added to Y. This results in an inconsistent database state.
Therefore, the transaction must be executed in its entirety in order to ensure the
correctness of the database state.
o Consistency:
o This means that integrity constraints must be maintained so that the database is
consistent before and after the transaction. It refers to the correctness of a
database. Referring to the example above,
The total amount before and after the transaction must be maintained.
Total before T occurs = 500 + 200 = 700.
Total after T occurs = 400 + 300 = 700.
Therefore, the database is consistent. Inconsistency occurs in case T1 completes
but T2 fails. As a result, T is incomplete.
19. Timestamp Ordering Protocol

o The Timestamp Ordering Protocol is used to order the transactions based on their
Timestamps. The order of transaction is nothing but the ascending order of the
transaction creation.
o The priority of the older transaction is higher that's why it executes first. To
determine the timestamp of the transaction, this protocol uses system time or logical
counter.
o The lock-based protocol is used to manage the order between conflicting pairs
among transactions at the execution time. But Timestamp based protocols start
working as soon as a transaction is created.
o Let's assume there are two transactions T1 and T2. Suppose the transaction T1 has
entered the system at 007 times and transaction T2 has entered the system at 009
times. T1 has the higher priority, so it executes first as it is entered the system first.
o The timestamp ordering protocol also maintains the timestamp of last 'read' and
'write' operation on a data.

Basic Timestamp ordering protocol works as follows:

1. Check the following condition whenever a transaction Ti issues a Read (X) operation:

o If W_TS(X) >TS(Ti) then the operation is rejected.

o If W_TS(X) <= TS(Ti) then the operation is executed.
o Timestamps of all the data items are updated.

2. Check the following condition whenever a transaction Ti issues a Write(X) operation:

o If TS(Ti) < R_TS(X) then the operation is rejected.

o If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled back otherwise
the operation is executed.

Where,

TS(TI) denotes the timestamp of the transaction Ti.

R_TS(X) denotes the Read time-stamp of data-item X.

W_TS(X) denotes the Write time-stamp of data-item X.

Advantages and Disadvantages of TO protocol:

o TO protocol ensures serializability since the precedence graph is as follows:

o TS protocol ensures freedom from deadlock that means no transaction ever waits.
o But the schedule may not be recoverable and may not even be cascade- fre

20. Locks are an integral part to maintain concurrency control in DBMS. A transaction in
any system implementing lock based concurrency control cannot read or write a statement
until it has obtained the required locks.
There are two types of locks in Lock based protocols. These are:

 Binary Locks - These can only be in one of two states, locked or unlocked.
 Shared/Exclusive Locks - Shared locks are acquired when only read operation is
to be performed. Shared locks can be shared between multiple transactions as there
is no data being altered. Exclusive locks are used when write operation is
performed. Only the transaction holding the exclusive lock is allowed to make
changes to the data value.
The different locking protocols are −

Simplistic Lock Protocol

A lock is obtained by the transaction on the data value before the write operation is
performed. After the write operation, the lock can be released. An example of Simplistic
Lock Protocol is:
T1 T2
R(A)
R(A)
Lock(B)
R(B)
W(B)
Unlock(B)
Lock(C)
R(C)
 T1 T2
W(C)
Unlock(C)
Commit
Commit
There are two transactions T1 and T2 shown above. There are no locks required for the read
operation but before the write operation, each of these transactions acquires a lock and
releases it after.

Two-Phase Locking Protocol

The two-phase locking protocol has two phases, namely the growing and shrinking phase.
The transaction can only acquire locks when it is in the growing phase. When it enters the
shrinking phase, it can release the previously acquired locks but cannot acquire new locks.
The exclusive locks are represented by X and the shared locks are represented by S. An
example of Two phase locking protocol is −

T1 T2

S(A)

R(A)

S(A)

R(A)

X(B)

R(B)

W(B)

X(C)

R(C)

W(C)

Unlock(C)

Unlock(A)

Unlock(B)

Unlock(A)

Commit
 T1 T2

Commit
In the above example, T1 and T2 share the variable A using a shared lock as only read
operation is performed on A. T1 acquires an exclusive lock on B for the write operation
and releases it soon after. T2 does the same with C.

Strict Two-Phase Locking Protocol

Strict two phase locking protocol is similar to two phase locking protocol. The only
difference is that in strict 2PL protocol all the exclusive locks acquired by the protocol need
to be held until the protocol either commits or aborts. An example of Strict two - phase
locking protocol is:

T1 T2

S(A)

R(A)

S(A)

R(A)

X(B)

R(B)

W(B)

X(C)

R(C)

W(C)

Unlock(A)

Unlock(A)

Commit

Unlock(B)

Commit

Unlock(C)
In the above example, T1 and T2 share the variable A using a shared lock as only read
operation is performed on A. T1 acquires an exclusive lock on B for the write operation
and T2 does the same with C. The exclusive locks are released only after the transactions
have committed. However, there is no such bound for the shared locks.

Rigorous two-phase locking protocol

Rigorous two phase locking protocol is merely an extension of two phase locking protocol
and strict two phase locking protocol. Here, all the locks held by a transaction, whether
shared or exclusive, are only released once the transaction commits or aborts. An example
of Rigorous two - phase locking protocol is:

T1 T2

S(A)

R(A)

S(A)

R(A)

X(B)

R(B)

W(B)

X(C)

R(C)

W(C)

Commit

Unlock(A)

Unlock(B)

Commit

Unlock(A)

Unlock(C)
In the above example, T1 and T2 share the variable A using a shared lock as only read
operation is performed on A. T1 acquires an exclusive lock on B for the write operation
and T2 does the same with C. Both the shared locks and the exclusive locks are only
released after the transactions have committed.
21. Shadow paging is one of the techniques that is used to recover from failure. We all
know that recovery means to get back the information, which is lost. It helps to maintain
database consistency in case of failure.

Concept of shadow paging

Now let see the concept of shadow paging step by step −

 Step 1 − Page is a segment of memory. Page table is an index of pages. Each table
entry points to a page on the disk.
 Step 2 − Two page tables are used during the life of a transaction: the current page
table and the shadow page table. Shadow page table is a copy of the current page
table.
 Step 3 − When a transaction starts, both the tables look identical, the current table is
updated for each write operation.
 Step 4 − The shadow page is never changed during the life of the transaction.
 Step 5 − When the current transaction is committed, the shadow page entry becomes
a copy of the current page table entry and the disk block with the old data is released.
 Step 6 − The shadow page table is stored in non-volatile memory. If the system crash
occurs, then the shadow page table is copied to the current page table.
The shadow paging is represented diagrammatically as follows −

Advantages

The advantages of shadow paging are as follows −

 No need for log records.

 No undo/ Redo algorithm.
 Recovery is faster.

Disadvantages

The disadvantages of shadow paging are as follows −

 Data is fragmented or scattered.
 Garbage collection problem. Database pages containing old versions of modified
data need to be garbage collected after every transaction.
 Concurrent transactions are difficult to execute.

22. Hashing in DBMS

In a huge database structure, it is very inefficient to search all the index values and reach the
desired data. Hashing technique is used to calculate the direct location of a data record on
the disk without using index structure.

In this technique, data is stored at the data blocks whose address is generated by using the
hashing function. The memory location where these records are stored is known as data
bucket or data blocks.
In this, a hash function can choose any of the column value to generate the address. Most of
the time, the hash function uses the primary key to generate the address of the data block. A
hash function is a simple mathematical function to any complex mathematical function. We
can even consider the primary key itself as the address of the data block. That means each
row whose address will be the same as a primary key stored in the data block.

The above diagram shows data block addresses same as primary key value. This hash
function can also be a simple mathematical function like exponential, mod, cos, sin, etc.
Suppose we have mod (5) hash function to determine the address of the data block. In this
case, it applies mod (5) hash function on the primary keys and generates 3, 3, 1, 4 and 2
respectively, and records are stored in those data block addresses.

Types of Hashing:
 o Static Hashing
o Dynamic Hashing

Indexing in DBMS

o Indexing is used to optimize the performance of a database by minimizing the

number of disk accesses required when a query is processed.
o The index is a type of data structure. It is used to locate and access the data in a
database table quickly.

Index structure:

Indexes can be created using some database columns.

o The first column of the database is the search key that contains a copy of the primary
key or candidate key of the table. The values of the primary key are stored in sorted
order so that the corresponding data can be accessed easily.
o The second column of the database is the data reference. It contains a set of pointers
holding the address of the disk block where the value of the particular key can be
found.

Indexing Methods
Ordered indices

The indices are usually sorted to make searching faster. The indices which are sorted are
known as ordered indices.

Example: Suppose we have an employee table with thousands of record and each of which
is 10 bytes long. If their IDs start with 1, 2, 3....and so on and we have to search student with
ID-543.

o In the case of a database with no index, we have to search the disk block from starting
till it reaches 543. The DBMS will read the record after reading 543*10=5430 bytes.
o In the case of an index, we will search using indexes and the DBMS will read the
record after reading 542*2= 1084 bytes which are very less compared to the previous
case.

Primary Index

o If the index is created on the basis of the primary key of the table, then it is known
as primary indexing. These primary keys are unique to each record and contain 1:1
relation between the records.
o As primary keys are stored in sorted order, the performance of the searching
operation is quite efficient.
o The primary index can be classified into two types: Dense index and Sparse index.

Dense index

o The dense index contains an index record for every search key value in the data file.
It makes searching faster.
o In this, the number of records in the index table is same as the number of records in
the main table.
o It needs more space to store index record itself. The index records have the search
key and a pointer to the actual record on the disk.
Sparse index

o In the data file, index record appears only for a few items. Each item points to a
block.
o In this, instead of pointing to each record in the main table, the index points to the
records in the main table in a gap.

Clustering Index

o A clustered index can be defined as an ordered data file. Sometimes the index is
created on non-primary key columns which may not be unique for each record.
o In this case, to identify the record faster, we will group two or more columns to get
the unique value and create index out of them. This method is called a clustering
index.
o The records which have similar characteristics are grouped, and indexes are created
for these group.

Example: suppose a company contains several employees in each department. Suppose we

use a clustering index, where all employees which belong to the same Dept_ID are
considered within a single cluster, and index pointers point to the cluster as a whole. Here
Dept_Id is a non-unique key.

23. Advantages

RAID 5 is one of the most common RAID configurations and is ideal for application and
file servers with a limited number of drives. Considered a good all-around RAID system,
RAID 5 combines the better elements of efficiency and performance among the different
RAID configurations.

Fast, reliable read speed is a major benefit. This RAID configuration also offers
inexpensive data redundancy and fault tolerance. Writes tend to be slower, because of the
parity data calculation, but data can be accessed and read even while a failed drive is being
rebuilt. When drives fail, the RAID 5 system can read the information contained on the
other drives and recreate that data, tolerating a single drive failure.

Disadvantages

Longer rebuild times are one of the major drawbacks of RAID 5, and this delay could
result in data loss. Because of its complexity, RAID 5 rebuilds can take a day or longer,
depending on controller speed and workload. If another disk fails during the rebuild, then
data is lost forever.

24. B tree is a self-balancing tree, and it is a m-way tree where m defines the order of the
tree. Btree is a generalization of the Binary Search tree in which a node can have more than
one key and more than two children depending upon the value of m. In the B tree, the data
is specified in a sorted order having lower values on the left subtree and higher values in the
right subtree.

Properties of B tree

The following are the properties of the B tree:

o In the B tree, all the leaf nodes must be at the same level, whereas, in the case of a
binary tree, the leaf nodes can be at different levels.

Let's understand this property through an example.

In the above tree, all the leaf nodes are not at the same level, but they have the utmost two
children. Therefore, we can say that the above tree is a binary tree but not a B tree.

o If the Btree has an order of m, then each node can have a maximum of m In the case
of minimum children, the leaf nodes have zero children, the root node has two
children, and the internal nodes have a ceiling of m/2.
 o Each node can have maximum (m-1) keys. For example, if the value of m is 5 then
the maximum value of keys is 4.
o The root node has minimum one key, whereas all the other nodes except the root
node have (ceiling of m/2 minus - 1) minimum keys.
o If we perform insertion in the B tree, then the node is always inserted in the leaf
node.

Suppose we want to create a B tree of order 3 by inserting values from 1 to 10.

Step 1: First, we create a node with 1 value as shown below:

Step 2: The next element is 2, which comes after 1 as shown below:

Step 3: The next element is 3, and it is inserted after 2 as shown below:

As we know that each node can have 2 maximum keys, so we will split this node through
the middle element. The middle element is 2, so it moves to its parent. The node 2 does not
have any parent, so it will become the root node as shown below:

Step 4: The next element is 4. Since 4 is greater than 2 and 3, so it will be added after the 3
as shown below:
Step 5: The next element is 5. Since 5 is greater than 2, 3 and 4 so it will be added after 4
as shown below:

As we know that each node can have 2 maximum keys, so we will split this node through
the middle element. The middle element is 4, so it moves to its parent. The parent is node
2; therefore, 4 will be added after 2 as shown below:

Step 6: The next element is 6. Since 6 is greater than 2, 4 and 5, so 6 will come after 5 as
shown below:

Step 7: The next element is 7. Since 7 is greater than 2, 4, 5 and 6, so 7 will come after 6 as
shown below:
As we know that each node can have 2 maximum keys, so we will split this node through
the middle element. The middle element is 6, so it moves to its parent as shown below:

But, 6 cannot be added after 4 because the node can have 2 maximum keys, so we will split
this node through the middle element. The middle element is 4, so it moves to its parent. As
node 4 does not have any parent, node 4 will become a root node as shown below:

What is a B+ tree?

The B+ tree is also known as an advanced self-balanced tree because every path from the
root of the tree to the leaf of the tree has the same length. Here, the same length means that
all the leaf nodes occur at the same level. It will not happen that some of the leaf nodes occur
at the third level and some of them at the second level.

A B+ tree index is considered a multi-level index, but the B+ tree structure is not similar to
the multi-level index sequential files.
Why is the B+ tree used?

A B+ tree is used to store the records very efficiently by storing the records in an indexed
manner using the B+ tree indexed structure. Due to the multi-level indexing, the data
accessing becomes faster and easier.

B+ tree Node Structure

The node structure of the B+ tree contains pointers and key values shown in the below
figure:

As we can observe in the above B+ tree node structure that it contains n-1 key values (k1 to
kn-1) and n pointers (p1 to pn).

The search key values which are placed in the node are kept in sorted order. Thus, if i<j then
ki<kj.

Constraint on various types of nodes

Let 'b' be the order of the B+ tree.

Non-Leaf node

Let 'm' represents the number of children of a node, then the relation between the order of
the tree and the number of children can be represented as:

Let k represents the search key values. The relation between the order of the tree and search
key can be represented as:

As we know that the number of pointers is equal to the search key values plus 1, so
mathematically, it can be written as:

Number of Pointers (or children) = Number of Search keys + 1

Therefore, the maximum number of pointers would be 'b', and the minimum number of
pointers would be the ceiling function of b/2.
Leaf Node

A leaf node is a node that occurs at the last level of the B+ tree, and each leaf node uses only
one pointer to connect with each other to provide the sequential access at the leaf level.

In leaf node, the maximum number of children is:

The maximum number of search keys is:

Root Node

The maximum number of children in the case of the root node is: b

The minimum number of children is: 2

Special cases in B+ tree

Case 1: If the root node is the only node in the tree. In this case, the root node becomes the
leaf node.

In this case, the maximum number of children is 1, i.e., the root node itself, whereas, the
minimum number of children is b-1, which is the same as that of a leaf node.

Representation of a leaf node in B+ tree

In the above figure, '.' represents the pointer, whereas the 10, 20 and 30 are the key values.
The pointer contains the address at which the key value is stored, as shown in the above
figure.

Example of B+ tree

25. Differences between Structured, Semi-structured and Unstructured data:

Unstructured
Properties Structured data Semi-structured data data

It is based on It is based on It is based on

Relational database XML/RDF(Resource character and
Technology table Description Framework). binary data

Matured transaction
and various No transaction
Transaction concurrency Transaction is adapted management and
management techniques from DBMS not matured no concurrency

Version Versioning over Versioning over tuples or Versioned as a

management tuples,row,tables graph is possible whole

It is more flexible than It is more

It is schema structured data but less flexible and there
dependent and less flexible than unstructured is absence of
Flexibility flexible data schema

It is very difficult to It’s scaling is simpler It is more

Scalability scale DB schema than structured data scalable.

New technology, not very

Robustness Very robust spread —
 Unstructured
Properties Structured data Semi-structured data data

Structured query Only textual

Query allow complex Queries over anonymous queries are
performance joining nodes are possible possible

XML Tree Structure

An XML document has a self descriptive structure. It forms a tree structure which is referred
as an XML tree. The tree structure makes easy to describe an XML document.

A tree structure contains root element (as parent), child element and so on. It is very easy to
traverse all succeeding branches and sub-branches and leaf nodes starting from the root.

Example of an XML document

1. <?xml version="1.0"?>
2. <college>
3. <student>
4. <firstname>Tamanna</firstname>
5. <lastname>Bhatia</lastname>
6. <contact>09990449935</contact>
7. <email>[email protected]</email>
8. <address>
9. <city>Ghaziabad</city>
10. <state>Uttar Pradesh</state>
11. <pin>201007</pin>
12. </address>
13. </student>
14. </college>

Let's see the tree-structure representation of the above example.

In the above example, first line is the XML declaration. It defines the XML version 1.0.
Next line shows the root element (college) of the document. Inside that there is one more
element (student). Student element contains five branches named <firstname>, <lastname>,
<contact>, <Email> and <address>.

<address> branch contains 3 sub-branches named <city>, <state> and <pin>.

XML Tree Rules

These rules are used to figure out the relationship of the elements. It shows if an element is
a child or a parent of the other element.

Descendants: If element A is contained by element B, then A is known as descendant of B.

In the above example "College" is the root element and all the other elements are the
descendants of "College".

Ancestors: The containing element which contains other elements is called "Ancestor" of
other element. In the above example Root element (College) is ancestor of all other
elements.

26. What is DTD

DTD stands for Document Type Definition. It defines the legal building blocks of an XML
document. It is used to define document structure with a list of legal elements and attributes.

Purpose of DTD

Its main purpose is to define the structure of an XML document. It contains a list of legal
elements and define the structure with the help of them.

Checking Validation

Before proceeding with XML DTD, you must check the validation. An XML document is
called "well-formed" if it contains the correct syntax.
 A well-formed and valid XML document is one which have been validated against DTD.

Valid and well-formed XML document with DTD

Let's take an example of well-formed and valid XML document. It follows all the rules of
DTD.

employee.xml

1. <?xml version="1.0"?>
2. <!DOCTYPE employee SYSTEM "employee.dtd">
3. <employee>
4. <firstname>vimal</firstname>
5. <lastname>jaiswal</lastname>
6. <email>[email protected]</email>
7. </employee>

In the above example, the DOCTYPE declaration refers to an external DTD file. The content
of the file is shown in below paragraph.

employee.dtd

1. <!ELEMENT employee (firstname,lastname,email)>

2. <!ELEMENT firstname (#PCDATA)>
3. <!ELEMENT lastname (#PCDATA)>
4. <!ELEMENT email (#PCDATA)>

Description of DTD

<!DOCTYPE employee : It defines that the root element of the document is employee.

<!ELEMENT employee: It defines that the employee element contains 3 elements

"firstname, lastname and email".

<!ELEMENT firstname: It defines that the firstname element is #PCDATA typed. (parse-
able data type).

<!ELEMENT lastname: It defines that the lastname element is #PCDATA typed. (parse-
able data type).

<!ELEMENT email: It defines that the email element is #PCDATA typed. (parse-able data
type).
 XML DTD with entity declaration

A doctype declaration can also define special strings that can be used in the XML file.

An entity has three parts:

1. An ampersand (&)
2. An entity name
3. A semicolon (;)

Syntax to declare entity:

1. <!ENTITY entity-name "entity-value">

An XML Schema describes the structure of an XML document.

The XML Schema language is also referred to as XML Schema Definition (XSD).

XSD Example
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

</xs:schema>

The purpose of an XML Schema is to define the legal building blocks of an XML
document:

 the elements and attributes that can appear in a document

 the number of (and order of) child elements
 data types for elements and attributes
 default and fixed values for elements and attributes
Why Learn XML Schema?

In the XML world, hundreds of standardized XML formats are in daily use.

Many of these XML standards are defined by XML Schemas.

XML Schema is an XML-based (and more powerful) alternative to DTD.

XML Schemas Support Data Types

One of the greatest strength of XML Schemas is the support for data types.

 It is easier to describe allowable document content

 It is easier to validate the correctness of data
 It is easier to define data facets (restrictions on data)
 It is easier to define data patterns (data formats)
 It is easier to convert data between different data types

XML Schemas use XML Syntax

Another great strength about XML Schemas is that they are written in XML.

 You don't have to learn a new language

 You can use your XML editor to edit your Schema files
 You can use your XML parser to parse your Schema files
 You can manipulate your Schema with the XML DOM
 You can transform your Schema with XSLT

XML Schemas are extensible, because they are written in XML.

With an extensible Schema definition you can:

 Reuse your Schema in other Schemas

 Create your own data types derived from the standard types
 Reference multiple schemas in the same document

27. Homogeneous Distributed Databases

In a homogeneous distributed database, all the sites use identical DBMS and operating
systems. Its properties are −
 The sites use very similar software.
 The sites use identical DBMS or DBMS from the same vendor.
 Each site is aware of all other sites and cooperates with other sites to process user
requests.
 The database is accessed through a single interface as if it is a single database.
Types of Homogeneous Distributed Database
There are two types of homogeneous distributed database −
  Autonomous − Each database is independent that functions on its own. They are
integrated by a controlling application and use message passing to share data updates.
 Non-autonomous − Data is distributed across the homogeneous nodes and a central
or master DBMS co-ordinates data updates across the sites.
Heterogeneous Distributed Databases
In a heterogeneous distributed database, different sites have different operating systems,
DBMS products and data models. Its properties are −
 Different sites use dissimilar schemas and software.
 The system may be composed of a variety of DBMSs like relational, network,
hierarchical or object oriented.
 Query processing is complex due to dissimilar schemas.
 Transaction processing is complex due to dissimilar software.
 A site may not be aware of other sites and so there is limited co-operation in
processing user requests.
Types of Heterogeneous Distributed Databases
 Federated − The heterogeneous database systems are independent in nature and
integrated together so that they function as a single database system.
 Un-federated − The database systems employ a central coordinating module
through which the databases are accessed.

28. XML Database is used to store huge amount of information in the XML format. As the
use of XML is increasing in every field, it is required to have a secured place to store the
XML documents. The data stored in the database can be queried using XQuery, serialized,
and exported into a desired format.

XML Database Types

There are two major types of XML databases −

 XML- enabled
 Native XML (NXD)

XML - Enabled Database

XML enabled database is nothing but the extension provided for the conversion of XML
document. This is a relational database, where data is stored in tables consisting of rows and
columns. The tables contain set of records, which in turn consist of fields.
Native XML Database
Native XML database is based on the container rather than table format. It can store large
amount of XML document and data. Native XML database is queried by the XPath-
expressions.
Native XML database has an advantage over the XML-enabled database. It is highly capable
to store, query and maintain the XML document than XML-enabled database.
Example
Following example demonstrates XML database −
<?xml version = "1.0"?>
<contact-info>
<contact1>
<name>Tanmay Patil</name>
<company>TutorialsPoint</company>
<phone>(011) 123-4567</phone>
</contact1>

<contact2>
<name>Manisha Patil</name>
<company>TutorialsPoint</company>
<phone>(011) 789-4567</phone>
</contact2>
</contact-info>
Here, a table of contacts is created that holds the records of contacts (contact1 and contact2),
which in turn consists of three entities − name, company and phone.