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.

Note

The Lineage Explorer is Team tier and above, like the audit log.

Opening the explorer

Open Lineage in the dashboard. The page stacks top to bottom:

1. Schema chips — one per saved schema. Pick the one you’re tracing.
2. A colour legend for the eight node types you’ll meet: measure, level, dimension, cube, schema, column, table, database. Worth a glance the first time; the colours carry meaning in the chain below.
3. A filterable tree of everything in the selected schema.
4. The detail panel, which fills in underneath once you click a node.

In Saiku Cloud a “cube” chip 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 lineage chain

Click any node — a measure, a calculated member, or a level — and the Lineage section traces it the whole way down, as a chain of labelled chips:

MSR store_sales → CUBE Cube 1 → SCHEMA Sales 4.8.0 Test
  → COL store_sales → TBL sales_fact_1997 → DB FoodMart PG

It reads left to right from the thing you clicked to the database serving it, through the cube and schema that define it and the column and table it physically lives in. That middle stretch is the part people usually can’t reconstruct from memory, and it’s the reason the chain is worth more than “which table is this on?”.

Above the chain you get the member’s own facts: its type, its aggregator for a declared measure (sum), and its MDX unique name — handy to copy straight into a query.

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 per contributing measure. A Profit member built from Sales and Cost shows two routes, alongside its formula and the members it depends on.

A single route can name more than one column, incidentally — a measure backed by a calculated column carries every column its SQL reads.

”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.

Caution

Agent usage is a rolling 30-day window, and it’s forward-looking. Two limits, and both matter if you’re about to delete something:

• A query only counts if it ran in the last 30 days. A measure used in a quarterly report — queried six weeks ago, due again next week — shows no agent usage at all.
• It only counts if it ran after the feature was enabled for your tenant. History before that point doesn’t exist.

So an empty Used by means “nothing referenced this recently”, never “nothing references this”. Treat it as evidence, not proof — especially for anything on a monthly or quarterly cadence.

We record only the member references a query made — schema identifiers like [Measures].[Sales] — never the raw query text or any result data.

Related

• 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.