BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

 

   
 


Data Modeling Theory

Oracle Tips by Burleson Consulting

The Data Warehouse Development Life Cycle

Oracle Data Warehouse Design

Normalization And Modeling Theory

Let’s begin by briefly reviewing data modeling theory from a normalization perspective. It is interesting to note that Dr. Codd coined the term normalization in reference to current events of the day. At the time Dr. Codd was developing his mathematical rules for data redundancy, President Nixon was normalizing relations with China. Because Nixon was normalizing relations, Dr. Codd decided that he would also normalize relations as he refined his rules. (I’m not making this up!)

For database systems, a systems developer begins by taking raw, de-normalized relations from a systems analysis. Then, the developer takes the relations to third normal form and looks at the introduction of redundancy for improved performance. Of course, data redundancy becomes even more important for an Oracle warehouse developer than for a traditional OLTP designer, so we will carefully explore the options of table de-normalization in this chapter. In addition, we will also design a method for storing the pre-calculated data summaries that were defined in our systems analysis. Finally, as pointed out in the last chapter, we cannot always predict all the possible combinations of data attributes that will compose aggregate fact tables, so we must design a method for allowing our end users to dynamically define aggregation criteria and store the aggregate values into Oracle tables.

This text does not attempt to fully explore data normalization because dozens of texts are available for that purpose. Instead, this text offers a brief discussion of the normalization process as it applies to our example from Guttbaum’s Grocery. The processes of normalization was originally intended to be a method for decomposing data structures into their smallest components. The process begins with the original data structures which are called un-normalized relations, and progresses through first normal for to third normal form. At this stage the data structures are completely free of redundancy and are at their most decomposed level. To fully appreciate the process, let’s take a look at the successive process of normalization.


This is an excerpt from "High Performance Data Warehousing", copyright 1997.
If you like Oracle tuning, you may enjoy the book Oracle Tuning: The Definitive Reference , with over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it directly from the publisher and save 30%, and get instant access to the code depot of Oracle tuning scripts.

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.