Customer Dimension is always needed?
5 posters
Page 1 of 1
Customer Dimension is always needed?
Hi,
I've been struggling for new data model.
first time i made customer dim, but after making mini dimensions I coulnd't find any valuable attributes in Customer dimension.
(i have CustomerDemographics Dim, CustomerIncomeProfileDim, CustomerCreditProfileDim)
We have customer management number in OLTP system. we can identify the individual by that number.
It is unique and never changed
If I remove customer dimesion and use this number as degenerated dimension key, is it wrong?
any comments will be helpful. thank you.
I've been struggling for new data model.
first time i made customer dim, but after making mini dimensions I coulnd't find any valuable attributes in Customer dimension.
(i have CustomerDemographics Dim, CustomerIncomeProfileDim, CustomerCreditProfileDim)
We have customer management number in OLTP system. we can identify the individual by that number.
It is unique and never changed
If I remove customer dimesion and use this number as degenerated dimension key, is it wrong?
any comments will be helpful. thank you.
eunyoung hwang- Posts : 5
Join date : 2011-06-21
Re: Customer Dimension is always needed?
It is not wrong to leave out information that has no reporting value.
BoxesAndLines- Posts : 1212
Join date : 2009-02-03
Location : USA
Re: Customer Dimension is always needed?
Agree with B&L, but I am skeptical that you don't need individual customer details like names and DOB in a DW. Normally you do need a customer dimension with corresponding attributes even if you have mini-dimensions as you may need to drill down to detail levels and it is not recommendable to drill across between DW and OLTP systems.
hang- Posts : 528
Join date : 2010-05-07
Location : Brisbane, Australia
Re: Customer Dimension is always needed?
Hi eunyoung,
From my understanding of the Kimball method, you should always generate a Customer Surrogate Key, and not rely on your OLTP system. There are many reasons to do this, probably the best is: to cater for merging "Customer" data from other sources in the future, which may have different keys, or may not be as clean/reliable as your current OLTP system.
Good luck!
Mike
From my understanding of the Kimball method, you should always generate a Customer Surrogate Key, and not rely on your OLTP system. There are many reasons to do this, probably the best is: to cater for merging "Customer" data from other sources in the future, which may have different keys, or may not be as clean/reliable as your current OLTP system.
Good luck!
Mike
Re: Customer Dimension is always needed?
I think what is being asked is the fundamental difference between a data warehouse and a data mart.
From an enterprise perspective, if you were building a data warehouse, you would include all aspects of the customer that your entire organization is aware of. The fact that the operational systems provide a customer number means that somewhere in the organization are people concerned about individual customers.
However, from a departmental perspective, such as Marketing, they are usually not so much interested in individuals, but rather demographic groups. Esentially, an aggregate data mart.
Best practice is to create a data warehouse and source the aggregate from the data warehouse. So, reducing the customer grain to demographics is fine from a departmental perspective. Wither it is ok to source this from the operational system is another discussion.
From an enterprise perspective, if you were building a data warehouse, you would include all aspects of the customer that your entire organization is aware of. The fact that the operational systems provide a customer number means that somewhere in the organization are people concerned about individual customers.
However, from a departmental perspective, such as Marketing, they are usually not so much interested in individuals, but rather demographic groups. Esentially, an aggregate data mart.
Best practice is to create a data warehouse and source the aggregate from the data warehouse. So, reducing the customer grain to demographics is fine from a departmental perspective. Wither it is ok to source this from the operational system is another discussion.
Similar topics
» Merging customer data from disparate sources to create a master customer dimension
» De-normalizing Customer Information to create a Customer Dimension
» Mini Dimension Needed?
» Customer Ship to Vs Customer Dimension
» Abstract Generic Dimension - Help Needed
» De-normalizing Customer Information to create a Customer Dimension
» Mini Dimension Needed?
» Customer Ship to Vs Customer Dimension
» Abstract Generic Dimension - Help Needed
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum