17.07.2015 Views

Download eBook (PDF) - Red Gate Software

Download eBook (PDF) - Red Gate Software

Download eBook (PDF) - Red Gate Software

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

3 – Schema Architecture StrategiesNormalization and Data <strong>Red</strong>undancyWhen a database is well normalized, the occurrence of repeating informationthroughout the database is reduced or eliminated. This, in turn, reduces oreliminates the likelihood that data is updated in one place and not another,thereby introducing inconsistencies. Consider, for example, a store that sells T-shirts. This store may have many types of shirts in their inventory, from manysuppliers. If their database was not normalized they would likely have thesupplier's address in each row of their inventory. When a supplier notifies themof a change of address they would need to update every row that contained theold address. This difficult task will be made worse by the fact that it is probablethat the address was recorded inconsistently throughout the database, and so it'slikely that some instances will be missed.If their database was normalized, the address information for each supplierwould be maintained in a single location in the database, most likely in a"supplier address" table, related to the supplier table. This would result inconsistency in the address information, elimination of the need to continuallyenter the address information, and would make the address change process asnap.Normalization and Data SecurityFor security purposes, the reduction in data redundancy provides anenvironment that can be managed in a more effective manner. Furthermore, theseparation of sensitive information from identifying information reduces thevalue of the sensitive information to the potential data thief, and provides adegree of obscurity to the casual, yet authorized, viewer.Consider the following example from our HomeLending database, illustratedin Figure 3-6. The Borrower table has a one-to-many relationship to theBorrower_Employer table. This design lets us capture each employer thatthe borrower lists on their application. The borrower's income data is stored ina separate table, called Borrower_Income, and is related to theBorrower_Employer table.67

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!