Liliendahl on Data Quality

I remember when I had the first chemistry lesson in high school our teacher told us that we should forget all about the chemistry we had learned in primary school, because this was a too simply model not reflecting how the real world of chemistry actually work.

Since I have started working with data quality and master data management I have a pet peeve in data modeling, namely being the probably most common example of doing data modeling: The classic customer table. Example from a SQL tutorial here:

Compared to how the real world works this example has some diversity flaws, like:

• state code as a key to a state table will only work with one country (the United States)
• zipcode is a United States description only opposite to the more generic “Postal Code”
• fname (First name) and lname (Last name) don’t work in cultures where given name and surname have the opposite sequence
• The length of the state, zipcode and most other fields are obviously too small almost anywhere

More seriously we have:

• fname and lname (First name and Last name) and probably also phone should belong to an own party entity acting as a contact related to the company
• company name should belong to an own party entity acting in the role as customer
• address1, address2, city, state, zipcode should belong to an own place entity probably as the current visiting place related to the company

Now I know this is just a simple example from a tutorial where you should not confuse by adding too much complexity. Agreed.

However many home grown solutions in business life and even many commercial ready-made applications use that kind of a data model to describe one of the most important business entities being our customers.

It may be that such a model does fit the purpose of use in some operations. Sometimes yes, sometimes no. But when reusing data from such a model on enterprise level and when adding business intelligence you are in big trouble. That is why we need master data hubs and why we need to transform data coming into the master data hub.

From such a customer record we don’t create just one golden record. We make or link several different related multi-domain entities as:

• The contact as a person in our party domain – maybe we knew her before
• The company in our party domain – maybe we knew the sister as a supplier before
• The address in our place (location) domain – maybe we knew that address as a place in time before