Dimensional Modeling for Time Period Analysis

Tip or Technique

IBM Cognos 8 Framework Manager - Dimensional Modeling

for Time Period Analysis

Product(s): IBM Cognos 8

Area of Interest: Modeling

IBM Cognos 8 Framework Manager - Dimensional Modeling for Time Period Analysis 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 APPLICABILITY ......................................................................................................... 4

2 IMPLEMENTATION........................................................................................ 4

2.1 STEP 1: REPLICATE THE FACT TABLES............................................................................ 5 2.2 STEP 2: ADD YTD TIME DIMENSION ............................................................................. 6 2.2.1 Create a new data source query subject. ................................................................ 7 2.2.2 Create Relationships.............................................................................................. 8 2.2.3 Define Determinants on the YTD_MONTHLY_ROLLUP Query Subject ..................... 13 2.2.4 Test the Data Source-level Implementation .......................................................... 16 2.2.5 Previous Year to Date.......................................................................................... 17 2.3 STEP 3: ADD DIMENSIONS........................................................................................ 17

3 STUDIOS TEST ............................................................................................ 21

4 APPENDIX A – SAMPLE MODEL................................................................... 23



1 Introduction

Implementing time period analysis as a part of the reporting solution is a popular requirement that comes from customers who implement financial reporting that allows calculating and comparing rolled up metrics for various periods, such as Year-to-Date, Previous-Year-to-Date and Quarter-to-Date, etc.

Built-in support for time period analysis is common to analytical engines in other multi-dimensional data storage products. This document discusses one technique for applying modelling concepts to allow time period analysis on relational data sources which do not have native support for this functionality.

The examples will be based on the GOSLDW data source and “GO Data Warehouse” model provided with the IBM Cognos 8 samples.

1.1 Applicability

This document applies to IBM Cognos 8.

2 Implementation

This section will illustrate the solution that implements a Year-To-Date rollup, YTD. General discussion on dimensional modelling concepts and techniques is covered in product documentation and will not be reiterated within this document.

YTD rollups can be implemented in the Framework Manager model rather than by using the time based OLAP functions (such as periodsToDate, etc.) in the Report Studio. While the OLAP functions can be used to implement the desired behaviour they cannot be implemented in Query Studio due to the ad-hoc relational nature of the tool. Also, when using these functions they must be created on a report by report basis rather than once as with the technique outlined in this document.

The fact tables from the GOSLDW sample data source (selected for portability) that are used in this example are SALES_FACT and PRODUCT_FORECAST_FACT. These tables also allow demonstration of data handling and rollup at multiple levels of granularity.



The SALES_FACT table stores data at the day level. There are several date keys that describe this level of granularity: ORDER_DAY_KEY, SHIP_DAY_KEY, and CLOSE_DAY_KEY. For the sake of this example the first date in the order pipeline, ORDER_DAY_KEY, will be used.

Figure 1: SALES_FACT Query Subject

The PRODUCT_FORECAST_FACT table stores data at the month level. The key representing this level of granularity is the MONTH_KEY column.

Figure 2: PRODUCT_FORECAST_FACT Query Subject

Generally, the implementation is performed in three stages: replicating the fact tables for the respective rollups, building a new conformed YTD time dimension(s) to link the fact tables, and adding dimensional structure to ensure appropriate aggregation at multiple levels of fact granularity.

2.1 Step 1: Replicate the Fact Tables

The multiple references to the individual fact tables allow for greater flexibility when generating a query. The individual tables for each time period rollup allow a query to reference the same measure (i.e. EXPECTED_VOLUME) for multiple periods simultaneously, i.e. both the current month and YTD, side by side in the same query and to perform calculations between the resulting values.



Create “replica” fact tables in your model by copying and pasting the original query subjects. By copying the query subject the relationships to other dimensions will be preserved. This will save some modelling time and effort as the relationships to non-time dimensions will remain the same for the new fact tables. Rename the new query subjects as SALES_FACT_YTD and PRODUCT_FORECAST_FACT_YTD respectively.

2.2 Step 2: Add YTD Time Dimension

In order to query from these two fact query subjects a conformed time dimension is needed to relate the data and allow rollup of the values to a higher levels of granularity. For example, daily data in SALES_FACT will be rolled up to the monthly level so the numbers can be properly compared to the PRODUCT_FOREAST. Alternately the monthly grain data in PRODUCT_FORECAST can be allocated down to a lower level of granularity, to the day, without affecting the rollup at higher levels.

Indeed, a conformed TIME_DIMENSION exists in GOSLDW that allows querying across these and other facts with different levels of granularity. However, the existing time dimension does not have sufficient detail or flexibility to allow for relative time rollup so a new time dimension must be created.

The new time dimension will be based on the existing time dimension table but will implement additional logical constructs in the Framework Manager model.

There have been several approaches published in the past that implemented the YTD time dimension as a reasonably expensive UNION-type query. These were created because the studios in Cognos ReportNet did not allow for multi-edge disjoint queries1 as is possible in Cognos 8.

