You are on page 1of 21

Proven Practice

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager
Product(s): IBM Cognos ReportNet, IBM Cognos 8, IBM Cognos 10 Area of Interest: Modeling Flexibility

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

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 cscogpp@ca.ibm.com .

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager Contents
1 1.1 1.2 1.3 2 3 3.1 3.2 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6

INTRODUCTION....................................................................................................4 PURPOSE..................................................................................................................4 APPLICABILITY.............................................................................................................4 EXCLUSIONS AND EXCEPTIONS...........................................................................................4 MINIMIZED SQL....................................................................................................5 METADATA CACHING.............................................................................................6 WHAT IS METADATA CACHING?..........................................................................................6 WHEN CAN METADATA NOT BE CACHED?................................................................................6 USING PARAMETER MAPS......................................................................................8 SQL IN DATA SOURCE QUERY SUBJECTS..............................................................................9 MODEL MAINTENANCE..................................................................................................10 CALCULATION AND FILTER OBJECTS...................................................................................12 USING PROMPTS.................................................................................................14 SQL IN DATA SOURCE QUERY SUBJECTS............................................................................14 MODEL MAINTENANCE..................................................................................................15 CALCULATION AND FILTER OBJECTS...................................................................................16 GENERAL RECOMMENDATIONS............................................................................16

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

1 Introduction
1.1 Purpose This document outlines proven practices for using prompts and parameter maps in ReportNet and IBM Cognos BI (Framework Manager) to increase model flexibility, decrease maintenance, and improve performance. This document addresses the effects of parameter maps and prompts on SQL generation. Other factors such as dimensional information and determinants play a role in generating SQL, but that is not covered in this document. Differences between Model Query Subjects (MQS) and Data Source Query Subjects (DQS) will be touched on where applicable. 1.2 Applicability The techniques and product behaviours outlined in this document apply to IBM Cognos ReportNet (tested in MR2), IBM Cognos 8.x., and IBM Cognos 10. All versions will be referred to as IBM Cognos BI in this document except where version specific information is required. 1.3 Exclusions and Exceptions Statements regarding metadata caching behaviours may change in future releases.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

2 Minimized SQL
The query engine behind IBM Cognos BI works to reduce the SQL where possible to the least set of columns and tables required to process a given query. The benefit to this is that with the minimal set of columns and tables included in a SQL expression then the database query planner is more likely to use the optimal path for returning the required data. This applies equally to indexes and materialized query tables that the given database may have in place. A good example of this is querying a table, TableA, which has an aggregated view based on ColumnA and the sum of ColumnB. The following statement would trigger the use of the pre-computed aggregate data from the database: SELECT ColumnA, SUM(ColumnB) FROM TableA GROUP BY ColumnA However, including a column that is not included in the aggregated dataset would force the query planner to disregard the pre-computed aggregates as a possibility for resolving the query. An example of such a statement would be: SELECT ColumnA, ColumnC, SUM(ColumnB) FROM TableA GROUP BY ColumnA, ColumnC The inclusion of ColumnC could potentially result in a full scan of TableA if there are no other aggregates or indexes to prevent such an access path. Keep in mind that many databases provide query rewrite capabilities. With such a feature the SQL statement will be rewritten into another statement that is functionally equivalent. So if we take the following example SELECT T1.ColumnA, SUM(T1.ColumnB) FROM (SELECT ColumnA, ColumnC, SUM(ColumnB) as ColumnB FROM TableA GROUP BY ColumnA, ColumnC) as T1 GROUP BY ColumnA then by rewriting this statement to the functional equivalent, we get the same result as the first example statement SELECT ColumnA, SUM(ColumnB)

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager FROM TableA GROUP BY ColumnA The above example shows how query rewrite serves to reform the SQL into the functional equivalent without derived tables or unnecessary column references. However, for the sake of those databases which are not capable of such rewrites and to make the SQL more legible, the aim of a modeller should be to create query subjects that are legible, efficient, and maintainable.

3 Metadata Caching
3.1 What is metadata caching? Metadata in the context of Framework Manager is all the information stored within the model that describes the objects within a data source and the manipulated objects created from your data source. In most standard scenarios, all the properties required to describe an object in Framework Manager will be captured during the import from a data source. However, there are times when changes to the model will result in query subjects that could potentially have varying properties. In cases where the metadata cannot be cached in the model, then when running a report the information must be fetched from the data source directly. Once the information is fetched from the data source, it will be cached for the duration of the connection to the data source. However, retrieving the metadata from a data source can add overhead to your complex reports. 3.2 When can metadata not be cached? There are several main items which will disable the ability to the metadata stored within the model.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

