InterSystems IRIS Data Platform 2019.2  /  Advanced Modeling for InterSystems IRIS Business Intelligence

Advanced Modeling for InterSystems IRIS Business Intelligence
Defining Shared Dimensions and Compound Cubes
Previous section           Next section
InterSystems: The power behind what matters   

This chapter describes how to define shared dimensions and compound cubes. It discusses the following topics:
You can define compound cubes in the Architect, but for shared dimensions, you must use Studio.
For background information, see the chapter “Summary of Model Options” in Defining Models for InterSystems Business Intelligence.
Also see “Accessing the Samples Shown in This Book,” in the preface.
This section provides an overview of shared dimensions and compound cubes.
Shared Dimensions
A shared dimension is a dimension that can be used in more than one cube. A shared dimension enables you to do the following:
Typically, dimensions based on location and time (see the note below) can be shared, even for unrelated cubes.
It might be possible to share other dimensions. For example, suppose that one cube represents transactions and another represents the customers who own the transactions. These two cubes might have common dimensions such as customer class, broker, and so on.
You can share dimensions in either of the following ways:
Date dimensions are automatically informally shared; that is, a date dimension in one cube automatically can affect other cubes that define a date dimension that has the same name. No work is necessary in order to share date dimensions.
Compound Cubes
A compound cube is a subject area that combines multiple cubes (typically two). For these cubes, any dimensions that have the same name must be formally shared dimensions. This enables you to create pivot tables that contain elements from multiple cubes.
The following shows a pivot table created from a compound cube:
In this pivot table:
In a compound cube, the available dimensions are the dimensions from the first listed cube and all formally shared dimensions. The available measures include all the measures from all the cubes. The following rules apply:
Defining a Formally Shared Dimension
To share a dimension formally:
  1. Define the dimension as usual in one cube definition.
    When that cube is built, the system determines the initial members of all levels of that dimension, in the usual way. When the source class receives additional data and the cube is updated, the system adds additional members for any levels, in the usual way.
  2. Open the other cube definition in the Architect and add a shared dimension as follows:
    1. Select Add Element.
    2. Select Shared Dimension.
    3. In the first drop-down list, select the cube that defines the dimension.
    4. In the second drop-down list, select the dimension.
    5. Select OK.
    For all levels in this dimension, the fact table for this cube points to the dimension tables of the other cube.
  3. Optionally, in the second cube, override the source data definition for the levels of the shared dimension.
    By default, the shared dimension uses the same source properties or source expressions that are used in the Dependent Cube. To override these, edit the class in Studio, find the applicable <dimension> element, and add child <hierarchy> and <level> elements as needed; see “Reference Information for Cube Classes” in Defining Models for InterSystems Business Intelligence. In this case, the dimension name, hierarchy names, and level names must be the same as in the other cube.
The following restrictions apply:
Also, for any filters that use these levels, the list of members includes all the members, from all cubes that share the dimension. So, for example, in a given dashboard, a user might see an unfamiliar city name in a filter drop-down, a city name that does not appear in the data used on that dashboard. The user can select it, but no matching data will be found.
The HoleFoodsBudget and CompoundCube/Doctors cubes both contain examples of shared dimensions. These examples are not related to each other.
Defining an Informally Shared Dimension
To define an informally shared dimension, ensure that the logical dimension name, its hierarchy names, its level names, and its member keys are the same in all relevant cubes. (The underlying details of the source expressions, transformation options, and so on do not matter. All that matters is that the logical names match and the member keys match.)
When you do this, you can define pivot tables in each of these cubes and then place those pivot tables on the same dashboard. If you include a filter widget that uses one of the shared dimensions, it can affect all the pivot tables.
The Patients cube (in the class BI.Model.PatientsCube) includes the HomeD dimension. This dimension includes an H1 hierarchy, which includes the ZIP and City levels.
The CityRainfall cube (in the class BI.Model.RainfallCube) also contains the HomeD dimension, which differs from the one in the Patients cube only as follows:
These definitions mean that you can use these cubes in different pivot tables on the same dashboard, and have them respond in the same way to any filters that use the HomeD dimension. The dashboard Dashboards/Demo Two Subject Areas Together demonstrates this. It has a pivot table that uses the Patients cube and another pivot table that uses the CityRainfall cube. The dashboard includes filter controls that affect both pivot tables.
Similarly, the Cities cube (in the class BI.Model.CityCube) contains a dimension named HomeD, which includes an H1 hierarchy, which includes the ZIP and City levels. The display name for HomeD is CityD, so that the dimension appears to have a different name in this cube. As before, the source properties used by the levels are different in the Cities cube than in the Patients cube.
Defining Compound Cubes
To create compound cubes, you must use Studio. To create a compound cube, do all the following:
Recompile any cube definitions that you change. Recompile the compound cube last.
In a compound cube, the available dimensions are the dimensions from the first listed cube and all formally shared dimensions. The available measures include all the measures from all the cubes.
Any dimensions that have the same name in both cubes must be formally shared. Any measures that have the same name in both cubes are aggregated together.
Detail Listings for Compound Cubes
To define detail listings for a compound cube, define identical detail listings in all the participating cubes. The system generates an SQL UNION of these listings.
Note that the listings must be directly based on SQL; detail listings via data connectors will not work for compound cubes.
Example Compound Cube
To see an example of a compound cube, see the class BI.Model.CompoundCube.CompoundCube. This class is defined as follows:
Class BI.Model.CompoundCube.CompoundCube Extends %DeepSee.SubjectArea 
[ DependsOn = (BI.Model.CompoundCube.Patients, BI.Model.CompoundCube.Doctors, 
BI.Model.CompoundCube.CityRainfall) ]

/// This XData definition defines the SubjectArea.
XData SubjectArea [ XMLNamespace = "" ]
<subjectArea name="CompoundCube/CompoundCube"  displayName="CompoundCube/CompoundCube"
    baseCube="CompoundCube/Patients,CompoundCube/Doctors,CompoundCube/CityRainfall"  >

The cube CompoundCube/Patients, which is defined in BI.Model.CompoundCube.Patients defines all the dimensions.
The other cubes (CompoundCube/Doctors and CompoundCube/CityRainfall) define dimensions that are shared from the CompoundCube/Patients. Notice that not all the dimensions are defined in all the cubes. The following table shows the dimensions available in each cube:
Dimension CompoundCube/Patients cube CompoundCube/Doctors cube CompoundCube/CityRainfall cube
The HomeD dimension is defined in all three cubes, so this dimension affects the measures of all three cubes. For example, the dashboard Demo Compound Cube includes this pivot table:
The Patient Count measure is defined in CompoundCube/Patients, Doctor Count measure is defined in CompoundCube/Doctors, and Avg Monthly Rainfall Inches measure is defined in CompoundCube/CityRainfall. Notice that the values are different for each measure for each city.
The same dashboard also includes a pivot table that use BirthD for rows:
Because CompoundCube/Doctors does not define the BirthD dimension, the measure Doctor Count cannot be broken out by birth decade. Notice that the Doctor Count column shows the same number in all cells; this is the total doctor count across birth decades for all patients.
Finally the Demo Compound Cube dashboard also includes a pivot table that use DoctTypeD for rows:
Because CompoundCube/CityRainfall does not define the DocTypeD dimension, the measure Avg Monthly Rainfall Inches cannot be broken out by doctor type. This measure is aggregated across all patients (by averaging, as defined in the measure).

Previous section           Next section
Send us comments on this page
View this book as PDF   |  Download all PDFs
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA
Content Date/Time: 2019-09-20 05:36:42