First off, happy new year to everyone. This post dives in to two of the most sticky problem areas for Data Vault Modelers, and suggests some basic workable solutions for these. I encourage you to post your solutions as comments to the bottom of this entry. The two most troublesome areas to model are: addresses and people.
Both of these topics share the same basic problem: lack of “real-world” business keys. Before you jump on me and tell me you have business keys for these, let me explain…
Issues with addresses…
Addresses consist mostly of non-unique data. The issue isn’t that the real-world address itself is non-unique, the issue is how the address is represented in computer systems (and entry applications) that make it non-unique. In general, a physical place usually has a single address, including mail-stops in large corporate buildings. However, getting a clean copyof all those addresses from all those systems in to a master data set is the tough part.
Yes, if you are going to assign unique business keys to addresses you mustbegin working with master data for them.
So what is the problem? Unfortunately the problem is in the manner in which the addresses are entered in to the systems. In other words:
- RD and ROAD may mean the same thing
- WY and W and WAY may mean “way”
- S, ST, STR, STREET all mean the same thing
- Sometimes, WY and RD are used when STREET is meant (or correct)
You get the idea, the first problem with addresses is: entry of non-standardized data sets. Basically the address entry screens are free-form, and allow each individual in the company to enter anything they please. Thus, resulting in duplicate address entries that differ in standard form one way or another – in other words from a data perspective they are unique, but from a human perspective, they are the same address.
So, address standardization is a huge issue that must be corrected before any sort of business key can be applied.
The next issue with addresses is: spelling errors, and address corrections, and don’t forget corrections to latitude and longitude. So even if you standardize the addresses, they will still have differences across multiple source applications. Furthermore, I’ve seen incorrect latitude and longitude ratings which complicate matters further.
So you say, well – we will just use an address cleansing / house holding solution. To that, I say great, wonderful – and if your business runs on addresses, even better. Hopefully the solution you choose will provide you with two things:
- The “as-was” (before cleansing) address, the “as-is” address (post-cleansing). Without these two address sets you do not have traceability / auditability back to the source
- The “assigned address key” – which should stay consistent every time the address cleansing software is run.
The services that I’m aware of that do this kind of thing for international addresses include MelissaData. I believe the US Postal service even outsources to them (If I’m not mistaken).
Yes, after cleansing, after standardization – then and only then could you think to assign a proper business key.
Issues with People…
Unique Identification of people in a general sense goes against the very grain of my beliefs. However, in business – as an employee, or a part of a company, it becomes important. Otherwise, analytics go haywire. Imagine if I owned a telephone company and couldn’t identify my customers uniquely? Wow, that would be a mess.
As it turns out, it IS a mess. It’s a huge mess. Employees (and sometimes contractors) on the other hand are generally assigned numbers that are associated with all the things they do within the corporation, so they are easier to track – and of course, the business key becomes the identifier that is assigned.
Now with customers, or people visiting a free medical clinic, or people in a hospital, prospects on a web site, the problem is exponentially more difficult. With data mining (and some basic location information), you can get a pretty decent result. However keep in mind that running the mining algorithm (if its a neural net instead of a heuristic / statistically driven space) may produce a different “key” for the same inputs based on learning new things.
So, neural networks are good for “possible unique identification” but bad for “absolute business key assignment”.
So putting together a “people HUB” becomes a bad idea.
Ok, these are the issues, where are the solutions?
Really, this is the crux of the problem with both of these “sticky spots”. Nearly every product, and every service that business engage in can or should or does have an identifiable business key.
Solution #1 is the easiest of all: Put addresses and “people” records as Satellites across your data model. Yes, you will have replication of data sets, yes you will increase the number of Satellites, BUT this information will be tied to a real business key that is auditable and has a trail. AND you can then mine the data, and use same-as links, and standardize/correct the data to produce results for your Business Vault.
This will give you an “as-was (raw auditable)” and “as-is (business)” image of both elements. It will keep you from getting hung up on trying to assign business keys for “people” identifiers when you don’t have one coming in from the source applications.
Solution #2: is far more difficult. For Addresses: use latitude, longitude, and altitude (high rise buildings, then office number or mail stop). MAKE SURE your latitude and longitude and altitude coordinants are correct! Otherwise, you will have a night mare on your hands IF these change, but the address stays the same.
For people: there is NO good solution. But if you MUST, then – use full name, address, gender, and if you have it: Social Security number (or something equivalent). Just remember, if any of these things change, you will be creating a new business key – and you will be forced to mine the data post-loading to try to “paste it together again” in a same-as link structure.
Hope this helps a little, would love your thoughts on the matter.