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

 

 


 

 

 

 

 

 
 

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

 

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.