BC remote Oracle DBA - Call (800) 766-1884
Free Oracle Tips

Oracle Consulting Oracle Training Development

Remote DBA

 

Remote DBA Plans
Remote DBA Service

 
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 Internals Magazine
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





   

 

 

 

 
 

Oracle Tips 

by Burleson Consulting

The Data Warehouse Development Life Cycle

The Role Of Functional Decomposition
The principles of top-down analysis tells us to begin our data flow diagram (DFD) at a very general level. The entire system is viewed as a single process, and this view is called a Context Level DFD. Next, the DFD is decomposed, and levels of detail are added to the model. Any process that can be identified can probably be subdivided to smaller processes, and it is possible to decompose a DFD to the level where each process represents a single statement. An extreme example of functional decomposition would be showing a statement such as add 1 to counter as a separate process on the data flow diagram. The pivotal question is: At what point should the developer stop decomposing the processes?

Theoreticians such as Gane and Sarson tell us that a DFD should be decomposed to the functional primitive level, where each process bubble performs one granular function. Under this definition, one could consider that the place_an_order behavior performs only one function and is therefore a functional primitive process. A good rule of thumb for data warehouse analysis, especially when the warehouse is intended to be used with a relational database, is that a DFD should be decomposed to the level where each process corresponds to an SQL operation. This allows the use of triggers within a relational database and greatly simplifies the data warehouse design.

As you are probably beginning to see, the level of partitioning is critical for a successful data warehouse systems analysis. Let’s explore this concept of partitioning a little further. In a traditional systems analysis, the place_order behavior is sufficiently partitioned, whereby the place_order process would become a single computer program. This program would perform all of the data manipulation and would have many DML verbs embedded within the code (see Figure 3.4). Following is what the mini-spec might look like for a place_order process:


This is an excerpt from "High Performance Data Warehousing". To learn more about Oracle, try "Oracle Tuning: The Definitive Reference", by Donald K. Burleson.  You can buy it direct from the publisher at 30% off here:
http://www.rampant-books.com/book_1002_oracle_tuning_definitive_reference_2nd_ed.htm
 

 


Expert Remote DBA

BC is America's oldest and largest Remote DBA Oracle support provider.  Get real Remote DBA experts, call
BC Remote DBA today.

 

 

Remote DBA Service
 

Oracle Tuning Book

Free Oracle dictionary reference poster

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

North Carolina Oracle Users Group

 

 Arabian horse breeder

Seeing eye horses

 

 

Burleson is the American Team

American Flag

 

 

BC Remote Oracle Support
P.O. Box 511 • Kittrell, NC, 27544

Remote DBA

Remote DBA Services

 

Copyright © 1996 -  2011 by Burleson Enterprises. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.