Skip to content
Casabase CubeCasabase Cube Documentation

High-Level Architecture

Casabase Cube is a multidimensional analytical engine delivered as a Snowflake Native Application. It provides OLAP capabilities including dimensions, hierarchies, dynamic aggregation, member formulas, and time intelligence over data that remains in Snowflake.

Casabase Cube does not require a separate OLAP server, external calculation service, gateway, or proprietary data store. The application, its metadata, its calculation engine, and its supported consumption interfaces operate within the customer’s Snowflake environment.

Architecture at a Glance

Section titled “Architecture at a Glance”

At a high level, Casabase Cube sits between your Snowflake source data and the tools that consume multidimensional information.

Your Snowflake Data
        │
        │  Dimension source tables
        │  Fact / transaction data
        │  Import files on stages
        ▼
┌─────────────────────────────────────────────┐
│            Casabase Cube                    │
│        Snowflake Native Application         │
│                                             │
│  Modeling and Administration                │
│  Dimensions and Hierarchies                 │
│  Dynamic Aggregation                        │
│  Formula Engine                             │
│  Time Intelligence                          │
│  Security Filtering                         │
│  Application-Managed Storage                │
│  Streamlit User Interface                   │
└─────────────────────────────────────────────┘
        │
        ▼
Supported Consumption Interfaces
        │
        ├── Query procedures
        ├── Secure views
        ├── Materialized reporting tables
        └── AI interfaces
        │
        ▼
Snowflake-Compatible Tools

All dimension processing, querying, formula evaluation, security filtering, and scheduled processing execute within Snowflake.

Core Architectural Principles

Section titled “Core Architectural Principles”

Five principles define the Casabase Cube architecture.

Runs Entirely Within Snowflake

Section titled “Runs Entirely Within Snowflake”

Casabase Cube executes inside the customer’s Snowflake account.

The application does not require an external Casabase-hosted service to process customer data. It makes no outbound connections, sends no provider telemetry, and does not move cube data outside the customer’s Snowflake environment.

Processing therefore occurs using the customer’s Snowflake environment, compute, region, identity, and security controls.

This architecture helps preserve the governance and security model already established for data in Snowflake.

Dynamic Aggregation

Section titled “Dynamic Aggregation”

Casabase Cube does not precompute and store aggregate values throughout a multidimensional cube.

Instead, parent values are dynamically derived from leaf-level data when queries execute.

As a result:

  • there is no cube aggregation or processing window
  • aggregate values do not become stale
  • newly loaded fact data is immediately available to queries
  • storage does not increase simply because hierarchies contain additional levels

Dimension structures are built and maintained separately from fact-data aggregation. Changes to dimension metadata require the affected dimension to be rebuilt, while changes to fact data do not require an aggregation rebuild.

Dimensions Are Built, Aggregates Are Not

Section titled “Dimensions Are Built, Aggregates Are Not”

Casabase Cube builds multidimensional structures from dimension metadata, typically using parent-child source tables.

These structures provide the hierarchy information required for operations such as:

  • parent and child navigation
  • ancestor and descendant resolution
  • generation and level calculations
  • alternate and shared member resolution
  • member selection
  • hierarchy-aware formulas
  • aggregation

Building a dimension does not create pre-aggregated copies of the underlying fact data.

The hierarchy provides the structure needed to calculate results dynamically from leaf data.

Snowflake Is the Integration Boundary

Section titled “Snowflake Is the Integration Boundary”

Casabase Cube exposes supported Snowflake objects for consumption rather than requiring a proprietary client protocol.

Depending on the use case, applications can consume Casabase Cube through:

  • query procedures such as QUERY_CUBE
  • QUERY_CUBE_PIVOT_JSON
  • secure fact views
  • secure dimension views
  • materialized reporting tables
  • AI interfaces such as Cortex Agent and MCP integrations

The primary secure views for a cube are:

<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS

Because these interfaces are Snowflake objects, tools that integrate with Snowflake can consume Casabase Cube without a Casabase-specific driver, gateway, or middle tier.

The appropriate interface depends on whether the consumer needs full multidimensional calculation semantics or relational access to underlying cube data.

Refuses Rather Than Approximates

Section titled “Refuses Rather Than Approximates”

Casabase Cube is designed not to silently return a plausible but incorrect result when the requested calculation cannot be performed correctly.

When the engine encounters a condition where a correct result cannot be produced, the query is refused and an error identifies the cause.

Examples can include:

  • unsupported calculation constructs
  • query selections exceeding supported calculation limits
  • missing dimensional context required for a calculation
  • incompatible security and calculation behavior

Applications consuming Casabase Cube should surface these errors rather than suppressing them.

Major Components

Section titled “Major Components”

Source Data

Section titled “Source Data”

Customer-controlled Snowflake objects provide the source information used by Casabase Cube.

These can include:

  • dimension source tables
  • fact or transaction tables
  • files placed on Snowflake stages

Casabase Cube accesses these objects only through privileges explicitly granted to the application.

The application does not require ownership of source tables and does not modify them.

Modeling and Administration

Section titled “Modeling and Administration”

Casabase Cube maintains the metadata that defines each multidimensional model, including:

  • cubes
  • dimensions
  • hierarchies
  • formulas
  • default members
  • security configuration
  • data classification
  • saved queries
  • schedules

