Skip to content
Casabase CubeCasabase Cube Documentation

Configuration Overview

A cube is the primary multidimensional model in Casabase Cube.

Each cube brings together the data and metadata required for multidimensional analysis, including dimensions, hierarchies, members, aggregation behavior, formulas, security configuration, and cube-level settings.

Dimensions are the primary analytical components of a cube, such as Account, Entity, Period, Product, or Scenario. Dimensions contain hierarchical structures that organize members and define their relationships and aggregation paths.

Casabase Cube manages the underlying implementation while users work with the logical multidimensional model.

                         Cube
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
           Data        Dimensions      Formulas
                           │
                           ▼
                      Hierarchies
                           │
                           ▼
                       Members
                           │
                  ┌────────┴────────┐
                  ▼                 ▼
             Aggregation         Security
              Behavior

All Casabase Cube processing, configuration, and managed data remain within the customer’s Snowflake environment.

Configuration Model

Section titled “Configuration Model”

Configuration defines the structure and behavior of a cube.

Depending on the model, configuration can include:

  • Dimensions
  • Hierarchies
  • Members and parent-child relationships
  • Aggregation behavior
  • Member properties
  • Aliases
  • Shared members
  • Formulas
  • Cube variables
  • Security configuration
  • Default members
  • Cube-level settings
  • Dimension-level settings

These definitions form the multidimensional metadata used by the Casabase Cube query engine.

Conceptually:

Source Metadata
      │
      ▼
Cube Configuration
      │
      ├── Dimensions
      ├── Hierarchies
      ├── Members
      ├── Properties
      ├── Formulas
      ├── Security
      └── Settings
      │
      ▼
Multidimensional Model
      │
      ▼
Query Engine

Creating Cubes

Section titled “Creating Cubes”

Casabase Cube supports two primary starting points for creating a multidimensional model:

Existing Oracle
Essbase / Cloud EPM
        │
        ├──────────────┐
        │              │
        ▼              │
      .OTL             │
        │              │
        ▼              │
 Casabase Cube         │
                       │
                       │
Snowflake Data         │
        │              │
        ▼              │
Dimension Definition   │
Tables                  │
        │              │
        ▼              │
 Casabase Cube ◄────────┘

The resulting cube uses the same Casabase Cube multidimensional model regardless of how its initial structure was created.

Oracle Essbase and Cloud EPM Migration

Section titled “Oracle Essbase and Cloud EPM Migration”

For organizations migrating from Oracle Essbase or Oracle Cloud EPM, Casabase Cube can create the multidimensional structure from the application’s native Essbase outline (.otl).

The outline provides metadata such as:

  • Dimensions
  • Hierarchies
  • Members
  • Parent-child relationships
  • Supported member properties
  • Supported formulas

Cube data can then be loaded from the application’s native level-0 export.

This preserves the existing multidimensional model while moving its execution into Snowflake.

Use the dedicated migration guide for the source application:

Creating a Cube from Snowflake Data

Section titled “Creating a Cube from Snowflake Data”

Casabase Cube can also create multidimensional models directly from data and metadata already available in Snowflake.

This does not require an existing Essbase application or .otl file.

For this approach, dimension structures are defined using Snowflake tables containing the metadata required to construct each dimension.

These dimension definition tables describe information such as:

Members
Parent-Child Relationships
Aggregation Behavior
Aliases
Member Properties

Casabase Cube uses these definitions to construct the dimensions and hierarchy structures of the multidimensional model.

There is no separate CREATE_CUBE operation in this workflow. The first CREATE_DIMENSION call establishes the cube, and subsequent calls add additional dimensions.

This allows Casabase Cube to operate as a native multidimensional modeling and query engine for analytical data originating directly in Snowflake.

See Creating a Cube from Snowflake Data and Dimension Definition Tables.

Dimensions

Section titled “Dimensions”

Dimensions define the analytical perspectives of a cube.

Typical dimensions include:

ACCOUNT
ENTITY
PERIOD
YEARS
SCENARIO
PRODUCT

A dimension contains members organized into hierarchical structures.

For example:

ENTITY


Total Entity
│
├── North America
│   ├── United States
│   └── Canada
│
└── Europe
    ├── United Kingdom
    └── Germany

