Views
Views sit on top of the data graph of cubes and create a facade of your whole data model with which data consumers can interact. They are useful for defining metrics, managing governance and data access, and controlling ambiguous join paths.
Views can not have their own members. Instead, use the cubes
or includes
parameters to include measures and dimensions from other cubes into the view. In
the example below, we create a new view active_users
which is made up of
properties from the users
cube:
views:
- name: orders
cubes:
- join_path: base_orders
includes:
- status
- created_date
- total_amount
- total_amount_shipped
- count
- average_order_value
- join_path: base_orders.line_items.products
includes:
- name: name
alias: product
- join_path: base_orders.users
prefix: true
includes: "*"
excludes:
- company
Views can be queried the same way as cubes; the example below show how to query the above view with SQL API:
SELECT
users_city,
MEASURE(total_amount)
FROM orders
GROUP BY 1
Views also do not define any pre-aggregations, instead they re-use pre-aggregations defined by the underlying cubes.
Parameters
name
The name
parameter serves as the identifier of a view. It must be unique among
all cubes and views within a deployment and follow the naming
conventions.
views:
- name: active_users
description
A description of the view allows your team to better understand what its purpose is. It is a very simple and yet useful tool that gives a hint to everyone and ensures that data is interpreted correctly by users.
views:
- name: active_users
description: 14 days rolling count of active users
cubes
Use cubes
parameter in view to include exposed cubes in bulk. You can build
your view by combining multiple joined cubes together and specifying the path by
which they should be joined for that particular view.
views:
- name: orders
cubes:
- join_path: base_orders
includes:
- status
- created_date
- total_amount
- total_amount_shipped
- count
- average_order_value
- join_path: base_orders.line_items.products
includes:
- name: name
alias: product
- join_path: base_orders.users
prefix: true
includes: "*"
excludes:
- company
When listing cubes to expose, you need to provide a join_path
parameter. It
uses dot notation to describe the join path: cube_1.cube_2.cube_3
. For the
root cube of the view, just put the cube name as in the example above for
base_orders
.
The other required parameter inside the cubes
block is includes
. You can
simply list measures, dimensions, or segments you'd like to include. In case you
need to rename some of them, you can provide name
and alias
parameters.
Alternatively, you can use the excludes
parameter in conjunction with the
includes all definition includes: "*"
.
Optionally, if you'd like to prefix exposed measures, dimensions, or segments
with the cube name, you can use the prefix: true
parameter. It will prefix
them with the cube name, e.g. users_city
. You can use the alias
parameter to
rename the cube for the prefixing purpose.
includes
The includes
property is used to bulk add measures or dimensions to a view.
views:
- name: active_users
includes:
# Measures
- users.rolling_count
# Dimensions
- users.city
- users.created_at
public
Prior to v0.33, this property was called shown
.
The public
property is used to manage the visibility of a view. Valid values
for public
are true
and false
. When set to false
, this view cannot
be queried through the API. Defaults to true
.
views:
- name: orders
public: false
You can also use COMPILE_CONTEXT
for dynamic visibility if necessary, check
out our
Controlling access to cubes and views
recipe.
views:
- name: arr
description: Annual Recurring Revenue
public: COMPILE_CONTEXT.security_context.is_finance
includes:
# Measures
- revenue.arr
# Dimensions
- revenue.date
- customers.plan
To learn more about using public
to control visibility based on security
context, read the Controlling access to cubes and views
recipe.
Using views with pre-aggregations
Pre-aggregations defined for original Cube members would still work when used in view queries. Please note that pre-aggregations use the same leaf members matching algorithm used for Cubes. As a consequence, all measures and dimensions included in pre-aggregation should be leaf members in order to be matched by view query.