Key Concepts

The Una engine stores data in a manner that allows querying in both multidimensional and relational formats. It is similar in many respects to an OLAP engine, but includes several enhancements specific to its purpose as a storage engine for financial planning.

Models

Multidimensional data is organized into models, and a tenant can contain an unlimited number of models. A model in Una defines the structure for storing and analyzing data across multiple dimensions (such as Account, Time, Scenario, Segment, etc.). Each model acts as a container for all the data, dimensions, and measures needed for a specific business area or use case.

• Multidimensional Structure: Models are designed to store data that can be analyzed along several axes (dimensions). For example, you might analyze financial data by time period, account, and business segment.
• Dimensions: Each model contains multiple dimensions, which define how data is categorized and analyzed. Required dimensions include Account, Time, and Scenario, with optional custom segments for additional business attributes.
• Fact Tables and Measures: Models contain fact tables, which store the actual data (measures) such as numbers, text, or dates. Measures are the quantitative fields you analyze (e.g., revenue, quantity).
• Hierarchies: Dimensions within a model can have hierarchies, allowing for roll-up and drill-down analysis (e.g., Year > Quarter > Month).
• Customizability: Models can be tailored with custom dimensions and hierarchies to fit specific business needs.

Models provide a flexible and powerful way to organize, store, and analyze complex data sets, supporting advanced financial planning, reporting, and analytics. They enable users to slice and dice data, aggregate results, and gain insights across various business perspectives.

Dimensions

In Una, a dimension is a structural attribute that organizes data within a model. Dimensions define the axes along which data can be analyzed, sliced, and aggregated. Each model contains multiple dimensions, and these dimensions provide context for the facts and measures stored in the model.

Type	Required	Cardinality	Valid Roles
Account	Yes	1	Account
Time	Yes	1	Time
Scenario	Yes	1	Scenario
Segment	No	0+	Segment (custom business segment) Currency Department Geography Product
Stage	Yes (RevIQ only)	1	Stage

Dimension Types

Dimensions in Una are categorized by type, each serving a specific analytical purpose within a model. Core types include Account, Time, Scenario, Segment, and Stage (RevIQ only). Every dimension has standard properties: a unique key, name, and caption (multi-language display name). Dimensions may have additional standard properties depending on its type.

Each model must include the required dimensions. The segment dimension is highly customizable and can represent various business attributes for detailed analysis and reporting.

Dimension Roles

When a dimension is assigned to a model, it is given a specific role. This enables Una to query the database via dimension roles instead of hard-coded dimension names. This allows for flexibilty across models with differing dimensionaility, as well as compatibilty with prebuilt content in the global file system.

Dimensions Hierarchies

Dimensions can have one or more hierarchies. Each dimension has a default hierarchy (also known as the primary hierarchy) that does not have a name. All members that can contain data in a dimension must be present in the primary hierarchy.

Dimension members are uniquely identified by both a name (string) and a key (integer). Each member also has a caption, which supports multiple languages and will be displayed in the user's preferred language. Captions do not have to be unique and cannot be used to identify members. Additionally, each dimension member can have a number of properties (also known as attributes) that are defined at the dimension level.

Note

Keys in the primary hierarchies are always positive numbers (≥ 1), with 1 typically reserved for the default leaf member that means "None" or "Not Applicable."

Alternate Hierarchies

Alternate hierarchies (also known as secondary hierarchies) provide alternative ways to aggregate the same data. Leaf members in alternate hierarchies must also exist as leaf members in the primary hierarchy for the same dimension, but a alternate hierarchy does not have to include all leaf members from the primary hierarchy. However, in this case, there will be differences in the data returned when using leaf descendants of the virtual root on an axis versus the virtual root member as a filter.

Keys in alternate hierarchies are identical to the keys in the primary hierarchy for leaf members. For nodes, keys are always negative numbers to prevent conflicts with members in the primary hierarchy.

Non-Leaf Data Members

A dimension may be marked as having non-leaf data members. This means that data can be associated with any member of that dimension in the fact tables, not just leaf members. Data stored in non-leaf nodes will be added to the data stored at lower levels to obtain the final result.

For example, if you store 10 in Jan, 10 in Feb, 10 in Mar, and 5 in Q1, when querying Q1, the result will be: 5 + 10 + 10 + 10 = 35.

Only primary hierarchies can contain non-leaf data members.

Time Balancing

When aggregating across the time dimension, children should not always be added up to obtain the parent value. For instance, the Revenue for Q1 will be the sum of the Revenue for Jan, Feb, and Mar, but the Cash Balance for Q1 will be the same as the Cash Balance for Mar—not the sum of the three months.

Time balancing can be set at the measure and/or account level and can be one of the following values:

Balance Type	Description
Sum	The parent value is the sum of the children values; this is the default
First	The parent value equals the value of its first child; V_Opening measures have time balance First
Last	The parent value equals the value of its last child; V_Closing measures have time balance Last

Static Accounts

Members of an account dimension can be flagged as "static." Static accounts are never aggregated across other dimensions, and data for a static account is always stored at the level from which it is read, regardless of the non-leaf data members setting of the other dimensions. This is useful for KPIs that don't aggregate additively and can be precalculated at various levels.

Measures

Each model contains multiple fact tables, and each table will contain a number of measures (data fields). Most of these will be numerical data, but some tables might also contain text and/or date measures.

Data Type	Aggregation Method
Numerical	Addition
String	Concatenation
Date	Maximum value

Line Item Details

Line Item Details (LID) is the ability of the system to store and discriminate data at a level below the leaf level for a cell. Each value that makes up the result can be composed of multiple numbers added together. To discriminate between the different numbers, each component has a different description associated (known as the line item description).

LIDs are stored directly in the fact table, using a dedicated measure field for the line item description (V_LID). Currently, LIDs are supported only for the Metrics fact table.

Note

Line Item Details only exist for cells that are at the leaf level on all dimensions—the concept doesn't apply to aggregated cells.