0% found this document useful (0 votes)
80 views

Assignment No. 3: ND ST

This document appears to be a student assignment submission. It contains multiple parts that discuss database normalization concepts including first normal form, second normal form, functional dependencies, and decomposition. It provides examples and explanations of key normalization topics. It also includes solved problems applying normalization rules to determine if a given decomposition preserves dependencies.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
80 views

Assignment No. 3: ND ST

This document appears to be a student assignment submission. It contains multiple parts that discuss database normalization concepts including first normal form, second normal form, functional dependencies, and decomposition. It provides examples and explanations of key normalization topics. It also includes solved problems applying normalization rules to determine if a given decomposition preserves dependencies.
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 11

ASSIGNMENT NO.

SUBMITTED TO:-G.S PUSHKARNA


SU
BMITTED BY:-

SHIVA
NI SINGH RE2801 B55

Sol -:1
No we can’t achieve 2nd normal form without using the concept of
1st normal form.this can be shown in following example.

Second normal form applies only to tables with composite primary


keys, that is, tables with a primary key composed of two or more
columns. A 1NF table with a single column primary key is
automatically in at least 2NF.
A second normal form (2NF) is a table that is already in 1NF
and in which the values in each non-primary-key column can be
worked out from the values in all the columns that makes up the
primary key.
A table in 1NF can be converted into 2NF by removing the
columns that can be worked out from only part of the primary
key. These columns are placed in a new table along with a copy of
the part of the primary key that they can be worked out from.
Part 2
Ans:- First normal form (1NF). This is the "basic" level of
normalization and generally corresponds to the definition of
database name

* It contains two-dimensional tables with rows and columns.


* Each column corresponds to a sub-object or an attribute of
the object represented by the entire table.
* Each row represents a unique instance of that sub-object or
attribute and must be different in some way from any other row
(that is, no duplicate rows are possible).
* All entries in any column must be of the same kind. For
example, in the column labeled "Customer," only customer names
or numbers are permitted.

Second normal form (2NF). At this level of normalization, each


column in a table that is not a determiner of the contents of
another column must itself be a function of the other columns in
the table. For example, in a table with three columns containing
customer ID, product sold, and price of the product when sold, the
price would be a function of the customer ID (entitled to a
discount) and the specific product.

Sol2
If more than one attributes of a single relation have relationships
then this is termed as functional dependency because one
attributes depends on the other for providing complete detail. It is
associated with the normalization because normalization is a
technique that is used to remove these functional dependencies
in order to represent the information in simple way or in shape of
tables.
Functional Dependencies are fundamental to the process of
Normalization Functional Dependency describes the
relationship between attributes(columns) in a table.
For example, if A and B are attributes of a table, B is functionally
dependent on A, if each value of A is associated with exactly one
value of B (so, you can say, 'A functionally determines B').

Functional dependency between A and B

Attribute or group of attributes on the left hand side of the arrow


of a functional dependency is refered to as 'determinant'

Simple example would be StaffID functionally determines


Position in the above tables.

Functional Dependency can be classified as follows:

• Full Functional dependency Indicates that if A and B are


attributes(columns)of a table, B is fully functionally
dependent on A if B is functionally dependent on A ,but not
on any proper subset of A.
E.g. StaffID---->BranchID

• Partial Functional Dependency Indicates that if A and B


are attributes of a table , B is partially dependent on A if
there is some attribute that can be removed from A and yet
the dependency still holds.
Say for Ex, consider the following functional dependency
that exists in the Tbl_Staff table:
StaffID,Name -------> BranchID
BranchID is functionally dependent on a subset of A
(StaffID,Name), namely StaffID.
• Transitive Functional Dependency: A condition where A
, B and C are attributes of a table such that if A is
functionally dependent on B and B is functionally dependent
on C then C is Transitively dependent on A via B.
Say for Ex, consider the following functional dependencies
that exists in the Tbl_Staff_Branch table:
StaffID---->Name,Sex,Position,Sal,BranchID,Br_Address
BranchID----->Br_Address
So, StaffID attribute functionally determines Br_Address via
BranchID attribute.

