Skip to content
Casabase CubeCasabase Cube Documentation

Cubes & Dimensions

What is a cube?

Section titled “What is a cube?”

A cube is the primary multidimensional model in Casabase Cube.

It brings together:

  • Cube data
  • Dimensions
  • Hierarchies
  • Members
  • Aggregation behavior
  • Formulas
  • Security
  • Cube variables
  • Saved queries
  • Cube-level settings

For example:

FINANCE
│
├── ACCOUNT
├── ENTITY
├── PERIOD
├── YEARS
├── SCENARIO
└── VERSION

Users query the logical cube rather than directly managing the underlying physical structures maintained by Casabase Cube.

See Configuration Overview.

What is the difference between a cube, dimension, hierarchy, and member?

Section titled “What is the difference between a cube, dimension, hierarchy, and member?”

These concepts form the basic multidimensional structure:

Cube
 │
 ├── Dimension
 │      │
 │      └── Hierarchy
 │             │
 │             └── Members
 │
 └── Dimension
        │
        └── Hierarchy
               │
               └── Members

A cube is the complete multidimensional model.

A dimension represents an analytical perspective, such as Account, Entity, Period, Scenario, or Product.

A hierarchy organizes members within a dimension and defines relationships such as parent, child, ancestor, and descendant.

A member is an individual element within a dimension.

For example:

Cube: FINANCE


Dimension: ENTITY


Hierarchy:


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

See Key Terminology and Hierarchy Capabilities.

How do I create a cube?

Section titled “How do I create a cube?”

Casabase Cube supports two primary creation paths.

You can create a cube from:

  1. Oracle Essbase or Oracle Cloud EPM artifacts.
  2. Data and metadata already available in Snowflake.

Conceptually:

Oracle Essbase / Cloud EPM
            │
            ▼
       Native .otl
            │
            ▼
      Casabase Cube




Snowflake Metadata
            │
            ▼
Dimension Definition Tables
            │
            ▼
      Casabase Cube

For an Oracle migration, the native Essbase outline provides the initial multidimensional structure.

For a Snowflake-native model, dimensions are created from dimension definition tables.

See Creating a Cube.

Can I create a cube directly from Snowflake data?

Section titled “Can I create a cube directly from Snowflake data?”

Yes.

You do not need an existing Oracle Essbase or Cloud EPM application.

For a Snowflake-native model, you define each dimension using a dimension definition table in Snowflake.

Casabase Cube uses those definitions to construct the multidimensional model.

See Creating a Cube from Snowflake Data.

Is there a separate CREATE_CUBE procedure?

Section titled “Is there a separate CREATE_CUBE procedure?”

For the Snowflake-native creation workflow, there is no separate CREATE_CUBE operation.

The first:

CUBE.CREATE_DIMENSION

call establishes the cube.

Subsequent calls add additional dimensions.

Conceptually:

First CREATE_DIMENSION
        │
        ▼
Create Cube
   +
First Dimension
        │
        ▼
Additional CREATE_DIMENSION Calls
        │
        ▼
Additional Dimensions

See Creating a Cube from Snowflake Data.

What is a dimension definition table?

Section titled “What is a dimension definition table?”

A dimension definition table is a Snowflake table containing the metadata Casabase Cube uses to construct a dimension.

Depending on the dimension, it can define information 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

Conceptually:

Dimension Definition Table
          │
          ├── Members
          ├── Parents
          ├── Aggregation
          ├── Aliases
          ├── Formulas
          └── Properties
          │
          ▼
   Casabase Cube
          │
          ▼
      Dimension
          │
          ▼
      Hierarchies

See Dimension Definition Tables.

Where can dimension definition tables be stored?

Section titled “Where can dimension definition tables be stored?”

Customer-created dimension definition tables can reside in a Snowflake database and schema accessible to the Casabase Cube Native App.

They do not have to reside inside the application.

For example:

FINANCE_DB.PLANNING.DIM_ACCOUNT
FINANCE_DB.PLANNING.DIM_ENTITY
FINANCE_DB.PLANNING.DIM_PERIOD

