Skip to content

Model a Data Vault on the canvas

Not part of the free edition, and not switched on for every paying organization either. The Data Vault and Data Mart accelerators are enrolled surfaces. If the menu items described below are missing, that is the reason, and it is not a fault. See Pricing for what each edition includes.

The Data Vault modeling view turns source tables into a logical Data Vault (hubs, links, and satellites) that you refine before materializing physical tables. Open it from the workspace canvas: right-click a Stage or Persistent Stage table and choose Data Vault.

The view opens in the workspace canvas area and shows a single model canvas. For AI help (renaming objects, restructuring the model, or asking questions about it), click Ask AI in the header. The Ask AI panel opens with this workspace already in context; skills that propose model changes show a preview you approve before anything is applied.

On this canvas the conversational skill is the Vault canvas assistant: ask it about the model or describe a change to the hubs, links, and satellites, and it explains and proposes in Data Vault terms, applying a change only after you confirm.

Acceleration reads a source table’s metadata (business keys, reference columns, change tracking) and decomposes it into Data Vault objects. Launch it from the workspace canvas: right-click a Stage or Persistent Stage table and choose Data Vault. The launched source seeds the model with its hub, satellites, and links.

To bring in more sources, choose Add tables in the header band and pick the source tables to accelerate; they join the same model additively. To follow the relationships you already have, use the Add related tables panel (below).

Acceleration is editor-only and needs an active feature branch: the same rules as every other model edit.

A hub usually has neighbours: the source tables already in your model reference other tables through their columns. When DeltaVault finds referenced source tables that are not yet in the model, an Add related tables panel appears in the top-right corner of the canvas, listing each candidate as a button. Click one to accelerate that table into the model; the button disappears once the table is in. The panel follows the whole model (every accelerated source, one reference hop out), so newly added tables surface the next set of candidates automatically. Editors only; the panel is hidden for viewers.

When you accelerate a source table, DeltaVault first makes sure it has a business name, so the generated hubs, links, and satellites are named for what the data means, not for the physical table. If a launched source has no linked business entity and no business name yet, the Assign a business name dialog appears before the model is built:

  • Business entity: search your business model and link the table to an existing entity. The Data Vault object names then derive from the entity’s technical name (or its name).
  • Business name: type a free-text business name when there is no entity to link.

One of the two is required to continue; choose Apply. If several sources were launched together, the dialog steps through them one at a time and counts its progress (Table 1 of 2, and so on). You can choose Skip this table to let it keep deriving names from its physical table name; skipped tables are called out so nothing is gated silently.

Because the name is resolved before the model is generated, the hubs, links, and satellites come out with business-meaningful names through your configured naming conventions.

A business name usually belongs to a whole ingest chain, not one table. When you assign a name to a non-view staging or persistent-staging table, the Apply the business name across the ingest chain dialog opens. It recommends applying the name to the related source, landing, staging, and persistent-staging tables that feed into it, and lists every related table in the chain as a checklist (found by following column lineage in both directions, stopping at the Data Vault, mart, and warehouse boundaries):

  • Tables with no business name yet are pre-checked: applying the name fills the gap.
  • Tables that already carry a different business name are shown but left unchecked and flagged with the name they already have, so an existing name is never overwritten unless you opt in.

Choose Apply to N tables and the same business name (or entity link) is written to every checked table in one step, keeping naming and governance consistent across the chain. Not now skips the cascade and names only the table you launched.

To move some of a satellite’s columns into a new satellite, select the columns on the satellite card, right-click, and choose Split Into New Satellite (the item stays disabled until at least one column is selected). In the Split into new satellite dialog the name box is prefilled with the current satellite’s name plus a trailing underscore (for example sat_customer_), with the cursor at the end: type a suffix to name the split, or accept the prefilled name as-is, then choose Confirm. Either way, confirming resolves the name: if the name you keep would collide with an existing object, DeltaVault appends a number until it is unique, so a split never fails just because of a name clash.

Drag any node to wherever it makes sense. Your arrangement is saved automatically and restored the next time you open the view: selections and clicks never reshuffle the layout. Objects that arrive later (a new acceleration, a satellite split) are placed next to what they connect to, without disturbing the nodes you’ve placed.

A few notes:

  • Arrangements are saved per workspace on your feature branch, like the model itself.
  • Renaming an object keeps its position.
  • Viewers can drag nodes to explore, but their arrangement isn’t saved.

Press Auto layout on the canvas controls rail in the bottom left corner of the canvas to re-run the automatic left-to-right layout over the visible model. It replaces your manual arrangement (and saves the result), so use it as a reset when the canvas gets messy. Hidden stub hubs keep their stored positions and reappear where they were.

