Normalization Normalization: Fourth Normal Form Pg 1

Transcription

1 Normalization Normalization: Fourth Normal Form Pg 1 Normalization: Fourth Normal Form Ray Lockwood Points: A table is in Fourth Normal Form if it doesn't have two or more independent Dependencies (MVD). The table must also be in all the lower Normal Forms. A 4NF problem is fixed by decomposition. History The Fourth Normal Form was introduced in 1977 by an IBM researcher named Ronald Fagin 1, who still works for IBM in San Jose, California. The lower Normal Forms (Second, Third, and Boyce-Codd) have to do with bad functional dependencies. Forth Normal Form is different because it addresses a Dependency (MVD). The problem solved by the Fourth Normal Form stems, as expected, from two objects in the same table. The Fourth Normal Form says there must not be two or more independent Dependencies in the same table. Let s see what this means. Ron Fagin then IBM was prolific in advancing the theory of the relational database. A Fourth Normal Form Problem Two Dependencies What happens when we have two independent dependencies in the same table? Here s the table for a bank which shows savings plan types and checking account types that belong to each customer: 845 SuperSaver MoneyMarket 845 CD FreeChecking This table has two redundant pairings of values. The same value of CustomerId is paired with SavingsPlan and CheckingAcct over and over. 1 Photo from

2 Normalization Normalization: Fourth Normal Form Pg 2 A glance at CustomerId 845 in the table tells you that something s not right. Why are all those account types repeated so many times? There's a redundancy problem in this table. Examining the Table A customer may open several types of savings plans, and have several types of checking accounts, so there are two dependencies: CustomerId SavingsPlan CustomerId CheckingAcct Savings plan and checking account are independent of each other. Savings Customer Checking This is the problem: The two independent dependencies are separate objects. Notice that the attributes in the two dependencies are independent of each other. SavingsPlans have nothing to do with CheckingAccts. Our table is already pretty well normalized: 1. First Normal Form because individual attributes are atomic and non-repeating. 2. Second Normal Form because there are no partial-key dependencies (the row is all key). 3. Third Normal Form because there are no transitive dependencies (the row is all key). 4. Boyce-Codd Normal Form because it has no non-key determinants (the row is all key). Yet, redundancy exists that will cause modification anomalies. Will Fewer Rows Work? Let s keep the data but with fewer rows. One row can have SuperSaver paired with FreeChecking, and another can have CD paired with MoneyMarket. This is misleading it implies that the customer uses his SuperSaver account only while using FreeChecking, and uses his CD account only while using his MoneyMarket account: The SavingsPlan paired with the CheckingAcct is a meaningless fact. You have to include every attribute of the table in the key, anything less isn't unique. If every attribute is in the key, there can be no non-key functional dependencies. There is no way to make the two independent objects get along with each other. A pairing of attributes creates a connection between the two. Remember, pairing establishes a fact.

3 Normalization Normalization: Fourth Normal Form Pg 3 This isn t logical because of the meaningless pairing of SavingsPlan and CheckingAcct. A savings plan and a checking account are completely independent of each other, so we must store every combination of the two to avoid meaningless pairing of attributes. Will a Disjoint Representation Work? Let s try storing a either a SavingsPlan or a CheckingAcct in a row, but not both (that s what disjoint means). That will get rid of the meaningless pairing. Uh-oh! We end up with many NULLs which is bad, and now it's impossible to find a primary key. (Keys can't contain NULL): 619 SuperSaver 619 FreeChecking 731 CD 731 MoneyMarket 845 SuperSaver 845 CD 845 FreeChecking 845 MoneyMarket No column alone is unique, and no combination of columns is free of Nulls. A primary key can't contain Nulls, so we can't make a primary key from these columns. What Happens When We Add a Row? Back to the original table. Suppose customer 845 opens a new BonusPoints checking account, and we add a new row to our table: 845 SuperSaver MoneyMarket 845 CD FreeChecking 845 CD BonusPoints Now the table implies that the customer uses the BonusPoints checking account only when using the CD savings account. More meaninglisss pairing.

