Why do we have to normalize? While normalization may be boring, it is not near as boring as redoing an entire database after one week of actual use. What would happen if as soon as all of the necessary modeling had been handled by the design team, and they took what they knew and put that information directly into a program like Microsoft Access for use? Well, even if the plan worked in the beginning, sooner than later Anomalies most certainly would creep into the information and leave the database rendered completely with out use.
Anomalies are caused when there is too much redundancy in the database's information. Anomalies can often be caused when the tables that make up the database suffer from poor construction. So, what does "poor construction mean?" Poor table design will become evident if, when the designer creates the database, he doesn't identify the entities that depend on each other for existence, like the rooms of a hotel and the hotel, and then minimize the chance that one would ever exist independent of the other.
The normalization process was created largely in order to reduce the negative effects of creating tables that will introduce anomalies into the database.
There are three types of Data Anomalies: Update Anomalies, Insertion Anomalies, and Deletion Anomalies.
Update Anomalies happen when the person charged with the task of keeping all the records current and accurate, is asked to change an employee’s title due to a promotion. If the data is stored redundantly in the same table, and the person misses any of them, update anomalies and other undesirable things will start to show up.
Insertion Anomalies happen when inserting vital data into the database is not possible because other data is not there. An example of this could be, if a clerk needed to add customer information for a new customer who has not yet made a purchase yet.
Deletion Anomalies happen when the deletion of unwanted information causes wanted information to get deleted as well.