Dimension metadata can define characteristics such as:

  • Member names
  • Parent-child relationships
  • Aggregation operators
  • Aliases
  • Shared members
  • Formulas
  • Time Balance properties
  • User Defined Attributes (UDAs)
  • Sort order
  • Other supported member properties

Dimension configuration can also include settings such as:

  • Default member
  • Dimension solve order
  • Security
  • Auto Rebuild
  • Active status

Dimensions can originate from imported Essbase outline metadata or from customer-provided dimension definition tables.

Hierarchies

Section titled “Hierarchies”

Hierarchies organize members and define relationships within a dimension.

They provide the structures used for:

  • Parent-child navigation
  • Ancestor and descendant relationships
  • Aggregation paths
  • Generation and level calculations
  • Hierarchy-aware member selection
  • Hierarchy-aware formulas
  • Security inheritance and scope

Casabase Cube supports multidimensional structures including ragged, unbalanced, alternate, and shared-member hierarchies.

See Hierarchy Capabilities for the architectural model.

Dimension Definition Tables

Section titled “Dimension Definition Tables”

For models created directly from Snowflake data, each dimension is backed by a dimension definition table.

The table provides the metadata Casabase Cube needs to construct the dimension and its hierarchy structures.

Conceptually:

Snowflake Dimension
Definition Table
       │
       ├── Members
       ├── Parents
       ├── Aggregation
       ├── Aliases
       ├── Properties
       └── Other Metadata
       │
       ▼
Casabase Cube
Dimension
       │
       ▼
Hierarchy Structures

Customer-created definition tables can reside in any Snowflake database and schema accessible to the Casabase Cube Native App. Definition tables generated from imported Essbase metadata are stored within the application’s SHARED_DATA schema.

The exact table structure and supported mappings are documented in Dimension Definition Tables.

Adding Dimensions

Section titled “Adding Dimensions”

After the initial cube structure exists, additional dimensions can be added as the model evolves.

Dimension creation can be performed through supported Casabase Cube interfaces, including programmatic configuration using:

CUBE.CREATE_DIMENSION

The dimension definition identifies the source metadata and configuration Casabase Cube needs to construct the dimension.

See Adding Dimensions for the detailed procedure.

Cube Settings

Section titled “Cube Settings”

Cube-level settings control behavior that applies to the multidimensional model as a whole.

The documented cube-level settings are:

Data Classification
Row Limit
Apply Member Formulas
Build Lock Timeout

These are separate from dimension-level settings such as Default Member, Dimension Solve Order, Security, Auto Rebuild, and Active status.

See Cube Settings for the supported settings and configuration procedures.

Default Members

Section titled “Default Members”

Default members are configured at the dimension level and affect query POV resolution.

If a dimension is omitted from a query and does not have a default member, that dimension is not included in the result set.

If the omitted dimension does have a configured default member, Casabase Cube resolves the dimension to that member and includes it in the effective query context.

Conceptually:

Dimension Omitted
       │
       ▼
Default Member Configured?
       │
   ┌───┴───┐
   │       │
  Yes      No
   │       │
   ▼       ▼
Resolve   Dimension
Default   Omitted from
Member    Result

See Point of View (POV) for complete behavior.

Cube Data

Section titled “Cube Data”

Cube data and Casabase Cube-managed structures reside within the Native App environment in the customer’s Snowflake account.

Users interact with the logical cube rather than directly managing the application’s internal physical structures.

Conceptually:

Customer Source Data
        │
        ▼
     Data Load
        │
        ▼
Casabase Cube
        │
        ├── Managed Cube Data
        │
        └── Multidimensional Metadata
                    │
                    ▼
               Query Engine
                    │
                    ▼
                  Result

For Oracle Essbase and Cloud EPM migrations, bottom-level data is typically sourced from a native level-0 export.

Models originating directly in Snowflake can use the supported Casabase Cube data-loading workflows for their source data.

Configuration Lifecycle

Section titled “Configuration Lifecycle”

A typical configuration lifecycle is:

Choose Creation Path
        │
        ▼
Create Initial Model
        │
        ▼
Define / Add Dimensions
        │
        ▼
Validate Dimension Structures
        │
        ▼
Load and Maintain Data
        │
        ▼
