View Part II
Paraphrasing E.F. Codd’s First Normal Form, it states that there should be, “No repeating groups”. The language column is the group in this example, below you will find the proposed design implements this rule, while the original design does not.
Original design
(Products table)
| ProductID | Name | English | Spanish | French | Italian |
| 1 | Ceramic tile | 1 | 0 | 0 | 0 |
Proposed design
(Products table)
| ProductID | Name | LanguageID |
| 1 | Ceramic tile | 1 |
(Language table)
| LanguageID | Name |
| 1 | English |
| 2 | Spanish |
| 3 | French |
| 4 | Italian |
Consider the original design and the proposed design above. The proposed design removes all of the hindrances that the original design put into place. Normalization frees the developer from handling issues, because those issues are simply not present.
Problem 1 solved: Suppose the business expands into a German speaking market, in the original design a column must be added and populated with a “0” for all current and subsequent records. In the proposed design, simply adding a fifth record to the language table is the only task that needs to be done.
Problem 2 solved: Keeping data clean is much simpler in the proposed design. If a product needs a different language, simply change the LanguageID field in the Product table. In the original design, this would, as best, involve altering data in two different columns.
Problem 3 solved: In the proposed design, there is no need to store data that is essentially keeps track of the language that the product is not. In the proposed design, if a product is not associated with a language, a record simply does not exist.
I hope this blog has shown the benefits of simple normalization. Making the decision to architect even your simplest of applications with normalization can guard against unforeseen complications, while keeping the focus on the business need.
Problem 1 solved: Suppose the business expands into a German speaking market, in the original design a column must be added and populated with a “0” for all current and subsequent records. In the proposed design, simply adding a fifth record to the language table is the only task that needs to be done.
Problem 2 solved: Keeping data clean is much simpler in the proposed design. If a product needs a different language, simply change the LanguageID field in the Product table. In the original design, this would, as best, involve altering data in two different columns.
Problem 3 solved: In the proposed design, there is no need to store data that is essentially keeps track of the language that the product is not. In the proposed design, if a product is not associated with a language, a record simply does not exist.
I hope this blog has shown the benefits of simple normalization. Making the decision to architect even your simplest of applications with normalization can guard against unforeseen complications, while keeping the focus on the business need.
No comments:
Post a Comment