Using Cube Inheritance
In some cases, it is necessary to define multiple similar cubes. Business Intelligence provides a simple inheritance mechanism to enable you to define these cubes more easily. This page describes how to use this mechanism. In some of the procedures described, you cannot use the Architect but must instead use an Integrated Development Environment (IDE) with support for ObjectScript: Visual Studio Code or Studio.
Introduction to Cube Inheritance
To use the cube inheritance mechanism:
-
Define one cube class according to the procedure described in Defining a Cube. This cube should contain the core items expected in all the similar cubes, and will serve as the parent cube.
-
Optionally, you can mark this cube as abstract so that it cannot be used directly.
-
On your BI instance, open a an IDE session and ensure you are in your analytics namespace.
-
In the XData definition, locate the <cube> element and set abstract="true" in its list of attributes. This prevents the compiler from validating the cube, the Analyzer from displaying it, and the user from executing queries against it.
-
Save your changes.
-
-
Define the child cubes in their own cube classes. This procedure deviates from the procedure used to define the parent cube.
-
On your BI instance, log in to the Management Portal as a user with administrative privileges.
-
Navigate to Home > Analytics > Architect.
-
Click the New button.
-
For Definition Type, select Cube.
-
Enter a Cube Name and, optionally, a Display Name of your choosing.
-
For Cube Source, select Cube.
-
In the Base Cube field, enter the logical name of the parent cube created previously.
-
Enter a Class Name for the Cube and, optionally, a Class Description.
-
Click OK to create the child cube. By default, cubes created in this way inherit all definitions from their parent cubes. Each cube may only have one Base Cube, but Base Cubes may themselves inherit from other cubes.
-
-
Make sure that the parent cube is compiled before any of its child cubes. In the Details pane to the right of the model viewer, enter the logical name of the parent cube into the Depends On field.
-
Optionally redefine any dimension, measure, or other top-level element specified in the parent cube. To do so, specify a definition in the child cube and use the same logical name as in the parent cube. The new definition completely replaces the corresponding definition from parent cube. Also see Hiding or Removing Items.
-
Optionally specify additional definitions (dimensions, measures, listings, and so on) in the child cubes.
Note the cube inheritance mechanism has no relationship with class inheritance. Each subcube has its own fact table and indexes, and (at run time) these are independent of the parent cube. The cube inheritance mechanism is used only at build time, and affects only the definitions in the cubes.
Cube Inheritance and the Architect
When you display a subcube in the Architect, you can view the inherited elements, override the inherited elements, and define new elements. The left area displays the source class for the cube, so that you can drag and drop items from this class for use as elements in the subcube. The middle area of the Architect displays both inherited items (in italic) and locally defined items (in plain font).
When you select an inherited item in the middle area of the Architect, the Details pane displays the following at the top:
The rest of the Details pane is read-only.
The following subsections describe how to redefine inherited items, remove overrides, and add local elements. For information on compiling and building cubes, see Compiling and Building Cubes; subcubes are handled in the same way as other kinds of cubes.
Redefining an Inherited Element
To redefine an inherited element, click the element in the middle area and then click the Customize button in the Details pane on the right. If the element you want to customize is not a top-level element, then click the top-level element that contains it, and then click the Customize button in the Details pane on the right.
When you click Customize, the Architect copies the definition from the parent cube to the subcube, creating a local definition that overrides the inherited definition. You can now edit the local definition.
Removing an Override
To remove a local definition that overrides an inherited definition:
-
Click the X in the row for that item, in the middle area of the Architect.
-
Click OK to confirm the action.
Adding a Local Element
To add a local element to the subcube, either use the Add Element button or use the standard drag-and-drop actions, as described in Adding Items to a Cube.
The %cube Shortcut
If the parent cube contains any source expressions that use the variable %cube, the system cannot build the cube unless you do either of the following:
-
Modify the child cube class that it extends the parent cube class. (That is, use class inheritance.)
-
Override the elements that use %cube. In your local definitions, replace %cube with the usual full syntax (##class(package.class)).
Hiding or Removing Items
To hide a measure, dimension, calculated member, or calculated measure, add an override for that item and select the Hidden option in your override. The item is still created but is not shown in the Analyzer.
To hide levels or hierarchies, redefine the dimension that contains them. To do so, add an override for the dimension. In your override, define all the hierarchies and levels that this dimension should contain. This new dimension completely replaces the inherited dimension. The new dimension can, for example, define fewer or more levels than the corresponding dimension in the parent cube.
Inheritance and Relationships
If the parent cube has any relationships, note that those relationships are inherited, but necessarily not in a useful way, because the relationships always point to the original cubes.
For example, suppose that two cubes (Patient and Encounter) are related to each other, and you create subcubes (CustomPatient and CustomEncounter) for each of them. By default, CustomPatient has a relationship that points to the original Encounter cube. Similarly, the CustomEncounter cube has a relationship that points to the Patient cube. If you want a relationship between CustomPatient and CustomEncounter, you must define that relationship explicitly in the subcubes.