Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency

. Normalization usually involves dividing large tables into smaller (and less redundant) tables and defining relationships between them. The objective is to isolate data so that additions, deletions, and modifications of a field can be made in just one table and then propagated through the rest of the database using the defined relationships.
Edgar F. Codd, the inventor of the relational model, introduced the concept of normalization and what we now know as the First Normal Form (1NF) in 1970. Codd went on to define the Second Normal Form (2NF) and Third Normal Form (3NF) in 1971, and Codd and Raymond F. Boyce defined the Boyce-Codd Normal Form (BCNF) in 1974. Informally, a relational database table is often described as "normalized" if it is in the Third Normal Form. Most 3NF tables are free of insertion, update, and deletion anomalies.

Objectives of normalization
A basic objective of the first normal form defined by Edgar Frank "Ted" Codd in 1970 was to permit data to be queried and manipulated using a "universal data sub-language" grounded in first-order logic. (SQL is an example of such a data sub-language, albeit one that Codd regarded as seriously flawed.) The objectives of normalization beyond 1NF (First Normal Form) were stated as follows by Codd:
1. To free the collection of relations from undesirable insertion, update and deletion dependencies; 2. To reduce the need for restructuring the collection of relations, as new types of data are introduced, and thus increase the life span of application programs; 3. To make the relational model more informative to users; 4. To make the collection of relations neutral to the query statistics, where these statistics are liable to change as time goes by. Functional dependency In a given table, an attribute Y is said to have a functional dependency on a set of attributes X (written X → Y) if and only if each X value is associated with precisely one Y value. For example, in an "Employee" table that includes the attributes "Employee ID" and "Employee Date of Birth", the functional dependency {Employee ID} → {Employee Date of Birth} would hold.

