Scribd
Upload
2 views

Normalizationl

The document discusses table normalization, outlining its objectives, processes, and advantages, such as eliminating data anomalies and improving database performance. It details the various normal forms (1NF, 2NF, 3NF, and BCNF) and their requirements, along with examples of functional dependencies and issues arising from non-normalized databases. Additionally, it addresses the merging of relations and potential duplication scenarios in database design.

Uploaded by

Marcelo, Nicole A.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
2 views

Normalizationl

The document discusses table normalization, outlining its objectives, processes, and advantages, such as eliminating data anomalies and improving database performance. It details the various normal forms (1NF, 2NF, 3NF, and BCNF) and their requirements, along with examples of functional dependencies and issues arising from non-normalized databases. Additionally, it addresses the merging of relations and potential duplication scenarios in database design.

Uploaded by

Marcelo, Nicole A.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Table Normalization

Objectives
▪ Normalize relations into 1st, 2nd or 3rd normal forms.
▪ Use normalization to make well-structured relations without
anomalies
Normalization
▪ The process of breaking relations and removing anomalies to form well-structured relations. Normalization
is used for mainly two purpose, Eliminating reduntant(useless) data. Ensuring data dependencies make
sense i.e data is logically stored.
Advantages
- No DML anomalies
-Inserts, deletes, and modifications are easier to handle
-No unnecessary information
-Better performance
-Avoid Duplication and Conserve Storage
Problem without Normalization
▪ Without Normalization, it becomes difficult to handle and update the database, without facing
data loss.
▪ Insertion, Updating and Deletion Anomalies are very frequent if Database is not Normalized.
Problem without Normalization (cont.)
▪ Update Anomaly : To update address of a student who occurs twice or more
than twice in a table, we will have to update S_Address column in all the rows,
else data will become inconsistent.
▪ Insert Anomaly : Suppose for a new admission, we have a Student id(S_id),
name and address of a student but if student has not opted for any subjects yet
then we have to insert NULL there, leading to Insertion Anomaly.
▪ Deletion Anomaly : If (S_id) 401 has only one subject and temporarily he drops
it, when we delete that row, entire student record will be deleted along with it.
Functional Dependency
▪ A dependency between an attribute B to
attribute A in which the value of A
distinctively determines the value of B,
wherein attribute A is the determinant.
Example:
Student_ID, Course_name --> Date_completed.
Student_ID, Course_name --> Grade.

An attribute or a set of attributes that


uniquely identify a row in a table is called
a candidate key. Consider this relation:
BOOK_ID --> Title, Author, Publisher.
Functional dependency (Cont.)
▪ Partial functional dependency ▪ Partial dependency Sample:
- is a functional dependency in which one Teacher_table
or more non-key attributes are ▪Column:
functionally dependent on a part (but not Teacher_id, subject, teacher_age
all) of the primary key. Candidate Keys: {teacher_id, subject}
Non prime attribute: teacher_age
▪ Transitive functional dependency
▪ Transitive dependency Sample:
- A functional dependency between two
(or more) non-key attributes
Rules for Normalization
▪ 1st Normal Form (1NF)
- A relation is considered to be in the 1st normal form if it has no multivalued attributes.
- No two Rows of data must contain repeating group of information
▪ 2nd Normal Form (2NF)
- A relation is said to be in the 2nd normal form if it is in 1NF and every non-key attribute is completely
functionally dependent on the primary key.
- There must not be any partial dependency of any column on primary key.
▪ 3rd Normal Form (3NF)
- A relation is in 3NF if it is in 2NF and no transitive dependency exists.
- Every non-prime attribute of table must be dependent on primary key
▪ BCNF (Boyce Codd Normal Form)
- extension of Third Normal Form on strict terms. A table complies with BCNF if it is in 3NF and for
every functional dependency X->Y, X should be the super key of the table.
Normalization Sample
Sample table with multi-valued attributes
st
1 Normal Form
▪ A relation is considered to be in the 1st normal form if it has no multivalued attributes. To do
this, eliminate repeating groups in the table.
nd
2 Normal Form
▪ A relation is said to be in the 2nd normal form if it is in 1NF and every non-key attribute is
completely functionally dependent on the primary key.
▪ None of the non-key attributes are dependent on part of the primary key.
rd
3 Normal Form
▪ A relation is in 3NF if it is in 2NF and no transitive dependency exists.
▪ Every attribute in the relation is solely dependent on the key and nothing but the key.
▪ A relation is said to be in the 3rd normal form if it is in 2NF and no transitive dependencies are
present.
Example: Student_id is Primary key, but street, city and state depends upon Zip
rd
3 Normal Form Sample (cont.)
The dependency between zip and other fields is called transitive dependency. Hence to
apply 3NF, we need to move the street, city and state to new table, with Zip as primary key.
Boyce Codd Normal Form (BCNF)
▪ A table complies with BCNF if it is in 3NF and
for every functional dependency X->Y, X should
be the super key of the table.
▪ Example: Suppose there is a company wherein
employees work in more than one
department.
Functional dependencies in the table above:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
The table is not in BCNF as neither emp_id nor
emp_dept alone are keys.
BCNF Solution
▪ Break the table in three tables

Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Merging Relations
▪ The following situations may determine if a Example:
database design need to be merged:
◦ When working on large projects
STUDENTA [Student_ID, Major]
◦ Combining existing databases with new requirements STUDENTB [Student_ID, Advisor]
◦ Existence of new data requirements during the
life-cycle of a database system It seems as if these can be merged to form:
STUDENT [Student_ID, Major, Advisor]
▪ Four Situations in which duplication may occur However, Advisor is dependent on Major if all
in merging database: majors have the same advisor. To settle this, we
1. Synonyms -- Two or more attributes have should create two entities:
different names but have the same meaning STUDENT [Student_ID, Major]
2. Homonyms -- The same attribute is used in MAJOR_ADVISOR [Major, Advisor]
defining more than one entity
3. Transitive Dependencies
4. Supertype/Subtype Relationships
Questions???

You might also like