Other solutions have also implemented a prompting scheme to identify the required target periods (i.e. a current period prompt that is used to determine a date range) for the time dimension that would relate different data sets. In general, supplying prompts to limit the data volume based on a target set of dates is necessary due to volume-driven performance considerations. In this example, prompts will be defined for both year and month although other prompting scenarios are equally valid.

1 A disjoint crosstab can be created by placing information from both the Time and Product

dimension on the crosstab rows. The query on the report layout is said to be “disjoint” when the information on an edge (rows or columns for example) is made up from multiple different

dimensions.



In the following examples, the calculations and additional logic for the time dimension are implemented in the SQL expression of a data source query subject. The choice of this approach is for the ease of demonstrating the Time Period Analysis technique. Greater modelling flexibility, reuse, and optimization during query generation can be achieved through using objects in Framework Manager such as model query subjects, calculation and filter objects within a model query subject, or stand-alone calculation and filter objects within the model.

2.2.1 Create a new data source query subject.

Use the following SQL for your YTD time dimension named YTD_MONTHLY_ROLLUP:

Select

'YTD by Month' as ROLLUP_PERIOD ,

TIME_DIMENSION.DAY_KEY as DAY_KEY,

TIME_DIMENSION.MONTH_KEY,

TIME_DIMENSION.MONTH_#$Language_Lookup{$runLocale} # as MONTH_NAME,

TIME_DIMENSION.QUARTER_KEY,

TIME_DIMENSION.CURRENT_QUARTER,

TIME_DIMENSION.CURRENT_YEAR,

# prompt( 'MONTH')# as SELECTED_MONTH_NUMBER,

# prompt( 'YEAR')# as SELECTED_YEAR

from

[go_data_warehouse].TIME_DIMENSION TIME_DIMENSION

where

CURRENT_YEAR = # prompt( 'YEAR')#

and CURRENT_MONTH<= # prompt( 'MONTH')#

Note the prompt macros and the WHERE clause in the SQL2. These filter conditions will return all records that are prior or within the month selected by the user, within the context of a year. For example, if user selects February 2006, this statement will return data for January and February 2006. Since the YTD Time Dimension is at a daily level at its lowest granularity the query will return 60 rows for these two months. The data in the fact tables will be aggregated over these records.

2 These structure of these prompts can be modified to suit other reporting requirements. In this case the prompts are for integer components of a date. In other scenarios a date type

prompt may be more appropriate. When using a date prompt the SELECTED_MONTH_NUMBER and SELECTED_YEAR columns in the query can be extracted

from the date prompt using the appropriate native or Cognos function expression.



There are also prompt macros as a part of the SELECT statement. These are needed to build a key that can be used to join this new dimension to the non-YTD facts that are at the month level.

By adding a calculated query item called SELECTED_MONTH_KEY to your YTD Time dimension a key can join the time dimension to the query subjects that will not be rolled up into a YTD aggregate, i.e.:

cast([Database Import].[YTD_MONTHLY_ROLLUP].[SELECT ED_YEAR] , integer)

* 100 + cast([Database

Import].[YTD_MONTHLY_ROLLUP].[SELECTED_MONTH_NUMBER], integer)

The result will be a numeric value that is similar to TIME_DIMENSION.MONTH_KEY, i.e. 200602 for February 2006.

At the end, your new query subject will look like this:

2.2.2 Create Relationships

New relationships to both the “current” and “YTD” fact tables can now be created to the new time dimension. As with all conformed dimensions, the relationships will have 1:1 on the dimension side and 1:n on the fact side.

For the YTD fact tables the appropriate keys need to be used. For SALES_FACT_YTD the relationship is on the ORDER_DAY_KEY.



Figure 3: Relationship between SALES_FACT_YTD and YTD Time Dimension



The relationship for PRODUCT_FORECAST_FACT_YTD is constructed using MONTH_KEY because the table granularity is at the month level.

Figure 4: PRODUCT_FORECAST_YTD and YTD Time Dimension Relationship



Relationships need to be a bit different for the non-YTD (i.e. Current Month) facts. There you do not want aggregations that are coming from the “less or equal” operator in the WHERE clause and need to only return data for the selected month. This is where the SELECTED_MONTH_KEY is used. These relationships need to be edited manually, like in the screenshots below:

Figure 5: Edited relationship for SALES_FACT and YTD Time Dimension



A similar approach is implemented with the other “current date” fact table.

Figure 6: Edited relationship for PRODUCT_FORECAST_FACT and YTD Time Dimension



The resulting simplified schema looks like the following:

Figure 7: YTD Schema

2.2.3 Define Determinants on the YTD_MONTHLY_ROLLUP Query Subject

This step is extremely important to assure that proper rollups occur and that there is no double-counting due to the differing levels of granularity in the fact data. There are four period levels and the Day level is unique.

Figure 8: Determinants



Here are the level definitions for this sample model. See the Framework Manager User Guide for additional details on creating determinants in IBM Cognos 8.

Figure 9: Year Determinant

Figure 10: Quarter Determinant



Figure 11: Month Determinant



Figure 12: Day Determinant

2.2.4 Test the Data Source-level Implementation

In IBM Cognos 8, you can test the query directly in Framework Manager. While holding Ctrl key, select ROLLUP_PERIOD from your YTD_MONTHLY_ROLLUP query subject, as well as Quantity from SALES_FACT and the same measure from SALES_FACT_YTD. Also select EXPECTED_VOLUME from both PODUCT_FORECAST_FACT and the YTD version of the fact table. Right-click the selection and choose “Test” from the context menu.

Figure 13: Test Query Items

You will be prompted for a month and year based on the prompts defined in the new time dimension. Enter 2 for the month and 2006 for the year. After the query runs for the first time, check the “Auto Sum” option and re-run it. For February 2006 the result will look like this:



Figure 14: Test Result – data source level

In this result set, Quantity represents the number for Current Month and Quantity1 represents the YTD. Similarly, Expected Volume represents the Current Month and Expected Volume 1 is the YTD rollup for February 2006. As you can see, these metrics can be queried side by side even at the very basic data source level.

2.2.5 Previous Year to Date

Once the YTD_MONTHLY_ROLLUP query subject is implemented, adding previous year to date is a breeze. Create a copy of your YTD_MONTHLY_ROLLUP query subject (the copy process will create the required relationships automatically) and rename it to “PYTD_ MONTHLY_ROLLUP”. Within the SQL statement, subtract one from the year calculations. Note that the change needs to be made in both Select and Where sections.

Select

'PYTD by Month' as ROLLUP_PERIOD ,

TIME_DIMENSION.DAY_KEY as DAY_KEY,

TIME_DIMENSION.MONTH_KEY,

TIME_DIMENSION.QUARTER_KEY,

TIME_DIMENSION.CURRENT_QUARTER,

TIME_DIMENSION.MONTH_#$Language_Lookup{$runLocale} # as MONTH_NAME,

TIME_DIMENSION.CURRENT_YEAR,

# prompt( 'MONTH')# as SELECTED_MONTH_NUMBER,

(# prompt( 'YEAR')# - 1) as SELECTED_YEAR

from

[go_data_warehouse].TIME_DIMENSION TIME_DIMENSION

where

CURRENT_YEAR = ( # prompt( 'YEAR')# - 1)

and CURRENT_MONTH<= # prompt( 'MONTH')#

2.3 Step 3: Add Dimensions

Dimensions need to be created in order to utilize OLAP-style analytics in C8.



Here we can define two measure dimensions – one for SALES

Figure 15: Facts of the Sales Measure Dimension

and one for PRODUCT FORECAST.

Figure 16: Facts of the Product Forecast Measure Dimension

The replication of fact tables is not necessary anymore as one measure dimension can contain both Current and YTD metrics.

In addition we will create regular dimensions for YTD Time, PYTD Time and incorporate additional dimensions, such as PRODUCTS. The two time dimensions will be created in an identical manner, each source from the appropriate data source query subjects (YTD and PYTD). Here is an example for the YTD regular dimension.



Figure 17: YTD Regular Dimension Hierarchy – Year Level

Figure 18: YTD Regular Dimension Hierarchy – Quarter Level



Figure 19: YTD Regular Dimension Hierarchy – Month Level

Use an appropriate key for business key on each one of the levels, such as MONTH_KEY for Month, QUARTER_KEY for Quarter and CURRENT_YEAR for Year. For a member caption, use descriptive strings. The following is a sample caption calculation for the Month level caption:

'YTD Itemized by ' +

[Database Import].[YTD_MONTHLY_ROLLUP].[MONTH_NAME]



Add other dimensions as you normally would, so your dimensional layer looks something like this:

Figure 17: Dimensional Layer with scope relationships

Publish the package; to the queries are ready to be used it in the studios.

3 Studios Test

In Report Studio, a report can now be created that contains both YTD and PYTD dimensions as well as the measures at different levels of granularity (i.e. multi-fact, multi-grain query).

The following is a screen capture of a PDF report that shows the output of such a report.



If drill up / down is enabled, we can drill on both the product hierarchy and the rollup times (i.e. to itemize by quarter).

This can be also shown in the Query Studio as in the screenshots below:

Figure 21: Drill Down in Query Studio



This query first shows general Quantity YTD rollup for June 2006. As you drill down the YTD total itemized by quarters is displayed followed by the lowest level itemized by months within the second quarter. Note that the current month amount does not change as it is fixed in place by filtering.

4 Appendix A – Sample Model

The sample model zipped below was created using Framework Manager 8.2.

go_data_warehouse.zip

Documents

Dimensional Modeling for Time Period Analysis