The same rail carries the view toggles, each an icon button named for what it does: Expand all satellites, Show stub hubs, Show suppressed objects, Show source tables, Show system columns, and Show history, each reading Hide or Collapse once it is on. The header band above the canvas carries Materialize, Add tables, and Exit.

Hub nodes show their hash key column and each business key column directly on the node, marked with a key icon: the hash key in muted text, business keys in regular text. Satellite nodes show their parent’s hash key pinned at the top, always visible even while the descriptive columns are collapsed. Nodes without key metadata show nothing extra.

Click any node to select it and open a detail pane on the right side of the canvas; Shift-click adds a node to the selection without moving the pane. The pane’s Details tab shows the kind, name, rationale, qualified name, source tables, parent, materialization, business keys (with their source columns), and the hash key, load date, record source, and hash diff columns where they apply; its Columns tab lists the object’s columns. Click a descriptive column inside an expanded satellite to see that column’s role (business key or descriptive) and its source column. Close the pane with the Close control in its corner.

Acceleration gives you a first-cut model, but real modeling means reshaping it. The operations below live on the right-click menu of a node, or in the detail pane you open by clicking a node. They are editor-only and need an active feature branch, like every other model edit. Where an operation changes the shape the model would otherwise derive on its own, DeltaVault records your intent so a later acceleration does not undo it (see Override durability below).

When acceleration classifies a source table as a hub but it really models a relationship, or the reverse, convert it in place.

  1. Right-click the node and choose Convert to Hub (on a link) or Convert to Link (on a hub).
  2. Read the confirmation. Converting rebuilds the object from its source table under the new classification: objects the old classification produced are replaced, and satellites move with the conversion.
  3. Choose Convert.

A conversion is blocked with a stated reason when it would leave the model inconsistent, for example when turning a hub into a link would leave the link with fewer than two hub references, or when the conversion would orphan links that point at it. Convert is offered only for a node that came from a single source table.

Deleting in a Data Vault model never throws anything away silently. A deleted object is suppressed: hidden from the canvas and left out of materialization, but recoverable.

  1. Right-click the node and choose Delete.
  2. Read the confirmation: the object is hidden from the canvas and will not materialize, its satellites are deleted with it, and re-running acceleration will not bring it back.
  3. Choose Delete.

To see suppressed objects again, choose Show suppressed objects on the canvas controls rail. Suppressed objects reappear dimmed, with a Suppressed chip in their detail pane. Right-click one and choose Restore to bring it back into the live model.

Deletion is blocked when another live object still depends on the one you are deleting, and the message names the objects that stand in the way so you know exactly what to fix first:

  • A hub referenced by live links cannot be deleted until you delete or rewire those links. The message lists them by name.
  • An object referenced by a live point in time table, bridge, or business object cannot be deleted until you edit or delete that consumer. The message names the consumer.

This is deliberate: naming the consumers turns a blocked delete into a short checklist instead of a guess.

A satellite can move between a hub and a link, for example when a descriptive group belongs on the relationship rather than on the entity.

  1. Right-click the satellite and choose Move to Parent.
  2. Pick the new parent from the list: a hub or link that shares the satellite’s business key. The item is hidden when no parent qualifies.
  3. Choose Move.

The satellite re-parents in place. If the new parent is a link, the satellite becomes a link satellite, and the reverse when you move it back to a hub.

A satellite’s variant controls how it tracks change. Open the satellite’s detail pane (click it) and pick a variant under Variant. Each variant collects the columns it needs:

  • Standard keeps one row per change to the descriptive columns. It collects no extra columns.
  • Multi-active allows several active rows per key (for example several phone numbers for one customer). It collects a Sub-sequence column that separates the active rows.
  • Effectivity tracks a business-effective window. It collects an Effective from column (required) and an Effective to column (optional).
  • Status tracks a record’s status over time. It collects a Status column.
  • Record Tracking records when a key appears in each load, with no descriptive columns of its own.

Choose the variant, fill in the columns it asks for, then choose Apply.

A driving key marks which of a link’s hub references drives the relationship, so effectivity and end-dating track against the correct key. Driving keys live on the link.

  1. Open the link’s detail pane (click it).
  2. Under Driving key, tick the hub references that drive the relationship.
  3. Choose Apply.

Driving keys feed the bridge builder’s default filter, so setting them here shapes what the bridge dialog offers later (see Bridge tables).

