Handling customers merged via MDM
2 posters
Page 1 of 1
Handling customers merged via MDM
Greetings!!!
I would really appreciate if you can shed some light on how we could handle these situations:
Situation #1:
Two similar customers exist in the customer dimension "ABC" & "ABC inc.". Both of these customers have sales entries in the sales fact. The MDM system identifies these two customers as duplicates and decides to merge the two customers into one - "ABC inc". What updates need to happen in the datawarehouse?
1. Inactivate "ABC" in the customer dimension.
2. For the entries in the sales fact that correspond to "ABC", update the customer dimension key to point to "ABC inc"
Is there an alternative design approach to handle this more gracefully? Perhaps, avoiding updates to the sales fact?
Situation #2:
Similar to above situation, the sales territory (geographic assignment of a customer to a territory) for a given customer "ABC Inc" can change from territory 101 to 102. How do we handle that?
Thanks in advance.
I would really appreciate if you can shed some light on how we could handle these situations:
Situation #1:
Two similar customers exist in the customer dimension "ABC" & "ABC inc.". Both of these customers have sales entries in the sales fact. The MDM system identifies these two customers as duplicates and decides to merge the two customers into one - "ABC inc". What updates need to happen in the datawarehouse?
1. Inactivate "ABC" in the customer dimension.
2. For the entries in the sales fact that correspond to "ABC", update the customer dimension key to point to "ABC inc"
Is there an alternative design approach to handle this more gracefully? Perhaps, avoiding updates to the sales fact?
Situation #2:
Similar to above situation, the sales territory (geographic assignment of a customer to a territory) for a given customer "ABC Inc" can change from territory 101 to 102. How do we handle that?
Thanks in advance.
contactkpatel- Posts : 1
Join date : 2015-05-13
Re: Handling customers merged via MDM
One thing to understand about MDM matching is it is not always correct. So, you need to take an approach that would allow for corrections.
To that end, never merge or rekey dimension entries in the DW, otherwise you will not be able to deal with corrections.
Store the MDM identification of the customer as an alternate key in the dimension table. Customer attributes coming from the MDM system would be updated against the dimension using the alternate key. If multiple rows apply to the same MDM id, all will have attributes set to the same value. It is these attribute values that will consolidate different customers into a 'merged' customer.
Same process with references and hierarchies, simply apply the update to all members with the same alternate key.
You do not remove dimension rows or alter fact table foreign keys.
To that end, never merge or rekey dimension entries in the DW, otherwise you will not be able to deal with corrections.
Store the MDM identification of the customer as an alternate key in the dimension table. Customer attributes coming from the MDM system would be updated against the dimension using the alternate key. If multiple rows apply to the same MDM id, all will have attributes set to the same value. It is these attribute values that will consolidate different customers into a 'merged' customer.
Same process with references and hierarchies, simply apply the update to all members with the same alternate key.
You do not remove dimension rows or alter fact table foreign keys.
Similar topics
» How to model merged donors
» Many-to-many attributes for Customers and DW design
» Percentage of customers from a district
» Supplier Dimension to include Customers & Employees
» Customers from 2 sources on different granulaties
» Many-to-many attributes for Customers and DW design
» Percentage of customers from a district
» Supplier Dimension to include Customers & Employees
» Customers from 2 sources on different granulaties
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum