When talking about Master Data Management (MDM) we deal with something that maybe could be better coined as Master Entity Management. As a good old (logical or not) data model in the relational database world also have relations between entities there must of course then also be something called Master Relationship Management. And indeed there is as mentioned by Aaron Zornes in the interview called MDM and Next-Generation Data Sources on Information Management.
As touched by Aaron Zornes the solution to handling relations in the future may come from outside the relational database world in the form of graph databases. This was also discussed in the post Will Graph Databases become Common in MDM?
An often mentioned driver for looking much more into relationships is the promise of finding customer, and other, insights in social data based on the match between traditional master entity data and social network profiles. Handling these relations is an important facet of social MDM, an often mentioned subject on this blog.
Building the relations doesn’t stop with party master entities. There are valuable relations to location master entities and not at least crucial relations between party master entities and product master entities as told in the post Customer Product Matrix Management.
So Master Relationship Management fits very well with the current main trends in the MDM world being embracing big data not at least social data and encompassing multi-domain MDM. The third main trend being MDM in the cloud also fits. It’s not that we can’t explore all the relations out there from on-premise solutions; it’s just that there is a better relationship in doing so in the cloud.
For Retailers, the classic MDM domains (or entities as Henrik states) are Product, Location, and Customer. Ecommerce, real-time SOA infrastructure, and now Big Data (unstructured data including Social Media) have enabled an OmniChannel shopping environment that is characterized by anywhere, anytime shopping by Consumers across a wide range of intermediaries and applications.
The classic data warehouse infrastructure organized by SQL columns and rows does not clearly show the visibility of the relationships between buyers & sellers and their intermediaries market baskets, and value creation. Leveraging Visual BI resources such as Qlik, Tableau, and Tibco Spotfire highlight the fast changing dynamics of buyer/seller relationships and their trading partners, services and applications. These Visual BI resources enable users to aggregate / disaggregate large data sets within and without the Retail Enterprise and opportunistically see what is driving their business from the diverse perspectives of People, Product, and Location instead of just the one view fits all that classical methods have provided.
Indeed, the flexible user insight of Relationship values can enable the ideation of additional value Omni-Channel domains not visible today.
Very interesting points about relationships, Henrik.
Properly designed databases based on fully normalised relational data models have been effectively holding key information about relationships for decades.
It might seem like an anomaly in terminology that critical information on relationships is actually held in data entities. Called ‘intersection entities’, these are the most common, yet most powerful, entities in an enterprise.
All major commercial transactions in an enterprise are actually recorded in intersection entities. For example, a Sale is the intersection between the entity Product and the entity Party. The shopping cart on an ecommercce website is an intersection entity that shows the connection between the Products and the Party purchasing them and the value being created by this intersection.
@Roland data warehouses do not use the rows and columns structure of relational databases. They would be better defined as a ‘data cube’. They are very powerful for answering a predefined set of questions but of no use for doing ad hoc queries.
All of the dynamic relationships that you talk about, and more, can be fully catered for by any good quality relational database – BUT only if they have been properly modelled and normalised at the logical level!
Visualisation tools are very powerful when it comes to better displaying what the underlying data means. However, they can lie to you – and big time! – if the underlying is not fully normalised. Breaches of Fifth Normal Form (5NF) are commonplace and completely misleading.
Thanks for adding in Roland and John. The key is, as I see it, in what degree you can think ahead and model relations, intersection entities and cubes or if you have to rely on some kind of inference that makes you discover none obvious relationships out there. I’m quite sure we will have some kind of hybrid solutions here.
At Reltio, we reflected upon the challenges described above and that we saw in the industry, and set forth to design a big data platform and architecture for MDM and MDM-aware applications, to try to resolve them. Operating on that platform, our nextGen MDM solution leverages a graph structure that gives us full flexibility to define relationships purely through lightweight meta-data, without the constraints or pre-think that has to be done using traditional tables/keys/intersections. And we also wanted to reduce the traditional friction of marrying master data to transactions, so our nextGen MDM platform actually inducts, stores and integrates interactions, blurring the traditional lines between a master data hub and a data warehouse, thus providing a single place to gain a level of insight in r/t, not available before. These are powerful ideas that dramatically reduce the time and cost of implementation and changes/upgrades, while boosting value. We’re trying to skate to where the puck is headed, and the marketplace is telling s we’re heading in the right direction.
Thanks a lot for commenting Curt. I have followed Reltio for a while.