Вы находитесь на странице: 1из 34

Successful Dimensional Modeling of Very Large Data Warehouses

By Bert Scalzo, Ph.D.


Bert.Scalzo@Quest.com

About the Author


Oracle DBA from 4 through 8i Worked for Oracle Education Worked for Oracle Consulting Holds several Oracle Masters BS, MS and PhD in Computer Science MBA and insurance industry designations Articles in
Oracle Magazine Oracle Informant PC Week (now E-Magazine)

About Quest Software

Know Your Application


What type of application are you building:
On Line Transaction Processing (OLTP)

Operational Data Store (ODS)


On Line Analytical Processing (OLAP) Data Mart / Data Warehouse (DM/DW)

OLTP
Business Focus Operational

ODS
Operational Tactical

OLAP
Tactical

DM/DW
Tactical Strategic

End User Tools


DB Technology Trans Count Trans Size Trans Time Size in Gigs Normalization Data Modeling

Client Server Web


Relational Large Small Short 10 200 3NF Traditional ER

Client Server Web


Relational Medium Medium Medium 50 400 3NF Traditional ER

Client Server
Cubic Small Medium Long 50 400 N/A N/A

Client Server Web


Relational Small Large Long 400 - 4000 0NF Dimensional

Embrace New Concepts


Teach Old Dog New Tricks
Throw out any OLTP baggage Forget OLTP Golden Rules

Star Schema Design


Star schema approach to dimensional data modeling was pioneered by Ralph Kimball
Dimensions: smaller, de-normalized tables containing business descriptive columns that end-users query on Facts: very large tables with primary keys formed from the concatenation of related dimension table foreign key columns, and possessing numerically additive, non-key columns used for calculations during end-user queries

Facts

Dimensions

108th -1010th

103rd -105th

Transform OLTP Model


Fold OLTP model into itself to form a Star:
De-Normalize parent/child relationships

De-Normalize lookup relationships


Use surrogate or meaningless keys

Create and populate a time dimension


Create hierarchies of data in dimensions

OLTP Model

Dimensional Model

Dimension Hierarchies
SQL> select distinct levelx from dw_period;
LEVELX -------------------DAY MONTH QUARTER WEEK YEAR

SQL> select distinct levelx from dw_product;


LEVELX -------------------ALL PRODUCTS CATEGORY ITEM PSA SUB_CATEGORY

Avoid Snowflakes

Avoid natural desire to normalize model: Complicates end-user query construction Adds additional level of JOIN complexity Database optimizers do not handle very well Saves some space at the cost of longer queries

Snowflake Model

Common Aggregations
Build end-user driven aggregate tables: By time (e.g. week, month, quarter, year) By geographic regions (e.g. time zones) By end-user reporting interests (e.g. beer) By dimension hierarchy (e.g. product category) Aggregates should be 5 to 10 times smaller

Time Aggregates

Non-Time Aggregates

Index Design

All fact table, foreign key columns must have individual bitmap indexes on them

All dimension table, non-key columns should have individual bitmap indexes

10 B-Tree Indexes

48 Bitmap Indexes!!!

Key Fact Table Issues


Fact tables should: NOT create or enable foreign key constraints NOT create or enable table check constraints NOT create or enable primary/unique constraints (use unique indexes which offer parallel creation) NOT create or enable column check constraints (other than simple NOT NULL check constraints)

NOT create or enable row level triggers


NOT enable logging on tables or their indexes

No PK/UK/FK Constraints

Key Oracle Issues


Trust me no way to build large DW in Oracle 7.X Very brief overview in next few slides of: Partioning options Indexing options Comparative timings Tuning ad-hoc Star queries

Serial versus Parallel queries


Materialized Views

Oracle Partitioning
Way beyond the scope of dimensional modeling, but:

Use Range or List Partitioning using your time dimension


Fact unique index = local, prefixed b-tree index