1. Enabling the Allow enhanced model portability at run time option in the project governors will force the fetching from the database. Turning on this governor disables the use of metadata from the model. Unless the model is being used in multiple environments where the columns in the database could potentially change in data type then this setting should be left disabled during production use of the model. There are cases such as during a model upgrade from ReportNet to IBM Cognos 8 and higher where the metadata should not be preserved so that a subsequent resynchronization of the model can appropriately update the data types of the modelled data items.

Note: The Governors dialog may appear differently depending on which version of IBM Cognos Framework Manager you are working with.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

2. Modifications to a DQS SQL expression can also disable caching of the metadata. This depends on the complexity of the statement. However for most scenarios the reasons for modifying a SQL expression are non-trivial and the changes will most often result in a non-trivial SQL statement where metadata cannot be cached. Using Parameter maps, Prompts, aggregates or filters within a DQS SQL expression will result in retrieval of the metadata from the database rather than capturing the information within the model. In the IBM Cognos 8 MR1 release and beyond, it is possible to get feedback on metadata caching within Framework Manager. When testing a query, there is additional information provided on the Query Information under Response. As seen below there is an informational message provided when metadata cannot be cached in the model.

The following sections will outline options for designing Framework Manager models to avoid this behaviour. However, in existing models, it may prove difficult to redesign according to the following sections. In such cases it is possible to create a set of query subjects to provide the cached metadata. To do so, one would create a new namespace and import all of the tables into this new namespace. By leaving these newly imported query subjects unmodified Framework Manager will be able to reference them as the trivial DB query subject required to satisfy the metadata calls for other queries in the model.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

4 Using Parameter Maps


Parameter maps are an invaluable method for substituting expressions and values into a query subject. A prime example of this functionality is available within the GO Data Warehouse sample model where a parameter map serves to provide the capabilities for reporting in multiple data languages depending on the user locale preference settings. An additional common application would include replacing data source connection information based on the user logon. Any place where a static framework for a query subject is required but the detailed definition within the query is variable would be a place where a parameter map can be applied. 4.1 SQL in Data Source Query Subjects In earlier versions of the GO Data Warehouse sample you will find the parameter map Language_lookup being used in the Product line DQS as follows: Select PRODUCT_LINE.PRODUCT_LINE_CODE, PRODUCT_LINE.PRODUCT_LINE_#$Language_lookup{$runLocale} # AS PRODUCT_LINE from [go_data_warehouse].PRODUCT_LINE The parameter map is keyed to the runLocale and provides the appropriate postfix to the column reference in the SQL statement. In the case of an English locale (en, en-us, en-ca, etc.) the statement would select the PRODUCT_LINE_EN column for use within this DQS while French locales would use PRODUCT_LINE_FR. This example is the key to providing multilingual data to report authors without complicated user interaction to pick the desired language column for their reporting. Obviously this is a valuable technique but there are a couple of items to consider for the above example. The first item for consideration is that the use of the parameter map in the SQL of a DQS means that the statement is no longer trivial and the SQL cannot be minimized. As a result you would expect to see the above statement as a derived table when used in your report queries regardless of whether you are selecting one or both of the columns defined by this query subject.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

10

Second, the metadata for the query subject cannot be cached in the model because the definition of the PRODUCT_LINE column is dynamic in nature. From one locale to the next you may receive different columns or expressions with potentially different data types. The end result is that a call must be made to the database when the query is executed to determine the properties of the relevant column used by PRODUCT_LINE.

4.2

Model Maintenance The core of creating any maintainable application is in making the application readable and making the change process easy for future administrators. Parameter maps are extremely useful for building flexibility into models based on prompts or session parameters. Unfortunately it is easy to get carried away and build too much into being dependent on parameter maps to satisfy a request. Such overuse can result in query subjects that are difficult to maintain. First, the dialog for creating Parameter Maps is not a full-fledged expression editor because the information stored within a parameter map is most often a fragment of an expression rather than a full, syntactically correct, statement. Using long values in the parameter map interface can become a maintenance issue as the expressions may not be fully visible within the frame allocated for the parameter map value. Second, when using parameter maps one must always consider how information is stored within the parameter map values. The values are actually stored as static strings without reference to any other objects in your model. The values exist unto themselves and are not evaluated for syntax validity within the context of a query. When testing a query subject it is only possible to validate one value from the parameter map at a time. For example, a parameter may contain a value which is badly formed or has syntax errors. If the query subject that uses the parameter map does not reference the malformed value when testing then the developer will not be aware that the invalid syntax is present in the parameter map until reports begin to call the invalid parameter map value containing the malformed syntax. For the sake of maintaining and validating complex calculations a better approach is to create the expressions as individual calculation objects. This way the validity of all the expressions can be checked immediately and feedback on individual calculations which may be syntactically invalid will be displayed within the full-fledged expression editor.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

11

A parameter map can then be created to reference these calculations rather than storing the full calculation expression itself. Similarly, filters can be created as filter objects within the model and a parameter map can reference the filter object from the model rather than defining the full Boolean expressions within the parameter map values.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

12

Additionally, the overuse of parameter maps can obfuscate the purpose of a query subject by making it unclear to anyone other than the original author. The following DQS definition is an example of such a scenario: Select #$Time_Lookup{'DAY'}#, #$Time_Lookup{'WEEK'}#, #$Time_Lookup{'MONTH'}#, #$Time_Lookup{'QUARTER'}#, #$Time_Lookup{'YEAR'}#, #$Time_Lookup{'W_'+$Language_lookup{$runLocale}}# as WEEKDAY, #$Time_Lookup{'M_'+$Language_lookup{$runLocale}}# as MONTH1 from [go_data_warehouse].TIME_DIMENSION Based on the use of the Time_Lookup parameter map there is no way of telling what the resulting SQL will return by visual inspection. In this particular instance the parameter map was constructed to mimic the original Time dimension query subject from the GO Data Warehouse samples which has the following structure: Select TIME_DIMENSION.DAY_KEY, TIME_DIMENSION.DAY_DATE, TIME_DIMENSION.MONTH_KEY, TIME_DIMENSION.CURRENT_MONTH, TIME_DIMENSION.QUARTER_KEY, TIME_DIMENSION.CURRENT_QUARTER, TIME_DIMENSION.CURRENT_YEAR, TIME_DIMENSION.DAY_OF_WEEK, TIME_DIMENSION.DAY_OF_MONTH, TIME_DIMENSION.DAYS_IN_MONTH, TIME_DIMENSION.DAY_OF_YEAR, TIME_DIMENSION.WEEK_OF_MONTH, TIME_DIMENSION.WEEK_OF_QUARTER, TIME_DIMENSION.WEEK_OF_YEAR, TIME_DIMENSION.WEEKDAY_#$Language_lookup {$runLocale} # AS WEEKDAY, TIME_DIMENSION.MONTH_#$Language_lookup {$runLocale} # AS MONTH1 from [go_data_warehouse].TIME_DIMENSION

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

13

The second statement shows a much clearer purpose for the time dimension and makes it immediately obvious which columns are required for the query subject. The prior version using the Time_Lookup map hides the fact that several of the parameter map keys return collections of columns to the query subject definition. The DAY key for example returns the following columns: DAY_KEY, DAY_DATE, DAY_OF_WEEK, DAY_OF_MONTH, and DAY_OF_YEAR. However, as seen in the next section, the preferred approach to the above SQL statement would be to create an MQS and within it create calculation objects for the WEEKDAY and MONTH so that the SQL in the DQS can be reduced to select * from 4.3 Calculation and Filter Objects The preferred option for using parameter maps is to include parameter maps in MQS calculation or filter objects or as stand alone calculation or filter objects rather than within the SQL expression of the original DQS. By leaving the original DQS SQL in a pristine import state, we can ensure that no factors will be present that will prevent either minimized SQL or metadata caching within the model. The syntax for using parameter maps in calculation or filter objects is similar to referencing them in SQL statements with the exception that any references to columns would be changed to reference the associated data item from a DQS. From the prior section we saw an example of parameter maps being used to choose a column based on a given locale. By resetting the Product line DQS to use Select * from [go_data_warehouse].PRODUCT_LINE the DQS will then list all of the columns from the PRODUCT_LINE table. By creating a new MQS or a stand alone calculation with the same parameter map, it is possible to do the same column selection as in the original SQL statement.
#'[Product dimension].[Product line].[PRODUCT_LINE_'+ $Language_lookup{$runLocale}+ ']'#

The macro expression serves to generate the reference to the model item required. The first portion of the statement serves to identify the namespace and DQS used to locate the columns for the PRODUCT_LINE labels. The parameter map then selects the single data item required from the collection of locale-specific data items just as with the original custom SQL expression shown in the previous section.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

14

The benefit to this approach is that the resulting SQL for the query subject is much easier to read and the model stores all the relevant metadata for each of the columns and prevents a request to the database for the metadata to be provided at run-time.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

15

A DQS using the custom SQL with the parameter map would provide the following SQL: select Product_line.Product_line_code as Product_line_code, Product_line.Product_line as Product_line from (select Product_line.PRODUCT_LINE_CODE as Product_line_code, XMIN(Product_line.PRODUCT_LINE for Product_line.PRODUCT_LINE_CODE ) as Product_line from (select PRODUCT_LINE.PRODUCT_LINE_CODE, PRODUCT_LINE.PRODUCT_LINE_EN as PRODUCT_LINE from go_data_warehouse...PRODUCT_LINE ) Product_line group by Product_line.PRODUCT_LINE_CODE ) Product_line With the changes to use an MQS with the parameter map, we obtain the following SQL: select Product_line.Product_line_code as Product_line_code, Product_line.Product_line as Product_line from (select Product_line.PRODUCT_LINE_CODE as Product_line_code, XMIN(Product_line.PRODUCT_LINE_EN for Product_line.PRODUCT_LINE_CODE ) as Product_line from go_data_warehouse...PRODUCT_LINE Product_line group by Product_line.PRODUCT_LINE_CODE ) Product_line The new MQS approach to parameter maps removes the inner derived table selecting the PRODUCT_LINE_CODE and the PRODUCT_LINE_EN. Note that the XMIN you see in the SQL is due to the group by option being checked for the PRODUCT_LINE_CODE determinant. Without this option, the SQL would collapse and remove the aggregation within the SQL. However, in this case the group by option is required for comparing facts from tables at different levels of granularity.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

16

5 Using Prompts
Prompts within a model serve a very valuable role in that they allow users to interact with the queries at a basic level. This can build performance and functionality into a model that would be difficult to achieve consistently in the end-user reporting environment. A good example of this would be a query subject designed to generate a set of relative time periods. A prompt for a current date would allow users to report relative time periods starting at any arbitrary date. Recreating this type of reporting in Report Studio is difficult due to the complexity of the queries required to generate the date ranges. Further, recreating these queries in many reports can be both tedious and prone to errors. 5.1 SQL in Data Source Query Subjects As with parameter maps, when using a prompt in DQS SQL, the addition of the prompt means that the SQL is no longer trivial. When the query becomes non-trivial it is evaluated as a whole to determine both the native SQL and the metadata associated with the data items. In this case a call to the data source may be made at run-time to fetch the data item properties. For some data sources, the function calls within the database required to perform this metadata fetch can account for several seconds of delay during the prepare phase of the query execution while IBM Cognos BI is waiting for the data source to return the required information. Since the SQL is evaluated as a unit, the prompt will be displayed to users any time that the query subject is referenced. In some cases this is good as it enforces a business rule to retrieve user input every time the request is submitted. In other cases such as when the prompt is used in a calculation that may or may not be required by the end report, then the prompting may be considered unnecessary from a user perspective. An example where the prompt would, by definition, always be presented to the user would be: Select * from [go_data_warehouse].PRODUCT_LINE PRODUCT_LINE Where PRODUCT_LINE.PRODUCT_LINE_CODE = #prompt(Product Line Code, integer)# Here the user will be forced to select only one Product Line at a time for reporting and would not be able to report against multiple Product Line values within the same query.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

17

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

18

An example of when the prompt may not be desirable when reporting is: Select *, Case PRODUCT_LINE.PRODUCT_LINE_CODE When #prompt(Target Product Line Code, integer, 1)# then 1 Else 0 End as Target Product Line from [go_data_warehouse].PRODUCT_LINE PRODUCT_LINE Here the Target Product Line calculation may serve to identify a set of values that can be used a as a baseline for comparison with other Product Lines. However, even if the user does not include the Target Product Line data item in their report, they will be prompted to provide a Product Line because the prompt is essential to evaluating the full definition of the DQS. 5.2 Model Maintenance The driving force behind prompts within a model is typically for specific business rules or reporting applications. When capturing common prompting scenarios in the model, the end users are forced to satisfy a particular prompt name to execute the query. For simple cases such as Query Studio and Analysis Studio, a single prompt name will have little impact on the ability of a user to create their desired queries. For power users of Report Studio, a single simplistic prompting scenario can be limiting. A good example of this is the relative time scenario mentioned earlier. By building a single date prompt into the relative time query subject, it is possible to generate multiple periods such as Month-To-Date and Year-ToDate to allow for easy reporting of relative time from a relational source. However, if a Report Studio author wanted to generate two queries in a single report that used different starting dates for the relative time query subject (say one used December as the current month while another would use October), then there would be difficulties as the single prompt name would drive all the queries that used the relative time query subject and you could only report from one current period at a time. This type of scenario could drive users to request multiple instances of the prompted query subject to be created in the model using different prompt names. This can quickly scale out of control as the large scale development of many redundant query subjects in a model will greatly increase maintenance costs.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager In scenarios where a query subject or calculation will be used by report authors in many wildly varying applications, it may be best to leave the prompting to the individual report authors as it is difficult to foresee every possible application that a user will need to generate for reporting. 5.3 Calculation and Filter Objects

19

Nearly any prompting scenario can be captured in an MQS or stand alone filter object. If we take the previous examples, the first case can be defined using a filter object as: [Product dimension].[Product line].[PRODUCT_LINE_CODE] = #prompt (Product Line Code, integer, 1)# Similarly, the case statement shown previously can be defined as the following calculation in an MQS or stand alone calculation: Case [Product dimension].[Product line].[PRODUCT_LINE_CODE] When #prompt(Target Product Line Code, integer, 1)# then 1 Else 0 End The difference when using calculation objects is that the Target Product Line Code prompt is no longer required if the calculation is not used in the users report. If the calculation is not included in this case, then there is no need to add it when referencing the base SQL statement from the DQS or to prepare the SQL for the request. Also when using calculations and filter objects in MQSs or as stand alone objects, the DQS SQL statement can be left untouched and the SQL will remain trivial. This eliminates the need to fetch metadata data from a data source connection as the information can be cached within the model and maintains the ability to minimize the SQL.

6 General Recommendations
In practice, it is better to use parameters and prompts within MQS or stand alone calculation and filter objects rather than inserting them within the SQL of a data source query subject. Following this approach will ensure better SQL generation that leads to better performance or better matching with underlying materialized views. Parameter maps are ideal for scenarios where information needs to be swapped dynamically based on session information or user interaction via prompts. As a general rule, parameter maps should be reserved for the following two scenarios.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

20

Using a parameter map greatly simplifies the resulting SQL for a query or expression. For example the following calculation in an MQS referencing columns from Table1 and Table2 CASE #prompt(Prompt Name, integer, 0)# WHEN 1 THEN [Table1].[Column1] * [Table2].[Column2] WHEN 2 THEN [Table1].[Column2] ELSE 0 END can be converted to use a parameter map #$Parameter_Map{ prompt(Prompt Name, integer, 0)}# where the Parameter map would contain the following: Key 1 2 Value [Table1].[Column1] * [Table2].[Column2] [Table1].[Column1]

The default value of the parameter map would be set to zero so that when 0 is supplied from the prompt the return would be the integer value of zero. With the parameter map, the individual conditions from the CASE statement can be inserted as required. This potentially eliminates the need to join to Table2 for when the prompt value equals 2 while the original case statement would have forced the join between the two tables every time the calculation was used regardless of the user input to the generated prompt. Using a parameter map accomplishes an operation that would be difficult if not impossible for the end user. An example would be the multi-lingual reporting data in the sample models. Based on the user preferences, the model will swap columns to return the appropriate data language for reporting. Similarly a parameter map can be used to swap columns, tables, schemas, or even data source connections based on parameters such as the user ID. This could be used to mimic the Virtual Private Database functionality that vendors such as Oracle are capable of, in other databases that do not naturally support such functionality.

IBM Cognos Proprietary Information

IBM Cognos BI - Modeling with Prompts and Parameter Maps in Framework Manager

21

In regards to prompt macros being built into a model, the main consideration for their use is in foreseeing all possible applications that a user may generate within the query tools. Typically a prompt built into a model will restrict some of the flexibility available to users in one way or another. The degree to which these restrictions impact the ability of users to generate the queries they need is the deciding factor for or against using a prompt within a model. In practice, when generating parameter maps and prompts within a model, it is difficult to see all the possible scenarios for their use when they are being created. In an ad-hoc reporting environment, this can be detrimental as the model will tend to direct users along set query paths determined by a parameter map or prompt. If parameterization and prompting in the model are taken to extremes, then the resulting queries can become inflexible to a point where a query subject can only be used to answer one specific business question. In such a scenario the tasks of a report author have been effectively rolled entirely into the model. At this point the overhead for model maintenance will be quite high as reports will be tied to such a degree to the query subject definition that new reports may require development of entirely new queries within the model. Likewise, updates to existing reports may require involvement of the model developer rather than being entirely within the scope of a report authors capabilities. By careful planning and limitation of parameterization and prompting to scenarios where they are absolutely required, a model developer can ensure that future maintenance tasks will remain simple and that the impact of change will be minimal to the report authors. Likewise the model will remain flexible enough to satisfy the ad-hoc nature of reporting in todays business world.

IBM Cognos Proprietary Information

You might also like