4 Normalization Normalization: Fourth Normal Form Pg 4 To be consistent, we need to add a row for all other savings plans that belong to this customer so they can be paired with his new account. We had to add two rows to the table when we opened one additional account. This is an insertion anomaly: 845 SuperSaver MoneyMarket 845 SuperSaver BonusPoints 845 CD FreeChecking 845 CD BonusPoints This table has insertion anomalies caused by the independent dependencies. Anomalies and Redundancy There's too much updating to add a fact to the table; this is an insertion anomaly. There are corresponding deletion and update anomalies, too. Redundancy is abundant! The table tells us over and over that customer 845 has a SuperSaver savings account. When a fact appears once, that s all there is to say about it. We haven t been able to fix it; all representations we ve tried cause problems in maintaining the data. Two Objects in One Table The problem, as always, is that one table contains facts about two different objects: savings plans and checking accounts. A customer s savings plans have nothing to do with his checking accounts, and vice versa. Putting both of them in the same table makes it seem as though they re related. A dependency represents an object in the real world. If there are two independent dependencies, then there are two unrelated real world objects in the same table. The table is not in Fourth Normal Form. Each dependency is a separate object.

5 Normalization Normalization: Fourth Normal Form Pg 1 Solution: Decompose the Table To remove the dependency, we divide the table into two and move each dependency into its own table. One table matches customers to their savings plans, and the other matches customers to their checking accounts: CustomerSavings CustomerChecking CustomerID SavingsPlan 619 SuperSaver 731 CD 845 SuperSaver 845 CD CustomerID Checking 619 FreeChecking 731 MoneyMarket 845 FreeChecking 845 MoneyMarket 845 BonusPoints A dependency that occupies its own table is called a Trivial Dependency. It doesn't cause data redundancy. CustomerID SavingsPlan These are intersection tables that make two M:M relationships. Savings CustomerID CheckingAcccount Checking Each independent dependency must be isolated to its own table. Customer Once again we have a greater number of smaller tables, one for each object. Notice that the two new tables have no relationship between each other. This is how it should be: If accounts are independent of each other, then the tables should be independent of each other, too. What About Non-Independent Dependencies? In the tables above, there was no information contained in the pairing of the two dependencies they were completely independent of each other. However, there are cases in which two dependencies are not independent and the pairing between them is significant. There is such a thing as dependencies that are dependent on each other.

6 Normalization Normalization: Fourth Normal Form Pg 2 Here's a table that lists the States in which insurance companies do business, along with the products they sell in those states. Some companies offer a product in one state but not in another. For example, company 845 offers Nofault insurance in Florida but not in Georgia. The dependencies are not independent and must appear together in the same table: InsuranceProducts InsuranceCompanyId State Product 619 Florida Nofault 731 Georgia Indemnity 845 Florida Nofault 845 Florida SafeDriver 845 Georgia SafeDriver InsuranceCompanyId State InsuranceCompanyId Product State Product This pairing is significant. These three dependencies are all related to each other. Dependent Dependencies may occupy the same table without violating 4NF. In fact, Dependent Dependencies must occupy the same table to establish their relationship. This dependency provides the relationship between the other two. Here, the pairing of the dependencies is significant and conveys information. Since the dependencies are not independent of each other, they must appear in the same table to establish their relationship. This does not violate Fourth Normal Form. Essence of the Fourth Normal Form. A table should not contain two or more independent facts about a single entity. Fourth Normal Form Is Different From the Lower Forms The gist of the Second, Third, and Boyce-Codd Normal Forms is that a non-key attribute should not imply (determine) anything about any other attribute in a row. Fourth Normal Form is different because it's concerned with pairs of dependencies that slip past the functional dependency tests. The lower normal forms concern Functional Dependencies. 4NF concerns Dependencies.