Normalisation DDM
Normalisation DDM
First Normal Form requires that all data in a database table is stored in individual cells that contain
only a single value (atomicity). This means that each column must hold unique, indivisible values—no
lists or sets within a single cell. Additionally, each row must be unique, and columns must have unique
names.
Example Scenario: Imagine you have a list of students and the courses they are taking. If you store all
the courses a student takes in one field (like “Math, Physics, Chemistry”), this violates 1NF because the
field contains multiple values.
How to Fix: To bring this data into 1NF, you would separate each course into its own row, ensuring that
every field contains only a single value. This makes it easier to search, update, and analyze the data.
Why it matters: 1NF eliminates repeating groups and makes data easier to manage and query.
2.Second Normal Form builds on 1NF and addresses the issue of partial dependencies. A partial
dependency occurs when a non-key attribute is dependent on only part of a composite primary key (a
primary key made up of more than one column). 2NF requires that every non-key attribute is fully
dependent on the entire primary key, not just a part of it.
Example Scenario: Suppose you have a table recording which students are enrolled in which courses,
and also storing the name of each course. The primary key is a combination of “Student ID” and “Course
ID.” However, the “Course Name” depends only on “Course ID,” not on the combination of “Student ID”
and “Course ID.” This is a partial dependency.
How to Fix:To achieve 2NF, you would separate the course information into its own table, with “Course
ID” as the primary key. The enrollment table would then only store “Student ID” and “Course ID.” Now,
non-key attributes depend on the whole key, not just part of it.
Why it matters: 2NF helps eliminate redundant data and ensures that each fact is stored only once,
making updates easier and reducing the risk of inconsistencies.
3.Third Normal Form takes normalization a step further by removing transitive dependencies. A
transitive dependency exists when a non-key attribute depends on another non-key attribute, rather than
directly on the primary key. 3NF requires that every non-key attribute is not only fully dependent on the
primary key (as in 2NF), but also independent of other non-key attributes.
Example Scenario: Imagine you have a table where each course has a teacher, and you store both the
teacher’s ID and their name in the course table. The teacher’s name depends on the teacher’s ID, not
directly on the course’s primary key. This is a transitive dependency.
How to Fix: To bring the table into 3NF, you would create a separate table for teachers, using “Teacher
ID” as the key and storing the teacher’s name there. The course table would only reference the “Teacher
ID.”
Why it matters: 3NF further reduces redundancy and the possibility of anomalies (such as having to
update a teacher’s name in multiple places), making the database more efficient and easier to maintain.