I am contributing towards designing a retail datawarehouse. the functional areas include stores, CRM, merchandising, category management etc. I need help in the dimensional modelling phase. Can anyone help please??

http://www.amazon.com/Dimensional-Data-Warehousing-MySQL-Tutorial/dp/0975212826/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1218569860&sr=8-1

i need a help. I have table from my professor and i am not getting what to do here. pls anyone can help and e-mail me for conatct at nir_prince@hotmail.com will be appriciated.

pls someone help me.

Nirav

Bobby,
In some cases it helps to point out that the Data Mart contains processed and transformed data – and replacing NULLS with alternate value can be considered a transformation.

Also, if you are making a Mart/Warehouse, it is extremely important to keep a detailed and updated Data Dictionary. These default values, etc. can be noted down against the respective columns in the Data Dictionary. A common IT Management apprehensions is that the knowledge (of default values, say) would be lost once the concerned resources are no longer around. This apprehension can be addressed to some extent by keeping the Data Dictionary updated, relevant, available and utilized.

Nisrith’s comment on setting a NULL value is also what I had described you would likely want to / need to do. To clarify my statement (and your question), since a row in the fact table has a multi-part key, you MUST have a legitimate value for the Promotion Id key, otherwise you have no choice but to NOT load the row in the fact table to maintain integrity.

Final thought on the “bad practice” of setting default values. Sounds like your clients are concerned about setting a default value when the quality of the source data is unknown. In other words, the product may or may not have been promoted – no one knows for sure. In this case, it is ok to set a value that means “unknown” vs. “not promoted”. In this way, you can always create a report listing of rows with “unknown” for follow-up resolution with the source.

Mike

You have correctly pointed out that when you make a report by a particular dimension (say promotion_id), then the report will not show data for records in the fact table having promotion_id column as blank.

This is a common enough situation, and the solution you have recommended to clients is almost always the right solution (use default values, say NULL, with a corresponding row in the Promotions dimension table).

Outer joins are expensive, and you definitely do not need multiple star-schemas.

I can understand some of the clients being apprehensive, and its upto you to educate them and keep reminding that the data warehouse is unlike any other database they have dealt with in small, yet very critical, ways.

The differences between OLTP and OLAP systems need to be understood by IT Management to roll out the best solutions instead of blindly following dogmas that are only for OLTP solutions. For example, a banking system database would need to be backed up at least daily, whereas a data warehouse with only a monthly batch refresh of data does not need a daily backup.

Thank you for the answer…

however I am not understanding why you say that “if a store is not running a Promotion on a given product during a given day/week you won’t have a row (transaction) in the fact table”

In my understanding if the store sold a product with no promotion then there would in fact be a row (transaction) in the fact table – it would have valid values for other measures including store_id, customer_id, product_id, etc.

Again my understanding is that one could measure sales across any of these dimensions. So I might have a report for sales by store_id or sales by product_id.

I would want to see my row from the store that does not have a promotion id in these reports.

However I am still left with two choices when I go to add the dimension of promotion id;

1. Left outer join between fact and promotion id table

2. not picking up the row (transaction) or rows that don’t have a promotion id

both seem bad options so my recommendation to clients is often to use a default value.

however many clients have refused this recommendation as bad practice (i.e. inserting a value when no value was present on the source data).

I am just wondering if there is one “best practice” way to do this when assembling star schemas.

Thanks again

bobby