I’m always on the lookout for ways to improve the understandability and readability of the Data Vault, especially when it comes to solving business user problems or issues. As you know, the Data Vault model relies on the best possible business keys being chosen for Hubs. Knowing your business data, understanding the business processes, and linking the two to the data warehouse, all happens through business keys. The more consistent the business keys are (across lines of business and through the business processes), the better the analytics will be, and the better the Data Vault model will be. In this entry I will be diving in a little bit to the technical aspects of unique identification. I will discuss MD5, hashing in general, uniqueness, and sequence numbers.
Get familiar with Hashing…
Let me just start by saying: if you are unfamiliar with Hashing, or don’t know what an MD5, SHA-1, or CRC is, you should probably read up on it. There are literally hundreds of sources for this information, but Wikipedia has a great set of definitions and explanations. Although for ease of simplicity, I will offer this over simplified definition (just for frame of reference and context).
MD5, and SHA-1, and a few other algorithms are considered to be cryptographic hashes. That is to say: they encrypt data, and then provide a mostly unique finger-print or ID for the data set that it ran through it’s mathematical algorithm. The RFC’s for these algorithms generally state that these functions have a probability of producing something called a collision. The collision is when you have two different data values go through the mathematical algorithm, and produce the same result.
CRC is of a slightly different class, in that it’s not cryptographically safe. It is in a class called a simple hash, and is known as a cyclical redundancy checksum.
The business of business keys…
Business keys are supposed to have meaning to the business user. In a perfect world, they really should be decipherable by individuals who live and work in that industry. For instance, VIN (vehicle identification number) numbers are really well known to those who work in the auto industry. Some individuals are so adept at reading these numbers they can tell you what some of the sequences mean – define the number for you. For all the things the auto industry may not get right, they have one thing right: a consistent business key for their main product. Not only that, but it’s standardized around the world; it’s used in ALL manufacturers plants for “most” motorized vehicles, including motorcycles, cars, and busses.
This key doesn’t change when it goes from the Sales system to the Contracts system, it doesn’t change when it’s transferred from the contracts system to the manufacturing system, or any other system in the business. It stays consistent once assigned. This provides for 100% traceability for the life of the vehicle from inception to even “parts selling” in a junk yard somewhere.
We should be so lucky as to have business keys for all our business data, that we would be able to finger print it across all the systems. As it is today, these keys change all the time, but that’s another blog entry for later this week. Let’s get back to hashing and business keys, and MD5.
Why can’t I use MD5 as a primary key in the Data Vault/Data Warehouse?
I get this question all the time. Let me first say this: MD5 is not infallable, it is not garaunteed to produce uniqueness – it is garaunteed to fingerprint and provide an encrypted set length of data for a given string of bits. In other words, produce the same hash or number/result for the same input every time. If you are looking for uniqueness in a primary key, you may get lucky – that is until two things happen that increase the chances of collisions.
1) If the bit string you put in to the MD5 is shorter than 128 bits (the length of the result of the hash function), you increase the chances of collision by multiple factors. In fact, a more simple way to look at it is: the shorter the input, the greater the likelyhood of producing the same number for two different input values.
2) The other possibility is: scale/size/scope of your EDW. The more rows you put in to your data warehouse, the greater the chance of collision, again: see #1 for the initial principle.
For instance: suppose you have a 15 character string as a business key, you’ve already increased your chances of duplicates with rule #1 above. Then, add to that: 110 million rows, you’ve now increased your chances of duplicate keys for different values by rule #2. The chances of Md5(“AB”) = md5(“BA”) can be fairly high with large numbers of rows being processed, these both are very short strings pushed in to the algorithm.
IF you have a finite set of rows that you know will never grow beyond 15 million or so, you might get away with no collisions and a great/speedy way of changing alpha-numeric business keys into fast indexable primary keys. OR if you have a very large business key (say 500 characters or longer) maybe an image, or a blob, then the massive length decreases the chances of duplicates being produced by MD5 (more unique bits to hash). Under these circumstances making MD5 results a business key might just work.
Right then. I’m off to set MD5 as my business keys…
Woaah, slow down, wait a minute, you’re moving too fast.
Remember this: the main purpose of a business key is to never change (legally) throughout the life of the data that it represents.
Tying the business key to the business process, to the data flow in the business process, and also to the physical model will nearly always lead to success in any business intelligence or operational system. It allows full traceability back to the source, and even across the sources. Otherwise horizontal pictures of the business cannot be created (but I ramble, and this too is for another blog entry coming up).
Do not simply “decide” to set MD5 as your business key and run off and implement it. Consider the implications first!
What is the issue we are trying to solve here?
The issue is really more of a two part question, one technical, one business.
Technical: How do I “detect/lookup/identify” data quickly without all the fuss of “caching lookup tables” or joining to the data in the database?
Business: How do I provide a value-added key that has meaning across the business, yet can be used in a technical solution?
Ok – there’s one more hidden question for both parts: HOW CAN I KEEP THE KEY FROM CHANGING ONCE IT’S CREATED? This is the biggest question of them all. If you’re using an MD5 against a “name” of some sort, then then imagine what happens when the “name” changes… Your algorithm for “identifying” data in the EDW, creates a new hash key, and can’t trace it back or tie it back to the old data that is still marked as current in your EDW!! Again, you should only create MD5 keys in limited data sets, and large enough keys that won’t contain collisions.
Now, if you’re lucky enough to capture the name change and your system can be fed an old-name and the new-name, you can use a hierarchical link (many-to-many hierarchy) table to relate the old information. We call this a same-as-link in Data Vault speak. Now, I’m going to make a very strong statement and take a stand here – because we don’t live in a perfect world, and keeping business keys that “never change” is usually a far-fetched reality.
CDC Is absolutely VITAL to the future of Data Warehousing and BI. CDC will MAKE a set of changing business keys become a seemless operation for horizontal integration of data in the next-gen data warehouse. CDC must be implemented on all future operational systems.
So is there a time when I can use MD5 as a business key in my Data Vault / Data Warehouse?
Strangely enough, the answer (as it turns out) is YES. I would suggest the following situations are valid and applicable to potentially using MD5 as a replacement for surrogates in the Data Vault: 1) Operational Data Vault, 2) Business Data Vault – where you may have control over the raw same-as links inside the raw Data Vault, and you are moving the data in to a master data system.
Wait a minute, did you just say that a Business Data Vault is a Master Data System? Yes, I did, and if it’s built properly, it can be the foundations for your Master Data Initiative (and a pretty good one at that). But, more on Business Data Vaults in yet another future blog post.
These are the two situations. Operational Data Vaults mean that your application sits on top of the Data Vault Warehouse directly, and therefore gives you complete control over maintiaining/establishing business keys that should never change. This means MD5 will work consistently and repeatably for you over time. Operational Data Vaults also give you the option of building CDC directly in to the application (thus allowing business keys to change over time – but be wary of this option, it leads to other problems in the future).
Business Data Vaults rely on cleansed/cleaned and integrated data. They rely on master-business keys being chosen for the Hubs. That being the case, MD5 should generate mostly unique surrogate keys across the board. The other piece, (if you’re lucky enough to have it or create it) is: CDC or audit-trail feeds are already stored inside the raw Data Vault and same-as links. This makes it easy to choose a consistent master key for the Business Data Vault.
Just remember the final two tennants: length of the business keys make a difference, longer is better. number of business keys also makes a difference – smaller number of keys is better (less chances of collision).
If you account for both of these, or develop a unique mitigation strategy for the second (so it can scale), then you’re home free.
By the way, some research is being done in Global Unique Hash (no, it’s NOT GUID – GUID is defined differently, don’t mistake the two). If they ever get to “perfect hash algorithm” that works, and make it public knowledge, I’ll be jumping on that band-wagon to test it out.
What are your experiences with Business Keys, Hashes, and Collisions? What do you do in your data warehouse to make it all work? I would love to hear from you.
PS: Don’t forget to check out one-on-one coaching! There’s more in-depth study and hands-on examples of these solutions inside!