Modeling Relative Time as Measures

Proven Practice

IBM Cognos 8 Framework Manager - Modeling Relative Time

as Measures

Product(s): IBM Cognos 8 and IBM Cognos ReportNet

Area of Interest: Modeling

IBM Cognos 8 Framework Manager - Modeling Relative Time as Measures 2

IBM Cognos Confidential Information

Copyright Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. Cognos does not accept responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to [email protected] .



Contents

1 INTRODUCTION ............................................................................................ 4

1.1 PURPOSE ................................................................................................................ 4 1.2 APPLICABILITY ......................................................................................................... 5 1.3 EXCLUSIONS AND EXCEPTIONS ..................................................................................... 6

2 VERIFICATION OF RESULTS ......................................................................... 6

3 EXAMPLE ....................................................................................................... 8

4 SAMPLE OFFSET TABLE ............................................................................... 15

5 ATTACHMENTS ............................................................................................ 17



1 Introduction

1.1 Purpose

This document outlines a solution for the problem of providing simpler handling of relative time dimensions and associated period-on-period calculations. It is similar to other relative time solutions in the respect that it provides similar functionality. For example; Current Month and Previous Month, 3 Months Ago, 12 months ago, rolling 3 months, rolling 12 months, etc.

One of the many outstanding features of the solution is that non-technical business authors (also known as casual ad-hoc or Query Studio users) can be provided drag-and-drop access to simple, but powerful, relative time features. This allows straightforward creation of period-on-period reports/analyses, also known by some users as “side-by-side” reports.

The figure below shows a very simplistic (non-finessed) example in Query Studio utilizing this solution [note: TP=this period, LP=last period].

Figure 1 - Simple Query Studio example

This technique enables the Data Modeler to develop a solution using a regular modeling approach and does not require the usual manipulations nor calculations in the model. More importantly, a Professional Author (Report Studio user) is not required to create the report calculations typically required. The period offset table in this technique allows a fact table to be joined on the current period and an alias of the fact table to be joined on a key referencing another relative period.

The result is that a single query subject or measure dimension can be created to contain the fact table key (product, etc) and a field from the first fact table instance (e.g. current period sales amount) and the same field from the second instance of the fact table (e.g. previous period sales amount).

The relative time evaluation of the fact data is implemented with joins rather than calculations so that the values returned to the author are as shown as distinct columns; i.e. a column for each of current period and previous period. A report author can simply drag and drop the two columns into a report and the current and previous values will be displayed beside each other. To calculate the growth from previous to current priod a calculation can be created in the report or model that references the distinct data items created for each period-specific measure.



1.2 Applicability

This solution has been tested with IBM Cognos 8 MR1 and MR2 using SQL Server 2000. Potentially, the solution should work with IBM Cognos 8 and earlier on any platform with any supported relational data source. However for performance reasons, it is highly recommended to use a RDBMS that supports the COALESCE function and full outer construct required to process the full query definition when using multiple period-specific data items. Using such an RDBMS avoids generation of queries which require local processing by the IBM Cognos query engine.

Reassure the DBA that no data need be duplicated, the only additional structures required to make this work are a Period table (Date Dimension) and an Offset Period table (a bridge to relate the multiple fact aliases). These are described in more detail later.

This approach can be further enhanced to handle calculations involving “null” values. To explain, a change or growth calculation where the prior month value is null will also result in the change and growth also appearing as null. This is because a null value is not treated as zero in a database.

Here is an example of the effect:

Figure 2 - Demonstration of the effect of null/missing values

If you wish to be able to treat null values as zero, then either utilize the isnull or if-then-else functions to return a zero value instead of a null. This is something the modeler should investigate with the user community prior to publishing the package.

It is worth noting that the modeler cannot account for all user interactions with the model. An example might be where a user provides an inappropriate filter (e.g. 2003-Q1), but is expecting values for the current period (e.g. 2004-Q1). In this instance, the user has effectively pegged the current period at 2003-Q1 and the prior quarter would automatically be relative to this, i.e. 2002-Q4.

Similarly, end users should be aware that rolling and period-to-date measures are semi-aggregates. This means that at higher levels in the time hierarchy the aggregation of rolling and period-to-date values from the lowest level grain will be invalid. For example, if the Quarter-To-Date measures at the month level were rolled up to the Quarter the value would double-count several of the months. This is because of the following:

January QTD = January values

February QTD = January values + February values

March QTD = January values + February values + March Values



The rollup calculated for the Quarter level is, by default, the sum of the values from the lower levels so:

Q1 QTD = January QTD + February QTD + March QTD

Q1 QTD = (January values) + (January values + February values) + (January values + February values + March Values)

Q1 QTD = 3 * January values + 2 * February values + 1 * March values

Users should be aware of this so that invalid aggregates are not performed on rolling and period-to-date measures.

1.3 Exclusions and Exceptions

This technique is not applicable for daily grain fact data. The number of days in a month is inconsistent and for months such as February the offset table will only allow the first 28 days of the prior month to be reported as there are no matching days for the 29th or 30th of January based on the February time data.

2 Verification of Results

As with any solution upon which important business decisions will be made, it is suggested that you verify/validate the results returned from this approach. Use quick test reports (simple Query Studio ones are perfect) to check results generated match those which the source system or database would produce.

If you obtain unexpected results, this is likely to be due to an overlooked detail in one or more of these areas: cardinality, determinants, and star schema groupings. All of these items can impact query generation. Incorrectly specified information in these listed areas can result in incorrect results being returned; hence the importance of simple verification/validation testing.

As a brief high level synopsis, each is described below. However, for definitive descriptions on their settings and use, please refer to the Framework Manager User Guide and metadata modeling guidelines.

Cardinality indicates the nature of the relationship between two objects, e.g. a dimension table and a fact table. Cardinality affects query generation by applying rules regarding the outcome of joins between objects and granularity. You must ensure cardinality is accurately represented.

Determinants are a tool for explicitly addressing granularity in data. It is worth knowing that during the initial import of database metadata, Framework Manager attempts to determine these automatically based on the structure of your database (keys, indexes, relationships and constraints). Ensure that the determinants created on query subjects during metadata import are accurate and/or specify additional determinants as required.



Star schema groups can make the model more intuitive for end users and facilitate multiple-fact reporting by providing context for queries with ambiguous joins (e.g. circular/loop joins). Star schema groups are not normally required for the approach described in this document but be aware that they might be required in some cases depending on the complexity of the data structures you are modeling.



3 Example

This example works with any fact table containing a relationship to a date dimension although depending on the format of the date key the period and offset tables may change. You can see in the data layer, there are two instances of the fact table: premium_summary and premium_summary1. Here is a simple example:

Figure 3 – Simple model representation of approach



Here’s a more complex example that includes multiple instances of the fact table. By prefix, you can see each one represents a different time period based on the relationship to the offset table. CM is current month, PM is previous month, PQ is previous quarter, and PY is previous year. The tables on the right, which start with d_, are other dimensions that join to the fact(s).

You can see that the Periods table relates directly to the current month fact table instance (prefixed CM), but the prior month fact table instance (prefixed PM) ties back via the Prior Month field in the Offset table. In a similar fashion, the PQ instance ties back via Prior Quarter, and the PY instance ties back via the Prior Year.

Figure 4 - Expanded model showing approach used with additional period comparisons and more dimensions.



Continuing with the complex example, here is a screen shot of the presentation layer data. You will see that it is made up of several items:

� Periods – allowing Calendar Year or Month Name to be dragged into the report and possibly filtered on

� Dimensions – containing just the description, for example products in a sales dimension

� Period Amounts – there are folders for each of the following; Current Period Amounts (partially shown), Last Period Amounts, Last Quarter Amounts, and Last Year Amounts

� And more…



Figure 5 - Model query subject, exposed for end-user



The way the Query Items are defined are shown in the upcoming screen shots. Basically, it is the Periods followed by the measures from the first instance of the fact table (current month), followed by the previous period amounts (when merging query subjects the second instance of a data item is appended with a “1” to make the data item name unique but you can rename them to more appropriately describe the relationship to the target period), and then the remaining periods. Each of these are referring to the same measure, but from a different period instances of the fact table. The different instances are from the appropriate period as defined in the offset table. The next few pages will show you the screen shots paging down part way into the measures as an example:

Figure 6 - Model query subject - detail, part 1 of 3







You can see by the above examples that this can allow ANY fact tables that are using a Time dimension to easily adapt for showing Relative Time.

The end result is that authors can easily drag in a column representing the human readable value for a particular time frame, such as Qtr 1 2007 or February 2008 or FY 2008, etc. They can also drag in a unique column that references the current or previous period (month, quarter, year, or whatever you define). Effectively, if you had a measure called Gross Sales, you could have columns such as Gross Sales Current Mo, Gross Sales Last Mo, Gross Sales Last Quarter, Gross Sales Last Year, etc. These would no longer need to be calculated by either the modeler or the report author.

Note here the change from cm_xxx fields to pm_xxx fields.



4 Sample Offset Table

You will need to build your Periods table to your desired specifications and your offset may be different than shown here based on your business needs. Examples of both are provided below.

Period_No Year Year_No Qtr Qtr_No Qtr_Name Mth Mth_No Mth_Name_Long Mth_Name_Short Period_End

200303 2003 2003 2003-Q1 1 Q1 2003-03 3 May May 05/31/2002 200306 2003 2003 2003-Q2 2 Q2 2003-06 6 August Aug 08/31/2002 200309 2003 2003 2003-Q3 3 Q3 2003-09 9 November Nov 11/30/2002 200312 2003 2003 2003-Q4 4 Q4 2003-12 12 February Feb 02/28/2003 … … … … … … … … … … …

Figure 9 - Example Periods table

Period_No Prior_Period_No Prior_Qtr_Period_No Prior_Year_Period_No

200303 200302 200212 200203

200306 200305 200303 200206

200309 200308 200306 200209

200312 200311 200309 200212

… … … …

Figure 10 - Example Offset Period table

Although the Periods table and Offset Periods tables are shown as discrete objects, these can also be combined/condensed in a single entity – i.e. a periods table that includes the period offsets or a degenerate query subject.

For rolling periods and period-to-date aggregates the following is an example of the fields required in the offset table. The prior examples in this document use a fact table with the period-to-date aggregates already defined. The addition of these columns to the offset table is only applicable when the fact table does not have precomputed values for the rolling or period-to-date aggregates.

Period_No Prior_Year_Period_No

Rolling_3M_Period_No

Rolling_6M_Period_No

QTD_Period_No

YTD_Period_No

Prior_Year_QTD_Period_No

200301 200201 200211 200208 200301 200301 200201

200302 200202 200212 200209 200301 200301 200201

200303 200203 200301 200210 200301 200301 200201

200304 200204 200302 200211 200304 200301 200204

200305 200205 200303 200212 200304 200301 200204

200306 200206 200304 200301 200304 200301 200204

200307 200207 200305 200302 200307 200301 200207

200308 200208 200306 200303 200307 200301 200207

200309 200209 200307 200304 200307 200301 200207

200310 200210 200308 200305 200310 200301 200210

200311 200211 200309 200306 200310 200301 200210

200312 200212 200310 200307 200310 200301 200210

… … … …

The join to the columns for the rolling or to-date periods would include a between clause to obtain the appropriate date range from the fact tables. For example, the Rolling 3 Month join expression would use:

Fact.Period_No between Offset.Rolling_3M_Period_No and

Offset.Period_No



For rolling and to-date aggregates for prior periods a combination of the prior period number and the new rolling or to-date period number. For Prior Year QTD the following would be an example of the required join expression:

Fact.Period_No between Offset.Prior_Year_QTD_Period_No and

Offset.Prior_Year_Period_No

While it is possible to determine the appropriate rolling period numbers based on the period number itself, the calculation of these values during the evaluation of a join can eliminate index selection. This may reduce the performance of the query when incorporating the new aliased fact tables in a report.

However, if the nature of the period selection required for reporting is arbitrary then it may not be possible to incorporate all periods into the offset table. This situation may take place when user requirement specify that any number of months can be incorporated into a rolling period aggregate rather than a predefined set such as 3, 6, 9, and 12 rolling months ranges. In this case it will be necessary to incorporate calculations to define the appropriate period numbers to be used in the join expressions. For the case of relative time comparisons any required prompts should be defined in the relationship definition between the offset table and the aliased fact table so that users are not prompted unnecessarily when accessing other aliased fact tables through the offset table. To make these calculations easier the offset table should be modified to include a date field representing the Period Number.

Period_No Period_Date Prior_Period_No Prior_Qtr_Period_No Prior_Year_Period_No

200303 03/01/2003 200302 200212 200203

200306 06/01/2003 200305 200303 200206

200309 09/01/2003 200308 200306 200209

200312 09/01/2003 200311 200309 200212

… … … …

The relationship for an arbitrary number of rolling months would be:

Fact.Period_No between extract(year,_add_months(Offset.Period_Date,-

?Rolling Months?))*100+

extract(month,_add_months(Offset.Period_Date,-?Rolling

Months?))_3M_Period_No and Offset.Period_No

The functions listed above are generic IBM Cognos functions. Note that it may be possible to streamline the expression by using functions available from the native database query engine. Consult the documentation provided by your database software vendor for available functions and syntax.



5 Attachments

Provided with this document is a sample of this technique based on the GO Data Warehouse sample data provided with IBM Cognos 8. The model was created using the MR2 release of Framework Manager and includes a demonstration of incorporating the measures as part of a Dimensionally Modeled Relational (DMR) package. Here the measures defined for the Relative Time periods are incorporated into a Measure Dimension rather than merged into a new query subject.

Modeling Relative Time as Measures

Documents