A hub keys on the business key designated on the staging table it was accelerated from: one column, either a plain column or a derived column built from several columns. You set and change that designation on the staging table itself, covered in Business key column. On the canvas you can review and adjust the hub’s business-key parts and their order in place:

  1. Open the hub’s detail pane (click it).
  2. Under Business key, reorder parts with the up and down controls, remove a part with its remove control, or add one from the Add a column picker.
  3. Choose Apply.

To fold the record source into the key, tick Add record source when you designate the key on the staging table, or turn on the Shared setting Prepend record source to the business key hash to do it for every key at once.

Some link columns are degenerate: they belong on the link itself rather than in a satellite, for example an order line number on a transactional link.

  1. Open the link’s detail pane (click it).
  2. Under Dependent child columns, tick the columns to carry on the link.
  3. Choose Apply.

Designated columns move onto the link and out of the satellite that would otherwise hold them. Columns that are key parts or reference columns are not eligible.

Convert, delete, re-parent, business-key edits, and dependent-child designations all change the shape the model would otherwise derive from source metadata. DeltaVault records each one as an override so a later acceleration honors your intent instead of resurrecting the derived shape.

How it behaves under re-acceleration:

  • Your edits survive. Re-running acceleration re-reads source metadata but applies your overrides on top, so a converted hub stays a link, a deleted object stays suppressed, a moved satellite stays with its new parent, and an edited business key keeps its parts and their order.
  • Removing an override returns the object to its derived shape. Restore a deleted object, or revert a conversion, and the next acceleration rebuilds it from source as if you had never changed it.

This is what lets you model with confidence: nothing you do by hand is silently undone, and nothing you undo is permanently stuck.

Acceleration and hand modeling both leave faults that are hard to spot on a busy canvas. Run Validate the Data Vault model from the Ask AI panel after accelerating or reshaping a model, and it reviews the whole vault for structural faults:

  • Hub key integrity: every hub declares business keys drawn from real source columns, plus a hash key.
  • Link grain and unit of work: each link relates the hubs that define exactly one unit of work at one grain, with no grain hub missing and none that does not belong.
  • Satellite placement: each satellite hangs off the correct parent, with descriptive columns that belong at that parent’s grain.
  • Orphaned constructs: satellites without a parent, hubs or links nothing references, and stubs that were never completed.
  • Naming discipline: hub, link, and satellite names follow one consistent convention.
  • Source coverage: every construct traces to at least one source table.

The result is a findings report ordered by severity: each finding names the construct, cites the evidence it rests on, states why it is a problem, and sketches what a fix would look like; the report closes with what is sound. It is a report only: the skill reads the model and changes nothing, so run it whenever the model has moved and a fault is still cheap to fix on the diagram.

A satellite that groups one volatile attribute with a dozen stable ones pays for it on every load: each change to the volatile attribute writes a new row that copies the stable values unchanged, bloating the satellite and burying real history. Run Analyze fast-changing attributes from the Ask AI panel to catch those groupings. It reads the measured profiling behind each satellite’s attributes (distinct cardinality, row counts, and null ratios) and flags attributes changing far faster than the group they sit in; where profiling has not run yet, it says so rather than guessing.

You get satellite split recommendations grounded in the measurements: which attributes belong together in a faster-changing satellite, which belong in a slower one, and the numbers that justify each split. It is a report only and changes nothing; carry out a recommendation yourself with Split a satellite above.

Point in time joins are cleanest when every satellite has a matching row for every snapshot date, even where no real row exists. Ghost records (also called zero keys) fill that gap with a system row that carries a zero hash key and sentinel values, so as-of joins stay inner joins instead of falling back to outer joins.

Ghost record handling is an organization-level setting. When it is on, hub, link, and satellite loads emit the ghost row, and point in time and bridge renders coalesce missing matches to the zero key. When it is off, point in time renders fall back to left joins and validation raises a readiness warning recommending that you turn it on.

One nuance to know: the point in time readiness warning reads the organization-level setting, even in a project that overrides the setting for its rendering. If a project overrides ghost record handling, the generated output follows the project override, while the readiness warning still reflects the organization value.

For how ghost records feed as-of joins in practice, see Point in time tables.

A data mart does not have to wait for the vault. In a methodology that models a data mart layer, right-click a Stage table, a Persistent Stage table, or a vault hub, link, or satellite on the workspace canvas and choose Data Mart. On a Stage or Persistent Stage table the menu offers Data Vault and Data Mart side by side: build the vault, seed a mart directly from staging, or both, from the same table.

Choosing Data Mart opens the Model into the data mart dialog. Pick the Shape the object takes, Dimension or Fact, and the Data mart model it joins; starting a new model turns the dialog into New data mart. Confirm, and DeltaVault records the selected object or objects as that model’s source scope, then opens the model’s own canvas so you can continue modeling it directly.