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.

To talk the model through, type into the Ask AI chat on this canvas: ask about the model or describe a change to the hubs, links, and satellites, and the chat runs the Ask about or change this Data Vault canvas skill, which explains and proposes in Data Vault terms and applies a change only after you confirm. That skill is not listed among the suggested skills; the chat is how you reach it.

Accelerate a source

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.

When you choose Materialize in the header band, DeltaVault builds physical tables for exactly the objects this view covers, including the dashed cards for objects from other tables that something in the view connects to, and leaves every other object in the model as it is. The view toggles change only what you see: a stub hub you have hidden is still built, and a suppressed object is never built, even while it is shown. A relationship you left out (see Get related tables ready) has no stub hub and no link in the model, so nothing is built for it.

When the run finishes you stay on the canvas, so you can keep modeling. A notice at the top of the canvas says how many tables the run built and how many columns it added or removed. Choose Details to list each table, Review and commit to open the pending changes (see Review and commit), or Dismiss to close the notice. A hub, link, or satellite that has no physical table yet shows its name in italic.

Every table your source points at through a foreign key becomes a hub and a link in the Data Vault, so each one needs a business name and a business key, just like the source itself. That is why, when the tables you accelerate point at other tables and any of them is still missing a business name or a business key, the Get related tables ready for the Data Vault dialog opens first, before anything is built. A related table you left out on an earlier run counts too, so one that still needs something brings the dialog back and you can tick it in again. When every row would already show its business name and business key, acceleration skips the dialog and builds the model straight away, and any table you left out before stays left out. When your tables point at no other table, acceleration goes straight to the business name and key steps (see Assign a business name when accelerating).

The dialog lists two groups of rows:

The table you are accelerating (or The tables you are accelerating, when you launched several). These rows are locked in and read Always included.
Tables stage_saleslt_product points at (named for your table, one group for each table you are accelerating): one row for each foreign key, marked with the column it goes through, for example “through productmodelid”. A table reached through two foreign keys, such as a bill-to and a ship-to address, gets a row for each, so you can keep one relationship and leave the other out.

The check looks one hop out: it lists the tables your accelerated tables point at, not the tables those point at in turn. A table that points at yours is checked when you add it.

Each row carries two pills:

The business name pill shows the linked business entity’s name or the table’s business name, or No business name when it has neither.
The business key pill shows, on a related table, the name of its business key column, or No business key. On the table you are accelerating it reads Business key set or No business key, or No key needed when that table is itself a link between other tables and so has no business key of its own.

Some related rows are ticked and cannot be unticked, and each says why:

Already in the model: the relationship is already part of this Data Vault model. The check only adds relationships; it never removes one you already have.
Part of the link: the table you are accelerating is a link between other tables, so the tables it connects are what it is. They all stay in, and each needs a business name and a business key before the run can continue.
Being accelerated too: the table is one you launched in the same run.

Untick a related row to leave that relationship out, and the row spells out what that means for the model: the related table gets no hub and no link from this relationship, and the foreign key column stays in the satellite as a plain descriptive column.

A left-out choice is remembered on the model. The next time the dialog opens for that table, the row appears unticked; tick it and DeltaVault asks for whatever the related table is missing, then builds its hub and link. When the dialog does not open because nothing is missing, your choice stands; to bring that table in, add it from the Add related tables panel (see Add related tables). Reset to default keeps your left-out choices (see Override durability).

The button on the right reads Continue when a ticked table is still missing a business name or a business key, and Accelerate when nothing is missing. Continue walks you through what is missing, one table at a time (see Assign a business name when accelerating below). Cancel acceleration builds nothing and closes the Data Vault view.

A hub usually has neighbors: 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 looks one reference hop out from the tables in this session (the table you launched from and every table you have added since), so each table you add surfaces the next set of candidates automatically. Editors only; the panel is hidden for viewers.

Adding a table this way, or through Add tables, runs the same Get related tables ready for the Data Vault check for the table you add (skipped, as above, when nothing is missing), followed by the same business name and key steps. Here the buttons read Add table (or Continue, when something is missing) and Cancel. Cancel adds nothing more and leaves the model open; when you came from Add tables, its picker opens again with the cancelled table and any still waiting ticked, so you can decide again, while tables added earlier in the same batch stay in. If you left a table out on an earlier run, adding it clears that choice and brings its links into the model.

Assign a business name when accelerating

When you accelerate a source table, DeltaVault first makes sure every table that will shape a hub or a link has a business name, so the generated hubs, links, and satellites are named for what the data means, not for the physical table. After the related tables check (or straight away, when your tables point at no other table), it walks the tables that still need something, one table at a time: the tables you are accelerating first, then each related table you kept ticked, in the check’s order. For each table it asks for the business name if the table has none, then for the business key if it has none (see The accelerate gate). When more than one table needs something, the dialogs count your progress (Table 1 of 3, and so on).

A table with no linked business entity and no business name opens the Assign a business name dialog:

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. On a related table, the dialog also says which table points at it and through which column.

Below the two fields, the Name from source table card offers a name: it walks back through the tables DeltaVault built this one from to the source table and suggests that table’s name, formatted with your entity naming convention, in a field you can edit. Use as business name fills the Business name field. Create entity and select creates a business entity with that name straight away and selects it; when an entity with that name already exists, the button reads Select existing entity and selects it instead of creating a duplicate. The card only fills the dialog: the table is named or linked when you choose Apply, although an entity the card created stays in your business model either way. Once an entity is selected, the card folds to one line. Table details covers the card in full.

The table you are accelerating cannot be skipped. Its dialog’s other button is Cancel acceleration (or Cancel, when you are adding a table from Add related tables or Add tables), and it builds nothing; business names and keys you already saved in earlier steps stay on their tables. A related table can be left out instead: its dialog offers Leave out, which drops that table’s remaining steps and leaves out every relationship to it. Once the rest of the walk is done, the check opens again with that table unticked, so you see exactly what will be built before anything is. A related table that the table you are accelerating needs as part of a link cannot be left out, so its dialog offers Cancel acceleration (or Cancel) instead.

Because every name is resolved before the model is generated, the hubs, links, and satellites come out with business-meaningful names through your configured naming conventions. Each related table’s hub is named from that table’s own business name, and the link to it is named from the table that points at it and the foreign key column.

Apply it across the ingest chain

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 source, landing, staging, and persistent-staging tables in the same chain, and lists every one of them 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 just named, whether it is a table you are accelerating or a related table.

Split a satellite

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 menu shows the item only while 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.

To undo a split, right-click the split satellite and choose Merge Into Satellite, then pick the satellite to fold it into under Merge into and choose Merge. Every column moves onto the satellite you pick, in source-table order, and the satellite you started from is removed; the one you pick keeps its name and settings. A split does not remember where it came from, so the picker offers every satellite the columns could go back to: the other satellites on the same hub or link, of the same kind and variant. The item appears only when at least one such satellite exists.

Arrange the model

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.

Auto layout

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.

Read the keys on each node

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.

Inspect an object or column

Click any node to select it and open its panel on the right side of the canvas; Shift-click adds a node to the selection without moving the panel. The panel’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. The panel’s toolbar is the one every detail panel shares, with one difference: a Data Vault object’s panel has no More actions, and its operations are on the node’s right-click menu. One Save in the header saves every section you changed (Variant, Driving key, Derived from, Business key, Dependent child columns) in one step, and Discard changes puts them all back. Close and Pop out ask the Unsaved changes question first while the panel holds an edit.

Remodeling operations

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 panel 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).

Convert a table between hub and link

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

Right-click the node and choose Convert to Hub (on a link) or Convert to Link (on a hub).
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.
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.

Delete and restore objects

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.

Right-click the node and choose Delete.
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.
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 panel. 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.

Re-parent a satellite

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.

Right-click the satellite and choose Move to Parent.
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.
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.

Satellite variants

A satellite’s variant controls how it tracks change. Open the satellite’s panel (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 select Save in the panel’s header. One Save saves every section you changed, so you can adjust several sections and save them together.

Driving keys on links

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.

Open the link’s panel (click it).
Under Driving key, tick the hub references that drive the relationship.
Select Save in the panel’s header.

Reset to inferred under Driving key waits while the section holds an unsaved edit, with “Save your driving key edits first.”

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

Edit a hub’s business key

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:

Open the hub’s panel (click it).
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.
Select Save in the panel’s header.

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.

Dependent child columns on links

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.

Open the link’s panel (click it).
Under Dependent child columns, tick the columns to carry on the link.
Select Save in the panel’s header.

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.

Override durability

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.

A related table you left out (see Get related tables ready) is remembered on the model too, and more firmly than your other edits. Reset to default, in the More actions menu of the History panel that Show history opens, clears your overrides and re-accelerates the model from its source tables once you confirm, but it keeps your left-out choices, just as it keeps which tables are in the model. Choosing Restore on an earlier entry in the same panel returns the model to its state just before that entry’s change, and the left-out choices return with it.

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

Validate the Data Vault model

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.

Find fast-changing satellite attributes

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 Find satellite attributes that change too often 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.

Ghost records

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.

Create a data mart

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.