0% found this document useful (0 votes)
77 views17 pages

Understanding Database Normalization Basics

Cs

Uploaded by

devileela921
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
77 views17 pages

Understanding Database Normalization Basics

Cs

Uploaded by

devileela921
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

NORMALIZATION

ABHIRAMI T
• candidate key is a set of one or more attributes (columns)
that can uniquely identify a tuple (row) in a relation (table).
A primary key is one candidate key that is chosen to
uniquely identify tuples within a relation
• A super key is a set of one or more attributes (columns) that, taken together,
uniquely identify tuples (rows) within a relation (table). In other words, a
super key is a superset of a candidate key. It can contain more attributes
than needed to uniquely identify tuples. Any combination of attributes that
includes a candidate key is considered a super key. For example, if a relation
has attributes A, B, and C, and {A, B} is a candidate key, then {A, B, C} and
{A, B, C, D} are both super keys.
Database normalization

• Database normalization is a database design principle


for organizing data in an organized and consistent way.

• It helps you avoid redundancy and maintain the


integrity of the database.

• It also helps you eliminate undesirable characteristics


associated with insertion, deletion, and updating.
• The main purpose of database normalization is to avoid
complexities, eliminate duplicates, and organize data in
a consistent way.

• In normalization, the data is divided into several tables


linked together with relationships.

• Database administrators are able to achieve these


relationships by using primary keys, foreign keys, and
composite keys.
• 1NF, 2NF, and 3NF are the first three types of database
normalization.

• They stand for first normal form, second normal form,


and third normal form, respectively.

• There are also 4NF (fourth normal form) and 5NF (fifth
normal form).

• There’s even 6NF (sixth normal form), but the


commonest normal form you’ll see out there is 3NF
(third normal form).
The First Normal Form – 1NF
• For a table to be in the first normal form, it must meet
the following criteria:

• a single cell must not hold more than one value


(atomicity)
• there must be a primary key for identification
• no duplicated rows or columns
• each column must have only one value for each row in
the table
The Second Normal Form – 2NF

• The 1NF only eliminates repeating groups, not


redundancy. That’s why there is 2NF.
• A table is said to be in 2NF if it meets the following
criteria:
• it’s already in 1NF
• has no partial dependency. That is, all non-key
attributes are fully dependent on a primary key.
The Third Normal Form – 3NF
• When a table is in 2NF, it eliminates repeating groups and
redundancy, but it does not eliminate transitive partial
dependency.

• This means a non-prime attribute (an attribute that is not part of


the candidate’s key) is dependent on another non-prime
attribute. This is what the third normal form (3NF) eliminates.

• So, for a table to be in 3NF, it must:

• be in 2NF
• have no transitive partial dependency.
Examples of 1NF, 2NF, and 3NF
• Database normalization is quite technical, but we will
illustrate each of the normal forms with examples.

• Imagine we're building a restaurant management


application. That application needs to store data about
the company's employees and it starts out by creating
the following table of employees:
• But even if you only know someone's employee_id,
then you can determine their name, home_state, and
state_code (because they should be the same person).
• This means name, home_state, and state_code are
dependent on employee_id (a part of primary
composite key).
• So, the table is not in 2NF. We should separate them
to a different table to make it 2NF.
• home_state is now dependent on state_code.

• So, if you know the state_code, then you can find the
home_state value.

• To take this a step further, we should separate them


again to a different table to make it 3NF.
Thankyou

You might also like