Activity 5 Advance DBM Normalization Research 3 DARWIN G RARALIO

Republic of the Philippines
Cagayan State University

CARIG CAMPUS
Carig Sur, Tuguegarao City
MSIT 202-ADVANCED DATABASE MANAGEMENT
TOPIC/s Activity 5: Normalization(Research 3)

Title of topic/s Normalization
 Functional Dependency
 The Normalization Process
 Anomalies in a Database
 Normalization and Database Design
 Denormalization
KEYWORDS Axiom, Decomposition, Dependent, Determinant, Union,

Main words used in the Normalization, Database
discussion
GUIDE QUESTIONS  To know what is functional dependency
get it from the discussions  To be familiar with different Normalization processes and its
Database Design
 To know what is database anomalies and how to solve it.
 To be able to denormalize Database.
DEFINITION OF  Functional Dependency - constraint that determines the

TERMS relation of one attribute to another attribute in a Database
Define term based on how it was Management System.
used in the discussion
 Multivalued Dependency - complete constraint between two
sets of attributes in a relation.
 Normalization - a method of organizing the data in the
database which helps you to avoid data redundancy, insertion,
update & deletion anomaly.
 Data anomalies - inconsistencies in the data stored in a
database as a result of an operation such as update, insertion,
and/or deletion.
 Denormalization - a database optimization technique in which
we add redundant data to one or more tables.
SUBMITTED BY: DARWIN G. RARALIO
DISCUSSIONS:
Functional Dependency
MSIT-GRADUATE SCHOOL
CARIG CAMPUS
What is Functional Dependency?
Functional Dependency (FD) is a constraint that determines the relation of one attribute to
another attribute in a Database Management System (DBMS). Functional Dependency helps
to maintain the quality of data in the database. It plays a vital role to find the difference
between good and bad database design.
A functional dependency is denoted by an arrow “→”. The functional dependency of X on Y

is represented by X → Y. Let’s understand Functional Dependency in DBMS with example.
Rules of Functional Dependencies
Below are the Three most important rules for Functional Dependency in Database:
 Reflexive rule –. If X is a set of attributes and Y is_subset_of X, then X holds a value

of Y.
 Augmentation rule: When x -> y holds, and c is attribute set, then ac -> bc also holds.
That is adding attributes which do not change the basic dependencies.
 Transitivity rule: This rule is very much similar to the transitive rule in algebra if x ->
y holds and y -> z holds, then x -> z also holds. X -> y is called as functionally that
determines y.
Types of Functional Dependencies in DBMS

There are mainly four types of Functional Dependency in DBMS. Following are the types of
Functional Dependencies in DBMS:
 Multivalued Dependency
 Trivial Functional Dependency
 Non-Trivial Functional Dependency
 Transitive Dependency
Multivalued Dependency in DBMS
CARIG CAMPUS

Multivalued dependency occurs in the situation where there are multiple independent
multivalued attributes in a single table. A multivalued dependency is a complete constraint
between two sets of attributes in a relation. It requires that certain tuples be present in a
relation. Consider the following Multivalued Dependency Example to understand.
CARIG CAMPUS

Trivial Functional Dependency in DBMS
The Trivial dependency is a set of attributes which are called a trivial if the set of attributes
are included in that attribute.
So, X -> Y is a trivial functional dependency if Y is a subset of X. Let’s understand with a

Trivial Functional Dependency Example.
Consider this table of with two columns Emp_id and Emp_name.
{Emp_id, Emp_name} -> Emp_id is a trivial functional dependency as Emp_id is a subset of

{Emp_id,Emp_name}.
Non Trivial Functional Dependency in DBMS

Functional dependency which also known as a nontrivial dependency occurs when A->B
holds true where B is not a subset of A. In a relationship, if attribute B is not a subset of
attribute A, then it is considered as a non-trivial dependency.
Example:
(Company} -> {CEO} (if we know the Company, we knows the CEO name)
But CEO is not a subset of Company, and hence it’s non-trivial functional dependency.
CARIG CAMPUS
Transitive Dependency in DBMS

A Transitive Dependency is a type of functional dependency which happens when “t” is
indirectly formed by two functional dependencies. Let’s understand with the following
Transitive Dependency Example.
{Company} -> {CEO} (if we know the compay, we know its CEO’s name)
{CEO } -> {Age} If we know the CEO, we know the Age
Therefore according to the rule of rule of transitive dependency:
{ Company} -> {Age} should hold, that makes sense because if we know the company name,
we can know his age.
Note: You need to remember that transitive dependency can only occur in a relation of three
or more attributes.
Advantages of Functional Dependency

 Functional Dependency avoids data redundancy. Therefore same data do not repeat at
multiple locations in that database
 It helps you to maintain the quality of data in the database
 It helps you to defined meanings and constraints of databases
 It helps you to identify bad designs
 It helps you to find the facts regarding the database design
CARIG CAMPUS

