Advanced Modeling for InterSystems IRIS Business Intelligence
Using Cube Inheritance
In some cases, it is necessary to define multiple similar cubes. The system provides a simple inheritance mechanism to enable you to define these cubes more easily. This chapter describes how to use this mechanism. In some parts of this procedure, you cannot use the Architect but must instead use Atelier or Studio.
To use the cube inheritance mechanism:
Define one cube class that contains the core items that should be in all the similar cubes.
This cube is the parent cube.
Optionally mark this cube as abstract so that it cannot be used directly.
To do so, specify abstract="true" in the <cube> element of this class. Then the compiler does not validate it, the Analyzer does not display it, and you cannot execute queries against it.
Note that it is necessary to use Studio to make this change.
Define the child cubes in their own cube classes. For each of these cubes, specify the inheritsFrom attribute. For the value of this attribute, specify the logical name of the parent cube.
This step means that, by default, each of these subcubes contains all the definitions from the parent cube.
You can specify only one cube for inheritsFrom. For inheritsFrom, you can specify a cube that inherits from another cube.
You can define these cubes in the Architect, but to specify the inheritsFrom attribute, it is necessary to use Studio.
Make sure that the parent cube is compiled before any of its child cubes. To do this, specify the DependsOn compiler keyword in each child cube class. For this step, it is necessary to use Studio.
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
You can use the Architect for this step.
Optionally specify additional definitions (dimensions, measures, listings, and so on) in the child cubes.
You can use the Architect for this step.
Note the cube inheritance mechanism has no relationship with class inheritance. Each subcube has its own fact table and indices, 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.
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 Defining Models for InterSystems Business Intelligence
; subcubes are handled in the same way as other kinds of cubes.
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.
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.
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)).
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.
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.
Content Date/Time: 2019-09-20 05:36:42