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 Warehouse Analysis

Oracle Tips by Burleson Consulting

The Data Warehouse Development Life Cycle

Data Warehouse Analysis
Another major difference between analysis for OLTP systems and data warehouse systems lies in the descriptions of the user interface. In a traditional analysis, careful attention is given to the method the end user will implement when interacting with the system. In a data warehouse analysis, developers expect that most, if not all, queries against the warehouse will be ad hoc. As such, data warehouse developers have more interest in specifying the data for the warehouse than for specifying the data access methods.

Do not confuse the analysis of data access methods with the analysis of data query requirements. While you may not care what tool is used to extract queries from your warehouse, you should care very much about what types of queries will be executed against your warehouse. We will discuss this issue later in this chapter.

Another analysis issue comes into play because Oracle warehouse developers know in advance that they are using an Oracle database to implement the warehouse. Oracle, by virtue of being relational, is inherently flexible, and it is relatively easy to drop or add data columns to table structures. A consequence of this reality is that developers can often begin prototyping the data warehouse before a complete analysis of data sources has been completed. To demonstrate this flexibility, consider the following code where we quickly alter our fact table to drop one column and add another:

SQL > alter table fact drop column customer_type;
column dropped
SQL > alter table fact add column total_sale int;
column added.

Of course, the flexibility of the relational architecture is only useful when prototyping the warehouse. The final data items should be carefully considered before the initial rollout of the system because altering a very large table can cause a huge amount of table fragmentation in a production warehouse. To fully appreciate the differences between traditional systems analysis and data warehouse analysis, let’s review the analysis steps for both traditional data processing systems and data warehouses.

This is an excerpt from "High Performance Data Warehousing".
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.


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.