Normalization is a systematic approach to organizing data within a database.
It reduces data redundancy and improves database efficiency.
It eliminates undesirable anomalies such as insertion, update, and deletion anomalies.
It involves breaking down large tables into smaller, well-structured ones.
It is based on analyzing relation schemas using Functional Dependencies (FDs) and primary
keys.
Database Normalization Forms
1NF (First Normal Form):
It disallows multivalued attributes, composite attributes, and their combinations.
2NF (Second Normal Form)
Second normal form (2NF) is based on the concept of full functional dependency. A functional
that the dependency does not hold anymore; That is, for any attribute A ∈ X, (X - {A}) does not
dependency X → Y is a full functional dependency if removal of any attribute A from X means
functionally determine Y.
3NF (Third Normal Form)
A database is in third normal form (3NF) if it satisfies the following conditions:
It is in second normal form
There is no transitive functional dependency
By transitive functional dependency, we mean the following relationship in a table:
A is functionally dependent on B
B is functionally dependent on C → Then A is transitively dependent on C via B
1. Illustrate the informal design guidelines for relation schemes with examples.
(10M)
The informal design guidelines help in evaluating the quality of a relation schema to avoid
anomalies and ensure data consistency. The four main guidelines are:
1. Imparting Clear Semantics to Attributes in Relations
Each attribute in a relation must describe a single role or concept. Mixing unrelated attributes
in a single relation leads to confusion and poor schema design.
2. Avoiding Redundant Information and Update Anomalies
Redundancy leads to excessive storage usage and anomalies during update, insertion, or
deletion operations.
🔹 5. Preserve Dependencies
Guideline:
Ensure that important functional dependencies are preserved after decomposition.
Example:
If EmpID → DeptID, and decomposition loses this dependency, enforcing integrity constraints
becomes harder.
➡ Aim for dependency-preserving decomposition for efficient constraint enforcement.
Insertion, Deletion, and Modification Anomalies in DBMS
In database systems, anomalies are problems that can occur when inserting, updating, or
deleting data in a poorly designed database. These anomalies lead to data inconsistency, data
loss, and integrity issues, especially when the database is not properly normalized.
1. Insertion Anomaly
Definition: An insertion anomaly occurs when we are unable to add data to the
database due to the absence of other data.
Cause: It arises when a single table is used to store multiple entities (e.g., Student and
Course), and inserting data about one entity requires having information about the
other.
Why it's bad: Prevents adding essential data and forces the insertion of null values or
dummy data, violating integrity rules.
Example:
Consider a table Student_Course:
| StudentID | StudentName | CourseID | CourseName |
| 101 | John | CSE101 | DBMS |
If a new course CSE102 - Networks is introduced, but no student has enrolled yet, we cannot
insert this course unless we add dummy student data, which leads to redundancy and poor
integrity.
2. Deletion Anomaly
Definition: A deletion anomaly occurs when deleting a record lead to the unintended
loss of other valuable data.
Cause: It happens when multiple facts are stored in one row, and deleting that row
removes all those facts.
Why it's bad: Leads to unintended data loss, especially when the deleted data is the
only occurrence of an important fact.
Example:
Suppose this is the only record for the course "DBMS":
| StudentID | StudentName | CourseID | CourseName |
|-----------|-------------|----------|------------|
| 101 | John | CSE101 | DBMS |
If John leaves the course and we delete this row, we also lose the information about the
existence of the course itself, which is undesirable.
3. Modification (Update) Anomaly
Definition: A modification or update anomaly happens when a single update requires
multiple rows to be changed to maintain data consistency.
Cause: This arises when data is duplicated across rows and all instances must be
updated simultaneously.
Why it's bad: If even one occurrence is missed during update, it causes inconsistent and
unreliable data.
Example:
If the course name for CSE101 appears in multiple rows:
| 101 | John | CSE101 | DBMS |
| 102 | Alice | CSE101 | Database |
Now if we update the course name to "Database Systems" only in the first row, we get
inconsistent course names for the same course ID.
Why Are These Anomalies Considered Bad?
They lead to data redundancy, increasing storage cost.
They cause data inconsistency, which results in unreliable results from queries.
They may lead to data integrity violations, such as null values where they shouldn't
exist.
They make database maintenance complex and error-prone.
They result in logical errors and loss of crucial data.
Solution: Normalization
To eliminate these anomalies, we apply normalization:
It breaks large tables into smaller related tables.
Removes repetitive data by placing data into logical groups.
Enforces referential integrity using primary and foreign keys.
Conclusion
Insertion, deletion, and modification anomalies pose significant threats to data accuracy and
consistency. These issues typically arise in unnormalized or poorly structured databases. By
applying normal forms and designing relational schemas properly, these anomalies can be
avoided, ensuring a robust, efficient, and reliable database system.
