Building Customer Conformed Dimension
2 posters
Page 1 of 1
Building Customer Conformed Dimension
Hi guys,
I have two source system which has customer information. But in dwh I should create a just one dimension ( conformed dimension ) which holds the all customer for that company.
Some of the customers can be existed in both source system. Some of them are existed in just one system.
What are the best practices of combining two customer source tables into the one dimension table ?
Thanks.
I have two source system which has customer information. But in dwh I should create a just one dimension ( conformed dimension ) which holds the all customer for that company.
Some of the customers can be existed in both source system. Some of them are existed in just one system.
What are the best practices of combining two customer source tables into the one dimension table ?
Thanks.
ozisamur- Posts : 30
Join date : 2014-10-27
Re: Building Customer Conformed Dimension
1. Decide on a mechanism that can reliably deduplicate your customer records - assuming that your customers are individuals then duplicating on first and last name would obviously not be a reliable mechanism.
2. There are other approaches to this, but I would make up a business key for my customer dim and then create a cross reference table that links my source business keys to my generated business key. Having decided that a source customer record matches a record in the customer dim (or it doesn't and you create a new customer dim record), you enter this data in the cross-reference table and then in subsequent data loads you can check this table first and if a record exists for your source record then you can just pick up the Dim business key and you don't have to go through the de-duplication process each time.
3. For every customer attribute, decide which of your source systems is the master (or possibly that all of them are) and then design your ETL so that an attribute in your customer dim only gets updated if it is changed in the master source.
2. There are other approaches to this, but I would make up a business key for my customer dim and then create a cross reference table that links my source business keys to my generated business key. Having decided that a source customer record matches a record in the customer dim (or it doesn't and you create a new customer dim record), you enter this data in the cross-reference table and then in subsequent data loads you can check this table first and if a record exists for your source record then you can just pick up the Dim business key and you don't have to go through the de-duplication process each time.
3. For every customer attribute, decide which of your source systems is the master (or possibly that all of them are) and then design your ETL so that an attribute in your customer dim only gets updated if it is changed in the master source.
nick_white- Posts : 364
Join date : 2014-01-06
Location : London
Similar topics
» Merging customer data from disparate sources to create a master customer dimension
» De-normalizing Customer Information to create a Customer Dimension
» Conformed Fields or Snowflake? - Shop and Customer Location
» Hot swappable dimension and conformed dimension usage (bank/ credit union)
» Replacing Aggregate dimension with Conformed base dimension at lowest level.
» De-normalizing Customer Information to create a Customer Dimension
» Conformed Fields or Snowflake? - Shop and Customer Location
» Hot swappable dimension and conformed dimension usage (bank/ credit union)
» Replacing Aggregate dimension with Conformed base dimension at lowest level.
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum