Customer Dimension Modeling - Level attribute
2 posters
Page 1 of 1
Customer Dimension Modeling - Level attribute
Hi,
I am in the process of designing loyalty customers transactions data mart. Now, I need to create Customer Dimension, here each customer will have their own unique ID, and based on their transaction points they will be moved to different levels like from Level 1 to Level 2 and so on. So the levels will be changed periodically. In this case, what should I do? should I create customer dimension as slowly changing dimension (then customer key will change) or Should I keep separate Customer-Level (relationship table between customer and level) with slowly changing dimension? Please advise me.
Thanks,
Mani
I am in the process of designing loyalty customers transactions data mart. Now, I need to create Customer Dimension, here each customer will have their own unique ID, and based on their transaction points they will be moved to different levels like from Level 1 to Level 2 and so on. So the levels will be changed periodically. In this case, what should I do? should I create customer dimension as slowly changing dimension (then customer key will change) or Should I keep separate Customer-Level (relationship table between customer and level) with slowly changing dimension? Please advise me.
Thanks,
Mani
Manivannan- Posts : 1
Join date : 2013-09-09
Re: Customer Dimension Modeling - Level attribute
Ok, levels change. So do other things about the customer. Creating a type 2 dimension only matters if you want to keep history.
Do you? And if so, what do you want history of? All customer attribute changes or just the customer level? And what are they going to do with it?
There are a lot of ways to keep history:
1. Type 2 dimension. Gives you full history. And yes, the PK changes. So what? Everybody seems to think that is a problem. It isn't. Its a very useful feature.
2. Type 3 dimension. Keep some fixed # of generations of history for a few attributes. Simple, can be effective.
3. Maintain a history of states as a fact table. Keep current in a type 1 customer dimension for ease of use. Customer/Date/Level. Useful for tracking customer movement, but not a whole lot else.
Do you? And if so, what do you want history of? All customer attribute changes or just the customer level? And what are they going to do with it?
There are a lot of ways to keep history:
1. Type 2 dimension. Gives you full history. And yes, the PK changes. So what? Everybody seems to think that is a problem. It isn't. Its a very useful feature.
2. Type 3 dimension. Keep some fixed # of generations of history for a few attributes. Simple, can be effective.
3. Maintain a history of states as a fact table. Keep current in a type 1 customer dimension for ease of use. Customer/Date/Level. Useful for tracking customer movement, but not a whole lot else.
Similar topics
» Customer snapshot
» Modeling an attribute that belongs in more than one dimension
» Modeling the Customer Dimension
» Customer Dimension Modeling Question
» Merging customer data from disparate sources to create a master customer dimension
» Modeling an attribute that belongs in more than one dimension
» Modeling the Customer Dimension
» Customer Dimension Modeling Question
» Merging customer data from disparate sources to create a master customer dimension
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum