About Dimensions

Dimensions

Dimensions are used to represent the hierarchical relationships between different elements when used in a cube.

For example, a sales cube may have a dimension for Products, with a hierarchy which holds different levels for product category, product subcategory, and individual product. This allows users to drill down from high-level summaries to more detailed information, and also to roll up from lower-level details to higher-level summaries.

Dimensions can be used to represent other types of hierarchical relationships as well, such as organizational structures, geographical hierarchies, profit and loss hierarchies and time periods.

Hierarchical dimensions are an important part of data modeling in MODLR, as they allow users to easily navigate and analyze complex data sets, and to understand the relationships between different data elements within a cube.

Creating and Maintaining a Dimension

Like most objects in MODLR, dimensions can be built and maintained manually by the user or automatically by a process which a user would need to configure. For automatic creation, the process which builds the dimension can use a multiple step approach and can use a variety of datasources.

Dimension Types

Dimensions have a base type which provides hints to the user interface for how best to arrange and process dimension elements.

Type	Description
Standard	The standard dimension type is most commonly used and provides no specific advantage over the other types.
Time	Time dimensions are build and managed by the system process "System.Dimension.Time" which is created automatically when a model is created. This process can be re-ran to extend any Time dimension.
Scenario	Scenario dimensions are expected to have an element named "Actual" and then additional planning scenarios such as "Budget" and "Forecast". Setting a dimension type to Scenario provides additional hints to the natural language processing systems.
Measure	Measure dimensions are used as the last dimension in each cube. In other dimension types, elements are used for categorising data i.e. "Auckland, Retail Channel, Brand A" the measures dimension elements are used to provide the type of data held i.e. "Units Sold or Revenue or Discount %" for the previous categories. Each cube can only contain a single measure dimension.
Geography	Geography dimensions presently behave like Standard type dimensions. This is a placeholder for future capabilities for mapping and geospatial datasets.

Subcomponents

Hierarchies

Hierarchies are typically implemented using a tree structure, with the root nodes representing the highest level in the hierarchy and the leaf nodes representing the lowest level. Each node in the tree represents a data element, and the parent-child relationships between the nodes represent the hierarchical relationships between the data elements.

Dimensions can have multiple hierarchies which can share leaf elements from the dimension.

Aliases

An alias is a substitute name for an element from a dimension or hierarchy. Aliases are often used to provide more meaningful or descriptive names for elements, or to simplify complex names.

For example:

A Product Dimension may has elements based on a product code, which represents the unique identifier for each product in the source data. An alias for this dimension might be "Name", which provides a more meaningful and user-friendly name for the element.
Similarly, a Sales Measure called "Sales incl. Tax" might have an alias called "Revenue", which is more simple and easier to understand.

Elements

An element is a discrete data category that belongs to a dimension. A dimension is a way of organizing and categorizing data, and elements are the individual data categories that belong to a dimension.

For example:

A dimension called "Product" would represents the different products that are sold. The elements of this dimension might be individual products, such as "Widget A", "Widget B", and "Widget C". Each element in this dimension represents a unique data category, and can be used to filter and analyse data associated with this element when this dimension is used in a cube.

Element Types

Dimensions are comprised of elements, hierarchies and aliases. There are three types of elements in MODLR which each have specific uses.

Type	Description
Numeric Element	Numeric Elements are objects of the dimension.
String Element	String Elements are sub-objects of the dimension.
Parent Element	Parent (Consolidation) Elements only exist inside specific Hierarchies. Parent elements can have either Numeric Elements (from the dimension) or other Parents Elements (from the same hierarchy) as children.

INFO

Parent Elements behave differently to how elements work in other multidimensional databases. Due to the unique behaviour within MODLR, the dimension object forms a N-Level list of elements and hierarchies can be created to perform multiple aggregation views of these.

Automation

The creation and maintenance of Dimensions and their subcomponents can be performed by Processes for automation.

Here are some common dimension automation user-scenarios:

Scenario	Automation Methodology
Department Dimension	`Default` Hierarchy - A simple hierarchy with a single parent at the top called "All Departments". This hierarchy would be loaded nightly via a process which directly integrates with the finance platform. `Management` Hierarchy - Manually Maintained via the Gateway Frontend
Account Dimension	`Default` Hierarchy - A hierarchy which mirrors the chart-of-accounts from the finance platform. This is loaded nightly via a process which integrates with the finance platform. `Management Accounts` Hierarchy - A User Defined Chart of Accounts which is stored and managed as records in a table in the Relational Database on the MODLR Instance. This is then loaded via a process which is ran after the `Default` Hierarchy creation nightly.
Sales Measures Dimension	`Default` Hierarchy - A manually maintained hierarchy and dimension.
Scenario Dimension	`Default` Hierarchy - A manually maintained hierarchy of the most commonly used scenarios. `Planning Scenarios` Hierarchy - A manually maintained hierarchy. Formulas for planning logic are then restricted to this hierarchy so that they only apply to our active scenarios. `Archived Scenarios` Hierarchy - A manually maintained hierarchy of scenarios which are values-only datasets. This means the data against these elements have no formulas applying and are used to hold point-in-time snapshots of plans.