Normalization:-Database Normalization is a step wise formal


process that allows us to decompose Database Tables in such a
way that both Data Redundancy and Update Anomalies(see above
for more info on update anomalies) are minimised.
It makes use of Functional Dependencies that exist in a table
(relation, more formally) and the primary key or Candidate Keys
in analysing the tables.
Three normal forms were initially proposed called First normal
Form (1NF), Second normal Form (2NF), and Third normal Form
(3NF).
Subsequently R.Boyce and E.F.Codd introduced a stronger
definition of 3NF called Boyce-Codd Normal Form(BCNF).
With the exception of 1NF, all these normal forms are based on
Functional dependencies among the attributes of a table. Higher
normal forms that go beyond BCNF were introduced later such as
Fourth Normal Form (4NF) and Fifth Normal Form (5NF). However
these later normal forms deal with situations that are very rare.

• First Normal Form (1NF) The only thing that is required


for a table to be in 1NF is to contain only atomic values
(intersection of each row and column should contain one and
only one value).this is sometimes referred to as : Eliminate
Repeating groups.

• Second Normal Form (2NF) A Table is said to be in 2NF if


it is in 1NF and there are no partial dependencies i.e. every
non primary key attribute of the Table is fully functionally
dependent on the primary key.
• Third Normal Form (3NF) A Table that is in 1NF and 2NF
and in which no non primary key attribute is transitively
dependent on primary key. Boyce-codd Normal Form
(BCNF) A Table is in BCNF if and only if every
determinant(it is an attribute or a group of attributes on
which some other attribute is fully functionally dependent,
see functional dependency described above) is a candidate
key. BCNF is a stronger form of 3NF.
The difference between 3NF and BCNF is that for a
Functional dependency A--->B, 3NF allows this dependency
in a table if attribute B is a primary key attribute and
attribute A is not a candidate key, where as BCNF insists
that for this dependency to remain in a table, attribute A
must be a candidate key.

Normalization Process
• Fourth Normal Form (4NF) 4NF is a stronger normal
form than BCNF as it prevents Tables from containing
nontrivial Multi-Valued Dependencies (MVDs) and hence data
redendancy.
The Normalization of BCNF Tables to 4NF involves the
removal of MVDs from the Table by placing the attribute(s)
in a new Table along with the copy of the determinant(s).

• Fifth Normal Form(5NF) 5NF is also called Project-Join


Normal Form(PJRF) and specifies that a 5NF Table has no
Join dependency.

Q3.A relation R(A,B,C,D,E,F) have the following set of functional


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?

Sol
- The relation R(A,B,C,D,E,F) have the set of dependency among
the their attributes as:
According to the given functional dependency:
F->CD
Because A->CD and F->A
And also F->CD and F->DE
So that F->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 form that is R1(A,B,C).
Partially of relation R in R1,
So all the three decomposition R2 and R3 are
commited
correct according to commited
the rule of functio0nal dependency.
active

transcation stays in this stateaborte


1) Active:-The initial ;thefailed while it is
executing. d
2) Partially commited:-After the final statement has been
executed.
3) Failed:-After the discovery that normal execution can no longer
proceed.
4) Aborted :-after the transcation has been rolled back and the
data base has been restored to its state of the transcation.
5) commited:-After successful completation.
For example:-
If a transcation added $20 to an account ,the compensating
transcation would subtract $20 from the account .however ,it is
not always possible to create such a compensating transcation
.therefore ,the responsibility of writing and executing a
compensating transcation is left to the user ,and is handled by the
database system.

A process is failed in only two case


1)it can restart the transcation ,but only transcation was aborted
as result of some hardware or software error that was not created
through the internal logic of the transcation .A restarted
transcation is considered to be a new transcation.
2)it can kill the transcation .it usually does so because of some
internal logical error that can be corrected only by rewriting the
application program ,or because the input was bad ,or because
the desired data were not found in the database.
Sol-:5
If a schedule s can be transformed into a schedule s’ by a series
of swap of non conflicting instruction. We say s and s’ are conflict
equivalence.
The concept of conflict equivalence lead to the concept of conflict
serializability .we say that a schedule s is conflict serializability if
it is conflict equivalent to a serial schedule.
For example
Transcation t1 transcation t2
Read (a)
A=a-50;
Write(a);
Read (b);
B:=b+50;
Write b
Read(a)
Temp=a*.1;
A:=a-temp;
Write (a);
Read (b);
B:=b+temp;
Write (b)
This transcation is conflict serializable with the transcation
Transcation t1 transcation t2
Read (a)
A=a-50;
Write(a);

