Hour Glass structure Too outdated

Courtesy
Edward, Oracle ACE Director - HyperionI give a presentation every year at the Hyperion conferences called "How Essbase Thinks." The "Hour Glass Model" is something that I have to readdress every year, because there' a ton of bad information out there on it.

First of all, the whole "largest dense to smallest dense, smallest sparse to largest sparse" thing is a serious oversimplication. Back in the pre-Essbase 7 days, here's what it really meant (in order from top to bottom):
- Densest dense dimension down to your least dense dense dimension.
- Sparse dimension with the smallest ratio of parents to children up through your sparse dimension with the largest ratio of parents to children.

The whole "put Accounts first and Time second" only matters if you still calculate your database doing a CALC ALL (which no one should be doing unless your database is the size of Sample.Basic). Might as well put them first, so the logic went, since CALC ALL was going to calculates your Account dimension first then your Time dimension anyway (because that's the order of dimensions CALC ALL uses).

That said, this all went out the window with the advent of parallel calculation. This made it much better to put all your non-aggregating sparse dimensions at the end of your outline. Non-aggregating dimensions are dimensions with no stored ancestor values (like Scenario, Versions, and Year, typically are, for instance).

Further, with the advent of databases being able to use multiple compression types (Essbase 7x and later), you should be using RLE compression (most of the time, at least) with your Time dimension first to maximize repeating values in your outline.

That gives us a current "Modified Hourglass" model of the following:
- Time (if it's dense)
- Accounts (if it's dense)
- Densest dense dimension to
- Least densest dense dimension
- Sparse dimension with the smallest ratio of ancestors to level 0 members
- Sparse dimension with the largest ratio of ancestors to level 0 members
- Largest sparse dimension (if you're using the calculator cache)
- Non-aggregating sparse dimensions

It's complicated, I know, which is why people have been saying Hourglass since 1995. I could also go on to add that since dense dimensions are typically dynamically calculated at all the upper-levels that the order of your dense dimensions is more about storage and retrieval (and less about calcing) these days, but that would be too much boringness for one post.

On Essbase Optimization:
For anyone that has to optimize Essbase cubes at their company, there's an entire day spent on Essbase optimization (including both optimizing outlines taught by Tracy McMullen and optimizing calc scripts taught by me) at ODTUG Kaleidoscope. At last check, there were 15 attendee spots still available in the Essbase track at Kaleidoscope:
http://www.odtugkaleidoscope.com/hyperion.html