The reasoning behind the potential pitfalls of OBT are really well thought out, and I’ll likely wheel them out at some future point when I’m inevitably caught up in some debate of Kimball v OBT.
“Someone once described Excel as being the second best tool for any job, and that’s why it’s so well adopted. Maybe star schemas occupy a similar space.”
Love this! Will def steal.
Great read. I often have to remind myself why we do it this way. I had to have that chat with someone about the Big Fat Table approach and felt slightly ill-equipped to answer with great convince until now.
The Kimball Group Reader book is another source. It collects magazine columns and blog posts from 1995 to 2015 written by Kimball, and later Margy Ross and others.
Also, remember this, there is no “star schema” or “dimensional model”, it’s really just good old relational database design. First example of a “star schema” design is in the 1970 Codd paper.
Hi Jonny, I think that the death of the start schema is true and real... but only as the one and only storage medium, like it was envisioned by Kimball. It is just too painful to store the data AFTER applying the business rules, making it harder to evolve.
I think it's still healthy and well alive for the delivery layer, where speed, simplicity and widespread adoption (tools and knowledge) make it almost always the best option.
Applying business rules and building star schemas AFTER storing the data makes it very easy to evolve them without backfilling and other painful activities.
My personal opinion is that both statements are true, hence the apparent contradiction.
Nowadays it's easy and cheap build a rock-solid, almost totally automated storage layer with full historization, followed by a refinement layer where you craft the organization's business concepts and use them to build the star schemas that populate the delivery data marts.
Getting the best of many architectures is now possible :)
That is the approach I have presented in my first book, and used in multiple projects.
I like this comment: "I sometimes think that my brain now thinks in facts and dimensions."
Someone that grew up with Data Vault before they learned other techniques might think in terms of Hubs, Links and Satellites.
I grew up with Conceptual-Logical-Physical so I tend to think like that. When I meet a Dimensional Modeler we go straight to Physical and we are both happy.
When I meet a One Big Table in a dashboard or report concept I often think of it as 1 fact with a bunch of dimensions squished into the table ... so in a sense it sometimes looks like a dimensional model to me.
Is this wrong? Do I have a very warped mind? Will there be hope for me in the afterlife?
The reasoning behind the potential pitfalls of OBT are really well thought out, and I’ll likely wheel them out at some future point when I’m inevitably caught up in some debate of Kimball v OBT.
“Someone once described Excel as being the second best tool for any job, and that’s why it’s so well adopted. Maybe star schemas occupy a similar space.”
Love this! Will def steal.
Great read. I often have to remind myself why we do it this way. I had to have that chat with someone about the Big Fat Table approach and felt slightly ill-equipped to answer with great convince until now.
Parsnips, chicken, egg? You're making me hungry.! Once again, I enjoyed the writing.
The Kimball Group Reader book is another source. It collects magazine columns and blog posts from 1995 to 2015 written by Kimball, and later Margy Ross and others.
Also, remember this, there is no “star schema” or “dimensional model”, it’s really just good old relational database design. First example of a “star schema” design is in the 1970 Codd paper.
Hi Jonny, I think that the death of the start schema is true and real... but only as the one and only storage medium, like it was envisioned by Kimball. It is just too painful to store the data AFTER applying the business rules, making it harder to evolve.
I think it's still healthy and well alive for the delivery layer, where speed, simplicity and widespread adoption (tools and knowledge) make it almost always the best option.
Applying business rules and building star schemas AFTER storing the data makes it very easy to evolve them without backfilling and other painful activities.
My personal opinion is that both statements are true, hence the apparent contradiction.
Nowadays it's easy and cheap build a rock-solid, almost totally automated storage layer with full historization, followed by a refinement layer where you craft the organization's business concepts and use them to build the star schemas that populate the delivery data marts.
Getting the best of many architectures is now possible :)
That is the approach I have presented in my first book, and used in multiple projects.
You can read more at https://pragmatic-data.org/
Ciao, Roberto
I like this comment: "I sometimes think that my brain now thinks in facts and dimensions."
Someone that grew up with Data Vault before they learned other techniques might think in terms of Hubs, Links and Satellites.
I grew up with Conceptual-Logical-Physical so I tend to think like that. When I meet a Dimensional Modeler we go straight to Physical and we are both happy.
When I meet a One Big Table in a dashboard or report concept I often think of it as 1 fact with a bunch of dimensions squished into the table ... so in a sense it sometimes looks like a dimensional model to me.
Is this wrong? Do I have a very warped mind? Will there be hope for me in the afterlife?