Configure Formulas,
Security and Settings
        │
        ▼
Validate Cube
        │
        ▼
Query and Operate

The exact sequence depends on how the model originated.

For example:

Essbase / Cloud EPM
        │
        ▼
Import .OTL
        │
        ▼
Load Level-0 Data

while a Snowflake-native model begins with:

Snowflake Metadata
        │
        ▼
Dimension Definition Tables
        │
        ▼
CREATE_DIMENSION

Both paths ultimately produce a Casabase Cube multidimensional model.

Dimension Validation

Section titled “Dimension Validation”

Casabase Cube validates dimension definitions during dimension creation and rebuild processing.

You can also validate a dimension definition independently before applying a change using:

CUBE.VALIDATE_DIMENSION

Validation can identify structural problems such as:

  • Invalid hierarchy relationships
  • Duplicate base members
  • Circular references
  • Invalid aggregation operators
  • Missing member names
  • Orphan members
  • Invalid shared-member structures

See Dimension Validation for the validation procedure and complete set of checks.

Rebuilding Dimensions

Section titled “Rebuilding Dimensions”

When the source definition of a dimension changes, the corresponding Casabase Cube structures must be rebuilt before those changes are reflected in the model.

The primary operation is:

CUBE.REBUILD_DIMENSIONS

Conceptually:

Source Metadata Changes
        │
        ▼
VALIDATE_DIMENSION
        │
        ▼
REBUILD_DIMENSIONS
        │
        ▼
Updated Dimension Structures
        │
        ▼
HEALTH_CHECK
        │
        ▼
Verification Query

A dimension rebuild is required for dimension metadata changes. Fact-data changes do not require a dimension rebuild merely because stored values changed.

See Rebuilding Dimensions for rebuild behavior.

Routine operational monitoring of rebuilds, asynchronous processing, snapshots, and build-lock recovery is covered in Operational Tasks.

Health Validation

Section titled “Health Validation”

After significant configuration changes, administrators can validate overall application and cube health using:

CALL CUBE.HEALTH_CHECK(NULL);

Health validation is particularly useful after:

  • Creating or significantly modifying a model
  • Rebuilding dimensions
  • Changing important configuration
  • Completing an application upgrade
  • Investigating unexpected behavior

Dimension validation and health validation serve different purposes:

VALIDATE_DIMENSION
      │
      └── Is the source dimension
          definition structurally valid?




HEALTH_CHECK
      │
      └── Is the resulting configured
          cube healthy?

The full health and diagnostic framework is documented in Health and Diagnostics.

Configuration and Administrative Lifecycle

Section titled “Configuration and Administrative Lifecycle”

Configuration focuses on defining and maintaining the multidimensional model.

Administrative lifecycle operations that act on the cube as an application object are documented separately under Administration.

These include:

  • Cloning an existing cube
  • Exporting and importing cube configuration
  • Dropping a cube

See:

Configuration vs. Administration

Section titled “Configuration vs. Administration”

Configuration and Administration are closely related but serve different purposes.

Configuration focuses primarily on defining and maintaining the multidimensional model:

Cube Creation
Dimensions
Dimension Definition Tables
Cube Settings
Dimension Validation
Dimension Rebuilds

Administration focuses primarily on operating, governing, and managing the lifecycle of the application and its cubes:

Roles and Privileges
Security
Classification
Audit
Upgrades
Health and Diagnostics
Operational Tasks
Cube Lifecycle

Some capabilities naturally cross this boundary.

For example, rebuilding a dimension is a model-maintenance operation, while monitoring an asynchronous rebuild or recovering a stale build lock is an administrative operation.

Similarly, cube configuration defines the model, while cloning, exporting, importing, and dropping cubes are lifecycle operations.

In This Section

Section titled “In This Section”

The Configuration documentation covers:

Application-wide health and diagnostic procedures are covered in Health and Diagnostics.

Cube lifecycle operations are covered under Administration.

Next Steps

Section titled “Next Steps”

If you are building a new multidimensional model, start with Creating a Cube to choose the appropriate creation path.

If your source is existing Snowflake data, continue with Creating a Cube from Snowflake Data.

If you are migrating an Oracle Essbase or Oracle Cloud EPM application, use the corresponding migration guide for that source system: