Guide Lines for FWM

COGNOS(R) 8

GUIDELINES FOR MODELING METADATA

THE NEXT LEVEL OF PERFORMANCETM

FRAMEWORK MANAGER

Guidelines for Modeling Metadata

01-08-2005

Framework Manager

8.1

Cognos(R) 8 Business Intelligence Readme

Guidelines for Modeling Metadata

GUIDELINES FOR MODELING METADATA

Product Information

This document applies to Cognos(R) 8 Version 8.1 and may also apply to subsequent releases. To check for newer versions of this document, visit the Cognos support Web site (http://support.cognos.com).

CopyrightCopyright (C) 2005 Cognos Incorporated.

Portions of Cognos(R) software products are protected by one or more of the following U.S. Patents: 6,609,123 B1; 6,611,838 B1; 6,662,188 B1; 6,728,697 B2; 6,741,982 B2; 6,763,520 B1; 6,768,995 B2; 6,782,378 B2; 6,847,973 B2; 6,907,428 B2; 6,853,375 B2.

Cognos and the Cognos logo are trademarks of Cognos Incorporated in the United States and/or other countries. All other names are trademarks or registered trademarks of their respective companies.

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 either the product or the document will be documented in subsequent editions.

U.S. Government Restricted Rights. The software and accompanying materials are provided with Restricted Rights. Use, duplication, or disclosure by the Government is subject to the restrictions in subparagraph (C)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, or subparagraphs (C) (1) and (2) of the Commercial Computer Software - Restricted Rights at 48CFR52.227-19, as applicable. The Contractor is Cognos Corporation, 15 Wayside Road, Burlington, MA 01803.

This software/documentation contains proprietary information of Cognos Incorporated. All rights are reserved. Reverse engineering of this software is prohibited. No part of this software/documentation 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 Incorporated.

Table of Contents

Chapter 1: Guidelines for Modeling Metadata 5

Scenarios 5New Objects in Cognos 8 5

Determinants 6Regular Dimension 6Measure Dimension 6Scope Relationship 7

Dimensional Modeling of Relational Data Sources 7Checking Imported Metadata 7Simplifying the Model Using Dimensional Concepts 10Resolving Ambiguous Relationships 12Defining Dimensions and Determinants 16Creating Star Schema Groups 22

Upgrading a Best Practices Model from ReportNet 1.x 23Reviewing the Existing Model 24Upgrading the Model 24

Chapter 2: The SQL Generated by Cognos 8 31Understanding Dimensional Queries When Using Best Practices 31

Single Fact Query 31Multiple-fact, Multiple-grain Query on Conformed Dimensions 32Modeling 1-n Relationships as 1-1 Relationships 34Multiple-fact, Multiple-grain Query on Non-Conformed Dimensions 35

Resolving Ambiguously Identified Dimensions and Facts 38Resolving Queries That Should Not Have Been Split 38Resolving Queries That Are Split in the Wrong Place 41

Index 47

Guidelines for Modeling Metadata 3

4 Framework Manager

Chapter 1: Guidelines for Modeling Metadata

Framework Manager is a metadata modeling tool. A model is a business presentation of the information in one or more data sources. When you add security, multilingual metadata, and dimensional metadata to this business presentation, one model can serve the reporting, ad hoc querying, and analysis needs of many groups of users around the globe.

A key goal of preparing metadata for business intelligence is to leverage existing metadata while adding value so that your users can find the information that they need.

Cognos 8 enables business intelligence on normalized and denormalized relational data sources as well as a variety of OLAP data sources.

This document addresses some fundamental concepts for modeling relational data sources in Framework Manager and outlines our recommendations for modeling metadata for use in business reporting and analysis. You can use Framework Manager to model any relational data source dimensionally. Although it is not mandatory that a dimensional schema be used in Cognos 8, many features were added to help you leverage the benefits of dimensional schemas as well as to create a logical dimensional view of non-dimensional schemas.

ScenariosThe topics in this document are organized according to different scenarios. Use the one that matches your goals.

Dimensional Modeling of Relational Data SourcesDimensional modeling of relational data sources is a capability made available by Cognos 8 Framework Manager. ReportNet 1.x enabled multiple-fact querying and prevented double-counting, and Cognos 8 introduces features designed explicitly for dimensional modeling. It is now possible to model dimensions with hierarchies and levels and to have facts with multiple measures. You can then relate the dimensions to the measures by using scope in the model.

For more information, see "Dimensional Modeling of Relational Data Sources" (p. 7).

Upgrading a Best Practices Model from ReportNet 1.xIf your model was built using the best practices from ReportNet 1.x, most of the upgrade to the new functionality of Cognos 8 can be performed in Framework Manager. The Verify Model command was enhanced so that you can select objects in the model and automatically convert them to Cognos 8 dimensions. This leverages the metadata available in the existing model. You can stay with query subjects and have ReportNet 1.x dimension information translated into determinants, or you can move forward to dimensions. If you move forward to dimensions, the existing dimension information in your model is used to create the first hierarchy and levels.

For more information, see "Upgrading a Best Practices Model from ReportNet 1.x" (p. 23).

New Objects in Cognos 8In ReportNet 1.x, dimension information combined the concept of uniqueness with the concept of dimensional hierarchies. In Cognos 8, the concept of dimension information is divided to provide control over uniqueness and granularity. This control is required for relationally-based query subjects and to more explicitly address dimensional concepts of hierarchies and levels for dimensional objects, even on relational sources.

When reviewing dimension information, you must understand how the dimension information is applied to the query subject and how the query subject will be used in the Cognos 8 model.



New objects have been introduced in Cognos 8:• determinants for query subjects• regular dimensions• measure dimensions• scope relationships

Determinants are not the same as levels and hierarchies but they can be closely related to a single hierarchy. The query engine evaluates determinants from first to last. One or more determinants may be specified.

If a model regular dimension is based on a query subject with determinants specified, we recommend that• one level correspond to each determinant that exists in the query subject • the order of the levels in the hierarchy reflect the order of the determinants

This results in a consistent model, facilitating upgrading the model in future releases of Cognos products.

DeterminantsA determinant is the set of database columns (query items) that can be used to uniquely identify a set of data. Determinants are imported based on key and index information in the data source. We recommend that you always review the determinants that are imported.

Use a determinant when you want to do the following:• Add information about functional dependencies between columns to avoid double-counting.• Specify the granularity of a denormalized query subject to control grouping and

double-counting when using model dimensions.For example, some facts join to time on month and some facts join to time on day. Specify determinants for time to clearly capture the functional dependency between month and day as a minimum to prevent double-counting for those facts that join at the month key.

• Uniquely identify the row of data when retrieving text blob data from the data source.• Override the determinants imported from the data source that conflict with relationships

created for reporting.For example, there are determinants on two query subjects for multiple columns but the relationship between the query subjects uses only a subset of these columns. Modify the determinant information of the query subject if it is not appropriate to use the additional columns in the relationship.

For more information, see "Defining Dimensions and Determinants" (p. 16).

Regular DimensionA regular dimension contains descriptive and business key information and organizes the information in a hierarchy, from the highest level of granularity to the lowest. It usually has multiple levels and may have multiple key segments to define a level. It may also have multiple hierarchies.

Only a single hierarchy can be defined on a data source regular dimension.

Multiple-fact querying is enabled with conformed dimensions.

Measure DimensionA measure dimension is a collection of facts.

You can create a measure dimension for one or more query subjects that have a valid relationship between them.

6 Framework Manager


Scope RelationshipScope relationships exist between measure dimensions and regular dimensions to define the level at which the measures are available for reporting. Scope relationships govern the reporting granularity of the regular dimension for a particular measure dimension.

Scope relationships are mandatory between measures and dimensions when reporting. The absence of a scope relationship results in an error at runtime. Scope relationships are for reporting purposes. They are not the same as joins and do not impact the Where clause.

You can use scope relationships to include or exclude the regular dimension from the star schema group.

Shortcuts cannot be created for scope relationships. Scope relationships can exist only between regular and measure dimensions. Scope relationships can also be created for shortcuts to dimension objects. When shortcuts to dimensions are used, the scope is derived from the scope of the target objects unless scope has been explicitly defined on the shortcuts.

Dimensional Modeling of Relational Data SourcesYou must dimensionally model a relational data source when you want to do one or more of the following:• use Analysis Studio• enable drill functionality in reports• improve control over query granularity• access member functions in the report authoring tools

We recommend that you follow this workflow when you dimensionally model relational data sources:

❑ Import the metadata.

❑ Check the imported metadata (p. 7).

❑ Customize the metadata.

❑ Simplify the model using dimensional concepts (p. 10).

❑ Resolve ambiguous relationships (p. 12).

❑ Define dimensions and determinants (p. 16).

❑ Organize the model by creating business views.

❑ Create star schema groups (p. 22).

❑ Apply security.

❑ Create packages and publish metadata.

For information about the topics not covered here, see "Designing a Project", "Preparing Relational Metadata for Use in Reports", and "Making Metadata Available to Report Authors" in the Framework Manager User Guide.

All examples in this document use the database view of the gosales_goretailers normalized model or the import view of the go_data_warehouse model, which are included with the Cognos 8 samples.

Checking Imported MetadataAfter importing metadata, you must check the imported metadata in these areas:• relationships and cardinality• the Usage property for query items• the Regular Aggregate property for query items

Relationships and cardinality are discussed here. For information on the Usage and Regular Aggregate properties, see "Modifying the Properties of Query Items" in the Framework Manager User Guide.



Cardinality is combined with dimensions to control how queries are generated so that you can• prevent double-counting• automatically resolve loop joins• enable cross-fact querying for reporting and analysis

You can create model dimensions and data source dimensions. Model dimensions are built on a foundation of query subjects that use determinants and relationships with cardinality. Data source dimensions contain their own SQL and use hierarchy and level information as well as relationships with cardinality to define query granularity.

Cardinality drives query behavior by allowing rules to be applied regarding the granularity of data that is returned by an individual object and the consequence of joins between objects. The cardinality specified in the relationship between query subjects or dimensions determines how and when Cognos 8 generates stitched queries. Stitched queries are needed for multiple-fact querying across conformed dimensions and across different levels of granularity.

Detecting Cardinality from the Data Source

When importing from a relational data source, cardinality is detected based on a set of rules that you specify. The available options are• use primary and foreign keys• use matching query item names that represent uniquely indexed columns• use matching query item names

The most common situation is to use primary and foreign keys as well as matching query items that represent uniquely indexed columns. The information is used to set some properties of query items as well as to generate relationships.

To view the index and key information that was imported, right-click a query subject or regular dimension and click Edit Definition. For a query subject, you can change the information in the Determinants tab. All regular dimensions begin as query subjects. If you converted a query subject to a regular dimension, note that determinant information for the query subject is leveraged as a starting point to define the levels of a single hierarchy. We recommend that you review the levels and keys created in the hierarchy of the dimension.

Optional relationships, full outer joins, and many-to-many relationships can be imported from your data source. Framework Manager will execute them as queries.

Reflexive relationships can be imported from your data source and appear in the model but Framework Manager does not execute them as queries. Although you can view the metadata that defines the reflexive relationship, you cannot edit a reflexive relationship in Framework Manager.

For more information, see "Reflexive and Recursive Relationships" (p. 15).

Cardinality in Generated Queries

Framework Manager supports both minimum-maximum cardinality and mandatory-optional cardinality.

0:1 - 0 is the minimum cardinality, 1 is the maximum cardinality

1:n - 1 is the minimum cardinality, n is the maximum cardinality

A relationship with cardinality 1-n can be specified as 1:1 to 1:n when reading the maximum cardinalities. The minimum cardinality of 1 is set to 0 for optional data. Therefore a 1-n relationship can also be specified as 0:1 to 0:n, 0:1 to 1:n, or 1:1 to 0:n.

The basic rules for how cardinality is used are the following:• Cardinality is applied in the context of a query, meaning that only the cardinalities of items

explicitly included in the query are evaluated.• 1-n cardinality implies fact on the n side and implies dimension on the 1 side. • A query subject can behave as a dimension in one query and as a fact in another. • Queries on more than one fact will result in a stitched query.

For more information, see "Single Fact Query" (p. 31) and "Multiple-fact, Multiple-grain Query on Conformed Dimensions" (p. 32).

8 Framework Manager


Modeling 1-n Relationships as 1-1 Relationships

If a 1-n relationship exists in the data but is modeled as a 1-1 relationship, SQL traps cannot be avoided because the information provided by the metadata to the query engine is insufficient.

The most common problems that arise if 1-n relationships are modeled as 1-1 are the following:• Double-counting for multiple-grain queries is not automatically prevented.

Cognos 8 cannot detect facts and then generate a stitched query to compensate for double-counting, which can occur when dealing with hierarchical relationships and different levels of granularity across conformed dimensions.

• Multiple-fact queries are not automatically detected. Cognos 8 does not have sufficient information to detect a multiple-fact query. For multiple-fact queries, an inner join is performed and the loop join is eliminated by dropping the last evaluated join. Dropping a join is likely to lead to incorrect or unpredictable results depending on the dimensions and facts included in the query.

You can work around these issues in Report Studio by creating an inner or outer join between queries. This requires the report author to have detailed knowledge of the data. There is no workaround available in Query Studio or Analysis Studio.

Analyzing the Model for Facts and Dimensions

To dimensionally model a relational data source for the purpose of cross-fact querying and analysis, you must examine the underlying schema and address areas where the role of an object as a fact or a dimension is not clear. This examination can result in creating a logical layer to present the data as a star schema. Or you may decide to make changes to the physical data source to deliver a higher performance application. Physical changes may include consolidating tables by using extract-transform-load tools or creating materialized views for frequently-used aggregations.

In a relational data source that was not de-normalized using star schema concepts, you may need to analyze the cardinality of the imported query subjects before creating dimensions or converting query subjects to dimensions. You must first understand the business applications of the underlying data as well as understand how Cognos 8 generates queries.

Within the context of a query, a query subject with a cardinality of n on all its 1-n relationships to other query subjects can be regarded as a fact. This implies that there are more rows of data in the fact query subject than in the related query subject on the 1 side of the relationship. Any query subject on the 1 side of a 1-n relationship to another query subject is treated as a dimension.

The following examples show how schemas can be interpreted.

In the first two examples, we see that Sales Staff can relate directly to Sales Fact but can also relate to Sales Fact through Sales Branch. Multiple sales staff belong to a sales branch and staff can belong to different sales branches over time. To correctly determine the sales for a branch at a given time, Sales Branch must be joined directly to Sales instead of being joined through Sales Staff.

Example 1In this example, all four query subjects are included in a query. The diagram shows that the query subjects having only n cardinalities are treated as facts. Sales Staff and Order Details are treated as facts. Order Header and Sales Branch are treated as dimensions.



Example 2In this example, only three query subjects are included in a query. Order Details is not used in the query. Order Header is now treated as a fact. Sales Staff continues to be treated as a fact.

Example 3 This example shows different query subjects. Arrows point to the query subjects whose cardinality indicates that they are always facts. Areas where the behavior is dependent on the context of the query are circled. All other query subjects behave as dimensions in all queries.

For more information, see "The SQL Generated by Cognos 8" (p. 31).

Simplifying the Model Using Dimensional ConceptsThese rules apply when modeling with query subjects or dimensions:• Create a regular dimension for groups of query subjects that have hierarchical relationships

representing a single business concept (p. 11).• Create a measure dimension for groups of query subjects that have factual data sharing many

regular dimensions or having a master-detail type of relationship (p. 11). • Use the cardinality rules to identify areas of the model where the role of an object as fact or

dimension is not clear. For more information, see "Cardinality in Generated Queries" (p. 8).

The result of simplifying the model should be a layer of regular and measure dimensions that clearly represent the data in terms of business concepts and ensure predictable query generation.

If your data source contains fact-to-fact relationships, we recommend that you handle these in the data source.

10 Framework Manager


Creating Regular Dimensions

Normalized or snowflaked data sources often have several tables that describe a single business concept. For example, a normalized representation of Product may include four tables related by 1-n relationships. Each Product Line has one or more Product Types. Each Product Type has one or more Products. Products have names and descriptions in multiple languages so they exist in a Product Lookup table.

An end user may not know the relationship between the individual query subjects. In addition, having to expand each query subject or dimension and select a query item requires more clicks for the end user.

When modeling dimensionally, you can create a regular dimension for Product that simplifies using Product for the purpose of ad hoc query and reporting, and presents the levels of the hierarchy as a visual cue about the relationship between the levels.

If you are maintaining a ReportNet 1.x model, you can create a model query subject with determinants instead of a regular dimension. You can replicate the presentation effect of levels by using query item folders. The resulting model query subject can be converted to a regular dimension at any time.

Creating Measure Dimensions

Data sources often have master-detail tables that contain facts. An example is Order Header and Order Detail. When these tables are used to insert and update data, this structure is beneficial. When these tables are used for reporting and analysis, combine them in a single business concept to simplify the model.

To simplify the model in this example, create a model query subject that combines the foreign keys of both Order Header and Order Details and includes all measures at the Order Detail level. Then create a measure dimension based on the model query subject.



You must always resolve ambiguously identified dimensions and facts. For more information, see "The SQL Generated by Cognos 8" (p. 31).

Resolving Ambiguous RelationshipsAmbiguous relationships occur when the data represented by a query subject or dimension can be viewed in more than one context or role. The most common ambiguous relationships are:• multiple valid relationships (p. 12)• reflexive and recursive relationships (p. 15)

You can resolve ambiguous relationships in Framework Manager, or the database administrator can fix them in the data source. For example, the database administrator can remove extra relationships, although this may not be practical. Resolving ambiguous relationships in the model involves determining which query path to use.

Multiple Valid Relationships

A table with multiple valid relationships between itself and another table is known as a role-playing dimension. Multiple valid relationships often occur between regular dimensions and measure dimensions. This is most commonly seen in dimensions such as Time and Customer.

For example, the Sales fact has multiple relationships to the Time dimension on keys such as Order Day, Ship Day, and Close Day.

Steps1. Leave all the relationships in place in the Import View. 2. Create a measure dimension for the fact.3. Create a regular dimension for each of the dimensions.4. Create or copy the regular dimension for each role. 5. Rename the dimension, hierarchy, levels, and attributes appropriately for their use. 6. Ensure that a single appropriate relationship exists between each regular dimension and the

measure dimension, or between the underlying query subjects. 7. Ensure that there is a corresponding scope relationship specific to each role.



8. Decide how you want to use these roles with other facts that do not share the same concepts.

For example, Product Forecast has only one time key.You can do one of the following:• Designate a specific time dimension to be the conformed time dimension.

You can pick the most common role that you will use and name it clearly as a conformed dimension. You can then ensure that this version of the dimension is joined to all facts requiring a time dimension.



• You can treat ship day, order day and close day as interchangeable time dimensions with Product Forecast fact. In this case, you must create joins between the role-playing dimensions and Product Forecast fact. You can use only one time dimension at a time when querying the Product Forecast fact or your report may contain no data. For example, Month_key=Ship Month Key (200401) and Month key=Close Month Key (200312).



Model Objects vs. ShortcutsYou can create model objects based on the original query subjects. These model objects can be model regular dimensions or model query subjects. Or you can create shortcuts.

Use model regular dimensions or model query subjects when you want to create custom views of the same query subject.

Use shortcuts when you want exact replicas of a regular dimension or query subject in more than one place.

A shortcut that exists in the same folder as its target behaves as an alias, or independent instance. However, a shortcut existing elsewhere in the model will behave as a reference to the original. This approach is less flexible overall from a presentation perspective because renaming can only be done at the object level.

Reflexive and Recursive Relationships

Reflexive and recursive relationships imply two or more levels of granularity. Framework Manager imports reflexive relationships but does not use them when executing queries. Reflexive relationships, which are self-joins, are shown in the model for the purpose of representation only.

To create a functioning reflexive relationship, you must create an alias using either a shortcut to the query subject in the same folder, or a model query subject based on the query subject. You then create a relationship between the query subject and the alias. Using a model query subject tends to be a better option because you can specify which query items are included in the query subject.

For example, the Staff query subject has a recursive relationship between Staff Key and Manager Key.

Steps1. Create a model query subject to represent Manager.2. Select which query items apply to Manager and rename them in a meaningful way. 3. Create a relationship with a 1:1 to 1:n between Staff and Manager.



For a simple two-level structure using a model query subject for Manager that is based on Staff, the model looks like this:

4. For a recursive hierarchy, repeat these steps for each additional level in the hierarchy.For a deep recursive hierarchy, we recommend that the hierarchy be flattened in the data source and that you model the flattened hierarchy in a single regular dimensions.

5. Select the query subjects, right-click, and click Merge in New Regular Dimension.

Defining Dimensions and DeterminantsUse dimensions and determinants to ensure that the aggregation in reports is correct and that queries generate correctly.

Use regular dimensions to organize and present descriptive information to guide the end user experience in the report authoring tools. Hierarchies are presented in a top-down format, from the coarsest level of granularity to the finest.

Data source regular dimensions treat hierarchy and level information as if they are determinants.

Model regular dimensions require determinants to be specified for the underlying query subjects.

Use determinants to specify which data is unique.

If a determinant defines attributes, all query items in the query subject must be defined as either a key or an attribute. You can have a determinant with no attributes defined for it. Framework Manager uses this type of determinant to indicate which query items are indexed.

Joins and granularity are the key factors in SQL generation. Specify granularity for the objects that have relationships by using either a hierarchy or determinants on the object to which the join is created.

You must use regular and measure dimensions to enable analysis on your relational data source. In most data sources, regular dimensions, which contain descriptive information, are likely to be shared by more than one measure dimension. Regular dimensions are often called shared dimensions. Regular and measure dimensions organized into a cluster is often referred to as a star schema group but can also be referred to as a functional or subject area group.

Measure dimensions are related to each other through the regular dimensions. To create reports that fully compare and contrast functional areas, you may need to use more than one measure dimension in a report.

When querying across star schemas or functional areas, you must consider the role the hierarchy plays in query generation:• Multiple-fact, multiple-grain queries (p. 17)• Multiple hierarchies (p. 21)



Multiple-fact, Multiple-grain Queries

Multiple-fact, multiple grain queries occur when dimensions are related to multiple fact tables at different levels. A dimension typically has distinct levels of attribute data with business keys that have a hierarchical relationship to each other. The report authoring tools automatically aggregate to the lowest common level present in the report. The hierarchical relationship between level keys is used to aggregate data to the lowest level included in the report. The potential for double-counting arises when creating totals on columns that may contain repeated data. When the level of granularity of the data is modeled correctly, double-counting can be avoided.

Note: You can report data at a level of a hierarchy below which it exists. This causes the data to repeat across members at that level, but the totals are not affected.

This example shows two data source measure dimensions, Sales and Product forecast, that share two regular dimensions, Time and Product.

The Time dimension is the focal point of the granularity issue in this example. In the underlying data source, Sales is joined to Time on the Day key, and Product forecast is joined to Time on the Month key. Because of the different join keys, a minimum of two levels must be clearly identified with keys for the Time Dimension.

Data Source DimensionsWhen using data source dimensions, we recommend that you create all levels that may be necessary for reporting instead of only those levels that are immediately necessary.

For example, the levels for Month and Day have their keys identified. Day is the lowest level of the hierarchy, and the Unique Level box is selected because this data is unique in the underlying data source.

For example, the level definitions for Month are as follows.



For example, the level definitions for Day are as follows.

The Product dimension has three levels: Product line, Product type, and Product. It has relationships to both fact tables on the Product key. All joins in the underlying tables occur on the Product key so there are no granularity issues for this dimension. Any hierarchy that you create is purely for the purpose of drilling and rollup.



By default, a report is aggregated to retrieve records from each fact table at the lowest common level of granularity. If you create a report that uses Quantity from Sales, Expected volume from Product forecast, Month_name from the Time dimension, and Product_name from the Product dimension, the report retrieves records from each fact table at the lowest common level of granularity. In this example, it is at the month and product level.

If you do not specify the levels of the hierarchy properly in the Time dimension, incorrect aggregation may occur. For example, Expected volume values that exist at the Month level in Product forecast is rolled up based on the lower time level, days, in the Time dimension. The values for Expected volume are multiplied by the number of days in the month.

To prevent double-counting when data exists at multiple levels of granularity, create a hierarchy for the Time dimension and correctly specify the levels with keys.

Note the different numbers in the Expected Volume column. Double-counting was prevented.

Model Regular Dimensions and Query Subjects with DeterminantsDeterminants are not the same as levels and hierarchies but they can be closely related to a single hierarchy. The query engine evaluates determinants from first to last. One or more determinants may be specified.

If a model regular dimension is based on a query subject with determinants specified, we recommend that• one level correspond to each determinant that exists in the query subject • the order of the levels in the hierarchy reflect the order of the determinants

This results in a consistent model, facilitating upgrading the model in future releases of Cognos products.

When using model dimensions, you begin with the query subjects that are the basis for the dimension. We recommend that you create a determinant for each level that may be necessary for reporting instead of only those levels that are immediately necessary.

For example, here is a solution for the Time dimension that is an alternative to using dimensions as previously described. Determinants are defined for Month and Day. Note that Day is the lowest level of the hierarchy.

For example, the determinants for Month are as follows.



For example, the determinants for Day are as follows.

The Uniquely Identified check box is selected for only the lowest level of the hierarchy because the data in this column is unique for every row in the underlying data source.

The Group By check box is selected for all levels whose data is not unique. If aggregation on an associated attribute is required, the key defined for the determinant should be used in a Group By clause in the query. Also, if an attribute of a Group By level is included in a query, a Minimum aggregate function may be used to ensure that the value is unique in the query.

The hierarchy for the model regular dimension would be the same as the one shown for the data source dimension.

For information about the SQL and the results generated for this example, see "Multiple-fact, Multiple-grain Query on Conformed Dimensions" (p. 32).



Multiple Hierarchies

Multiple hierarchies occur when different structural views can be applied to the same data. Depending on the nature of the hierarchies and the required reports, you may need to evaluate the modeling technique applied to a particular case.

You can specify multiple hierarchies on regular dimensions in Framework Manager. Multiple hierarchies for a regular dimension behave as views of the same query. You cannot use the different hierarchies of the same dimension in a single report query.

For example, sales staff can be viewed by manager or geography. In the report authoring tools, these hierarchies are separate but interchangeable logical structures, which are bound to the same underlying query.

Here is sales staff as a single dimension with two hierarchies:

The hierarchies are defined in Framework Manager as follows.

If you need more than one hierarchy from a dimension in a report, such as on opposing axes, you must create a regular dimension for each hierarchy. Each regular dimension must be a single distinct hierarchy. In this way, you can issue the same, or slightly different, block of SQL multiple times.

Here are separate dimensions for each hierarchy.



Use this approach if dramatically different sets of columns are relevant for each hierarchy and it is more intuitive for end users to model the hierarchies as separate dimensions with separate and simpler queries.

Creating Star Schema GroupsStar schema groups can make the model more intuitive for end users by indicating which regular dimensions and measure dimensions are related. Star schema groups can also facilitate multiple-fact reporting by indicating how to use regular dimensions that are common to many measure dimensions. Multiple-fact reporting is also known as cross-functional reporting.

Star schema groups also provide context for queries with ambiguous joins. By creating star schema groups in the business view of the model, you can clarify which join path to select when multiple join paths are available. This is particularly useful for fact-less queries.

Multiple Conformed Star Schemas or Fact-less Queries

You will likely see conformed regular dimensions between measure dimensions. Join ambiguity is an issue when you report using items from multiple dimensions without including any items from the measure dimension. This is called a fact-less query.

For example, Product and Time are regular dimensions related to the Product forecast and Sales measure dimensions.

Using these relationships, how do you write a report that uses only the Product and Year items? The business question could be which products were forecasted for sale in 2005 or which products were actually sold in 2005. Although this query involves only the Product and Time dimensions, these dimensions are related through multiple measure dimensions. There is no way to guess which business question is being asked. You must set the context for the fact-less query.

In this example, we recommend that you create two namespaces, one containing Product, Time, and Product forecast, and another containing Product, Time, and Sales.



When you create these namespaces, use the Create Star Schema Grouping wizard to select the correct dimensions for each measure, create shortcuts for all objects, and move the shortcuts to a new namespace.

When you do this for all star schemas, you resolve join ambiguity by placing shortcuts to the measure dimension and all regular dimensions in a single namespace. The shortcuts for conformed dimensions in each namespace are identical and are references to the original object.

With a namespace for each star schema, it is now clear to the end users which items to use. To create a report on Products Sold in 2005, they use Product and Year from the Sales Namespace. The only relationship that is relevant in this context is the relationship between Product, Time, and Sales Fact, and it is used to return the data.

Upgrading a Best Practices Model from ReportNet 1.xPart of the Cognos 8 installation was to automatically update all published models to work in Cognos 8. To begin reporting, you do not need to modify these models. When you want to reflect changes in the data or metadata or use new features, you must explicitly upgrade the model in Framework Manager. When you upgrade, you must decide when and where to use new features. Tools in Framework Manager help you upgrade to new features based on the existing metadata in the model.

If you used the modeling recommendations in the Modeling in Framework Manager for Predictable Queries and Results paper, which is available from the Cognos support Web site (http://support.cognos.com), to create the ReportNet 1.x model, we recommend the following workflow:

❑ Review the existing model (p. 24).

❑ Upgrade the model (p. 24).

❑ Define dimensions and determinants (p. 16).

❑ Create measure dimensions or convert facts to measure dimensions.

❑ Create and test star schema groups (p. 22).

❑ Republish the metadata.

For information about the topics not covered here, see "Preparing Relational Metadata for Use in Reports" and "Making Metadata Available to Report Authors" in the Framework Manager User Guide.

All examples in this document use the database view of the gosales_goretailers normalized model or the import view of the go_data_warehouse model, which are included with the Cognos 8 samples.



Reviewing the Existing ModelIn ReportNet 1.x, dimension information combined the concept of uniqueness with the concept of dimensional hierarchies. In Cognos 8, the concept of dimension information is divided to provide control over uniqueness and granularity. This control is required for relationally-based query subjects and to more explicitly address dimensional concepts of hierarchies and levels for dimensional objects, even on relational sources.


Before upgrading the model to Cognos 8, we recommend that you review the ReportNet 1.x model using the Modeling in Framework Manager for Predictable Queries and Results paper. You must ensure that dimension information was specified correctly. The upgrade process uses the dimension information to create dimensions or determinants. Dimensions and determinants are the means of controlling granularity and automatic aggregation as well as preventing double-counting in Cognos 8.

We highly recommend that you run the Verify Model command in ReportNet 1.x. Repair all errors and review all warnings before you start the upgrade.

Upgrading the ModelAfter Cognos 8 automatically upgrades the model, you must manually review the new features because some alter query behavior. The initial automated upgrade to Cognos 8 is designed to produce a model that can be published to a Cognos 8 report server.

Most changes to modeling concepts in Cognos 8 are in the areas of data types, dimensions, and determinants.

Changes to Data TypesCognos 8 added support for new data types. This may change how data types are mapped between Cognos and the source data on metadata import. The primary areas of change are as follows:• nChar

In some cases, data types that were char become nChar.• nVarChar

In some cases, data types that were varChar become nVarChar.• numeric

In some cases, data types that were decimal become numeric.• timestampTZ

In some cases, data types that were varChar become timestampTZ.• IntervalTZ

In some cases, data types that were varChar become IntervalTZ.

Mapping of these data types varies by data source vendor and can be confirmed from the data type support section of the Cognos support Web site (http://support.cognos.com).

The Allow enhanced model portability at runtime governor is selected upon initial upgrade. This governor prevents rigid enforcement of data types so that the Cognos 8 model can function as a ReportNet 1.x model until you update the data types in the metadata.

It is not possible to automatically determine the new data type based on the existing data types saved in the model. For this reason, use the Verify Model, Verify Selected Objects, or Update Object commands to update the mapping of the data types.

Dimensions and DeterminantsIn ReportNet 1.x, dimension information combined the concept of uniqueness with the concept of dimensional hierarchies. In Cognos 8, the concept of dimension information is divided to provide control over uniqueness and granularity. This control is required for relationally-based query subjects and to more explicitly address dimensional concepts of hierarchies and levels for dimensional objects, even on relational sources.




The metadata previously specified by dimension information is implicitly preserved in the model and continues to exist for query subjects until those query subjects are repaired. You cannot change this dimension information. You can upgrade the dimension information to regular dimensions or determinants. Until you upgrade the query subject, Cognos 8 query generation uses the dimension information previously specified in ReportNet 1.x.

The Allow dynamic generation of dimension information governor is selected upon initial upgrade. This governor ensures consistent behavior with ReportNet 1.x by deriving a form of dimension information from the relationships, key information, and index information in the data source.

For more information, see "New Objects in Cognos 8" (p. 5).

Checking and Repairing the Model

After automatically updating the metadata, Framework Manager prompts you to check the model. We highly recommend that you complete this step before making any changes to the model.

Understanding WarningsThe following warnings commonly appear when you check a ReportNet 1.x model:• Needs reevaluation

This message is most likely related to data type changes. The majority of items with this warning can be selected for repair. The repair option steps you through your options for evaluating and upgrading specific elements of metadata. Tip: You can also evaluate a query subject by using the Evaluate Object command from the Tools menu.

• Join expression conflicts with the determinant information defined in the query subjectSometimes the index and key information specified for a query subject implies a level of granularity that does not match the relationships specified on a query subject. For more information, see "Defining Dimensions and Determinants" (p. 16).

• None of the query items in this level have a role Caption specifiedWhen defining levels, you must ensure that a business key and caption roles are specified. These roles are relevant for member functions in the report authoring tools and to assist in the member-oriented tree in Analysis Studio.

• One or more determinants that describe the keys and attributes of the query subject should be specifiedWhen importing from a relational data source, determinants are specified for any indexes and keys that exist in the data source. It is possible that no determinants exist on a query subject upgraded from ReportNet 1.x, especially for model query subjects. We recommend that you use determinants to explicitly specify the granularity of the data in the query subject and the functional dependencies between query items. However, it is not mandatory to specify determinants for query subjects representing a single level or fact data. Determinants are required only if the item is a BLOB data type.

Selecting and Repairing ObjectsYou can select all items with check boxes and repair them. The repair process first evaluates all selected items. This evaluation automatically resolves issues around new data types and prompts you to deal with dimension information in the model. We recommend that you upgrade most query subjects that used dimension information in ReportNet 1.x to dimensions.

Converting Query Subjects to Dimensions

You can convert a query subject to a dimension by using the dimension information in the query subject. You can also convert a dimension to a query subject with determinants at any time after completing the upgrade.



Dimension information is mapped to regular dimensions as follows.

For example, the Product query subject in ReportNet 1.x has the following dimension information.

When you convert this query subject to a regular dimension, the dimension information is used to create these hierarchies and levels in Cognos 8.

Dimension information Regular dimension

Hierarchies Hierarchies

Levels Levels

The first level of the hierarchy is automatically defined as the All level. It contains a single root member, which represents the top level of the hierarchy.

You cannot delete or move the All level. You can change its name, description, and screen tip.

Keys _businessKey role

Unique Key Unique Level

Alphabetically first text attribute _memberCaption role

All other attributes Can be manually assigned to be _memberDescription, custom role, or no role



Things to Review After conversion, you must review the following:• Unique Level

A unique level indicates that the keys of the levels above are not necessary to identify the members in this level.

• memberCaption roleTo leverage member functions and enable dragging and dropping levels in the report authoring tools, you must assign a memberCaption to each level in a dimension. Because this role does not exist in ReportNet 1.x, it is mapped where possible. If there are no attributes for the level, the absence of a caption is highlighted when you check the model.

• Attributes In general, all other attributes should be included in the dimension and associated to the correct level. By default, they are included with no role. You have the option to create custom roles or assign attributes to existing roles.

• Multiple Hierarchies Only the first hierarchy from a ReportNet 1.x query subject is upgraded to a dimension. You must re-create all other hierarchies.

For example, after upgrading the Product query subject to a regular dimension, you can further refine it. In this example, Product name is now defined as the memberCaption role.



Converting Dimension Information to Determinants

When maintaining models that do not fully conform to ReportNet 1.x recommendations, you may need to preserve query subjects. Dimension information is then mapped to determinants as follows.

For example, the Product query subject with dimension information looks like this in ReportNet 1.x.

When you convert it to a query subject with determinants, it looks like this.

Dimension information Determinants

Hierarchies Order of determinants.

Levels Determinants

Uniquely Identified

Group By

Unique Key is not selected Key segments from higher levels are included in the key.

Unique Key is selected Only the key segment, or segments, for the level are included in the key.

Attributes Attributes

Unassociated attributes are assigned to the last determinant, which generally corresponds to the lowest level.



Things to Review After conversion, you must review the following:• Uniquely Identified

The Uniquely Identified check box indicates that a determinant uniquely identifies a row in the data set.

• Group By The Group By check box implies a mandatory grouping will be done on any query using this determinant or any item determined by it. This helps to resolve double-counting in the case of dimensions being joined on different keys at different levels of granularity. If attribute items are determined by a determinant that has the Group By check box selected, the Minimum aggregate function is applied to them in the query.

• Multiple Hierarchies Determinants do not explicitly support the concept of hierarchies and provide no mechanism to represent multiple hierarchies. If two hierarchies existed on a query subject in ReportNet 1.x, only the first hierarchy is upgraded to a determinant. You must create a second query subject and manually specify the determinants for the other hierarchy.

For example, after upgrading the Product query subject to use determinants, you can further refine it. In this example, Product key is now the unique identifier, and Product line code and Product type code are used to group query items.



For more information, see "Defining Dimensions and Determinants" (p. 16).


Chapter 2: The SQL Generated by Cognos 8

The SQL generated by Cognos 8 is often misunderstood. This document explains the SQL that results in common situations.

Understanding Dimensional Queries When Using Best Practices

Dimensional queries are designed to enable multiple-fact querying. The basic goals of multiple-fact querying are:• Preserve data when fact data does not perfectly align across common dimensions, such as

when there are more rows in the facts than in the dimensions.• Prevent double-counting when fact data exists at different levels of granularity by ensuring

that each fact is represented in a single query with appropriate grouping. Determinants may need to be created for the underlying query subjects in some cases.

Single Fact QueryA query on a star schema group results in a single fact query.

In this example, Sales is the focus of any query written. The dimensions provide attributes and descriptions to make the data in Sales more meaningful. All relationships between dimensions and the fact are 1-n.

When you filter on the month and product, the result is as follows.



Multiple-fact, Multiple-grain Query on Conformed Dimensions

A query on multiple facts and conformed dimensions respects the cardinality between each fact table and its dimensions and writes SQL to return all the rows from each fact table.

For example, Sales and Product Forecast are both measure dimensions.

Note that this is a simplified representation and not an example of how this would appear in a model built using Cognos best practices.

The ResultIndividual queries on Sales and Product Forecast by Month and Product yield the following results. The data in Sales is actually stored at the day level.

A query on Sales and Product Forecast respects the cardinality between each fact table and its dimensions and writes SQL to return all the rows from each fact table. The fact tables are matched on their common keys, month and product, and, where possible, are aggregated to the lowest common level of granularity. In this case, days are rolled up to months. Nulls are often returned for this type of query because a combination of dimensional elements in one fact table may not exist in the other.



Note that in February 2004, Course Pro Umbrellas were in the forecast but there were no actual sales. The data in Sales and Product Forecast exist at different levels of granularity. The data in Sales is at the day level, and Product Forecast is at the month level.

The SQLThe SQL generated by Cognos 8, known as a stitched query, is often misunderstood. A stitched query uses multiple subqueries, one for each star, brought together by a full outer join on the common keys. The goal is to preserve all dimensional members occurring on either side of the query.

The following example was edited for length and is used as an example to capture the main features of stitched queries.select

coalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME,coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,D2.EXPECTED_VOLUME as EXPECTED_VOLUME,D3.QUANTITY as QUANTITY

from (select TIME.MONTH_NAME as MONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY ) as EXPECTED_VOLUME

from (select TIME.CURRENT_YEAR as CURRENT_YEAR,TIME.QUARTER_KEY as QUARTER_KEY,TIME.MONTH_KEY as MONTH_KEY,XMIN(TIME.MONTH_NAME for TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY ) as MONTH_NAMEfrom TIME_DIMENSION TIMEgroup by TIME.MONTH_KEY) TIMEjoin PRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACTon (TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY)join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY)

where (PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella')) and (TIME.MONTH_NAME in ('April 2004','February 2004','February 2006'))

group by TIME.MONTH_NAME, PRODUCT_LOOKUP.PRODUCT_NAME

) D2full outer join (select TIME.MONTH_NAME as MONTH_NAME,

PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR, TIME.QUARTER_KEY, TIME.MONTH_KEY, PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE, PRODUCT.PRODUCT_KEY ) as QUANTITY

from select TIME.DAY_KEY,TIME.MONTH_KEY,TIME.QUARTER_KEY,

TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAME from TIME_DIMENSION TIME) TIMEjoin SALES_FACT SALES_FACTon (TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY)

where



(PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella')) and (TIME.MONTH_NAME in ('April 2004','February 2004','February 2006'))

group by TIME.MONTH_NAME,PRODUCT.PRODUCT_NAME

) D3on ((D2.MONTH_NAME = D3.MONTH_NAME) and (D2.PRODUCT_NAME = D3.PRODUCT_NAME))

What Is the Coalesce Statement? A coalesce statement is simply an efficient means of dealing with query items from conformed dimensions. It is used to accept the first non-null value returned from either query subject. This statement allows a full list of keys with no repetitions when doing a full outer join.

Why Is There a Full Outer Join?A full outer join is necessary to ensure that all the data from each fact table is retrieved. An inner join gives results only if an item in inventory was sold. A right outer join gives all the sales where the items were in inventory. A left outer join gives all the items in inventory that had sales. A full outer join is the only way to learn what was in inventory and what was sold.

Modeling 1-n Relationships as 1-1 RelationshipsIf the cardinality were modified to use only 1-1 relationships between query subjects or dimensions, the result of a query on Product Forecast and Sales with Time or Time and Product generates a single Select statement that drops one join to prevent a circular reference.

The example below shows that the results of this query are incorrect when compared with the results of individual queries against Sales or Product Forecast.

The results of individual queries are as follows.

When you combine these queries into a single query, the results are as follows.

The SQLIf you look at the SQL, you can see that, because Cognos 8 detected that a circular join path exists in the model, it did not include one of the relationships that was not necessary to complete the join path. In this example, the relationship between Time and Product Forecast was dropped.

A circular join path rarely results in a query that produces useful results.select



TIME_.MONTH_NAME as MONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,XSUM(SALES_FACT.QUANTITY forTIME_.CURRENT_YEAR, TIME_.QUARTER_KEY, TIME_.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY ) as QUANTITY,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME_.CURRENT_YEAR, TIME_.QUARTER_KEY, TIME_.MONTH_KEY, PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE, PRODUCT.PRODUCT_KEY ) as EXPECTED_VOLUME

