I design chain store and product list, which is many to many relationship, it seems the data redundancy is huge. For example, if I consider Walmat, Carrefour as stores, which have 200 items to sell. I have only 400 items to list. If I consider Walmat Shanghai as one independent store from Walmat Beijing, then we got double. So geolocation-sensed design will increase the data very quickly. The reason I design geo-based database, because supermarket is always regional orientated, in most of time, they don’t share the same product list.

If I consider the system to serve more than 100 chain store, which have 10~100 stores in China, each one has listed 1000 product items. The data is huge, huge data redundancy and tough work for data uploading.

Any good ideas ?

We also do projects, especially data migration, ETL, data warehouse design, develop and implementation. As well as, analytic and reporting.

Feel free to contact me: ranazafarullah @ hotmail . com

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