You decide. I recently read a new “tip” on the Kimball site regarding “new types” of slowly changing dimensions. I received an email from my good friend Kent Graziano about the tip, but also reminding me that Bill Inmon wrote about this 20+ years ago in his original writings, and that I had added it to Data Vault modeling 15+ years ago when I published the standard.
If in fact, Kimball & camp is aligning Star Schemas towards Data Vault mdoeling, I guess that’s a good thing, as copying is the sincerest form of flattery. On the other hand, I’d like to hear your opinions – what do you think Kimball’s post really says? Does it align with Data Vault Modeling or not?
Of course there is still the fundamental question & issues to deal with like: how does Kimball truly define a “data warehouse?” and, where exactly should the business rules live? I know my views on the subject, but I’d like to find out more from you. Please add your comments and thoughts to the end of this post.
DISCLAIMER: Please remember: 1) I am biased 2) I am specifically referring to the use of star schema modeling as an EDW in this context – I am NOT referring to the use of star schema modeling for production and release to the business users. I do believe in star schemas for data release to business users, just not for use as a back-end EDW.
Where’s the post?
Overlap? What overlap? Are these truly new innovations?
With type 0, the dimension attribute value never changes, so facts are always grouped by this original value
In the original specification of the Data Vault methodology I define clearly the use of RAW Data sets that are never changed by business. One of the impacts to following this method, is that it cannot be conformed, altered, or changed in any way. However, no where in his definition of a “type zero” does he even remotely suggest that the business rules should be moved downstream. I would tend to say that if you truly want a “type zero” kind of thing, that you should really be considering using Data Vault modeling in the first place. At the very least – you will now be required to move the business rules down-stream, otherwise the descriptive data that is “changed/munged/altered and conformed” will change over time – making a type zero near impossible to achieve.
The type 4 technique is used when a group of dimension attributes are split off into a separate mini-dimension. This approach is useful when dimension attribute values are relatively volatile.
Did I miss something here? This is the standard method of Data Vault modeling, and has been there from the beginning in 2000/2001 when I released the Data Vault modeling standards. Splitting of Satellites by type of data and rate of change have always been a good practice. Now, he finally suggests it for Dimensional modeling. Ok, no problem – it is a good advancement. But yet again, I have to ask the questions:
- IF you are changing data on the way IN to the Dimensional Warehouse, HOW then would you track changes back to a Mini Dimension?
- And even harder to answer: WHERE and WHAT represents the business key in this “mini dimension”? In other words, if you don’t have a business key identified, then it is near impossible to go back and “end-date” the old record, and activate the new one. In fact, in his example, he doesn’t even show “temporal” aspects of data change.
As if it wasn’t hard enough to track changes, he continues on to introduce Type 5, 6, and 7
The type 5 technique builds on the type 4 mini-dimension by embedding a “current profile” mini-dimension key in the base dimension that’s overwritten as a type 1 attribute. This approach, called type 5 because 4 + 1 equals 5,
What? What kind of serious logic is this? You must be joking – using simple addition to justify changes to an architectural design?
Adding 4+1 = 5 is mundane. What about the serious definition? the architecture considerations? the risk of snowflaking that has been proven to be bad to begin with (bad for performance, bad for design, bad for architecture, etc…) Now to apply a band-aid to an ailing “modeling technique for data warehousing” he simply says do a little simple addition, and voila – you have a new dimensional type.
The ETL team must update/overwrite the type 1 mini-dimension reference whenever the current mini-dimension changes over time. If the outrigger approach does not deliver satisfactory query performance, then the mini-dimension attributes could be physically embedded (and updated) in the base dimension.
Really? You’ve got to be joking…
He just contradicted himself for the purpose of a mini-dimension that is “type 5” – it cannot exist according to the statements he’s made. Let me explain: first, he said: use a Type 4 for the “faster changing information” (the mini dimension), use a type 1 for the main dimension. Then he said: the outrigger is a type-1 mini dimension and should be overwritten (meaning no history). WELL FOLKS, WHICH IS IT? He goes on to then suggest denormalizing (re-combining the type 4 + type 1) back together again to re-form a type 3 dimension if performance doesn’t work… Wow, so in other words there is no new innovation here at all, and it would be near impossible to construct the correct “mini-dimension” given the multiple definition.
Breaking it down:
- Type 4 mini-dimension is updatable, and is broken out because of rapidly changing attributes
- Type 4 mini-dimension should really be a type 1 mini-dimension with a type 4 main dimension – making this a type 5
- Type 5 is really a type 1 mini-dimension with a type 4 main dimension – that is de-normalized back together at the first sign of performance problems (ending up right back where you started with a huge dimension and copying attributes that change frequently).
The Data Vault Model in contrast is based on mathematical study of data, the rates of change, and the classifications of data. This study also includes the study of horizontal and vertical partitioning of data for performance and parallelism reasons – hence it’s close alignment with MPP systems (think Big Data and NoSQL). The Data Vault Modeling paradigm is not abritrary and does not simply “append” styles just to meet the needs of true enterprise data warehousing, no, the Data Vault Modeling paradigm is built on a solid foundation of tried and true methods and best practices.
On the one hand it’s good that Dr. Kimball is trying to innovate – for that I applaud his efforts. On the other hand to show such non-concern for the nature of the data itself and merely suggest “new types” of design patterns to an already troubled architecture is quite disconcerting. I fear that these “advancements” will only feed the fires of EDW troubles more quickly.
Type 6 builds on the type 2 technique by also embedding current attributes in the dimension so that fact rows can be filtered or grouped by either the type 2 value in effect when the measurement occurred or the attribute’s current value. The type 6 moniker was suggested by an HP engineer in 2000 because it’s a type 2 row with a type 3 column that’s overwritten as a type 1; both 2 + 3 + 1 and 2 x 3 x 1 equal 6. With this approach, the current attributes are updated on all prior type 2 rows associated with a particular durable key, as illustrated by the following sample rows:
What a minute… he just told you to put measurements or facts in a dimension. If this is true, then what’s the point of assigning monikers like dimension and fact? If this is true, then he’s just conflicted the standards and the definitions (not to mention destroying the patterns) for putting specific types of attributes under specific labels.
I don’t know if you caught it: but he states IN THIS PARAGRAPH that the attributes are updated on all prior type 2 rows… Now if I return to the base definition of enterprise data warehouse, I believe that Inmon defines the data set as NON VOLATILE. That should mean that there are NO UPDATES to existing data sets of user based data!! He just suggested that an update (which changes data values of data sets that arrived from the source systems) be executed against user based data. At that point, if you follow this rule, you DO NOT have an enterprise warehouse. You HAVE a Data Mart, where the information is subject to change.
He is updating the “Current Strategy” column, which is ok – he’s maintaining audibility in the historical column but then again, from a big data perspective how good will the performance be over time? The speed of the Updates will continue to degrade as the data set grows.
For this case, proper sense would dictate that you build a new “higher level type 3 dimension” and fact table combination on top of the low-level detail. This higher level of grain would house the current assignments and overrides. Eliminating the need for updates entirely, also eliminating the need for “current row indicators”
Finally Kimball Introduces:
With type 7, the fact table contains dual foreign keys for a given dimension: a surrogate key linked to the dimension table where type 2 attributes are tracked, plus the dimension’s durable supernatural key linked to the current row in the type 2 dimension to present current attribute values.
Type 7 delivers the same functionality as type 6, but it’s accomplished via dual keys instead of physically overwriting the current attributes with type 6. Like the other hybrid approaches, the current dimension attributes should be distinctively labeled to minimize confusion.
Ok, interesting. So, you can query by “active label” versus “previously assigned label” or dimension row. This one almost makes sense.
Conclusions and Summary
In my humble opinion Dr. Kimball is combining (unsuccessfully) two major functions that shouldn’t be combined:
- Storage, History, Non-volatility (Data Warehouses)
- Presentation, Preparation and Release (Data Marts)
He’s trying to hard to get the data modeling archtiecture of star schemas to “bend” and meet the needs of the enterprise data warehouse. He has introduced massive complexity in to his systems, and the ETL routines to keep all this straight will end up as spaghetti code within the second or third project iteration.
A life lesson… I was always taught to take a big problem in life and break it in to bite-sized chunks to solve it, and not try to force fit solutions or build band-aids as short stop gap measures. This is why I hold fast to the belief that the data warehouse IS PHYSICAL and IS NOT the same as a data mart layer. That view provides me the opportunity of separating the “jobs” and responsibilities of presentation from the jobs and responsibilities of historical storage and integration by business key.
In my opinion, again, I applaud Dr. Kimball for attempting to innovate, only in this case, I believe that these innovations will prove out to be ill-fated prescriptions for those who follow the advice, and continue mixing data warehouses with data marts in the same architectural layers.
Please let me know what you think of all this. Do you think it will work? Do you see benefits to his approach? Do you see the overlap with the Data Vault Modeling Techniques?