Measure lineage

The Lineage Explorer answers the questions every data team eventually asks about a metric:

“Where does this measure actually come from?” — its physical column, table, and database.
“If I change or remove this, what breaks?” — what references it.

It reads straight from your governed schema and recent query activity, so the answer is always live — there is no index to rebuild and nothing to keep in sync.

Opening the explorer

Open Lineage in the dashboard. It’s a two-pane explorer:

Left — a filterable tree of everything in the selected schema.
Right — the detail panel for whichever node you click.

Pick a schema from the picker at the top. In Saiku Cloud a “cube” is one of your uploaded schemas, identified by its label — a single schema can hold several Mondrian cubes (the demo FoodMart schema contains Sales, Warehouse, HR, and more), and the tree shows them all.

Browsing the tree

The tree mirrors the shape of your schema, at a fixed depth:

Branch	Contents
Cube → measure group → measure	The declared measures in each cube, grouped as in the schema.
Cube → calculated members	Calc-members defined on the cube — e.g. `Profit = [Measures].[Sales] - [Measures].[Cost]`.
Cube → dimension → hierarchy → level	The dimensional structure, down to each level.

Use the filter box at the top of the tree to narrow it — type part of a measure, dimension, hierarchy, or level name and the tree collapses to the matches. Matching a cube name reveals all of that cube’s calculated members.

Reading the physical route

Click any node — a measure, a calculated member, or a level — and the detail panel shows its physical route as a chain of chips:

column → table → database

That’s the real backing column, the table it lives on, and the database connection that serves it. For a declared measure you also see its aggregator (e.g. sum); for a level you see the column it keys on.

Calculated members fan out

A calculated member has no single backing column — it’s a formula over other members. The explorer fans it out: it resolves the formula’s base measures (the member’s dependsOn set) and renders one route row per underlying column. So a Profit member built from Sales and Cost shows two routes, one per fact column, alongside its formula and the list of members it depends on.

”Used by” — what references a member

The detail panel has a Used by lane. Click Click to load usage and it lazily fetches everything that references the selected member, each entry tagged by kind:

Kind	What it is
Calculated member	A calc-member in the schema whose formula references the selected member.
Saved query	A saved `.saiku` query whose MDX references the member.
Agent query	A recent agent query that referenced the member, drawn from the audit trail. (See the caveat below.)

The fetch is lazy on purpose — usage scans your recent activity, so you only pay for it on the nodes you actually inspect.

Audit log — the source of agent-query usage; who queried what, when.
Schema designer — where calculated members and measures are defined.
API keys — mint a key for programmatic access.