Tip or Technique

Bridge Tables and IBM Cognos 8

Product(s): IBM Cognos 8
Area of Interest: Modeling
Bridge Tables and IBM Cognos 8 2

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

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 3

Contents
1 INTRODUCTION ............................................................................................ 4
1.1 PURPOSE ................................................................................................................ 4
1.2 APPLICABILITY ......................................................................................................... 4
1.3 EXCLUSIONS AND EXCEPTIONS ..................................................................................... 4
2 BRIDGE AND FACT TABLES ........................................................................... 4
2.1 ALTERNATE AGGREGATES............................................................................................ 9
3 CONCLUSION .............................................................................................. 11

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 4

1 Introduction
1.1 Purpose
Not all database schemas can be formed into distinct star schemas related
through conformed dimensions. On occasion the star schemas or subject
areas can only be linked through a factless fact or bridge table. The point of
such tables is to provide a many to many relationship between two distinct
data sets.
The key difference between a bridge table and a fact table is that the bridge
table relationship is mandatory and is used to restrict the data from one
subject area based on the records returned from another subject area. A fact
table does not provide such a restriction because the two other data sets will
operate as non-conformed dimensions and a filter applied to one will have no
impact on the other.

1.2 Applicability
This document was written as of IBM Cognos 8 MR2. Refer to your product
documentation in later releases to identify if this approach is required.

1.3 Exclusions and Exceptions

When working with a bridge table the dimensional modelling techniques using
conformed dimensions will not be applicable. Additional query paths resulting
from conformed dimensions may cause the bridge table to be left out of a
query when it is necessary to provide the appropriate data matching between
the two subject areas. The additional dimensions must be created as distinct
model query subjects so that a direct connection does not exist through these
dimensions and allow the bridge table to be removed from the query.

Further, the techniques outlined in this document apply only to relational

modelling and cannot be extended to dimensionally modelled relational
packages.

2 Bridge and Fact Tables

A prime example of a bridge table occurs when describing Real Estate
Properties and Owners. In this scenario each property may be owned by
multiple owners and each owner may own multiple properties.

If these tables were modelled according to the data cardinality the bridge
table would have n records for every 1 record from either the owner or
property tables. By following the data cardinality the bridge table becomes a
fact table within the model.

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 5

In the diagram above we see the bridge table acting as a fact table between
the OWNER and PROPERTY query subjects. The OWNER and PROPERTY
query subjects are then non-conformed dimensions to the OWNER_FACT and
PROPERTY_FACT respectively. The facts associated with non-conformed
dimensions will be evaluated outside the context of the other dimensions in a
query. We can see the results of this by combining fact values from the
property data with values from the owner dimension.

The above result is the entire data set in our sample data. We can see that
there are multiple entries for some of the cities. In our example this shows
that different people share ownership of a property in that city. For example,
Corinne Dufour, Tilly Masterson, and Sridar Devjan all have joint ownership of
a property in Cordoba.

One other interesting item from the above data is that the total of the
appraised values is the same for each owner. This result occurs because the
property appraised value is evaluated only within the context of the property
dimension because a conformed relationship to the owner data does not
exist. This becomes more apparent when a filter is applied to the owners:

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 6

We can see immediately that the subtotals still reflect the entire set of
property appraisal values. This occurs because there is no conformed
dimension in place so the filter is only applied to the owner data rather than
the unrelated property information. The extra row for Moose Jaw also occurs
because of this non-conformed owner dimension. The query for the property
information is not restricted based on the selected owners so all properties
are returned for the query.

If the bridge table were some other fact data then this scenario would be
entirely valid because there would be the lack of shared/conformed
dimensions would mean that the fact data is truly unrelated. However, a
bridge table is an exceptional case and the relationship between the
dimensions must be enforced through the bridge table records.

The desired results when using a bridge table is to see both sets of fact data
restricted when a filter is applied to one dimension or another. Further, the
subtotals should only reflect the individual contributions rather than the
overall totals.

To obtain these results there are three main changes that must be applied to
the model.
1. Change the relationships to the bridge table to be many-to-many
to prevent the bridge from acting as a fact table.
2. Apply determinants to the tables so that a unique key is available
to generate aggregates over the correct data groupings.
3. Change the Regular Aggregate of fact query items to Calculated.
This changes the order of operations applied when the measures
are aggregated so that the rollup is performed on the records
pertaining to each given data set.

The first change is applied to the relationships in the following manner:

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 7

This change prevents the split select for multiple facts from being applied
around the bridge table. Filters applied to the query and the subtotals will
now reflect the mandatory relationship across the bridge table.

So now the subtotals reflect the individual records returned for each and the
the property records are restricted based on the owner filter. However, the
grand total is incorrect.

If we look closer at the detail values we can see that Corrine and Tilly have
joint ownership of a property in Cordoba. The individual subtotals correctly
include all the detail values but the grand total ends up counting Cordoba
twice. This behaviour can be corrected by the second and third steps listed
above.

First, the unique keys for the tables must be defined:

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 8

The second step applies the calculated aggregate type to the fact query item
in Framework Manager.

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 9

With these changes we can return to Query Studio or Report Studio to

generate the following query:

Now both the subtotals and the grand total reflect the unique values for each
data set. In the overall summary Cordoba is only counted once and is
obtained via simple drag-and-drop operations within Query Studio.

2.1 Alternate Aggregates

The calculated aggregate is the key to obtaining the correct order of

operations to roll up the measure values. Unfortunately the calculated
aggregate can be overridden within the studios. This will result in unexpected
rollups of the data. For example, if the footer rollup function for
appraised_value is changed in Query Studio to Average instead of using
Calculated (or Automatic to leverage the model properties) then the following
will be returned:

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 10

The individual subtotals are correct in that they reflect the average of the
individual values. However, the overall summary shows 454 000 and this is
the average of all the detail values including the second instance of the
Cordoba value. The expected average would be created using the distinct
values from the data set to obtain an average of 460 000.

This type of aggregation can be handled using Framework Manager. The

regular data items with the calculated aggregate type leverage the data type
to define the aggregate function for the detail records. In the case of numeric
data this is the same as a sum or total of the detail records. To obtain an
average or any other aggregate function the function must be defined within
the expression for the data item and the calculated aggregate applied to the
calculation results.

To create the aggregate calculation a calculation object can be created within

a folder or namespace outside of the query subject itself. For an average the
following expression might be used:

average( [Namespace].[Query Subject].[Query Item] )

The calculated aggregate function would then be applied as shown earlier in

this document.

The resulting calculated data item can be dragged into the report directly to
create the average subtotal and overall summaries that are required.

IBM Cognos Proprietary Information

Bridge Tables and IBM Cognos 8 11

3 Conclusion
With proper handling, a bridge table can be a useful tool for relating distinct,
but closely related, data sets. By applying determinants, cardinality, and
calculated aggregates the query subjects can be designed for rudimentary
use in Query Studio without requiring advanced filters or calculations to relate
the data sets.

IBM Cognos Proprietary Information