PART-A

Question 1: Can we achieve 2NF without 1NF. Also differentiate 1NF and 2NF with
an example.

No we cannot achieve 2NF without 1NF.

A relation R is in 2NF if
(a) R is 1NF , The normalization of 1NF relations to 2NF involves the removal of
partial dependencies. If a partial dependency exists, we remove the function
dependent attributes from the relation by placing them in a new relation along with a
copy of their determinant.
(b) All non-prime attributes are fully dependent on the candidate keys, which is
creating relationships between these new tables and their predecessors through the use
of foreign keys.
A prime attribute appears in a candidate key.
There is no partial dependency in 2NF.

First normal form (1NF) sets the very basic rules for an organized database:

* Eliminate duplicative columns from the same table.

* Create separate tables for each group of related data and identify each row with a
unique column or set of columns (the primary key).

The following table is not in 1NF

DPT_NO MG_NO EMP_NO EMP_NM

D101 12345 20000 Carl Sagan

Mag James
20001 Larry Bird

20002
D102 13456 30000 Jim Carter
30001
Paul Simon

Now, the table is in INF

DEP_NO MG_NO EMP_NO EMP_NAME

D101 12345 20000 CARL SAGAN
D101 12345 20001 MAG JAMES
D101 12345 20002 LARRY BIRD
D102 13456 30000 JIM CARTER
D102 13456 30001 PAUL SIMON

Second normal form (2NF) further addresses the concept of removing duplicative
data:

* Meet all the requirements of the first normal form.

 * Remove subsets of data that apply to multiple rows of a table and place them in
separate tables.
* Create relationships between these new tables and their predecessors through the
use of foreign keys.

Example:
Inventory

Description Supplier Cost Supplier Address

Inventory

Description Supplier Cost

Supplier

Name Supplier Address

The above relation is now in 2NF since the relation has no non-key attributes.

Question 2: How is the concept of functional dependency associated with the process
of normalization?

Normalization is a formal technique for analyzing relations based on their primary

key (orcandidate keys in the case of BCNF) and functional dependencies.
Normalization is often performed as a series of tests on a relation to determine
whether it satisfies or violates the requirements of a given normal form.

Three normal forms were initially proposed, which are called first (1NF), second
(2NF) and third (3NF) normal form. Subsequently, a stronger definitionof third
normal form was introduced and is referred to as Boyce-Codd normal form (BCNF).
All of these normal forms are based on the functional dependencies among the
attributes of a relation.

Question 3: A relation R (A, B, C, D, E, F) have the following set of dependency:

A->CD; B->C; F->DE ;F->A
Is the decomposition of R in R1 (A, B, C,), R2 (A, F, D) and R3 (E, F) dependency
reversing?:
Ans3-According to above functional dependency:

F->CD

Because
A->CDandF->A

And
alsoF->CDandF->DE

So
thatF->D

Therefore
the relation R2(A,F,D) is a correct decomposition.

And also F->E so we can make the relation R3(E,F).

Now
the remaining attributes A,B,C and B->C , so there is another relation R1(A,B,C)

.So the three decomposition of relation R in R1, R2 and R3 are correct according to
the rule of functional dependency
PART- B

Question 4: Draw the state diagram showing various states of a transaction. Also give
the working of this diagram.

A database transaction can be in one of the following four states:

Active State: It is divided into two phases.

Initial Phase: a database transaction is in this phase while its statements start to be
executed.

Partially Committed Phase: a database transaction enters this phase when its final
statement has been executed.
At this phase, the database transaction has finished its execution, but it is still possible for the
transaction to be aborted because the output from the execution may remain residing
temporarily in main memory - an event like hardware failure may erase the output.

Failed State: A database transaction enters the failed state when its normal execution
can no longer proceed due to hardware or program errors.

Aborted State: A database transaction, if determined by the DBMS to have failed,

enters the aborted state. An aborted transaction must have no effect on the database, and thus
any changes it made to the database have to be undone, or in technical terms, rolled back.
 The database will return to its consistent state when the aborted transaction has been rolled
