Golden Relations and Platinum Relations, by Henrik Liliendahl Sørensen
“Golden copy” is a term widely used in master data management (MDM), as we often see the master data hub as a golden copy of the data in the company’s operational databases.
The golden records in the hub are formed from the master data records typically describing the customers, suppliers, products and locations in the transactions made in the enterprise application stack. In the master data hub, we emphasize consolidating, and eventually also splitting, the master data (to be) from different contexts into golden records being as close to the real world as needed in the enterprise as a whole.
As in common database theory, we also need relations between the golden records and we may, staying in the metallic tune, call them golden relations.
Golden Relations in the Party Domain
In understanding our customers, suppliers and other party roles, we build hierarchies of the golden records in the golden copy. Typical hierarchies include:
- Consumers belonging to a household
- Company family trees, often derived from external reference data
- Contacts within the companies which are our customers and suppliers
My guess is that we’ll start seeing more advanced relationship tracking in this domain in the near future. An example would be social network-based tracking of contacts changing jobs between parties who are our customers, prospects and suppliers.
Golden Relations in the Product Domain
Hierarchy building in the product domain is much more diverse between industries and in a single organization than hierarchy building is in the party domain.
Therefore, flexible structures are needed within a golden copy or master data hub used for Product Information Management (PIM).
Our ability to handle more products in our databases and the trend towards globalization making more products available will only increase the demand for handling the golden relations between the golden product master records.
Golden Relations in the Place Domain
I like to name the domain of locations as the “place” domain, because then we have a “P” trinity of Parties, Products and Places.
Hierarchies come naturally with places, as they form a geographical hierarchy of the type we like to use, typically being country, state, postal code / city, street name / block, building number and unit depending on where on the earth our place is situated.
The trend of governments around the world making public sector data more open helps a lot in getting the structures of the place master data aligned with the real world.
Golden Relations in Multi-Domain MDM
A multidomain master data hub embracing the “P” trinity of parties, products and places will have some important golden relations between the golden records within each domain like:
- The exact place where a unique party such as a consumer lives. This also helps with forming the right households.
- The exact place of a certain part of a product, being a locality for example in hospitality and travel – and the exact places of the nearby attractions.
- The sales figure in a defined period for products belonging to a given category sold to parties being companies in a given line-of-business.
Most interesting business problems require more than one domain of data for their solution.
Transforming already existing records representing parties in the prospect and customer role into the hub is still the most common direction today. Therefore that discipline is still often called Customer Data Integration (CDI).
In this process, it is highly recommended not to purge the records and relations that already exist when we merge data into golden records. You should keep the incoming records with a platinum relation to the new golden record as it sometimes happens that you have to rollback.
Mass import and transformation of data also happens in the product domain, for example at retailers. Also here it’s recommended to keep the original data and make platinum relations.
In some places, I’ve come across a case of “keeping up appearances”, called vanity addressing. Here your customer insists on using a somewhat incorrect address that “sounds better”, such as “Beverly Hills” instead of “Los Angeles”. For that reason too, it’s recommended to keep the vanity address and a platinum relation to the real world place.
This article was written by Henrik Liliendahl Sørensen, a well known blogger whom we hope will be a frequent guest author here. You can find his blog, “Liliendahl on Data Quality” at http://liliendahl.wordpress.com.