from (select TIME.DAY_KEY,TIME.MONTH_KEY, TIME.QUARTER_KEY,TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAME from TIME_DIMENSION TIME) TIMEjoin SALES_FACT on (TIME_.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)join PRODUCT_FORECAST_FACT on (TIME_.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY)join PRODUCT (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY)

where (PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella')) and (TIME_.MONTH_NAME in ('April 2004','February 2004','February 2006'))

group by TIME_.MONTH_NAME, PRODUCT.PRODUCT_NAME

Multiple-fact, Multiple-grain Query on Non-Conformed DimensionsIf a non-conformed dimension is added to the query, the nature of the result returned by the stitched query is changed. It is no longer possible to aggregate records to a lowest common level of granularity because one side of the query has dimensionality that is not common to the other side of the query. The result returned is really two correlated lists.

The ResultThe results of individual queries on the respective star schemas look like this.



Querying the same items from both star schemas yields the following result.

In this result, the lower level of granularity for records from Sales results in more records being returned for each month and product combination. There is now a 1-n relationship between the rows returned from Product Forecast and those returned from Sales.

When you compare this to the result returned in the example of the multiple-fact, multiple grain query on conformed dimensions, you can see that more records are returned and that Expected Volume results are repeated across multiple Order Methods. Adding Order Method to the query effectively changes the relationship between Quantity data and Expected Volume data to a 1-n relationship. It is no longer possible to relate a single value from Expected Volume to one value from Quantity.

Grouping on the Month key demonstrates that the result in this example is based on the same data set as the result in the multiple-fact, multiple-grain query but with a greater degree of granularity.



The SQLThe stitched SQL generated for this example is very similar to the SQL generated in the multiple-fact, multiple-grain query (p. 32). The main difference is the addition of Order Method. Order Method is not a conformed dimension and affects only the query against the Sales Fact table.select

D2.QUANTITY as QUANTITY,D3.EXPECTED_VOLUME as EXPECTED_VOLUME,coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,coalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME,D2.ORDER_METHOD as ORDER_METHOD

from (select PRODUCT.PRODUCT_NAME as PRODUCT_NAME,TIME.MONTH_NAME as MONTH_NAME,ORDER_METHOD.ORDER_METHOD as ORDER_METHOD,XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR,TIME.QUARTER_KEY, TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY,ORDER_METHOD_DIMENSION.ORDER_METHOD_KEY ) as QUANTITY

from PRODUCT_DIMENSION PRODUCTjoin SALES_FACT SALES_FACTon (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY)join ORDER_METHOD_DIMENSION ORDER_METHODon (ORDER_METHOD.ORDER_METHOD_KEY = SALES_FACT.ORDER_METHOD_KEY)join TIME_DIMENSION TIMEon ( TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)

where (PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella')) and ( TIME.MONTH_NAME in ('April 2004','February 2004','February 2006'))

group by PRODUCT.PRODUCT_NAME,TIME.MONTH_NAME,ORDER_METHOD.ORDER_METHOD) D2

full outer join (select

PRODUCT.PRODUCT_NAME as PRODUCT_NAME,TIME.MONTH_NAME as MONTH_NAME,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME.CURRENT_YEAR, TIME.QUARTER_KEY, TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY ) as EXPECTED_VOLUME

from PRODUCT_DIMENSION PRODUCTjoin PRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACTon (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY)join

(select TIME.CURRENT_YEAR as CURRENT_YEAR,TIME.QUARTER_KEY as QUARTER_KEY,TIME.MONTH_KEY as MONTH_KEY,XMIN( TIME.MONTH_NAME for TIME.CURRENT_YEAR, TIME.QUARTER_KEY, TIME.MONTH_KEY ) as MONTH_NAME

from TIME_DIMENSION TIME

group by TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY) TIMEon ( TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY)

where (PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella')) and



( TIME.MONTH_NAME in ('April 2004','February 2004','February 2006'))group by

PRODUCT.PRODUCT_NAME,TIME.MONTH_NAME) D3on ((D2.PRODUCT_NAME = D3.PRODUCT_NAME) and (D2.MONTH_NAME = D3.MONTH_NAME))

Resolving Ambiguously Identified Dimensions and FactsIf ambiguously identified dimensions and facts are not resolved, the result could be unpredictable or incorrect queries. These queries could contain double-counted results, result sets that are incorrectly related, and inefficient queries. They can also contain incorrect summaries for queries with multiple facts.

In this example, you must resolve the areas that are circled.

You can resolve the circled areas by using a combination of data source and model query subjects. There are some cases that can even be resolved by adding filters to the query subjects that effectively change the cardinality from n to 1. The query subjects you create will form the foundation of a dimensional model.

Resolving Queries That Should Not Have Been SplitIf queries are split and should not be split, you must resolve these queries.

Query subjects on the n side of all relationships are identified as facts. We can see that in the following example, Order Header and Country Multilingual are behaving as facts. In reality, the Country Multilingual query subject contains only descriptive information and seems to be a lookup table. From a dimensional or business modeling perspective, Country Multilingual is an extension of Country.

Why is it a problem to leave the model like this?



Test this model by authoring a report on the number of orders per city, per country. Using this model returns an incorrect result. The numbers are correct for the cities but some cities are shown as being in the wrong country. This is an example of an incorrectly related result.

Usually the first place to look when you see something like this is in the SQL.

The SQLIn this example, we see a stitched query, which makes sense if we have multiple facts in the model. A stitched query is essentially a query that attempts to stitch multiple facts together. It uses the relationships that relate the facts to each other as well as the determinants for the conformed, or common, dimensions defined in the model. A stitched query can be identified by two queries with a full outer join. The wrapper query must include a coalesce statement on the conformed dimensions.

Note the following problems in the SQL:• The query has no coalesce statement.• RSUM indicates an attempt to create a valid key.select

D3.COUNTRY as COUNTRY,D2.CITY as CITY,D2.number_of_orders as number_of_orders

from (select

SALES_BRANCH.CITY as CITY,XCOUNT(ORDER_HEADER.ORDER_NUMBER for SALES_BRANCH.CITY ) as number_of_orders,RSUM(1 at SALES_BRANCH.CITY order by SALES_BRANCH.CITY asc local) as sc from gosales.gosales.dbo.SALES_BRANCH SALES_BRANCHjoin gosales.gosales.dbo.ORDER_HEADER ORDER_HEADERon (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE)

group by SALES_BRANCH.CITY

order by CITY asc) D2

full outer join (select

COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,RSUM(1 at COUNTRY_MULTILINGUAL.COUNTRY order by COUNTRY_MULTILINGUAL.COUNTRY asc local) as sc

from gosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL

group by COUNTRY_MULTILINGUAL.COUNTRY

order by COUNTRY asc



) D3on (D2.sc = D3.sc)

By looking at the stitched columns in each query, we see that they are being calculated on unrelated criteria. This explains why there is no apparent relationship between the countries and cities in the report.

So why do we see a stitched query? To answer that question, we must look at the model.

In this example, the query items used in the report came from different query subjects. Country came from Country Multilingual, City came from Sales Branch, and the Number of Orders came from a count on Order Number in the Order Header query subject.

The problem is that the query splits because the query engine sees this as a multiple-fact query. However, the split does not have a valid key on which to stitch because there is no item that both facts have in common.

There is more than one way to solve this problem but both require understanding the data.

Solution 1You can add a filter to Country Multilingual that changes the cardinality of the relationship to 1-1.

Select *from [GOSL].COUNTRY_MULTILINGUALWhereCOUNTRY_MULTILINGUAL."LANGUAGE"=’EN’

Or you can add a filter on the relationship and change the cardinality to 1-1.COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODE and COUNTRY_MULTILINGUAL.LANGUAGE = ’EN’

Either choice results in a model that has a single fact in this query.

Solution 2Simplify the model by consolidating the related query subjects. This gives the greatest benefit by simplifying the model and reducing the opportunities for error in query generation.

With either solution, the result of the query is now correct.



The SQL is no longer a stitched query.select

Country.c7 as COUNTRY,SALES_BRANCH.CITY as CITY,XCOUNT(ORDER_HEADER.ORDER_NUMBER for Country.c7,SALES_BRANCH.CITY ) as number_of_orders

from (select

COUNTRY.COUNTRY_CODE as c1,COUNTRY_MULTILINGUAL.COUNTRY as c7

from gosales.gosales.dbo.COUNTRY COUNTRYjoin gosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALon (COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODE)where COUNTRY_MULTILINGUAL.LANGUAGE='EN') Country

join gosales.gosales.dbo.SALES_BRANCH SALES_BRANCHon (SALES_BRANCH.COUNTRY_CODE = Country.c1)join gosales.gosales.dbo.ORDER_HEADER ORDER_HEADERon (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE)

group by Country.c7,SALES_BRANCH.CITY

Resolving Queries That Are Split in the Wrong Place Sometimes using 1-n cardinality does not resolve circular join paths. Incorrect results are still returned because of an improperly-formed stitched query.

For example, the model contains these objects.



If you report on Sales Target and Actual Sales grouped by Product and Sales Staff, the result set is incorrect. Actual Sales are a bit too large.

To check the result, query each fact separately.

This confirms that the first report is giving a much larger result for Actual Sales than it should.

The SQLNote the following problems when you look at the SQL:• Only one of the dimension columns has a coalesce statement. This indicates that the query

has been improperly split.• Grouping is correct for the Sales Target side of the query. This explains why Sales Target is

accurate.• The quantity side of the stitched query is grouped only by Product, which explains why the

Actual Sales are too large.select

coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,D2.LAST_NAME as LAST_NAME,D2.SALES_TARGET as SALES_TARGET,D3.Actual_sales as Actual_sales

from (select

Product.PRODUCT_NAME as PRODUCT_NAME,SALES_STAFF.LAST_NAME as LAST_NAME,XSUM(SALES_TARGET.SALES_TARGET for Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME ) as SALES_TARGET

from



(select PRODUCT_MULTILINGUAL.PRODUCT_NAME,PRODUCT.PRODUCT_NUMBER from gosales.gosales.dbo.PRODUCT PRODUCT, gosales.gosales.dbo.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL where PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER) Productjoin gosales.gosales.dbo.SALES_TARGET SALES_TARGETon (Product.PRODUCT_NUMBER = SALES_TARGET.PRODUCT_NUMBER)join gosales.gosales.dbo.SALES_STAFF SALES_STAFFon (SALES_STAFF.SALES_STAFF_CODE = SALES_TARGET.SALES_STAFF_CODE)

group by Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME) D2

full outer join (select Product.PRODUCT_NAME as PRODUCT_NAME,XSUM(XSUM((ORDER_DETAILS.QUANTITY * ORDER_DETAILS.UNIT_SALE_PRICE) for Product.PRODUCT_NAME ) at Product.PRODUCT_NAME for Product.PRODUCT_NAME ) as Actual_sales

from (select PRODUCT_MULTILINGUAL.PRODUCT_NAME,PRODUCT.PRODUCT_NUMBER from gosales.gosales.dbo.PRODUCT PRODUCT, gosales.gosales.dbo.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL where PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER) Productjoin gosales.gosales.dbo.ORDER_DETAILS ORDER_DETAILSon (Product.PRODUCT_NUMBER = ORDER_DETAILS.PRODUCT_NUMBER)

group by Product.PRODUCT_NAME) D3on (D2.PRODUCT_NAME = D3.PRODUCT_NAME)

These problems exist because nothing was selected from Order Header. It was not included in the query so there was no way to link Sales Staff to Order Details. Linking Sales Staff to Order Details was not necessary to connect all the tables because there was already a relationship between Sales Staff and Sales Target.

Although you can resolve this by including an item from Order Header in the report, your users may not know to do that. We recommend that you fix it in the model. This is the recommended solution from both a dimensional and business modeling standpoint. In addition, a simpler model makes it harder to write a report that generates bad SQL.

Consolidate query subjects where logical groupings are possible. In this example, combine the Order Details and Order Header query subjects. The new group of query subjects can now be used for dimensional modeling.



When you use this new group of query subjects, the report looks like this.

When you look at the SQL, you see this:select

coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,coalesce(D2.LAST_NAME,D3.LAST_NAME) as LAST_NAME,D2.SALES_TARGET as SALES_TARGET,D3.Actual_sales as Actual_sales

from (select Product.PRODUCT_NAME as PRODUCT_NAME,SALES_STAFF.LAST_NAME as LAST_NAME,XSUM(SALES_TARGET.SALES_TARGET for Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME ) as SALES_TARGET

from (select PRODUCT_MULTILINGUAL.PRODUCT_NAME,PRODUCT.PRODUCT_NUMBER from gosales.gosales.dbo.PRODUCT PRODUCT, gosales.gosales.dbo.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL where PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER) Productjoin gosales.gosales.dbo.SALES_TARGET SALES_TARGETon (SALES_TARGET.PRODUCT_NUMBER = Product.PRODUCT_NUMBER)join gosales.gosales.dbo.SALES_STAFF SALES_STAFFon (SALES_STAFF.SALES_STAFF_CODE = SALES_TARGET.SALES_STAFF_CODE)

group by Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME) D2full outer join (select Product.PRODUCT_NAME as PRODUCT_NAME,SALES_STAFF.LAST_NAME as LAST_NAME,XSUM((ORDER_DETAILS_ORDER_HEADER.c5 * ORDER_DETAILS_ORDER_HEADER.c8) for Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME ) as Actual_sales

from



(select PRODUCT_MULTILINGUAL.PRODUCT_NAME,PRODUCT.PRODUCT_NUMBER from gosales.gosales.dbo.PRODUCT PRODUCT, gosales.gosales.dbo.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL where PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER) Productjoin (select ORDER_DETAILS.PRODUCT_NUMBER as c4,ORDER_DETAILS.QUANTITY as c5,ORDER_DETAILS.UNIT_SALE_PRICE as c8,ORDER_HEADER.SALES_STAFF_CODE as c14

from gosales.gosales.dbo.ORDER_DETAILS ORDER_DETAILSjoin gosales.gosales.dbo.ORDER_HEADER ORDER_HEADERon (ORDER_HEADER.ORDER_NUMBER = ORDER_DETAILS.ORDER_NUMBER)) ORDER_DETAILS_ORDER_HEADERon (ORDER_DETAILS_ORDER_HEADER.c4 = Product.PRODUCT_NUMBER)join gosales.gosales.dbo.SALES_STAFF SALES_STAFFon (SALES_STAFF.SALES_STAFF_CODE = ORDER_DETAILS_ORDER_HEADER.c14)

group by Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME) D3on ((D2.PRODUCT_NAME = D3.PRODUCT_NAME) and (D2.LAST_NAME = D3.LAST_NAME)))