back. The DBMS's recovery scheme is responsible to manage transaction aborts.

Committed State: A database transaction enters the committed state when enough
information has been written to disk after completing its execution with success.

In this state, so much information has been written to disk that the effects produced by the
transaction cannot be undone via aborting; even when a system failure occurs, the changes
made by the committed transaction can be re-created when the system restarts.

Question 5: Make a comparison between conflict and view serializability with an

example.
Ans- Conflict serializability
Instructions li and lj of transactions Ti and Tj respectively, conflict if and only if there
exists some item Q accessed by both li and lj, and at least one of these instructions
wrote Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q). They conflict.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
Intuitively, a conflict between li and lj forces a (logical) temporal order between them.
If li and lj are consecutive in a schedule and they do not conflict, their results would
remain the same even if they had been interchanged in the schedule.
If a schedule S can be transformed into a schedule S´ by a series of swaps of non-
conflicting instructions, we say that S and S´ are conflict equivalent. We say that a
schedule S is conflict serializable if it is conflict equivalent to a serial schedule
Example of a schedule that is not conflict serializable:
T3 T4
read(Q)
write(Q)
write(Q)

We are unable to swap instructions in the above schedule to obtain either the serial
schedule < T3, T4 >, or the serial schedule < T4, T3 >.

Schedule 3 below can be transformed into Schedule 1, a serial schedule where T2

follows T1, by series of swaps of non-conflicting instructions. Therefore Schedule 3 is
conflict serializable.

SCHEDULE1 TO WHICH THE SCHEDULE3 IS SERIALLY EQUIVALENT

SCHEDULE3

View serializability:
Let S and S´ be two schedules with the same set of transactions. S and S´ are view
equivalent if the following three conditions are met:
1. For each data item Q, if transaction Ti reads the initial value of Q in schedule
S, then transaction Ti must, in schedule S´, also read the initial value of Q.
2. For each data item Q if transaction Ti executes read(Q) in schedule S, and that
value was produced by transaction Tj (if any), then transaction Ti must in schedule S´
also read the value of Q that was produced by transaction Tj .
3. For each data item Q, the transaction (if any) that performs the final write(Q)
operation in schedule S must perform the final write(Q) operation in schedule S´.
A schedule S is view serializable it is view equivalent to a serial schedule. Every
conflict serializable schedule is also view serializable.

Schedule 9 — a schedule which is view-serializable but not conflict serializable.

Every view serializable schedule that is not conflict
serializable has blind writes.

Question 6: Are the ACID properties of a transaction essential to ensure the integrity
of data? Give an example of each property.

A transaction is a group of operations that have the following properties: atomic, consistent,
isolated, and durable (ACID). The support of transactions enables new types of applications
to be developed, while simplifying the development process and making the application more
robust.

In an atomic group of operations, either every operation in the group must succeed, or the
effects of all of them must be undone (also known as rolling back).

For example, a bank transfer must be an atomic set of two operations: a debit from one
account and a credit to another account. The debit and credit must be implemented as an
atomic group. If those two operations do not both succeed, then the transfer is either unfairly
in favor of the bank or the account holder.

The requirement of consistency means that the data is consistent after the transaction
(assuming that we started with a consistent system before the transaction).

For the bank transfer example, consistency may be defined as having the combined account
balance of the two accounts be a constant. To implement consistency in the bank transfer
example, the debit and credit operations simply need to be for the same amount of money.

Another example of a transaction is an update to a website. An electronic commerce site

requires that a new product category navigation page to appear at exactly the same time as the
product detail pages that describe the new products.

In this case, there is a need to update and add multiple directory entries under the control of a
transaction. Not only is it necessary to have the updates be atomic, but it is also necessary that
a customer who is currently shopping must not see the updates in progress. This is an
example of the isolation property of transactions.
The property of durability requires that after an update is finished, its effects persist even if
the system stops responding.

In the previous example, durability can be provided simply by ensuring adequate data
recovery so that all new file system entries that represent the addition of a new product to the
site appear after a system stops responding. This requires a system with data backup,
recovery, and high availability mechanisms.