can serve as dimension definition tables when the application has the required access.

Dimension definition tables generated from imported Essbase metadata are maintained within the application’s SHARED_DATA schema.

See Dimension Definition Tables and Roles and Privileges.

Does Casabase Cube copy my dimension definition tables?

Section titled “Does Casabase Cube copy my dimension definition tables?”

Customer-owned dimension definition tables remain separate Snowflake source objects.

Casabase Cube uses those tables to construct and rebuild its application-managed multidimensional structures.

Conceptually:

Customer Dimension
Definition Table
       │
       ▼
CREATE_DIMENSION /
REBUILD_DIMENSIONS
       │
       ▼
Casabase Cube
Dimension Structures

The source definition and the resulting application-managed structures serve different purposes.

What hierarchy structures are supported?

Section titled “What hierarchy structures are supported?”

Casabase Cube supports multidimensional hierarchy structures including:

  • Balanced hierarchies
  • Ragged hierarchies
  • Unbalanced hierarchies
  • Alternate hierarchies
  • Shared members

These structures support hierarchy-aware operations such as:

  • Parent and child navigation
  • Ancestor and descendant navigation
  • Generation and level calculations
  • Aggregation
  • Member selection
  • Formulas
  • Security

See Hierarchy Capabilities.

What is a shared member?

Section titled “What is a shared member?”

A shared member allows the same logical member to participate in more than one hierarchy location.

For example:

Total Products
│
├── Products by Category
│   └── Product A
│
└── Products by Market
    └── Product A

Shared-member behavior allows multidimensional models to represent alternate rollups without treating every hierarchy occurrence as unrelated business data.

Shared-member configuration is defined through the supported dimension metadata.

See Hierarchy Capabilities.

Can dimensions contain formulas?

Section titled “Can dimensions contain formulas?”

Yes.

Dimension definitions can include member formulas where supported.

For example, an Account dimension might contain calculated members whose values are evaluated dynamically during query processing.

Whether configured member formulas participate in query processing is also controlled by the cube-level:

Apply member formulas

setting.

See:

What is a default member?

Section titled “What is a default member?”

A default member is a dimension-level setting used when that dimension is omitted from a query POV.

For example:

SCENARIO
Default Member = Actual

If SCENARIO is omitted from the submitted POV, Casabase Cube can resolve it to:

Actual

The important distinction is:

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

An omitted dimension without a configured default member is not automatically forced to an arbitrary member.

See Point of View (POV).

What is member solve order?

Section titled “What is member solve order?”

Member solve order is a dimension-level setting that participates in calculation ordering where applicable.

It is separate from member formula definitions themselves.

Formula evaluation can depend on factors such as:

  • Formula dependencies
  • Cross-dimensional references
  • Member solve order
  • Member solve order
  • Query context

See Solve Order & Dependencies.

Can I add dimensions after a cube has been created?

Section titled “Can I add dimensions after a cube has been created?”

Yes.

Additional dimensions can be added to an existing cube using the supported Cube Config interface or programmatically with:

CUBE.CREATE_DIMENSION

The new dimension requires the appropriate definition and configuration.

See Adding Dimensions.

Can I change a dimension after it has been created?

Section titled “Can I change a dimension after it has been created?”

Yes.

A dimension’s source definition and applicable settings can be changed as the multidimensional model evolves.

When the underlying dimension metadata changes, the dimension must be rebuilt before those structural changes are reflected in the active cube.

A typical workflow is:

Modify Dimension Definition
          │
          ▼
VALIDATE_DIMENSION
          │
          ▼
REBUILD_DIMENSIONS
          │
          ▼
Updated Dimension
          │
          ▼
HEALTH_CHECK
          │
          ▼
Verification Query

See Rebuilding Dimensions.

Do I need to rebuild dimensions when dimension metadata changes?

Section titled “Do I need to rebuild dimensions when dimension metadata changes?”

Yes.

Changes to dimension metadata require the corresponding Casabase Cube structures to be rebuilt.

