on - edited on by
jvonallmen
Introduction
This document is intended to outline how Dimensions and Extensibility impact Cube View metadata and data intersections. This document does not involve details on designs and behaviors using “Sparse Row Suppression”.
Dimension Overview
As a basic definition, Cube View rows, and/or columns, are defined within the Expansion Level’s Member Filter field. A Dimension Type is assigned to each Expansion Level to correspond with the Member Filter definition.
Dimensions in OneStream are defined within a Dimension Type, such as Entity, Scenario or Account Type. Within each Type, Dimensions are created and given a Dimension Name, such as “CorpAccounts” in which members are defined.
OneStream Extensibility allows the application architect to establish a “standard” definition of members which can be extended to suit process and reporting needs. An example of an Extended Account Dimension can be found in the Golfstream reference application between “CorpAccounts” and “HoustonAccounts”. The example shows the “HoustonAccounts” members are extended off the “CorpAccounts’” base member 60000.
.
Dimension are assigned to Cubes to define the dimensionality which will be supported by the Cube. The “Cube Dimensions” dimension properties includes an option for “Scenario Type”, which allows the dimensions to vary by “Scenario”. This means, the business process and reporting can vary between Scenarios, such as an Actual and Budget type Scenario.
Lastly, the management of Extensibility is completely integrated, and seamless, within the OneStream platform. The “main” Cube, the one that all other related Cubes roll-up to, is defined as the “Top Level Cube for Workflow”.
Along with having its dimensionality defined, the “top level” Cube will include properties for “Cube References”. The “Cube References” act to establish the relationship between the Entities across one or more Cubes in order to seamlessly integrate the results from many linked Cubes.
The design and configuration of Dimensions in an Extensible application creates a flexible and integrated system to tailor all business processes and reporting requirements. The integration of the Extended Dimensions defined at the “Top Level Cube”, is reflected in the Dimension’s “Merged Hierarchy”. The Merged Hierarchy reflects the complete collection of members across a “Top Level Cube’s” dimensionality.
In summary, the OneStream platform enables each Cube and associated Entity, to have dimensionality designed to meet very specific business needs, by Scenario Type.
Cube View Dimension Assignment
The Cube View is structured to filter against the multi-dimensional database to return and display results. The Cube View facilitates this definition using the Point of View, Row and Column properties, such as the Member Filters. In the Row example below, the Row is defined to return the complete account hierarchy, from the parent “60000”.
When the Cube View is executed, the dimension detail presented is determined by the Cube being referenced. “Top Level Cubes” will present the dimension from the “Merged Hierarchy”, reflecting the Extensibility across Cubes.
Extended Cubes will render the dimension detail reflecting the assigned Cube Dimensions.
Managing Display Detail
All data in OneStream is managed as a Data Intersection. This reflects that a value being displayed is tied to an intersection across all the OneStream Dimensions. When a Dimension is not relevant to the data, that Dimension must still be used to define the data, most often the “None” member is used.
Invalid Records
Invalid data records can display due to Account Constraints or because of a conflict between the Cube-Entity setting and the Dimension members being referenced.
Account Constraints
An Account Constraint will produce an Invalid intersection. This is generally due to a conflict between the Account and the Flow or User Defined Dimension being used as a data intersection. In the example below, viewing the properties of the Account Member, it has a Constraint applied for UD1. This Constraint establishes the only valid data intersection to be a base member of “TotalCostCenters”
In the Cube View example below, an invalid cell displays due to the Constraint.
Right-Clicking the cell for “Cell POV Information” we can see the Cube View is defined for U1#None, which is not within the Constraint of “TotalCostCenters”
By editing the Cube View Row or Column properties, setting the “Data” tab Suppression setting for “Suppress Invalid Rows” to true will address this display issue.
Dimension References
As outlined, in an Extensible application the metadata definition is directly tied to the Cube and Entity being referenced. In this example, an Extended Entity is being displayed using the “Top Cube” reference generating Invalid Intersections due to both the Constraints and some of the Merged Hierarchy Accounts not being associated with the Entity’s dimensionality.
In this example, the Cube View property of “Suppress Invalid Rows” can be applied to address the Constraints and Invalid Dimension references.
Our example still shows instances of invalid records. This is because in an Extensible application, a member can function as a parent or base member depending upon how the dimension is used.
In this case, we should ensure we also apply the suppression of invalid intersections to the parent members.
Focusing Dimension References with .Options
As mentioned, in an Extended application, the generation of the Cube View is highly dependent upon the Cube and Entity settings. However, there are reporting requirements that may dictate that the reporting is driven off the “main” dimension. For example, when reporting Entities from the main “top level cube”, the requirement may be to only view the results by the Cube’s Dimension. In this case, the details from Extended cube details driven off the “merged hierarchy” are not desired.
To help control what metadata is returned to the Cube for the Row Member Filter expansion, the designer can use the Member Expansion Function “.Options”. This function is appended to an expansion to set the Cube, Scenario Type and Merged Hierarchy control.
In the example below, the “Top Level” Cube is assigned the “MainAccounts” dimension. The Extended Cube and Entity being displayed is assigned the “SubSidAccounts”.
Use .Options to eliminate the use of the Merged hierarchy to limit the results to the designed main “top level” cube dimension reporting detail.
Other Suppression
There are many reporting design and use cases which influence the type of Member Filter expression and formatting selections on a Cube View. For example, there are cases where not all suppression of members is desired. In the example below, the parent “Current Assets” should always display.