The Normalization Process
What is Normalization?
Normalization is a method of organizing the data in the database which helps you to avoid
data redundancy, insertion, update & deletion anomaly. It is a process of analyzing the
relation schemas based on their different functional dependencies and primary key.
Normalization is inherent to relational database theory. It may have the effect of duplicating
the same data within the database which may result in the creation of additional tables.
As with many formal rules and specifications, real world scenarios do not always allow for
perfect compliance. In general, normalization requires additional tables and some customers
find this cumbersome. If you decide to violate one of the first three rules of normalization,
make sure that your application anticipates any problems that could occur, such as redundant
data and inconsistent dependencies.
The following descriptions include examples.
Normalization and Database Design
First normal form

 Eliminate repeating groups in individual tables.
 Create a separate table for each set of related data.
 Identify each set of related data with a primary key.
Do not use multiple fields in a single table to store similar data. For example, to track an
inventory item that may come from two possible sources, an inventory record may contain
fields for Vendor Code 1 and Vendor Code 2.
What happens when you add a third vendor? Adding a field is not the answer; it requires
program and table modifications and does not smoothly accommodate a dynamic number of
vendors. Instead, place all vendor information in a separate table called Vendors, then link
inventory to vendors with an item number key, or vendors to inventory with a vendor code
key.
CARIG CAMPUS

Second normal form
 Create separate tables for sets of values that apply to multiple records.
 Relate these tables with a foreign key.
Records should not depend on anything other than a table's primary key (a compound key, if
necessary). For example, consider a customer's address in an accounting system. The address
is needed by the Customers table, but also by the Orders, Shipping, Invoices, Accounts
Receivable, and Collections tables. Instead of storing the customer's address as a separate
entry in each of these tables, store it in one place, either in the Customers table or in a
separate Addresses table.
Third normal form

Eliminate fields that do not depend on the key.
Values in a record that are not part of that record's key do not belong in the table. In general,
anytime the contents of a group of fields may apply to more than a single record in the table,
consider placing those fields in a separate table.
For example, in an Employee Recruitment table, a candidate's university name and address
may be included. But you need a complete list of universities for group mailings. If university
information is stored in the Candidates table, there is no way to list universities with no
current candidates. Create a separate Universities table and link it to the Candidates table
with a university code key.
EXCEPTION: Adhering to the third normal form, while theoretically desirable, is not
always practical. If you have a Customers table and you want to eliminate all possible
interfield dependencies, you must create separate tables for cities, ZIP codes, sales
representatives, customer classes, and any other factor that may be duplicated in multiple
records. In theory, normalization is worth pursing. However, many small tables may degrade
performance or exceed open file and memory capacities.
It may be more feasible to apply third normal form only to data that changes frequently. If
some dependent fields remain, design your application to require the user to verify all related
fields when any one is changed.
Other normalization forms

Fourth normal form, also called Boyce Codd Normal Form (BCNF), and fifth normal form do
exist, but are rarely considered in practical design. Disregarding these rules may result in less
than perfect database design, but should not affect functionality.
CARIG CAMPUS

