Data Storage & Boundaries

Casabase Cube runs entirely within the customer’s Snowflake environment.

Understanding where data and application objects reside is important for architecture, governance, security review, integration design, and application upgrades.

At a high level, Casabase Cube separates the environment into three layers:

Customer Source Data
        │
        ▼
Casabase Cube Application Internals
        │
        ▼
Supported Consumption Surface

Each layer has a different ownership and integration purpose.

Storage Layers

Layer	Contains	How It Should Be Used
Customer Source Data	Dimension source tables, fact data, staged import files	Customer-owned source objects read by Casabase Cube
Application Internal	Built dimension structures, fact storage, compiled formula information, configuration, audit log	Managed by Casabase Cube; not a supported integration target
Consumption Surface	Documented procedures, secure views, materialized reporting tables	Stable interface for applications, BI tools, SQL users, and integrations

The design rule is simple:

Build integrations against documented Casabase Cube procedures, secure views, and reporting tables rather than application-internal objects.

Application-internal object names and structures can change as the product evolves, while the supported consumption surface is the intended integration contract.

Customer Source Data

Casabase Cube reads customer-controlled Snowflake data sources such as:

• Dimension source tables
• Fact or transaction tables
• Files placed on Snowflake stages

For example:

SOURCE_DB
│
├── DIM_ENTITY
├── DIM_ACCOUNT
├── DIM_PERIOD
└── GL_FACT

or:

IMPORT_STAGE
└── source files

These objects remain customer-owned.

Casabase Cube reads them through Snowflake grants explicitly provided to the application.

Conceptually:

Customer Table
      │
      │ SELECT
      ▼
Casabase Cube

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

Source Data Access

The application can access only the Snowflake objects for which it has been granted the required privileges.

A typical source-data access pattern is:

Customer Database
      │
      ▼
USAGE on Database
      │
      ▼
USAGE on Schema
      │
      ▼
SELECT on Required Tables
      │
      ▼
Casabase Cube

For staged import files, the application can also be granted access to the appropriate Snowflake stage.

The recommended model is least privilege:

Grant what the cube needs to read
        │
        ▼
Do not grant ownership
        │
        ▼
Do not grant unnecessary source access

Application-Managed Storage

Casabase Cube creates and manages internal Snowflake structures required to provide multidimensional behavior.

These can include:

• Built dimension structures
• Application-managed fact storage
• Compiled formula information
• Cube configuration
• Security configuration
• Saved Query configuration
• Scheduling metadata
• Audit history
• Other application implementation objects

These objects exist inside the installed Native App and are managed by Casabase Cube.

They should be considered implementation details, not stable customer integration interfaces.

Built Dimension Structures

Dimensions are built from source hierarchy metadata.

For example:

Source Parent-Child Table
        │
        ▼
Dimension Build
        │
        ▼
Application-Managed Hierarchy Structure

The built structure provides the metadata required for:

• Parent-child relationships
• Ancestor and descendant navigation
• Generations and levels
• Hierarchy expansion
• Aggregation
• Formula evaluation
• Security inheritance

When the source hierarchy changes, the affected dimension must be rebuilt.

Fact-data changes do not require this hierarchy rebuild.

Fact Storage and Aggregation

Casabase Cube does not create stored aggregate values at every hierarchy level.

Fact data exists at stored intersections, while parent values are dynamically derived when queried.

Conceptually:

Stored Leaf Data
      │
      ▼
Query
      │
      ▼
Dynamic Aggregation
      │
      ▼
Parent Result

There is therefore no separate stored aggregate layer that must be processed whenever fact data changes.

This is an important distinction between:

Application-managed fact storage

and:

Precomputed OLAP aggregates

Casabase Cube may maintain application-managed fact structures, but hierarchy aggregates are not duplicated and stored throughout the cube. They are calculated dynamically from the underlying stored data.

Configuration and Metadata

Casabase Cube maintains application configuration inside the Native App.

This includes metadata defining areas such as:

• Cubes
• Dimensions
• Hierarchies
• Default members
• Formulas
• Security
• Data classification
• Cube Variables
• Saved Queries
• Schedules

Consumers should use supported administrative interfaces and procedures to manage this configuration rather than directly modifying application-internal tables.

Audit Data

The Casabase Cube audit log is also maintained inside the customer’s Snowflake account as part of the application’s internal state.

