Structuring Time

At first sight, Time is a deceptively simple dimension to build. How hard can it be? If you are thinking about economic of financial analysis, there seems to be a natural, perfectly regular hierarchy:

Years
Quarters
Months

If this structure solves all your problems then you may skip to the following section.

Of course, if you are thinking about sales or production, you might want to add days. That seems OK, too. At the most, there is this little hiccup in February caused by leap years (Why can’t this planet adjust its movements, huh?).

Even if your application needs hours, or even seconds, that will mean more levels and more members, but not more conceptual complexity. Of course if you intend to keep data to the second you have to take into account there are 31 million seconds in a year. Careful planning and lots of resources may be needed.

At this stage, two classical complications may appear.

One of them is the need to roll up weeks. If you need first week of the month, second week and so on, this is solved by adding yet another level. However, you have to consider the “short” weeks at the end of each month whenever you create formulas, or if you are going to compare weeks side by side.

Things get a little more complicated if you want to roll up weeks within a year. Since weeks will not fit into months you will need to create a multiple hierarchy, and how easily you can do this will depend on your MDDB.

The second complication is the need to roll up your months into calendar years and fiscal years. Again this issue is usually solved by defining a multiple hierarchy.

If days are important to your application, then it will be just a matter of time before you will need to discriminate working days from week-ends and holidays. In this case your MDDB better have some way of defining properties or attributes for dimension members, since this is the simplest solution, barring specific time-related functionality.

Granularity

This issue may arise in many situations but it is very common to find it related to the Time dimension. Granularity is a truly a multidimensional problem, since it can only appear at the intersection of two or more dimensions. More over this is a problem that applies to specific members of the related dimensions.

It is very simple to define: for a given member of a dimension, its granularity in terms of another dimension is the lowest level you have source data for. For example, you may have a sales analysis cube with three dimensions:

Time (Year, Quarter, Month)

Scenario : Actual, Budget

Products (Line, Family,  Product)

We are assuming an implicit measure: sales in dollars.

In an ideal (from a technical viewpoint) situation you would have Actual and Budget data for each Product for each Month.

However, it would not be unusual that sales were budgeted for each Product for each Quarter. In such a case we say the Time granularity of the Scenario member Budget is Quarter, while the Actual member Time granularity is Month.

When this happens, you are left with a number of null cells. You have three options: you can leave null cells in your cube, and deal with the missing data problem when queries are made, or fill them using formulas according to an allocation algorithm. Since the subject of allocation methods  warrants a separate column, I will just say that there are quite a few of them, and none is perfect. It depends on the application. (Heard that one before, haven’t you?) The third option to solve a serious granularity problem is to split your cube in two.

As I said earlier different granularities appear at the intersection of two dimensions, but there may be more than two dimensions involved. In our previous example, some product Lines might be budgeted for each Product, while others might be budgeted down to the Family level. The conceptual solutions are the same but the specific implementation becomes considerably more difficult. You will need double allocation algorithms, or your formulas will have to take into account missing data with more complex patterns.

From the preceding paragraphs you can easily see why it is desirable to know  the granularity of available data before you start designing your solution.

Rolling Up Time

Another issue that may occur in any dimension, but is often associated with time, is the need for custom rollups.

Two classic examples are balance or stock related measures. When you have to rollup monthly figures into quarterly total adding them, as any self-respecting MDDB engine will do by default that not yield the correct result. Instead, you have to take the number for the last period, that is to say, your Stock for Quarter 1 will be your March figure, your 2001 stock will be the same as the 4th Quarter of 2002, and so on.

Why does this happen? Members of the Time dimension, no matter at what level, can represent two different things : a time span or an instant in time. In the first case, data for December 2002 would measure the variation of whatever we are measuring aggregated during the 31 days of December, while in the second it would mean the value of that measure at midnight of December 31st.

This tends to be so obvious to users that they will rarely make it explicit. For instance, if you talk about sales or expenses of course you mean time spans. On the other hand, balance sheet accounts will usually be taken as closing values. There are MDDB engines that provide functionality that addresses this particular case, in other products you are on your own.

A second case of non-additive time rollups occurs when you define formula based members. For instance, you might have sales and cost and define a cost-to-sales ratio or percentage. In such a case the value for a quarter cannot be calculated by adding the values for each month. Instead, you have to calculate the ratio using the aggregated values for sales and costs. What this means is that what will happen depends on the calculation order (I may write a column on calculation order one these days) of the product you are using. In some cases the engine you are using may use the right formula by default but you should always make sure.

There are too many possibilities to explore them in-depth in this column but by now you may have realized this is another aspect of cube design that is worth taking into account at design-time.

Question Time

When we include a Time dimension in a cube we must know as much as we can about the questions that cube is supposed to answer. Of course such a list will never be complete but it will give us valuable information to guide our design decisions. Time related queries can range from the trivial to the hair-rising.

These are just a few common patterns:

How many times: Time is the one dimension most likely to be viewed on more than one axis when slicing-and-dicing. The classic example: the study of seasonal trends. Reports are usually of the form:

To create these reports, from a purely design standpoint you have the choice of creating more than one dimension, or using multiple hierarchies. However MDDB engines may include functionality (or the lack of it) that forces your choice.

Moving target: There are many applications that require aggregations and calculations based on the “current period”. While the meaning of this expression varies, it usually refers to the last period for which data has been loaded into the cube. There are, however two important considerations: first, in cases of partial loads, there may be a requirement of completeness before a period is considered the current period; second, where there is an scenario dimension, current period will usually mean actual data, so that periods for which planned or budget data only has been loaded should not be considered. While this particular problem has been explored by Ralph Kimball (see Related articles) in terms of Data Warehouse design, when thinking about cubes different rules apply.

Previous period: Many applications require calculated members to compare a given period with a previous period. This could be the last month, or the same month from last year, and from here it usually gets worse. The nice thing about this kind of members is that they may build upon your existing roll-up problems and also define the “current previous period”. While you may try to “forget” asking users if they need this functionality, it is advisable to know as soon as possible, even if you decide to leave implementation for version 2.