Dimensions
You can use thedimensions parameter within cubes to define dimensions.
You can think about a dimension as an attribute related to a measure, e.g. the measure user_count
can have dimensions like country, age, occupation, etc.
Any dimension should have the following parameters: name, sql, and type.
Dimensions can be also organized into hierarchies.
Parameters
name
The name parameter serves as the identifier of a dimension. It must be unique
among all dimensions, measures, and segments within a cube and follow the
naming conventions.
case
The case statement is used to define dimensions based on SQL conditions.
The when parameters declares a series of sql conditions and labels
that are returned if the condition is truthy. The else parameter declares
the default label that would be returned if there’s no truthy sql
condition.
The following example will create a size dimension with values
xl, xxl, and Unknown:
label property can be defined dynamically as an object with a sql
property in JavaScript models:
title
You can use the title parameter to change a dimension’s displayed name. By
default, Cube will humanize your dimension key to create a display name. In
order to override default behavior, please use the title property:
description
This parameter provides a human-readable description of a dimension.
When applicable, it will be displayed in Playground and exposed
to data consumers via APIs and integrations.
public
The public parameter is used to manage the visibility of a dimension. Valid
values for public are true and false. When set to false, this dimension
cannot be queried through the API. Defaults to true.
format
format is an optional parameter. It is used to format the output of dimensions
in different ways, for example, a link for external_url. Please refer to the
Dimension Formats for the full list of supported
formats.
meta
Custom metadata. Can be used to pass any information to the frontend.
order
The order parameter specifies the default sort order for a dimension. Valid
values are asc (ascending) and desc (descending). This parameter is optional.
When set, the dimension’s default sort order is exposed via
APIs and integrations. Consuming applications, such as BI tools
and custom frontends, can use this metadata to apply consistent default sorting
when displaying dimension values, ensuring a uniform user experience across
different tools connected to the semantic layer.
primary_key
Specify if a dimension is a primary key for a cube. The default value is
false.
A primary key is used to make joins work properly.
Setting
primary_key to true will change the default value of the public
parameter to false. If you still want public to be true, set it
explicitly.count measure of the cube shown above will generate the following
SQL to the upstream data source:
propagate_filters_to_sub_query
When this statement is set to true, the filters applied to the query will be
passed to the subquery.
sql
sql is a required parameter. It can take any valid SQL expression depending on
the type of the dimension. Please refer to the Dimension
Types to understand what the sql parameter should
be for a given dimension type.
mask
The optional mask parameter defines the replacement value used when the
dimension is masked by a data masking access policy.
The mask can be a static value (number, boolean, or string) or a SQL expression:
mask is defined, the default mask value is NULL. See
data masking for more details.
sub_query
The sub_query statement allows you to reference a measure in a dimension. It’s
an advanced concept and you can learn more about it here.
type
type is a required parameter. There are various types that can be assigned to
a dimension. Please refer to the Dimension Types
for the full list of dimension types.
granularities
By default, the following granularities are available for time dimensions:
year, quarter, month, week (starting on Monday), day, hour, minute,
second.
You can use the granularities parameter with any dimension of the type
time to define one or more custom granularities, such as
a week starting on Sunday or a fiscal year.
See this recipe for more custom granularity
examples.
interval parameter is required. It specifies
the duration of the time interval and has the following format:
quantity unit [quantity unit...], e.g., 5 days or 1 year 6 months.
Optionally, a custom granularity might use the offset parameter to specify how
the time interval is shifted forward or backward in time. It has the same
format as interval, however, you can also provide negative quantities, e.g.,
-1 day or 1 month -10 days.
Alternatively, instead of offset, you can provide the origin parameter.
When origin is provided, time intervals will be shifted in a way that one of
them will match the provided origin. It accepts an ISO 8601-compliant date time
string, e.g., 2024-01-02 or 2024-01-02T12:00:00.000Z.
Optionally, a custom granularity might have the title parameter with a
human-friendly description.
Calendar cubes
When thegranularities parameter is used in time dimensions within calendar
cubes, you can still use it to define custom granularities.
Additionally, you can override the default granularities. This can be useful for
modeling custom calendars, such as fiscal calendars.
time_shift
The time_shift parameter allows overriding the time shift behavior for time dimensions
within calendar cubes. Such time shifts can be referenced in
time-shift measures of other cubes, enabling the use of custom calendars.
The time_shift parameter can only be set on time dimensions within calendar cubes,
i.e., cubes where the calendar parameter is set to true.
The time_shift parameter accepts an array of time shift definitions. Each definition
can include time_dimension, type, interval, and name parameters, similarly to the
time_shift parameter of time-shift measures. Additionally,
you can use the sql parameter to define a custom time mapping using a SQL expression.