Administrators manage these objects through the built-in Streamlit interface and supported stored procedures.

Calculation Engine

Section titled “Calculation Engine”

The calculation engine converts a multidimensional query into results dynamically.

Conceptually, the engine:

  1. resolves the requested point of view
  2. determines the user’s permitted data scope
  3. aggregates permitted leaf-level data
  4. evaluates formulas and multidimensional calculations
  5. returns, materializes, or refuses the result

Security scope is established before aggregation and formula evaluation. Calculations therefore operate against the same permitted data the user could query directly.

Application-Managed Storage

Section titled “Application-Managed Storage”

Casabase Cube maintains internal Snowflake objects required to implement the application.

These include structures such as:

  • built dimension structures
  • fact storage
  • compiled formula information
  • configuration
  • audit information

These objects are managed by the application and should not be treated as supported integration interfaces.

Consumers should integrate through documented procedures, secure views, and reporting tables instead of relying on internal implementation objects.

Built-In User Interface

Section titled “Built-In User Interface”

Casabase Cube includes a Streamlit user interface for interactive operations such as:

  • modeling
  • querying
  • formula management
  • security administration
  • configuration
  • operational administration

The UI operates against the same application capabilities exposed through supported procedures and Snowflake objects.

Consumption Surfaces

Section titled “Consumption Surfaces”

Casabase Cube provides several ways to consume multidimensional data.

Calculation Engine

Section titled “Calculation Engine”

Use the calculation engine when results depend on Casabase Cube semantics such as:

  • hierarchy-aware aggregation
  • calculated members
  • formulas
  • solve order
  • time intelligence
  • multidimensional member selection

The primary query interfaces include:

CALL CUBE.QUERY_CUBE(...);

and:

CALL CUBE.QUERY_CUBE_PIVOT_JSON(...);

Secure Views

Section titled “Secure Views”

Each cube exposes secure relational views including:

<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS

These provide relational access to stored facts and dimension metadata while enforcing applicable Casabase Cube security.

They are useful when a consuming tool needs a conventional Snowflake table or view interface and will perform its own modeling or aggregation.

Secure views do not reproduce all calculation-engine behavior. For example, calculated members and cube-level time-balance processing are calculation-engine capabilities rather than properties of the stored leaf-level fact rows.

Materialized Reporting Tables

Section titled “Materialized Reporting Tables”

Saved queries can be executed on a schedule and written to reporting tables.

This pattern is useful when:

  • a BI tool cannot call stored procedures
  • a result is queried much more frequently than its underlying data changes
  • consumers need a conventional relational table
  • multidimensional calculations should be performed once during refresh rather than on every read

The resulting table contains the calculated output of the saved query.

Once materialized, however, it is a regular Snowflake table. Casabase Cube security was applied under the identity that executed the query; subsequent access to the materialized table is governed by Snowflake privileges on that table.

AI Interfaces

Section titled “AI Interfaces”

Casabase Cube can also expose multidimensional business context through Snowflake AI capabilities, including Cortex Agent integration and MCP-based access.

These interfaces allow AI consumers to work with the governed structures and business semantics defined in Casabase Cube while remaining within the Snowflake architecture.

Security Boundary

Section titled “Security Boundary”

Casabase Cube uses Snowflake identity and evaluates row-level security using the current Snowflake user.

The application does not maintain a separate authentication system or hold end-user credentials.

When Casabase Cube row-level security applies to a user, the permitted data scope is established before aggregation and calculation. This means formulas cannot be used to retrieve data outside the user’s permitted scope.

Security is opt-in per user. Enabling security on a dimension makes that dimension eligible for filtering, but a user is restricted only when that user has active security rules on the cube.

A user with no active security rules remains unrestricted by Casabase Cube row-level security.

For details, see Access Control and Security Model.

Data Boundary

Section titled “Data Boundary”

Customer data remains within the customer’s Snowflake environment.

Casabase Cube:

  • does not move cube data to a Casabase-hosted service
  • does not make outbound network connections
  • does not send usage telemetry to the provider
  • does not require a separate external database
  • does not modify customer source tables
  • does not store external credentials for accessing customer data

The application reads source objects through grants made by the customer and performs its processing within Snowflake.

For a detailed discussion of where data and application objects reside, see Data Storage & Boundaries.

Architectural Separation

Section titled “Architectural Separation”

A useful way to think about the architecture is as three layers:

Layer Purpose
Customer Source Data Customer-owned dimension sources, fact data, and staged import files
Casabase Cube Application Multidimensional structures, configuration, calculation engine, formulas, security, administration, and application-managed storage
Consumption Surface Supported procedures, secure views, reporting tables, and AI interfaces

This separation is important because application-internal objects are implementation details.

As a general rule, integrations should be built only against documented Casabase Cube interfaces.

What Casabase Cube Does Not Require

Section titled “What Casabase Cube Does Not Require”

Casabase Cube does not require:

  • a separate OLAP server
  • a Casabase-hosted calculation service
  • an external metadata repository
  • precomputed aggregate cubes
  • a proprietary client driver
  • an XMLA endpoint
  • an MDX query layer
  • an on-premises gateway
  • movement of customer data outside Snowflake

The Snowflake account remains the execution, data, security, and integration boundary.

Next Steps

Section titled “Next Steps”

Continue with: