Download eBook (PDF) - Red Gate Software

3 – Schema Architecture StrategiesFigure 3-6: Borrower table to Borrower_Income table relationship.As a DBA you might find yourself, one fine day, troubleshooting theBorrower_Income table in this database. The table is opened and within it isincome information for all borrowers. Since the table has been effectivelynormalized, the only data that is disclosed will be a series of rows containingmoney values, each associated with a numeric foreign key, referring to theBorrower_Employee table. If the table were not normalized, it is likely thateach piece of income data in the table would have the borrower's name next toit, disclosing confidential and identifying data. In addition, you could make afair bet that the borrower's federal tax identification number would be there too!Normalization and the Borrower_Identification tableLet's now take a look at the Borrower_Identification table, depicted inFigure 3-7, and consider its use of normalization.Figure 3-7: The Borrower_Identification table.This table's design is unique in that the Identification_Value column isused to store various values that are used to validate identity, such as federalidentification number, passport number and driver's license number. TheIdentification_Type_ID column is a foreign key to a reference tablecalled Identification_Type. It is the Identification_Type_IDcolumn that differentiates these values for each row.68