Read(a)
Temp=a*.1;
A:=a-temp;
Write (a);
Read (b);
B:=b+50;
Write b
Read (b);
B:=b+temp;
Write (b)
Because we are able to find a serial transcation similar to the 1st
transcatin by swapping read(a) and write (b) because these are
the swapping of different data item which has no effect on
transcation and then swapping and then read b with read a
because in case of operation on similar data only read operation
has no effect on swapping .so by doing two swapping we show
that table 1 transcation and table 2 transcation are conflict
serializable.

NOW VIEW SERIALIZABILITY:-


The concept of view equivalence leads to the concept of view
serializable ,we say that a schedule s is view seriazable if its view
equivalent to serial schedule.
Basic steps in showing view serializability:-
1)for each data item Q ,if transcation Ti,reads the initial value of Q
in schedule S then transcation Ti ,in schedule S’ also read the
initial value of Q.

2)for each data item Q ,if transcation Ti executes read(q) in


schedule S ,and if the value was produced by a write(Q) operation
executed by transcation Tj,
Then the read (Q) operation of transcation Ti ,must in schedule
S’ ,also read the value of Q that was produced by the same write
(q) operation of transcation Tj.

3)for each data item Q ,the transcation (if any) that perform final
write(Q) operation in schedule S must perform the final write(Q)
operation in schedule S’.

Example

Transcation T3 transcation T4
Read(Q)
Write(Q)
Write (Q)

Transcation T3 transcation T4
transcation T6
Read(Q)
Write(Q)
Write (Q)
Write(Q)
The schedule is view serializable with above transcation .it is view
equivalent to the serial schedule<T3,T4,T6> since the one
read(Q) instruction reads the initial value of Q in both schedule
and T6 perform the final write of Q in both schedule.
Transcation T4 and T6 perform write(Q) operation without having
performed a read(Q) operation .write of this sort is called blind
writes .

Sol 6

ACID (atomicity, consistency, isolation, and durability) is an


acronym and mnemonic device for learning and remembering the
four primary attributes ensured to any transaction by a
transaction manager (which is also called a transaction monitor).
These attributes are:

Atomicity. In a transaction involving two or more discrete pieces


of information, either all of the pieces are committed or none are.

Consistency. A transaction either creates a new and valid state of


data, or, if any failure occurs, returns all data to its state before
the transaction was started.

Isolation. A transaction in process and not yet committed must


remain isolated from any other transaction.

Durability. Committed data is saved by the system such that,


even in the event of a failure and system restart, the data is
available in its correct state.

Sol 6

The ACID concept is described in ISO/IEC 10026-1:1992 Section 4.


Each of these attributes can be measured against a benchmark.
In general, however, a transaction manager or monitor is
designed to realize the ACID concept. In a distributed system, one
way to achieve ACID is to use a two-phase commit (2PC), which
ensures that all involved sites must commit to transaction
completion or none do, and the transaction is rolled back
All Database systems which include transaction support
implement ACID properties to ensure the integrity of the
database. ACID stands for Atomicity, Consistency, Isolation and
Durability

Atomicity: Each transaction is said to be “atomic.” If one part of


the transaction fails, the entire transaction fails. Modifications on
the data in the database either fail or succeed.
Consistency: This property ensures that only valid data will be
written to the database. If, for some reason, a transaction is
executed that violates the database’s consistency rules, the
entire transaction will be rolled back and the database will be
restored to a state consistent with those rules.
Isolation: It requires that multiple transactions occurring at the
same time not impact each other’s execution.
Durability: It ensures that any transaction committed to the
database will not be lost.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy