Platinum and Gold

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.

Platinum Relations

Reaching UpMaster data may be born in the hub or may be born outside the hub and then transformed into the hub, thus becoming the golden copy.

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

You can retweet this by cutting and pasting >> Great #MDM article on Hub Designs by Henrik Liliendahl Sørensen: “Golden Relations and Platinum Relations” at

Tags: , , , , ,

3 Comments on “Golden Relations and Platinum Relations, by Henrik Liliendahl Sørensen”

  1. TheGlobal5000 04/20/2011 at 7:39 am #

    Henrik – curious to know what you are seeing in the B2B environment where an increasing number of contacts are not located at a business entity .. work from home, mobility, etc. What seems to be the trend in handling that linkage of contact to company?

  2. Henrik Liliendahl Sørensen 04/20/2011 at 1:50 pm #

    Indeed we in many cases must be able to embrace this kind of engagement.

    The fact that a contact operates under an account doesn’t mean that the physical address is the same. The model must be able to reflect that, if the physical address is important. I once noticed that a company had a business rule saying that if a direct mail to a named person wasn’t addressed to the actual location, the direct mail was forwarded to the bin.

    Also people today may have engagements with several companies at the same time – I’m one of those specimens. Getting the full picture of these kinds of complex relations will become increasingly important.

    In the old days these relations was in the head or in the personal notes kept by a salesperson and other employees. Today information must be available to everyone in order to have a single business partner view within the enterprise.

    External reference data and social network integration will play a large role in fulfilling the requirements for maintaining such recordings of relations.

  3. Dan Power 04/21/2011 at 11:26 am #

    @TheGlobal5000 – good question.

    @hlsdk – very thorough answer. For me, it’s a matter of data modeling, really.

    You want to make sure your off-the-shelf hub can handle the types of scenarios that Henrik brings up (contact’s address different than company location that person is tied to – for work-from-home people, or one contact engaging with several companies at once, or storing many different social network IDs per individual or company).

    If you’re using a hub that lets you create your own data model, that’s easier but it puts all of the onus on you to create that type of rich party data model.

%d bloggers like this: