Best Practices Report Studio General

  • Published on

  • View

  • Download

Embed Size (px)


Best Practices Report Studio General


Best Practices Cognos Report StudioFormatting:1. Classes - Define classes for all objects in the report. It would help in maintaining consistency in formatting of all the objects throughout the report page. 2. Consistency Maintain consistency for the formatting options (Font, Margin, Border, etc.) throughout the report. This will help in improving readability. 3. Report Expressions - Add Report expressions above the crosstab for the selection made in the prompts. This will help the user know the selections made in the report; It would also help in the scenario, where there is no data for the selections.

Filters & Prompts:1. Ensure that the report contains filters for every dimension required. The rows fetched from the database will be less. 2. Use = instead of in for single value comparison in filters. This reduces the query run time. 3. Use CASE statement instead of IFELSE, for implementing conditional filter. This helps in improving the performance of the filter execution. 4. Delete filters which are not required instead of disabling them. This is required as unused Code hampers the performance of the report. 5. If a prompt is kept required; the corresponding filter in the query should also be kept required. This is done to maintain consistency between filter and prompt.

Calculations:1. Use in-built calculations instead of calculating manually. This improves performance for the execution of report. 2. Assign proper solve order for the calculated data items. This helps in proper sequence of execution of the calculations. 3. Use explicit brackets for expression definitions. The calculations may give wrong answer if the Brackets are not used in the expressions or calculations of data items. 4. Avoid the usage of tuple function in Calculations unless necessary. The use of tuple function affects the performance as it goes to the detailed level of data, and does it for every record.

Query Items:1. Remove all unnecessary objects from the report. This improves execution because when the report is executed, the data is fetched for all the data items in the report. 2. Use data items instead of Calculated members and Calculated measures. The calculations of members should be done in data items. It helps to reduce the run time of calculations. 3. Special Characters should be avoided in the Query names. This can result in the user being unable to generate the SQL/MDX query. 4. For the query items which are not involved in any type of calculations, set the Aggregate Function and Roll Up Aggregate to NONE. This improves execution of report.

Charts:1. Show Tool Tip for the report items displayed on the chart. This helps the user to easily understand the chart values.

2. Define single Palette for all the charts in the report. This helps to maintain consistency for all the charts used. 3. When using grouping between the data items in the Series; if you want to hide the 2 nd data item, keep the source type for that data item to text and dont put any text.

General:1. Use brackets in IFELSE, CASE. and other expression. Not using Brackets in the control structures or expressions may result in Parsing error and readability of the expression reduces. 2. Minimum use of Java Script. Usage of Java script might affect the performance of the report. 3. Use Render variable instead of Style variable to show or hide any report items. Style variable executes the item on the report page and then hides it but the render variable does not execute the item which is not to be displayed in the report page. 4. Use Boolean variables instead of String variables unless string variables are unavoidable. Boolean variables get executed faster as compared to String variables.

Best Practices in Modelling IBM Cognos 8 Semantic LayersCognos 8 BI StackThe IBM Cognos 8 Corporate Performance Management system offers report authors a single platform to create reports, dashboards, events and perform analysis on multidimensional data. Cognos uses a three tier architecture to service the report consumers and authors. The client connects using a zero footprint webbrowser to Cognos Connection. Zero Footprint means no additional software or applets at all are installed on the client PC.

From the end-user perspective, the Cognos platform is split into a number of studios:

Query Studio to perform basic reporting using basic queries and formatting Report Studio to perform advanced, pixel perfect reporting with complex queries Analysis Studio to perform multidimensional analysis Metrics Studio to follow metric performance over time and define actions as necessary Event Studio to create agents to follow up on triggers

The metadata used to create reports is created by the modeller and is called a semantic layer. The same layer of metadata can be used in the different end-user studios. This Insight will discuss the best modelling techniques for the metadata layer.

But first, what exactly is a semantic layer?

Semantic LayersThe purpose of a semantic layer is to create a business representation of corporate data. This representation hides database complexity to the end-user by creating an intuitive model and by using common business names across the organisation.

The semantic layer maps complex data into business terms and shields cryptic database language from the end-user. Furthermore, a semantic layer can handle multilingual features and consolidate different database sources and OLAP cubes. This enables the use of different databases even from different vendors- and OLAP cubes in a single semantic layer, enabling the ability for use in a single report and in a transparent uniform manner.

The semantic layer insulates business users from underlying data complexity, while ensuring the business is accessing the correct data sources and using consistent terminology. This improves end-user productivity and enables greater business autonomy from the Information Services Department in accessing data.

The main metadata modelling tool within Cognos 8 is called Framework Manager. Framework Manager is used to create relational and dimensionally modelled relational models, called frameworks. Other metadata modelling tools include Cognos Transformer, used to create OLAP-cubes and Cognos Metric Designer. The metadata modelling tools within Cognos are client-server applications.

Flexible ModelsModel flexibility can be defined from two different points of view. How easily can the model be adapted to changing conditions and how easily can the user generate ad hoc query requests? Both questions can be answered by using dimensional modelling.

The dimensionally modelled database is ideal for reporting and is often referred to as a data warehouse. In a data warehouse facts and dimensions are established and data is stored at the lowest granular level. In every data warehouse a number of star schema's are present. The central table represents the fact table and only

contains numeric and additive measures. The satellite tables represent the set of dimensions that can be used to look at the measures from different angles. By using conformed dimensions, a data warehouse bus is established. Conformed dimensions are dimensions used by multiple fact tables. This method of modelling enables executing multifact, multigrain queries ensuring a predictable, clean set of results. When new facts or dimensions are added, they can be quite easily added to the model, representing a new star schema. However not all frameworks are build on dimensionally modelled databases. Quite often a data warehouse is not available and reporting is enabled directly on an OLTP (On Line Transaction Processing)-database, used in an operational system like an invoicing or order entry system, or an operational data store. These types of databases are modelled relationally and are highly normalized. There are a number of drawbacks for reporting on a relational model. The first drawback is query performance, a highly normalized model will lead to dozens of tables in a single SQL statement, leading to large execution plans and potentially slow performance. Doing such queries on an application production environment could even lead to problems with the applications operational performance. Relational data sources also pose a number of modelling challenges for the framework modeller to create predictable query results. Therefore it is recommended to always use a dimensionally modelled database for querying.

Framework ObjectsA framework uses a number of objects to create a structured model. A namespace creates a qualifying container for objects, avoiding naming conflicts. Within a namespace the modeller can use folders to group filters or query subjects. There are three different types of query subjects :

Data source query subject: performs a query on the underlying data source Model query subject: refers to an existing query subject in the model. Stored procedure query subject: used to retrieve data from stored procedures.

click to enlarge Figure 1: Cognos 8 BI Framework Manager - Overview of the Data Foundation View

Query subjects are linked together using relationships. A query subject can be edited by replacing the standard SQL with custom written SQL. The same can be done for relationships between query subjects. For maintenance purposes, it is however recommended never to make any changes at all in freehand SQL. When a physical table is changed, the new definition has to be manually adjusted or the table needs to be imported again. Importing is by far the easiest way to allow for bulk changes. When freehand SQL was entered, all these changes are lost following a new import. Calculations and determinants can be added without making changes to the SQL code by using the proper tab pages. A determinant is needed to identify certain levels of aggregation within the query subject. This is a particularly useful feature while dealing with multifact, multigrain queries. For OLAP functionality, two additional objects are available: a measure dimension and a regular dimension. A measure dimension contains a collection of facts. The regular dimension provides the accompanying set of descriptions and identifiers. The measure and regular dimensions are linked with scope relationships to define the level at which the measures are available for reporting.

Creating Durable ModelsWhile creating a model it is important to create a proper structure. The use of a multi-tier structure will shield the end-user from changes at database level such as migration to a different database technology or version or changes to column or table names. By creating an efficient layered structure, relational models can be modelled into virtual star schemas, providing predictable and reliable query results to the end user.

The first step in creating the framework model is importing the metadata. This can be handled by using the Metadata Wizard. It is good practice to create a separate namespace for every data source that is needed in the framework. On top of the namespace for the data source, a global namespace should be created: the Data Foundation View.

Figure 2: Cognos 8 BI Framework Manager - Query subjects and setting basic properties

When all data source objects are imported, the model should be scrutinized concerning relations between objects. Not only objects within the same data source should be linked together but relationships between different data sources are needed as well. This step will be much harder to do with a relational modelled data source then with a dimensionally modelled data source. In the Data Foundation view, calculations, embedded and standalone filters, determinants are added. Database column names are translated to more understandable business names in multiple languages if needed. For every query item, the modeller should check if the usage is set correctly. The usage of a field can be identifier, attribute or fact. Facts are numeric, usually additive or semi-additive data. All indexed columns or columns containing business keys should be set as identifier. Attributes are typically all other strings.

For every fact column, the aggregate should be set. Other options that should be set are the format, screen tip, description These properties are inherited by derived objects later on in the modelling process. A number of reporting traps is handled in this layer by creating model query subjects. If you are not the database owner, it is good practice to import all the metadata once more in a Reference View. In this view no changes at all are made, the objects are not used beyond this view in the framework. The Reference View represents the original state of the data source at the time of the model creation. Not only very useful as reference to the original data for the modeller, but this will also allow for detecting undocumented database changes. Other levels in the structure are the Consolidation View and the Presentation View, but first let's delve into modelling a bit deeper.

Model for predictable resultsThe greatest challenge for the model developer lies in creating a model that returns proper query results at all times, no matter what columns were selected in the report by the user. The objective is to model a relationally modelled data source as a virtual star schema. Most of what is following does not apply to a dimensionally modelled data source such as a data warehouse. In this type of data source most reporting traps were already handled by the data warehouse design & team.

Simplify with dimensional conceptsWhen importing from a relational data source, cardinality is detected based on a set of rules specified by the modeller. The best option is to use the primary and foreign key constraints present in the data source. Framework Manager uses the following rules:

cardinality is always applied in the scope of a query performed by the user 1 or 0-to-n relationship implies a fact but only if ALL relationships to that query subject are 1 or 0-to-n 1 or 0 to 1 implies a dimension

This means it is possible that a query subject will behave as a dimension in one query and as fact in another query. This is typically the case with master detail tables, such as INVOICE_HEADER and INVOICE_LINE. This situation can be handled by using a model query subject. The model query subject will logically condense

INVOICE_HEADER and INVOICE_LINE into one model query subject INVOICE_FACT, thus enforcing the correct context in every Invoice related query. Condensing this master-detail relation will avoid unwanted query splits and blind spots. Blind spots occur when there is a missing relationship between two tables due to the omission of a query subject in a query. To avoid cross-joins between two fact tables, all dimensional information from the fact table should be removed. The fact table should only contain keys and numeric values. The removed items a...