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

Aggregating Data For The Oracle Warehouse
Using SQL To Create Summary Tables

If we created a metadata table that contained each possible dimension, it would be easy to write a PL/SQL routine to dynamically re-create and populate the 45 summary tables that are required. The pseudo-code for such a routine might look something like this:

    SELECT dimension_name FROM dimensions ORDER BY dimension_name;
FOR EACH outer_dimension
   FETCH c1 INTO dimension_one;
   SELECT dimension_name FROM dimensions ORDER BY dimension_name;
   FOR EACH inner_dimension
   FETCH c2 INTO dimension_two;
   CALL create_SQL (dimension_one, dimension_two);
   NEXT inner_dimension
NEXT outer_dimension

In this fashion, we could create all 45 summary tables each night immediately after our new values have been loaded. But will all of these tables be needed by our end users? Because a complete pre-calculation of 45 tables is not an overwhelming task, we may decide that we can afford to have all possible summary table combinations available to our end users.

On the surface, it appears that SQL can be used against two-dimensional tables to handle three-dimensional time-series problems. It also appears that SQL can be used to roll up aggregations at runtime, alleviating the need to do a roll up at load time, as with a traditional database. While this implementation does not require any special multidimensional databases, the following two important issues remain to be resolved:

* Performance--Joining a table against itself (especially when comparing ranges of dates) may create many levels of nesting in the SQL optimization resulting in poor response time.

* Ability--No end user would be capable of formulating this type of sophisticated SQL query.

If you strip away all of the marketing hype and industry jargon, you can see that a data warehouse and a multidimensional database can be easily simulated by pre-creating many redundant tables, each with pre-calculated roll-up information. In fact, the base issue is clear--complex aggregation needs to be computed at runtime or when data is loaded.

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:


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.