Superkey A superkey is a combination of attributes that can be used to uniquely identify a database record. <SSN> and <Phone Extension> has many possible superkeys. Skill}. Name> and <SSN.It follows from the previous two sentences that each {Employee ID} is associated with precisely one {Employee Date of Birth}. because it is also dependent on {Employee ID}. <Phone Extension. . as is {Employee Address} → {Employee Address}. Multivalued dependency A multivalued dependency is a constraint according to which the presence of certain rows in a table implies the presence of certain other rows. Join dependency A table T is subject to a join dependency if T can always be recreated by joining multiple tables each having a subset of the attributes of T. Employee Address} → {Employee Address} is trivial. Example: A table with the fields <Name>.Even by the removal of {Skill} functional dependency still holds between {Employee Address} and {Employee ID}. <Age>. Three of these are <SSN>. one in which X→Z only by virtue of X→Y and Y→Z. Trivial functional dependency A trivial functional dependency is a functional dependency of an attribute on a superset of itself. Name>. {Employee ID. Of those. A table might have many superkeys. and not functionally dependent on any proper subset of X. Candidate key A candidate key is a special subset of superkeys that do not have any extraneous information in them: it is a minimal superkey. Transitive dependency A transitive dependency is an indirect functional dependency. {Employee Address} has a functional dependency on {Employee ID. Full functional dependency An attribute is fully functionally dependent on a set of attributes X if it is:   functionally dependent on X. only <SSN> is a candidate key as the others contain information not necessary to uniquely identify records ('SSN' here refers to Social Security Number. but not a full functional dependency. which is unique to each person).

also by definition. Achieving the "higher" normal forms (above 3NF) does not usually require an extra expenditure of effort on the part of the designer. With respect to normalization. all candidate keys have equal standing and are treated the same. Newcomers to database design sometimes suppose that normalization proceeds in an iterative fashion. then to 3NF. a table always meets the requirements of its HNF and of all normal forms lower than its HNF. furthermore. Each table has a "highest normal form" (HNF): by definition. Primary key One candidate key in a relation may be designated the primary key. conversely. NF) of relational database theory provide criteria for determining a table's degree of immunity against logical inconsistencies and anomalies. is an attribute that does occur in some candidate key. Prime attribute A prime attribute. if it is 3NF.e. A sensibly designed table is likely to be in 3NF on the first attempt. to say that an entire database is in normal form n is to say that all of its tables are in normal form n. a 1NF design is first normalized to 2NF. and so on. While that may be a common practice (or even a required one in some environments). it is overwhelmingly likely to have an HNF of 5NF. it is strictly notational and has no bearing on normalization. The normal forms are applicable to individual tables. The higher the normal form applicable to a table. Normal forms The normal forms (abbrev. i.Non-prime attribute A non-prime attribute is an attribute that does not occur in any candidate key. the less vulnerable it is. Employee Address would be a non-prime attribute in the "Employees' Skills" table. . This is not an accurate description of how normalization typically works. The main normal forms are summarized below. a table fails to meet the requirements of any normal form higher than its HNF. because 3NF tables usually need no modification to meet the requirements of these higher normal forms.

. Zaniolo (1982) Every non-prime attribute is nontransitively dependent on every candidate key in the table.  Second Normal Form (2NF): Each field in a table that is not a determiner of the contents of another field must itself be a function of the other fields in the table.Normal form Defined by In Brief definition First 1NF normal form Two versions: E. (1) In relational database design.F. and the value of each [9] 2003 attribute contains only a single value from [10] that domain. Second 2NF normal form E. the process of organizing data to minimize redundancy. each table would contain only one birthdate field. deletions. and modifications of a field can be made in just one table and then propagated through the rest of the database via the defined relationships. In other words. (3) The objective is to isolate data so that additions. no transitive dependency is allowed. There are three main normal forms.F. Codd(1971). Date (2003) A relation is in first normal form if the domain of each attribute contains [1] 1970 and only atomic values. (2) Normalization usually involves dividing a database into two or more tables and defining relationships between the tables.F. For example. each with increasing levels of normalization:  First Normal Form (1NF): Each field in a table contains different information. Codd(1970). Codd 1971 [2] No non-prime attribute in the table is functionally dependent on a proper subset of any candidate key Third 3NF normal form Two versions: E. C. The attributes that do not [2] 1971 and contribute to the description of the primary [11] 1982 key are removed from the table. C.J. in an employee list.

storing the same data in more than one table) and ensuring data dependencies make sense (only storing related data in a table). a process applied to all data in a set that produces a specific statistical property. for example. they can also make them more complex because data is separated into so many different tables. changing the format of a floating-point number so the left-most digit in the mantissa is not a zero. if two tables both require a birthdate field. Fifth normal form is very rarely seen and won't be discussed in this article. such as Boyce Codd Normal Form (BCNF). (3) In programming. (2) In data processing. Any change to a birthdate would automatically be reflect in all tables that link to the birthdate table. each expenditure for a month can be divided by the total of all expenditures to produce a percentage. and the two other tables would then access the birthdate information via an indexfield in the birthdate table. In practical applications. These are referred to as normal forms and are numbered from one (the lowest form of normalization. referred to as first normal form or 1NF) through five (fifth normal form or 5NF). and3NF along with the occasional 4NF. Third Normal Form (3NF): No duplicate information is permitted. . the birthdate information would be separated into a separate table. What is Normalization? Normalization is the process of efficiently organizing data in a database. There are two goals of the normalization process: eliminating redundant data (for example. fourth normal form (4NF) and fifth normal form (5NF). So. you'll often see 1NF. Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key). Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored. 2NF. The Normal Forms The database community has developed a series of guidelines for ensuring that databases are normalized. There are additional normalization levels. First Normal Form (1NF) First normal form (1NF) sets the very basic rules for an organized database:   Eliminate duplicative columns from the same table. While normalization makes databases more efficient to maintain. For example.