Fact time index = local, prefixed bitmap index


Fact non-time index = local, non-prefixed bitmap index

If any non-time dimension provides a good locality of reference for typical user queries, then sub-partition on that dimension (i.e use 8is new composite partitioning)

TABLE

OBJECT

RELATIONAL

TABLE IN CLUSTER

TABLE IN TABLESPACE

ORG INDEX

ORG HEAP

TABLE NONPARTITION CLUSTER INDEX NONCLUSTER INDEX TABLE-IZED INDEX

TABLE PARTITION

INDEX NONPARTITION

INDEX NONPARTITION

INDEX NONPARTITION

INDEX NONPARTITION

INDEX PARTITION

INDEX NONPARTITION

INDEX PARTITION

GLOBAL

GLOBAL

GLOBAL

GLOBAL

GLOBAL

GLOBAL

GLOBAL

LOCAL

1. BTREE

2. BTREE

12. BTREE

4. BTREE

6. BTREE

7. BTREE

9. BTREE

10. BTREE

3. BITMAP

5. BITMAP

8. BITMAP

11. BITMAP

Indexing Options!!!

Oracle 8i Table Option Timings


Fact Implementation Regular Heap Table
Single Column Partition Multi Column Partition Composite Partition Index Organized Table

Timing
9,293 4,747 4,987 6,319 12,508

Partition Index 14,902 NOTE: specific to my data and user queries Organized

Tuning Star Queries


Way beyond the scope of dimensional modeling, but: Use Oracle 8.Xs Range Partitioning based upon your time dimension (do not try to use hash or composite partitioning)

Fact unique index uses local, prefixed b-tree index


Fact time index uses local, prefixed bitmap index

Fact non-time index use local, non-prefixed bitmap index

Typical User Query

Query: beer and coffee sales for November of 98 in Dallas

Best Explain Plan

Star Transformation

Oracle 8i Query Options


Explain Plan Serial, No Partition
Serial, with Partition Parallel, No Partition Parallel, with Partition

UNIX 9,688

NT

22,34 4 5,578 11,62 5


ORA600 ORA600

11,14 0

25,45 4

NOTE: specific to my data and user queries

Oracle 8i Materialized Views


Way beyond the scope of dimensional modeling, but : Special form of snapshots (i.e. replication) End-users direct all queries against detail table Optimizer rewrites queries to use best aggregate Optimizer suggests new aggregates based on load Eliminates need for numerous aggregation programs

Other DW Presentations
Optimizing Data Warehouse Ad-Hoc Queries against "Star Schemas Attendees will learn optimal techniques for designing, monitoring and tuning "Star Schema" Data Warehouses in Oracle 8.0 and 8i. While there are numerous books and papers on Data Warehousing with Oracle, they generally provide a 50,000 foot overview focusing on hardware and software architectures -- with some database design. This presentation provides the ground level, detailed recipe for successfully querying tables whose sizes exceed 500 million rows. Issues covered will include table and index designs, partitioning options, statistics and histograms, Oracle initialization parameters and star transformation explain plans. Attendees should be DBAs familiar with "Star Schema" database designs, have at least one years experience with Oracle 8.0, and some exposure to Oracle 8i. Optimizing Data Warehouse Loading via Parallelized Pro-C and SQL Attendees will learn optimal techniques for coding, monitoring and tuning parallel loading of Data Warehouses in Oracle 8.0 and 8i. While there are numerous books and papers on Data Warehousing with Oracle, they generally provide a 50,000 foot overview focusing on hardware and software architectures -- with some database design. This presentation provides the ground level, detailed recipe for high speed loading of tables whose sizes exceed 500 million rows. Issues covered will include database instance options, table and index designs, partitioning options, optimizer choices, plus Oracle initialization parameters. Attendees should be DBAs or senior developers familiar with Oracle 8.X, ProC and SMP or MPP UNIX environments.

THANK YOU FOR LISTENING