Audit information records application-level activity and remains inside the Native App rather than being transmitted to a provider-hosted logging service.

This provides application-specific operational history while keeping the data within the customer’s Snowflake environment. The audit log is application-managed data, and administrative and data-access activity is recorded inside the customer account.

See Logging & Auditability and Audit Log for details.

Supported Consumption Surface

The supported consumption surface is the boundary applications and integrations should use.

It includes:

• Documented stored procedures
• Secure cube views
• Materialized reporting tables

The primary secure views for each cube are:

<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS

Materialized query output is written to tables in:

SHARED_DATA

The consumption surface is designed to provide stable access without exposing internal implementation structures.

Procedures

Casabase Cube procedures provide supported interfaces for multidimensional operations.

Examples include:

QUERY_CUBE
QUERY_CUBE_PIVOT_JSON
LIST_CUBES
LIST_DIMENSIONS
SEARCH_MEMBERS

and supported modeling and administrative procedures.

Consumers should use these procedures rather than querying internal calculation or configuration objects directly.

Secure Fact View

Each cube provides:

<CUBE>_FACT_SECURE

This view exposes security-filtered stored fact data.

It is intended for consumers that require relational access to stored cube facts.

The secure fact view does not reproduce the complete calculation-engine behavior.

In particular, it does not provide:

• Dynamically calculated parent members
• Member formula evaluation
• Calculated members
• Cube time-balance treatment

Those capabilities belong to the Casabase Cube calculation engine.

Secure Dimension View

Each cube also provides:

<CUBE>_DIMENSIONS

This exposes supported hierarchy and member metadata.

The view can be used to retrieve information such as:

• Dimension name
• Member name
• Parent
• Alias
• Generation
• Level
• Leaf status
• Sort order
• UDA metadata
• Other supported dimensional properties

This allows applications and BI tools to consume hierarchy metadata without depending on internal dimension tables.

Materialized Reporting Tables

Casabase Cube can write calculated query results to reporting tables in SHARED_DATA.

For example:

Saved Query
     │
     ▼
QUERY_CUBE
     │
     ▼
SHARED_DATA.RPT_MONTHLY_PL

These tables contain the calculated result at the time the query runs.

They are useful for:

• BI dashboards
• Reporting datasets
• Data pipelines
• Application consumption
• Workloads that repeatedly read the same calculated result

Once created, the result is a normal Snowflake table.

This introduces an important security boundary.

Security Boundary for Materialized Results

When a query is executed directly against Casabase Cube, security is evaluated using the identity executing that query.

For a scheduled Saved Query, security is evaluated using the identity under which the scheduled query runs.

The resulting data is then written to a plain Snowflake table.

Conceptually:

Execution Identity
        │
        ▼
Casabase Cube Security
        │
        ▼
Calculated Result
        │
        ▼
Materialized Table
        │
        ▼
Snowflake Table Grants

After materialization, consumers are no longer querying the cube. They are reading a Snowflake table.

Casabase Cube row-level security therefore does not dynamically re-evaluate for every reader of that table. Access to the materialized result is controlled by Snowflake privileges on the table.

This has an important design consequence:

Do not use a single security-scoped materialized result to serve users who require different Casabase Cube access scopes.

Instead, either:

• have those users query Casabase Cube directly, or
• materialize separate datasets for the appropriate audiences.

Application Boundary

Casabase Cube executes entirely within the customer’s Snowflake account.

The application does not:

• Move customer cube data outside the account
• Make outbound network calls
• Send provider telemetry
• Require a provider-hosted data-processing service
• Require an external OLAP database
• Hold customer credentials outside Snowflake

Every dimension build, query, formula calculation, and scheduled refresh occurs within the customer’s Snowflake environment.

Identity Boundary

Casabase Cube operates under Snowflake identity.

It does not maintain a separate application authentication system for querying customer cube data.

For example, row-level security is evaluated using Snowflake session context, including:

CURRENT_USER()

This keeps identity evaluation within Snowflake rather than introducing a second identity store.

See Security Model and Roles and Privileges.

Network Boundary

Casabase Cube does not require a data path through an external Casabase network service.

Conceptually:

User / Tool
    │
    ▼
Snowflake
    │
    ▼
Casabase Cube Native App
    │
    ▼
Customer Data

rather than:

Customer Snowflake
      │
      ▼
External Vendor Service
      │
      ▼
External Calculation Platform
      │
      ▼
Customer

This architecture removes the need for a separate gateway or middle tier for normal cube consumption.

What Persists Across an Upgrade

Customer-specific Casabase Cube state persists across application upgrades.

This includes:

• Cubes
• Dimension definitions
• Formulas
• Data
• Security rules
• Data classifications
• Saved Queries
• Schedules
• Audit history

The Native App upgrade replaces application code and can rebuild or migrate internal structures as required by the new version.

Conceptually:

Before Upgrade

Application Code v1
Customer Configuration
Customer Data


          │
          ▼


After Upgrade

Application Code v2
Customer Configuration
Customer Data

The customer-specific logical model remains while the application’s implementation can evolve.

Internal Structures Can Change

Internal application objects are not the supported compatibility boundary.

During an upgrade, Casabase Cube can:

• Replace application code
• Migrate internal metadata
• Rebuild internal structures
• Recreate supported views
• Remove superseded internal objects

This is why consumers should not build directly against internal tables.

A custom integration tied to an undocumented internal object may break even though the supported Casabase Cube interfaces continue to operate normally.

Customer-Created Objects

Objects created by the customer outside the Native App remain the customer’s responsibility.

Examples include:

• Customer-created views
• BI semantic models
• Saved SQL referencing Casabase Cube objects
• Other external objects referencing the application by name

An application upgrade cannot automatically rewrite arbitrary objects that live in customer-owned schemas.

If a release changes a referenced supported object or integration pattern, those customer-created objects may need to be updated.

AI objects created and managed through the current Native App Intelligence integration have their own Snowflake lifecycle and governance model. See Setting Up the Agent for the current architecture.

Source Data vs. Application Data

It is useful to distinguish two categories of data associated with a cube.

Customer Source Data

These are objects the customer owns independently of Casabase Cube:

Dimension Tables
Fact Tables
Import Files

The application reads them.

Application-Managed Data

These are objects Casabase Cube maintains to operate the multidimensional model:

Built Dimension Structures
Fact Storage
Configuration
Compiled Formula Information
Audit Information

These are managed by the Native App.

The boundary is:

Customer Source
     │
     ▼
Read by Casabase Cube
     │
     ▼
Application-Managed Structures
     │
     ▼
Supported Consumption Surface

Stable Integration Contract

When designing an integration, ask:

Is this object a documented procedure?
        │
        ├── Yes ──► Supported interface
        │
        └── No
              │
              ▼
Is it <CUBE>_FACT_SECURE
or <CUBE>_DIMENSIONS?
        │
        ├── Yes ──► Supported interface
        │
        └── No
              │
              ▼
Is it a reporting table
you asked Casabase Cube to create?
        │
        ├── Yes ──► Supported consumption object
        │
        └── No ──► Treat as internal

This protects integrations from unnecessary dependence on implementation details.

Architectural Implications

The storage boundary has several practical consequences.

Governance

Customer data and application processing remain inside Snowflake, so existing Snowflake governance controls remain relevant to the environment.

Security

Snowflake identity and grants govern access to the application and source objects, while Casabase Cube adds application roles and row-level security for cube functionality.

Integration

Consumers integrate through Snowflake rather than through an external Casabase service.

Upgrades

Application internals can evolve without requiring consumers to redesign integrations that use the supported consumption surface.

Data Residency

Casabase Cube does not require customer analytical data to leave Snowflake for calculation or storage.

Key Principles

• Customer source data remains customer-owned.
• Casabase Cube reads source tables but does not modify them.
• Internal application structures are managed by Casabase Cube.
• Internal objects are not a supported integration target.
• The stable consumption surface consists of documented procedures, secure views, and materialized reporting tables.
• <CUBE>_FACT_SECURE exposes stored fact data.
• <CUBE>_DIMENSIONS exposes supported dimension metadata.
• Materialized results become normal Snowflake tables after they are written.
• Customer-specific cube state persists across application upgrades.
• Customer-created external objects remain the customer’s responsibility.
• Customer data and Casabase Cube processing remain within the customer’s Snowflake environment.

Related Topics

• High-Level Architecture
• Query Architecture
• Security Model
• Integration Points
• Logging & Auditability
• Application Upgrades
• Roles and Privileges