Skip to content

Query Builder

Query Builder provides a visual interface for building and executing multidimensional queries without manually writing SQL or constructing a Point of View (POV).

Users can browse the dimensions and hierarchies of a cube, select members and member sets, configure query options, review the generated POV, estimate the size of the query, and execute it directly from the Casabase Cube interface.

Query Builder uses the same Casabase Cube query engine available programmatically through CUBE.QUERY_CUBE.

Navigate to Query Builder from the Casabase Cube sidebar.

Select the cube you want to query.

Once a cube is selected, Query Builder loads the dimensions and hierarchy metadata associated with that cube.

Conceptually:

Select Cube
Select Members
Build POV
Configure Query Options
Estimate
Execute
Review Results

A query is built by selecting members from the dimensions of the cube.

For each dimension, you can select individual members or use hierarchy-aware selections to retrieve related members.

For example, a query might request:

MEASURES
└── Units
TIME
└── Qtr1
├── Jan
├── Feb
└── Mar
YEARS
└── Curr Year

The resulting POV could be:

{
"MEASURES": ["Units"],
"TIME": [{"children": "Qtr1"}],
"YEARS": ["Curr Year"]
}

Query Builder constructs the POV from the selections made in the interface.

Query Builder allows you to browse the hierarchy for each dimension and select the members required by the query.

Selections can include:

  • Individual members
  • Children of a member
  • Descendants of a member
  • Inclusive hierarchy selections
  • Ancestors
  • Siblings
  • Bottom-level members
  • Other supported hierarchy-based selections

The selected members determine the multidimensional coordinates returned by the query.

For the complete list of supported selection operators and their exact behavior, see Point of View (POV).

Individual Members and Hierarchy Expansions

Section titled “Individual Members and Hierarchy Expansions”

Selecting an individual member and expanding a hierarchy relationship are different operations.

For example, selecting:

Qtr1

requests the value associated with Qtr1.

Selecting the children of Qtr1 requests:

Jan
Feb
Mar

Conceptually:

Qtr1
├── Jan
├── Feb
└── Mar

Individual selection:

Qtr1

Children selection:

Jan
Feb
Mar

Casabase Cube performs the hierarchy aggregation required to return an upper-level member such as Qtr1.

As selections are made, Query Builder generates the corresponding POV.

For example:

{
"MEASURES": ["Units"],
"TIME": [{"children": "Qtr1"}],
"YEARS": ["Curr Year"]
}

Reviewing the POV is useful for understanding exactly what the query will execute.

It is also useful when developing queries that will later be executed programmatically through CUBE.QUERY_CUBE.

The same POV concepts are used by both Query Builder and the SQL interface.

See Point of View (POV) for the complete POV reference.

The generated POV can also be edited directly when you need more precise control over a query.

This is useful for:

  • Combining several member selections
  • Using hierarchy operators
  • Adding Cube Variables
  • Testing a POV intended for programmatic use
  • Refining a query without rebuilding every selection through the hierarchy browser

After editing the POV, make sure the resulting JSON follows the supported Casabase Cube POV syntax.

A query does not necessarily need to explicitly select every dimension in the cube.

When a dimension is omitted from the POV, its behavior depends on the cube configuration.

If the dimension does not have a configured default member, it does not appear as a column in the result.

If the dimension has a configured default member, Casabase Cube resolves the dimension to that member and includes the dimension in the result.

Because a default member slices the query to a particular member, it can affect both the shape of the result and the value returned.

The complete behavior, including explicit top-member selections and hierarchy expansions, is covered in Point of View (POV).

Cube Variables can be used in a POV to make member selections dynamic.

For example, instead of hardcoding a reporting year, a POV can reference a variable whose value is maintained centrally.

This is particularly useful when developing queries that will later be saved or scheduled.

Query Builder allows the resolved POV to be tested interactively before the query is reused elsewhere.

See Cube Variables for variable syntax and behavior.

Query Builder can return member names or aliases when an alias table is configured for the cube.

Aliases affect the output of the query. They do not change the member identifiers used in the POV.

For example, a member might have:

Member Name: 100-10
Alias: Cash

The POV continues to reference the member name:

{
"ACCOUNT": ["100-10"]
}

while the result can display:

Cash

when the appropriate alias table is selected.

This distinction allows the query definition to remain tied to stable member names while presenting user-friendly labels in the result.

When Apply Member Formulas is enabled, calculated members included in the query are evaluated dynamically by the Casabase Cube calculation engine.

For example, a query can select members such as:

Gross Profit
Gross Margin %
Variance

and Casabase Cube evaluates the formulas associated with those members within the multidimensional context of the query.

Apply Member Formulas is enabled by default.

If it is disabled, member formulas are not calculated for the query.

See Formula Overview for formula behavior and Formula Editor for formula management.

Before executing a query, Query Builder can estimate the size of the requested result.

This is particularly useful for queries containing broad hierarchy expansions.

For example:

{
"ENTITY": [{"idescendants": "Total Entity"}],
"PRODUCT": [{"idescendants": "Total Product"}]
}

may expand to a much larger multidimensional result than a query selecting a few specific members.

Use the estimate to understand the potential size of the result before execution.

If a query is larger than intended, narrow the POV by selecting more specific members or smaller hierarchy branches.

Once the POV and query options are ready, execute the query from Query Builder.

Casabase Cube resolves the selected members and hierarchies, applies configured security, performs the required aggregation and calculations, and returns the result.

At a high level:

POV
Resolve Members
Apply Security
Aggregate Cube Data
Apply Calculations
Return Results

The physical cube storage is resolved automatically from the selected cube. Users do not specify an underlying fact table when executing the query.

Query Builder displays the multidimensional result in relational form.

For example:

MEASURES TIME YEARS AMT
--------- ----- ---------- -----
Units Jan Curr Year 42228
Units Feb Curr Year 20841
Units Mar Curr Year 31434

The dimension columns that appear depend on the resolved POV and the cube’s default-member configuration.

The AMT column contains the calculated value for each returned multidimensional intersection.

Aliases can be used to display alternate member labels when configured.

Configured row-level security is applied when Query Builder executes a query for a user who has active Casabase Cube security rules. Security is opt-in per user; application access without active Casabase Cube security rules is not, by itself, row-level restricted.

If a user does not have access to a secured member, rows associated with that member are omitted from the result.

Security filtering is silent.

For example, a broad selection such as:

{
"ENTITY": [{"idescendants": "Total Entity"}]
}

can return the full hierarchy to a user with full access while returning only an authorized branch to a restricted user.

The same POV can therefore produce different permitted result sets for different users.

If a query returns fewer rows than expected, verify the user’s access to the dimensions involved before assuming that cube data is missing.

Queries that will be used repeatedly can be saved.

A Saved Query stores a named POV associated with a cube so the multidimensional selection does not need to be rebuilt each time.

This is useful for:

  • Frequently executed analyses
  • Standard reporting selections
  • Reusable application queries
  • Queries that will later be scheduled for materialization

Saved Query configuration and scheduling are managed from Vars & Saved Queries.

See Saved Queries for the complete workflow.

Query Builder maintains access to recently executed queries so users can return to previous query definitions without rebuilding them from scratch.

Recent Queries are useful during interactive analysis and query development, particularly when testing variations of a POV.

For queries that should be retained as a reusable named definition, use a Saved Query instead.

Query Builder can also serve as a visual development tool for programmatic queries.

A common workflow is:

Build Query Visually
Review Generated POV
Execute and Validate
Reuse POV with QUERY_CUBE

This allows a multidimensional query to be developed interactively before the same POV is incorporated into a Snowflake worksheet, application, data pipeline, or other SQL-based workflow.

See Querying with SQL for programmatic query execution.