Index

Aambiguous objects, 38attributes, 25, 28

Ccardinality

1-1, 341-n, 34checking, 7data source, 8dimensions and facts, 9queries, 8rules, 8types, 8

circular joins, 41conformed dimensions

multiple facts, 32, 35conformed star schema groups, 22copyright, 2creating

measure dimensions, 11regular dimensions, 11star schema groups, 22

cross-fact queries, 9

Ddata source dimensions, 17data types, 24determinants, 6

cardinality, 8converting from dimension information, 28defining, 16reviewing, 29upgrading to, 24

dimension information, 25, 28dimensional queries, 31

multiple facts and grains, 32, 35single fact, 31

dimensionally modeling relational metadata, 7dimensions

ambiguous, 38converting from query subjects, 25data source, 17defining, 16hierarchies, 21identifying, 9measure, 6, 11, 16model, 17query subjects, 17regular, 6, 11, 16, 17reviewing, 27

dimensions (cont'd)role-playing, 12scope relationships, 7star schema groups, 22upgrading to, 24

documentversion, 2

double-counting, 6, 9, 34, 38

Ffact-less query, 22facts, 6, 11

ambiguous, 38identifying, 9

full outer joins, 8

Ggranularity, 15

Hhierarchies, 6, 16, 17, 25, 28

multiple, 21

Iidentifiers

unique, 6imported metadata

checking, 7

Jjoins

circular, 41full outer, 8

Kkeys, 8, 25, 28

Llevels, 6, 25, 28

Mmandatory cardinality, 8many-to-many relationships, 8master-detail tables, 11maximum cardinality, 8measure dimensions, 6

creating, 11defining, 16


Index

measure dimensions (cont'd)role-playing, 12

minimum cardinality, 8model dimensions, 17models

repairing, 25reviewing, 24upgrading, 24

multiple hierarchies, 21multiple valid relationships, 12multiple-fact queries, 17, 32, 35multiple-grain queries, 17, 32, 35

Oone-to-many relationships, 9, 34one-to-one relationships, 9, 34optional cardinality, 8optional relationships, 8outer joins

full, 8

Qqueries

fact-less, 22multiple-fact, 17, 32, 35multiple-grain, 17single fact, 31split, 38, 41stitched, 7

query subjectsconverting to dimensions, 25determinants, 28dimensions, 17star schema groups, 22

Rrecursive relationships, 15reflexive relationships, 15regular dimensions, 6, 17

creating, 11role-playing, 12

relationships1-n, 9, 34checking, 7levels of granularity, 15many-to-many, 8multiple valid, 12scope, 7

repairing models, 25resolving

ambiguous objects, 38split queries, 38, 41

reviewing models, 24role-playing dimensions, 12rules of cardinality, 8

Sscope relationships, 7shared dimensions, 16

simplifying models, 10single fact queries, 31split queries, 38, 41SQL, 31star schema groups

creating, 22multiple conformed, 22

stitched queries, 7

Uunique identifiers, 6unique keys, 25, 28upgrading

data types, 24upgrading models, 24

converting, 25, 28from ReportNet 1.x, 23repairing, 25reviewing, 24warnings, 25

Vvalid relationships

multiple, 12verifying models, 25version

document, 2

Wworkflows, 7, 23


Guide Lines for FWM

Documents

Transcript of Guide Lines for FWM