As long as the keys are in a sorted order from month to month (they can be out of order within a month, but not cross month boundaries) it will work (though you should modify the date dimension data population to guarantee this — its a very good design practice). If this is not the case, you would be best to redesign it to be such as the gains will likely be quite significant given partition elimination.

I’d recommend reading up on these Kimball Design Tips:

• Kimball Design Tip #2: Multiple Time Stamps
• Kimball Design Tip #5: Surrogate Keys for the Time Dimension
• Kimball Design Tip #51: Latest Thinking on Time Dimension Table
• Kimball Design Tip #85: Smart Date Keys to Partition Fact Tables

The surrogate keys are just numbers, so 2010-01-01 could be 245 and 2010-02-01 : 263 etc.

And because they are generated from a sequence there is no guarantee thet the key for a date has an relation to it’s date sequence.

So I’m not sure your example applies in this scenario.

For 1 month partitions you can use range partitioning and use the date key for first day of the next month as the “values less than” value.

For example:
create table fact ( ... )
partition by range(date_key) (
partition p200912 values less than({date_key for 2010-01-01}),
partition p201001 values less than({date_key for 2010-02-01}),
partition p201002 values less than({date_key for 2010-03-01}),
...)

Hard code surrogate keys for list partitioning, just partition by day surrogate key (and ignore the month) or something else?

Thanks,
Paul

To quote the link from the Oracle Documentation from my previous response:

A bitmap index should be built on each of the foreign key columns of the fact table or tables

so, if you desire star transformation, then both FK columns on the fact table require bitmap indexes.

The date column can be represented by a number which is the key to the time/date dimension so it is ok to use this for the partitioning key. Oracle can use subquery pruning or bloom filters to first get the list of values from the time/date dimension and use that to get partition pruning.

The indexes you create should be to solve a problem. You have not stated what you are trying to solve so I really can not make any index recommendations. It’s like asking “should I go to the doctor”? The answer depends on if you are sick or not, and you have not provided enough detail to determine this.

My question is that as in a dimensional model, there are certain dimension tables and then there is a fact table. In the fact table, there are foreign keys from the dimensions and then there are fact columns:

e.g.

SQL> DESC Customer_Fact

Customer_Fact_pk ——–> Surrogate Key
Customer_Transaction_Date_fk ——–> Foreign Key from the Time dimension
Customer_Region_fk ———–> Foreign Key from the Region dimension
Amount—–> additive fact

Now please correct/validate me on the following point:

we should create bitmap indexes on Customer_Transaction_Date_fk and Customer_Region_fk columns.

What sort of index should we create on Customer_Fact_pk and Amount column?

Should we range partition this fact table on Customer_Transaction_Date_fk? But as this column contains number and not a date, so should we include the date column also in the fact table and partition the table on that date column?

Thanks and best regards

Fahd

Q: Should tables loaded by time have the time key as the partition key?
A: The partition key should be the column that represents when the event happened and is frequently used in the predicate of queries so partition pruning/elimination can be leveraged. E.g. How much was sold yesterday (or last Tuesday) can prune to 1 day or 1 month, etc.

Q: Should the fact table FK columns have bitmap indexes on them?
A: If your design is to leverage star transformations, then yes. Read more.

Q: Should indexes be local prefixed b-tree?
A: Possibly. Indexes should have a design that solves a problem. E.g. Use what design is necessary to get the execution plan you desire, but if you are using star transformation, then it is unlikely you will have any other indexes other than the FK bitmaps.

Q: Should stats be gathered after every load with DBMS_STATS.AUTO_SAMPLE_SIZE?
A: Stats should be gathered where there are none or they are stale. If on 11g, then yes, else generally yes, but there may be exceptions (read more).

Almost all the times, fact tables in the data warehouses should be partitioned. If the data is loaded w.r.t time then the partition key should be the date column. All the foreign keys in fact table should have bit map indexes upon them. Local prefixed indexs should be created on the partitions haveing the partition key at the leading edge, and these indexes should be B Tree. Stats should be gathered after every data load and the estimate size should be DBMS_STATS.AUTO_SAMPLE_SIZE.

Thanks and regards