II B.Tech – II Sem Database Management Systems Dept.

of AI

DBMS – Unit 3: Relational Database Design & Transactions

3.1 Features of Good Relational Designs
Relational databases need ACID characteristics. ACID refers to four essential properties:
Atomicity, Consistency, Isolation, and Durability. These features are the key difference between a
relational database and a non-relational database.

Atomicity: Atomicity keeps data accurate. It makes sure all data is compliant with the rules,
regulations, and policies of the business. It also requires all tasks to succeed, or the transaction will
roll back. Atomicity defines all the elements in a complete database transaction.

Consistency: The state of the database must remain consistent throughout the
transaction. Consistency defines the rules for maintaining data points. This ensures they remain in a
correct state after a transaction. Relational databases have data consistency because the
information is updated across applications and database copies (also known as ‘instances’). This
means multiple instances always have the same data.

Isolation: With a relational database, each transaction is separate and not dependent on others.
This is made possible by isolation. Isolation keeps the effect of a transaction invisible until it is
committed. This reduces the risk of confusion.

Durability: Durability means that you can recover data from a failed transaction. It also ensures
that data changes are permanent.

3.2 Functional Dependency

Functional dependency (FD) is set of constraints between two attributes in a relation.

Functional dependency says that if two tuples have same values for attributes A1, A2,..., An then
those two tuples must have to have same values for attributes B1, B2, ..., Bn.
Functional dependency is represented by arrow sign (→), that is X→Y, where X functionally
determines Y. The left hand side attributes determines the values of attributes at right hand side.

Armstrong's Axioms (set of rules)

If F is set of functional dependencies then the closure of F, denoted as F+, is the set of all
functional dependencies logically implied by F. Armstrong's Axioms are set of rules, when applied
repeatedly generates closure of functional dependencies.
 Reflexive rule: If alpha is a set of attributes and beta is_subset_of alpha, then alpha holds
beta.
 Augmentation rule: if a → b holds and y is attribute set, then ay → by also holds. That is
adding attributes in dependencies, does not change the basic dependencies.
 Transitivity rule: Same as transitive rule in algebra, if a → b holds and b → c holds then a →
c also hold. a → b is called as a functionally determines b.

Trivial Functional Dependency

 Trivial: If an FD X → Y holds where Y subset of X, then it is called a trivial FD. Trivial FDs are
always hold.
 Non-trivial: If an FD X → Y holds where Y is not subset of X, then it is called non-trivial FD.
 Completely non-trivial: If an FD X → Y holds where x intersect Y = Φ, is said to be completely
non-trivial FD.

DrAA Unit-3 1
II B.Tech – II Sem Database Management Systems Dept. of AI

3.3 Normalization
Normalization is a data analysis technique to design a database system. It allows the
database designer to understand the current data structures within an organization. The
end result of normalization is a set of entities, which removes unnecessary redundancy (ie
duplication of data) and avoids the anomalies. Storing the same information redundantly,
that is, in more than one place within a database, can lead to several problems:

Problems Caused by Redundancy

Redundant storage: Some information is stored repeatedly.

 Update anomalies: If one copy of such repeated data is updated, an inconsistency is
created unless all copies are similarly updated.
Insertion anomalies: It may not be possible to store some information unless some
other information is stored as well.
 Deletion anomalies: It may not be possible to delete some information without losing
some other information as well.

The steps of normalization are:

 Select the data source and convert into an unnormalised table (UNF)
 Transform the unnormalised data into first normal form (1NF)
 Transform data in first normal form (1NF) into second normal form (2NF)
 Transform data in second normal form (2NF) into third normal form (3NF)

Occasionally, the data may still be subject to anomalies in third normal form. In this case,
we may have to perform further transformations.

 Transform third normal form to Boyce-Codd normal form (BCNF)

 Transform Boyce-Codd normal form to fourth normal form (4NF)
 Transform fourth normal form to fifth normal form (5NF)
Normalization is a method to remove all these anomalies and bring database to consistent
state and free from any kinds of anomalies.

The Normalization Process

We've now been through the complete process. Having started off with an unnormalized table
we finished with four normalized tables in 3NF. You will notice that duplication has been removed
(apart from the keys needed to establish the links between those tables).
The process may look complicated. However, if you follow the rules completely, and do not
miss out any steps, then you should arrive at the correct solution. If you omit a rule there is a high
probability that you will end up with too few tables or incorrect keys.

A summary of the complete normalization process is given on the following steps.

DrAA Unit-3 2
II B.Tech – II Sem Database Management Systems Dept. of AI

Step 1: UNF
Select the data source and convert into an unnormalised table (UNF)
Process:
 Create column headings (ignoring any calculated fields)
 Enter sample data into table
 Identify a key for table (and underline it)
 Remove duplicate data
Step 2: 1NF
Transform a table of unnormalised data into first normal form (1NF)
Rule: Remove any repeating attributes to a new table
Process:
 Identify repeating attributes
 Remove repeating attributes to a new table together with a copy of the key from the UNF
table
 Assign a key to the new table (and underline it). The key from the unnormalised table always
becomes part of the key of the new table. A compound key is created. The value for this key
must be unique for each entity occurrence.
Example: First Normal Form:
This rule defines that all the attributes in a relation must have
atomic domains. Values in atomic domain are indivisible units.

Before 1NF:

Figure: un-organized relation

We re-arrange the relation (table) as below, to convert it to First Normal Form

After 1NF:

Figure: relation in 1NF

Each attribute must contain only single value from its pre-defined domain.

DrAA Unit-3 3
II B.Tech – II Sem Database Management Systems Dept. of AI

Step 3: 2NF
Transform data in first normal form (1NF) into second normal form (2NF)

Rule: Remove any non-key attributes that only depend on part of the table key to a new table
Ignore tables with a) a simple key or b) with no non-key attributes (these go straight to 2NF with no
conversion)
Process:
 Take each non-key attribute in turn and ask the question
- is this attribute dependent on one part of the key?
 If yes, remove attribute to new table with a copy of the part of the key it is dependent upon.
The key it is dependent upon becomes the key in the new table. Underline the key in this new
table.
 If no, check against other part of the key and repeat above process.
 If still no, ie not dependent on either part of key, keep attribute in current table.

Example: Second Normal Form: Before we learn about second normal form, we need to
understand the following:

 Prime attribute: an attribute, which is part of prime-key, is prime attribute.

 Non-prime attribute: an attribute, which is not a part of prime-key, is said to be a
non-prime attribute.
Second normal form says that every non-prime attribute should be fully functionally dependent on
prime key attribute. That is, if X → A holds, then there should not be any proper subset Y of X, for
that Y → A also holds.
Before 2NF:

Figure: relation not in 2NF

We see here in Student_Project relation that the prime key attributes are Stu_ID and Proj_ID.
According to the rule, non-key attributes, i.e. Stu_Name and Proj_Name must be dependent upon
both and not on any of the prime key attribute individually. But we find that Stu_Name can be
identified by Stu_ID and Proj_Name can be identified by Proj_ID independently. This is called partial
dependency, which is not allowed in Second Normal Form.
After 2NF:

Figure: relation in 2NF

We broke the relation in two as depicted in the above figure. So there exists no partial
dependency.

DrAA Unit-3 4
II B.Tech – II Sem Database Management Systems Dept. of AI

Step 4: 3NF
Transform data in second normal form (2NF) into third normal form (3NF)
Rule: Remove to a new table any non-key attributes that are more dependent on other non-key
attributes than the table key
Ignore tables with zero or only one non-key attribute (these go straight to 3NF with no conversion).
Process:
 If a non-key attribute is more dependent on another non-key attribute than the table key
 Move the dependent attribute, together with a copy of the non-key attribute upon which it is
dependent, to a new table
 Make the non-key attribute, upon which it is dependent, the key in the new table. Underline the
key in this new table.
 Leave the non-key attribute, upon which it is dependent, in the original table and mark it a
foreign key (*).
Example: Third Normal Form: For a relation to be in Third Normal Form, it must be in Second Normal form
and the following must satisfy:
 No non-prime attribute is transitively dependent on prime key attribute
 For any non-trivial functional dependency, X → A, then either
 X is a superkey or,
 A is prime attribute.
Before 3NF:

Figure: relation not in 3NF

We find that in above depicted Student_detail relation, Stu_ID is key and only prime key attribute. We find that
City can be identified by Stu_ID as well as Zip itself. Neither Zip is a superkey nor City is a prime attribute.
Additionally, Stu_ID → Zip → City, so there exists transitive dependency.
After 3NF:

Figure: relation in 3NF

We broke the relation as above depicted two relations to bring it into 3NF.

Boyce-Codd Normal Form: BCNF is an extension of Third Normal Form in strict way.
BCNF states that
 For any non-trivial functional dependency, X → A, then X must be a super-key.

In the above depicted figure, Stu_ID is super-key in Student_Detail relation and Zip is super-key in
ZipCodes relation. So,
Stu_ID → Stu_Name, Zip
&
Zip → City
Confirms, that both relations are in BCNF.

DrAA Unit-3 5