Examples can include changes to:

  • Members
  • Parent-child relationships
  • Hierarchy structures
  • Aggregation behavior
  • Aliases
  • Shared-member definitions
  • Formulas or other mapped dimension properties

Use:

CUBE.REBUILD_DIMENSIONS

to rebuild applicable dimensions.

This replaces the older way of describing the operation as “rebuilding hierarchies.” The administrative unit being rebuilt is the dimension, which can contain the hierarchy structures associated with that dimension.

See Rebuilding Dimensions.

Do I need to rebuild dimensions when fact data changes?

Section titled “Do I need to rebuild dimensions when fact data changes?”

No.

A change to fact-data values does not by itself require a dimension rebuild.

Dimension rebuilding is concerned with multidimensional metadata and structures.

Fact-data loading is a separate operation.

Conceptually:

Dimension Metadata Changes
          │
          ▼
REBUILD_DIMENSIONS




Fact Data Changes
          │
          ▼
Data Load

If both the dimension structure and fact data change, perform the appropriate operation for each.

What is Auto Rebuild?

Section titled “What is Auto Rebuild?”

Auto Rebuild is a dimension-level setting that determines whether a dimension participates in applicable automatic rebuild processing.

For example:

ACCOUNT     Auto Rebuild = Enabled
ENTITY      Auto Rebuild = Enabled
PERIOD      Auto Rebuild = Disabled
SCENARIO    Auto Rebuild = Disabled

Auto Rebuild is configured individually for each dimension.

It should not be confused with the cube-level Build lock timeout setting.

See Rebuilding Dimensions and Cube Settings.

Can I validate a dimension before rebuilding it?

Section titled “Can I validate a dimension before rebuilding it?”

Yes.

Use:

CUBE.VALIDATE_DIMENSION

to validate a dimension definition independently before applying the change.

This is particularly useful when modifying a customer-owned dimension definition table.

Conceptually:

Dimension Definition
        │
        ▼
VALIDATE_DIMENSION
        │
   ┌────┴────┐
   │         │
 Valid     Errors
   │         │
   ▼         ▼
Rebuild    Correct
          Definition

See Dimension Validation.

What kinds of problems can dimension validation detect?

Section titled “What kinds of problems can dimension validation detect?”

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

Validation allows these problems to be identified before an invalid definition is applied to the active multidimensional model.

See Dimension Validation for the complete validation behavior.

What happens if dimension validation fails?

Section titled “What happens if dimension validation fails?”

A failed validation identifies problems in the source definition so they can be corrected.

The normal workflow is:

VALIDATE_DIMENSION
       │
       ▼
Validation Errors
       │
       ▼
Correct Source Definition
       │
       ▼
VALIDATE_DIMENSION
       │
       ▼
Successful Validation
       │
       ▼
REBUILD_DIMENSIONS

Validation should be treated as a structural check of the dimension definition rather than a general cube health check.

For broader validation of the configured application and cube, use:

CUBE.HEALTH_CHECK

See Health and Diagnostics.

What happens during a dimension rebuild?

Section titled “What happens during a dimension rebuild?”

A dimension rebuild reconstructs the Casabase Cube multidimensional structures from the configured dimension definition.

Conceptually:

Dimension Definition Table
          │
          ▼
REBUILD_DIMENSIONS
          │
          ▼
Members
Hierarchies
Relationships
Properties
          │
          ▼
Updated Dimension

The exact rebuild behavior depends on the dimension configuration and the options used for the rebuild.

See Rebuilding Dimensions.

Can I rebuild more than one dimension at a time?

Section titled “Can I rebuild more than one dimension at a time?”

Yes.

REBUILD_DIMENSIONS operates at the cube level and can rebuild the applicable dimensions according to the procedure options and dimension configuration.

This is useful when multiple dimensions have changed or when a broader model rebuild is required.

See Rebuilding Dimensions for the supported rebuild options.

What prevents two conflicting builds from modifying a cube at the same time?

Section titled “What prevents two conflicting builds from modifying a cube at the same time?”

Casabase Cube uses build locks to prevent conflicting build operations from modifying the same multidimensional structures concurrently.

Conceptually:

Build Starts
    │
    ▼
Acquire Build Lock
    │
    ▼
Perform Build
    │
    ▼
Release Lock

The cube-level:

Build lock timeout (minutes)

setting controls build-lock timing.

Stale build-lock inspection and recovery are administrative operations.

See Cube Settings and Operational Tasks.

Can multiple cubes use the same source data?

Section titled “Can multiple cubes use the same source data?”

Yes, where the applicable source objects are made available to Casabase Cube.

For example, multiple cube configurations can be built from common customer-owned Snowflake source data or metadata.

However, each Casabase Cube is its own logical multidimensional model and manages its own cube configuration and application-managed structures.

This is different from saying that every query simply points multiple cubes at the same physical fact table.

Conceptually:

Customer Source Data
       │
   ┌───┴────┐
   │        │
   ▼        ▼
Cube A    Cube B
   │        │
   ▼        ▼
Independent Multidimensional
Models

See Data Storage & Boundaries.

Can I use a Snowflake view as a dimension definition?

Section titled “Can I use a Snowflake view as a dimension definition?”

Use the supported source-object types documented in Dimension Definition Tables and Creating a Cube from Snowflake Data.

The important requirement is not simply whether an object can be queried in Snowflake. The source must be supported by the Casabase Cube dimension-creation and rebuild workflow and must expose the required metadata columns.

For production models, use the definitive Configuration documentation rather than assuming that every Snowflake queryable object is interchangeable with a dimension definition table.

Can I clone a cube?

Section titled “Can I clone a cube?”

Yes.

Use:

CUBE.CLONE_CUBE

to create a new cube from an existing cube.

The P_REBUILD parameter determines whether the clone is populated or empty.

With:

P_REBUILD = TRUE

Casabase Cube:

  • Copies the configuration
  • Rebuilds the dimensions
  • Copies the source fact table

The result is a populated replica.

With:

P_REBUILD = FALSE

Casabase Cube:

  • Copies the configuration
  • Leaves the dimensions inactive until rebuilt
  • Does not copy the source fact table

The result is an empty replica.

See Cloning a Cube.

Can I export a cube’s configuration?

Section titled “Can I export a cube’s configuration?”

Yes.

Use:

CUBE.EXPORT_CUBE_CONFIG

to export portable cube configuration as JSON.

The export can contain configuration such as:

  • Dimension definitions
  • Formulas
  • Saved queries
  • Cube variables
  • Configuration metadata

It does not contain the cube’s fact data.

See Exporting & Importing Configuration.

How do I remove fact data without deleting the cube?

Section titled “How do I remove fact data without deleting the cube?”

Use:

CLEAR_CUBE_DATA

when the cube structure should remain but its fact data needs to be removed.

This is different from:

DROP_CUBE

which permanently removes the cube and its associated Casabase Cube objects.

Conceptually:

CLEAR_CUBE_DATA
       │
       ├── Cube Preserved
       └── Fact Data Removed




DROP_CUBE
       │
       └── Cube Removed

See Dropping a Cube.

How do I permanently delete a cube?

Section titled “How do I permanently delete a cube?”

Use:

CUBE.DROP_CUBE

DROP_CUBE supports a dry-run confirmation model.

With:

P_CONFIRM = FALSE

Casabase Cube previews what would be removed without making changes.

With:

P_CONFIRM = TRUE

the cube and its associated Casabase Cube objects are permanently removed.

Export any configuration required for recovery before confirming an important deletion.

See Dropping a Cube.

How many cubes can I create?

Section titled “How many cubes can I create?”

The previous FAQ stated that there was no limit on the number of cubes in an installation.

Rather than treating that as an absolute product guarantee, plan the number of cubes according to the expected workload, Snowflake resources, operational requirements, and any current Casabase Cube limits.

For environment-specific limits or unusually large deployments, consult the current product documentation or Casabase support.

How many dimensions can a cube have?

Section titled “How many dimensions can a cube have?”

Use the current System Requirements and product documentation as the authoritative source for supported product limits.

If you are designing a model with an unusually large number of dimensions, validate the design and expected query patterns before production deployment.