4 ms·

I'm a bit opinionated on data modelling, so a couple points. 1. "OLAP Cubes" arguably belong to Microsoft and refer to SQL Server cubes that require MDX querie

I'm a bit opinionated on data modelling, so a couple points. 1. "OLAP Cubes" arguably belong to Microsoft and refer to SQL Server cubes that require MDX queries. It's a solution given to us by Microsoft that comes with well understood features. "OLAP" itself is a general term used to describe any database used for analytical processing, so OLAP has a wide range of uses. 2. OLAP Cubes (as defined above) started to decrease in population in 2015 (I'd argue). 3. Any solution to fixing "OLAP" that comes from a commercial vendor is suspicious. As painful as Kimbal & Inmon are, they are ideas that don't require vendor lock in. 4. At my current company, we recently wrapped up a process where we set out to define the future of our DW. Our DW was encumbered by various design patterns and contractors that came and went over the past decade. We analyzed the various tables & ETLs to come up with a clear set of principles. The end result looks eerily close to Kimball but with our own naming conventions. Our new set of principles clearly solve our business needs. Point being you don't need Kimball, Inmon, Looker, etc to solve data modelling problems. 5. Columnar databases are so pervasive these days that you should no longer need to worry about a lack of options when choosing the right storage engine for your OLAP db. 6. More and more data marts are being defined by BI Teams w/little modeling/CS skills. To that end, I think it's important to educate your BI teams as a means to minimize the fallout, and be accommodating in your DW as means to work efficiently with your BI teams. This is to say settle on a set of data modelling principles that work for you, but may not work for someone else.

papandada 5y ago
I'm struggling to figure out what you mean by number 4. Isn't the result of that exercise proof that the Kimball approach is a worthwhile one?
- iblaine 5y ago
  We evolved our guidelines for data modeling to something that closely resembles Kimball, but it's not Kimball. Some of our ETLs were created by people that were not familiar with Kimball. We went about defining new data modeling guidelines, taking the good parts out of this work, eliminating the bad parts, and many of the good parts share a lot in common with Kimball.
  - valzam 5y ago
    To me this still sounds if the original person had known Kimball designs the bad parts might have been avoided since apparently the good stuff was a re-discovery of Kimball methods anyway?

papandada 5y ago

I'm struggling to figure out what you mean by number 4. Isn't the result of that exercise proof that the Kimball approach is a worthwhile one?

iblaine 5y ago
We evolved our guidelines for data modeling to something that closely resembles Kimball, but it's not Kimball. Some of our ETLs were created by people that were not familiar with Kimball. We went about defining new data modeling guidelines, taking the good parts out of this work, eliminating the bad parts, and many of the good parts share a lot in common with Kimball.
- valzam 5y ago
  To me this still sounds if the original person had known Kimball designs the bad parts might have been avoided since apparently the good stuff was a re-discovery of Kimball methods anyway?