Boyce-Codd Normal Form (BCNF or 3. Create relationships between these new tables and their predecessors through the use of foreign keys. it's not an absolute requirement.Second Normal Form (2NF) Second normal form (2NF) further addresses the concept of removing duplicative data:   Meet all the requirements of the first normal form.  Third Normal Form (3NF) Third normal form (3NF) goes one large step further:   Meet all the requirements of the second normal form. Should I Normalize? While database normalization is often a good idea. Remove columns that are not dependent upon the primary key. adds one more requirement:   Meet all the requirements of the third normal form. .5NF) The Boyce-Codd Normal Form. A relation is in 4NF if it has no multi-valued dependencies. fourth normal form (4NF) has one additional requirement:   Meet all the requirements of the third normal form. Fourth Normal Form (4NF) Finally. also referred to as the "third and half (3. Remove subsets of data that apply to multiple rows of a table and place them in separate tables. Every determinant must be a candidate key. In fact.5) normal form". there are some cases where deliberately violating the rules of normalization is a good practice.

recall the first rule imposed by 1NF: eliminate duplicative columns from the same table. For the purposes of our example. imagine the case where a manager already has 4 subordinates . Intuitively. Bill. The first rule dictates that we must not duplicate data within the same row of a table.First Normal Form (1NF) sets the very basic rules for an organized database:   Eliminate duplicative columns from the same table. this concept is referred to as the atomicity of a table.a table within a human resources database that stores the manager-subordinate relationship. Furthermore. the Subordinate1-Subordinate4 columns are duplicative. Joe" . when creating a list or spreadsheet to track this information.the Subordinate2Subordinate4 columns are simply wasted storage space (a precious database commodity). a second bright idea usually occurs to database novices: We don't want to have more than one column and we want to allow for a flexible amount of data storage. Take a moment and ponder the problems raised by this scenario. Within the database community. Clearly.what happens if she takes on another employee? The whole table structure would require modification. Create separate tables for each group of related data and identify each row with a unique column (the primary key). At this point. Let's try something like this:   Manager Subordinates where the Subordinates field contains multiple entries in the form "Mary. Let's explore this principle with a classic example . we might create a table with the following fields:      Manager Subordinate1 Subordinate2 Subordinate3 Subordinate4 However. Tables that comply with this rule are said to be atomic. we'll impose the business rule that each manager may have one or more subordinates while each subordinate may have only one manager. What do these rules mean when contemplating the practical design of a database? It's actually quite simple. If a manager only has one subordinate .

What happens if we hire another employee named Jim? How do we store his manager-subordinate relationship in the database? It's best to use a truly unique identifier (such as an employee ID) as a primary key. However. our table is in first normal form! If you'd like to continue learning about normalization. Here's a table that satisfies the first rule of 1NF:   Manager Subordinate In this case. it complicates the process of selecting data from the database in future queries. That's not a big deal in this situation. what about the second rule: identify each row with a unique column or set of columns (the primary key)? You might take a look at the table above and suggest the use of the subordinate column as a primary key. In fact. .This solution is closer. but it also falls short of the mark. placing it in new table(s) and creating relationships between those tables. the data that we've chosen to store in our table makes this a less than ideal solution. each subordinate has a single entry. read the other articles in this series: Normalizing Your Database: Second Normal Form (2NF) Putting a Database in Second Normal Form Recall the general requirements of 2NF:   Remove subsets of data that apply to multiple rows of a table and place them in separate tables. These rules can be summarized in a simple statement: 2NF attempts to reduce the amount of redundant data in a table by extracting it. Now. the subordinate column is a good candidate for a primary key due to the fact that our business rules specified that each subordinate may have only one manager. Create relationships between these new tables and their predecessors through the use of foreign keys. Our final table would look like this:   Manager ID Subordinate ID Now. The subordinates column is still duplicative and non-atomic. What happens when we need to add or remove a subordinate? We need to read and write the entire contents of the table. but managers may have multiple entries. but what if one manager had one hundred employees? Also.

In a 2NF-compliant database structure. but imagine the wasted space if we had thousands of rows in our table. Someone taking an order might have asked you for your ZIP code first and then knew the city and state you were calling from. Imagine an online store that maintains customer information in a database. . Our new table (let's call it ZIPs) might have the following fields:    ZIP City State If we want to be super-efficient. Now. we've satisfied the first rule of second normal form. NY 11579" and "Miami. We still need to use a foreign key to tie the two tables together.Let's look at an example. Here's our new Customers table:      CustNum FirstName LastName Address ZIP We've now minimized the amount of redundant information stored within the database and our structure is in second normal form! Normalizing Your Database: Third Normal Form (3NF) Putting a Database in Third Normal Form Third normal form (3NF) is a database principle that allows you to cleanly organize your tables by building upon the database normalization principles provided by 1NF and 2NF. Surely. that might not seem like too much added storage in our simple example. They might have a single table called Customers with the following elements:        CustNum FirstName LastName Address City State ZIP A brief look at this table reveals a small amount of redundant data. we'd need to make that change in many places throughout the database. you've encountered a situation where this type of database was utilized. Additionally. We're storing the "Sea Cliff. FL 33157" entries twice each. Now that we've removed the duplicative data from the Customers table. We'll use the ZIP code (the primary key from the ZIPs table) to create that relationship.the post office provides a directory of all valid ZIP codes and their city/state relationships. if the ZIP code for Sea Cliff were to change. This type of arrangement reduces operator error and increases efficiency. this redundant information is extracted and stored in a separate table. we can even fill this table in advance -.

There are two basic requirements for a database to be in third normal form:      Already meet the requirements of both 1NF and 2NF Remove columns that are not fully dependent upon the primary key. Second Normal Form (2NF) • Meet all the requirements of the first normalform. Normalization Stages 7. First Normal Form (1NF)• The values in each column of a table areatomic (No multi-value attributes allowed).     5. Normalization Stages• 1NF• 2NF• 3NF• 6. .   8. NORMALIZATION IN DATABASE ABOUT NORMALIZATION• Normalization is the process of efficiently organizing data in a database.• Two goals of normalization process:     Eliminating Redundant Data  Ensuring data dependencies• The objective is to isolate data so that changes of a field can be made in just one table and then propagated through the rest of the database using the defined relationships.  • Each table has a primary key: minimal set of attributes which can uniquely identify a record  • There are no repeating groups: two columns do not store similar information in the same table.

   9.     14.   • Remove columns that are not dependent upon the primary key. Third Normal Form (3NF) • Meet all the requirements of the second normal form. TRANSFORMATION FROM UNF TO HIGHERNORMAL FORMS USING AN EXAMPLE•  Example: Institution Having Two departments– Each Department Has 6 Different Students And SomeCourses– Each Student in a department can study more than one Course– Each course has its course fee. 11. • Remove subsets of data that apply to multiple rows of a table and place them in separate tables  .– Periodically. directly dependent) on every super key of R.e. report is generated that contains information displayed which can be represented in a table as shown in next slide. • Every non-prime attribute of R is non-transitively dependent (i. Conversion to 1st Normal Form 15. Conversion To 1st Normal Form – ADVANTAGES • Each table has at least one minimal set of attributes which can uniquely identify a record    • The values in each column have Single Value– DISADVANTAGES • Redundant data across multiple rows of the table is still there .• Create relationships between these new tables and their predecessors through the use of foreign keys.

Stud_age}{Dep No. Dep_name} . Course_name. Stud No . Stud_name. {Dep No. {Stud no. Stud_name.Course name} . Conversion to 3rd Normal Form• Advantages:– No non-key attribute depends transitively on a candidate key– All The attributes in a table Depend on a single primary key .– Some records depend on attributes other thant he tables primary key  19. Stud_DOB. Course_fee}Department Details:Course Details: Student Details:        18. Conversion to 2nd Normal Form• Advantages– eliminates redundant data in the table– It includes no partial dependencies:– Create separate tables for sets of values that apply to multiple records• Disadvantages The table contains Transitive Dependencies. Course_fee}     20. Conversion to 2nd Normal Form{Dep No.Stud_DOB} . Dep_name}{Stud no. {Course_name.  • Existence of partial and transitive dependencies 16. Stud No . The Dependency diagram – Depicts all dependencies found within given table structure– Helpful in getting bird’s-eye view of all relationships among table’s attributes– Makes it less likely that will overlook an important dependency  17. Conversion to 3rd Normal Form Student Details:Department Details:Course Details:Student course:{Dep No.