Normalizing an example table
These steps demonstrate the process of normalizing a fictitious student table.
1. Unnormalized table
2. First normal form: No repeating groups
Tables should have only two dimensions. Since one student has several classes, these
classes should be listed in a separate table. Fields Class1, Class2, and Class3 in the above
records are indications of design trouble.
Spreadsheets often use the third dimension, but tables should not. Another way to look at
this problem is with a one-to-many relationship, do not put the one side and the many side
in the same table. Instead, create another table in first normal form by eliminating the
repeating group (Class#), as shown below:
CARIG CAMPUS

3. Second normal form: Eliminate redundant data
Note the multiple Class# values for each Student# value in the above table. Class# is not
functionally dependent on Student# (primary key), so this relationship is not in second
normal form.
The following tables demonstrate second normal form:
CARIG CAMPUS
4. Third normal form: Eliminate data not dependent on key
In the last example, Adv-Room (the advisor's office number) is functionally dependent on
the Advisor attribute. The solution is to move that attribute from the Students table to the
Faculty table, as shown below:
CARIG CAMPUS

Anomalies in a Database
Data anomalies are inconsistencies in the data stored in a database as a result of an
operation such as update, insertion, and/or deletion.
Such inconsistencies may arise when have a particular record stored in multiple locations and
not all of the copies are updated.
What Causes Anomalies In Database?

An anomaly occurs when too many redundant elements are present in the database. In order
to reduce the negative effects of creating tables that will introduce anomalies into the
database, the normalization process was designed mainly to reduce the negative effects.
What Are The 3 Database Anomalies?

An anomaly can be either an update, a deletion, or an insertion. An update anomaly is a
result of data redundancy and a partial update occurring in the same data set.
What Are The Different Types Of Data Anomalies?

Data anomalies can be categorized into three types:
 Update Anomalies,
 Insertion Anomalies, and
 Deletion Anomalies.
How Can Data Anomalies Be Resolved?

Data that is redundant (or repeated) will be removed from the database.
Deletion of undesirable insertions, updates, and dependencies.
By reducing the amount of time it takes to restructure the database every time new fields are
added, it is easier to use.
What Are The Different Anomalies In Dbms?

Unnormalization of a database results in three types of anomalies. An anomaly in insertion,
update, and deletion occurs.
CARIG CAMPUS
Denormalization in Databases
Denormalization is a database optimization technique in which we add redundant data to

one or more tables. This can help us avoid costly joins in a relational database. Note that
denormalization does not mean not doing normalization. It is an optimization technique that
is applied after doing normalization.
In a traditional normalized database, we store data in separate logical tables and attempt to
minimize redundant data. We may strive to have only one copy of each piece of data in
database.
For example, in a normalized database, we might have a Courses table and a Teachers table.
Each entry in Courses would store the teacherID for a Course but not the teacherName. When
we need to retrieve a list of all Courses with the Teacher’s name, we would do a join between
these two tables.
In some ways, this is great; if a teacher changes his or her name, we only have to update the
name in one place.
The drawback is that if tables are large, we may spend an unnecessarily long time doing joins
on tables.
Denormalization, then, strikes a different compromise. Under denormalization, we decide
that we’re okay with some redundancy and some extra effort to update the database in order
to get the efficiency advantages of fewer joins.
Pros of Denormalization:-
 Retrieving data is faster since we do fewer joins
 Queries to retrieve can be simpler(and therefore less likely to have bugs),
since we need to look at fewer tables.
Cons of Denormalization:-
1. Updates and inserts are more expensive.

2. Denormalization can make update and insert code harder to write.
3. Data may be inconsistent . Which is the “correct” value for a piece of data?
4. Data redundancy necessitates more storage.
In a system that demands scalability, like that of any major tech company, we almost always
use elements of both normalized and denormalized databases.
5.
CARIG CAMPUS

References:
 https://www.guru99.com/dbms-functional-dependency.html
 https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-
description#:~:text=Normalization%20is%20the%20process%20of,eliminating
%20redundancy%20and%20inconsistent%20dependency.
 https://databasemanagement.fandom.com/wiki/Data_Anomalies
 https://www.geeksforgeeks.org/denormalization-in-databases/

Activity 5 Advance DBM Normalization Research 3 DARWIN G RARALIO

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Activity 5 Advance DBM Normalization Research 3 DARWIN G RARALIO

Uploaded by

Copyright:

Available Formats

Republic of the Philippines

Cagayan State University

MSIT 202-ADVANCED DATABASE MANAGEMENT

TOPIC/s Activity 5: Normalization(Research 3)

KEYWORDS Axiom, Decomposition, Dependent, Determinant, Union,

DEFINITION OF  Functional Dependency - constraint that determines the

SUBMITTED BY: DARWIN G. RARALIO

MSIT 202-ADVANCED DATABASE MANAGEMENT

What is Functional Dependency?

A functional dependency is denoted by an arrow “→”. The functional dependency of X on Y

 Reflexive rule –. If X is a set of attributes and Y is_subset_of X, then X holds a value

Types of Functional Dependencies in DBMS

Multivalued Dependency in DBMS

MSIT 202-ADVANCED DATABASE MANAGEMENT

MSIT 202-ADVANCED DATABASE MANAGEMENT

So, X -> Y is a trivial functional dependency if Y is a subset of X. Let’s understand with a

Consider this table of with two columns Emp_id and Emp_name.

{Emp_id, Emp_name} -> Emp_id is a trivial functional dependency as Emp_id is a subset of

Non Trivial Functional Dependency in DBMS

MSIT 202-ADVANCED DATABASE MANAGEMENT

Transitive Dependency in DBMS

Advantages of Functional Dependency

MSIT 202-ADVANCED DATABASE MANAGEMENT

The following descriptions include examples.

Normalization and Database Design

First normal form

MSIT 202-ADVANCED DATABASE MANAGEMENT

Third normal form

Other normalization forms

MSIT 202-ADVANCED DATABASE MANAGEMENT

2. First normal form: No repeating groups

MSIT 202-ADVANCED DATABASE MANAGEMENT

The following tables demonstrate second normal form:

MSIT 202-ADVANCED DATABASE MANAGEMENT

4. Third normal form: Eliminate data not dependent on key

MSIT 202-ADVANCED DATABASE MANAGEMENT

What Causes Anomalies In Database?

What Are The 3 Database Anomalies?

What Are The Different Types Of Data Anomalies?

How Can Data Anomalies Be Resolved?

What Are The Different Anomalies In Dbms?

MSIT 202-ADVANCED DATABASE MANAGEMENT

Denormalization is a database optimization technique in which we add redundant data to

1. Updates and inserts are more expensive.

MSIT 202-ADVANCED DATABASE MANAGEMENT

You might also like