Master Data Access Use Case #2: The Composite Record

1

In the last post we looked at the use case for master data in which the consuming application expected a single unique representative record for each unique entity. This would be valuable in situations for batch accesses like SQL queries where aggregates are associated with one and only one entity record. This week, we look at a second use case that might be more common in an interactive environment where the users desire access to all the data associated with a particular entity, such as customer service or fraud investigation.

Because an MDM system applies identity resolution to link sets of records together from one or more data sets, collections of matched records can be assigned a common entity linkage identifier that indicates a grouping. In a customer service example, sales records, support call records, returns and social media comments can be linked to the unique customer.

Due to the diversity of the source data, it is unlikely that a single record will add as much value to the customer service representative’s interaction with the customer as having access to the entire set of customer touch points and transactions. This perspective might be what the vendors often characterize as the “360-degree view of the customer,” although I prefer to refer to it as a composite record.

The composite master record provides visibility into enterprise information about an entity without forcing any application of survivorship rules. One of the main benefits of the composite view is that interpretation of the data is completely left to the user. For an application such as fraud analysis, having access to data that has not been cleansed or standardized may be preferable to materializing a single record. Because details of prior interactions may show behaviors intended to hide suspicious activities using variations of names or locations, the ability to establish links among raw records can facilitate identifying fraudulent activities.

Whether your business processes rely on use case 1 (the single record) or use case 2 (the composite record), it is still difficult to convey a description of what MDM does without being able to show what it does – and devising an MDM demo is the topic of our next post!

Share

About Author

David Loshin

President, Knowledge Integrity, Inc.

David Loshin, president of Knowledge Integrity, Inc., is a recognized thought leader and expert consultant in the areas of data quality, master data management and business intelligence. David is a prolific author regarding data management best practices, via the expert channel at b-eye-network.com and numerous books, white papers, and web seminars on a variety of data management best practices. His book, Business Intelligence: The Savvy Manager’s Guide (June 2003) has been hailed as a resource allowing readers to “gain an understanding of business intelligence, business management disciplines, data warehousing and how all of the pieces work together.” His book, Master Data Management, has been endorsed by data management industry leaders, and his valuable MDM insights can be reviewed at mdmbook.com . David is also the author of The Practitioner’s Guide to Data Quality Improvement. He can be reached at loshin@knowledge-integrity.com.

Related Posts

1 Comment

  1. Hi David,

    Great point. While I have seen use case 1 ( single record) all the time, the way use case 2 is realized is by still creating single record but providing lineage information as part of MDM solution itself so the user of the application can demand access to raw (before standardization/transformation/cleansing) data coming from source. I have also seen scenarios where 'aggregate view' is created before confirming the merge so the user knows the result of the merging before hand. Have you seen use case 2 done differently?

    -Prash

Leave A Reply

Back to Top