Business key column

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.

A Data Vault hub keys on a business key: the value that identifies each real-world thing, independent of any warehouse surrogate. In DeltaVault a staging table carries a single designated business-key column (at most one per table), and the accelerator keys the hub on that column. This guide covers what a designation is, how to set one on a table’s Details tab, how to build a derived key from several columns with transforms and macros, the accelerate gate that makes sure every hub-shaped table has one (the tables your source points at included), and how links reuse the same definition on the far end.

What a business key designation is

A designation names the single column a staging table is keyed on. It is one of two things:

A plain column already on the table, when one column identifies the row on its own (for example a customer number).
A derived column that DeltaVault builds at the Staging layer by joining several columns together, when the key spans more than one column. A customer might be unique only by customer number within a region, or an order line only by order number plus line number.

Either way, the result is one column. Downstream, the hub keys on that one value rather than on the separate parts, and a link that references the table reuses the same definition (see How links reuse the definition below).

A designation lives on Stage tables, on tables in the Data Vault and data mart layers, and on designer-built views stored in the staging, persistent staging, Data Vault, or data mart layer. You will not see the Business key section on a source or landing table.

Designate a key

Open the table and go to its Details tab. The Keys section shows the table’s Primary key and, on a staging table, a Business key below it. When nothing is set yet, the Business key reads No business key designated.

Choose Add beside Business key (the button reads Edit once a key already exists).
The Add a business key dialog opens with a two-way mode toggle:
- Use existing picks one Column from the table. Choose the column that identifies each row.
- Derive composes several columns into one new column (covered under Build a derived key with transforms and macros below).
To key on the table’s own primary key, choose Use primary key. A single primary-key column fills the existing-column mode; a multi-column primary key switches to the derived mode with those columns already in order.
Read the Preview. It shows the exact concatenation and the full hash expression the staging generator will build, so what you see is what gets deployed, not an approximation. It updates as you change the key.
Choose Save.

The designated column, and its hash expression, then show in the Business key section on the Details tab.

Build a derived key with transforms and macros

Switch the dialog to Derive when one column is not enough. The derived mode gives you:

A Separator placed between the joined values (for example ||). It seeds from your organization default and is always stored on the designation, so the built column stays stable even if that default changes later.
A Column name for the new column. It seeds from your naming pattern (a key named Customer becomes a column such as Customer_BK). Once the derived column exists, its name is fixed.
A Columns checklist of every column on the table. Check a column to add it to the key; it lands at the end of the order.
An Order list of the columns you checked. Drag a row by its handle, or use the up and down buttons, to set the sequence the columns join in. Order matters, because it fixes the value the hub keys on.
An Add record source checkbox that folds the record source into the key.

Where a constituent column carries a transform (a cast, a trim, a macro call), the dialog shows it as a small badge next to the column, so you can see at a glance that the value is shaped before it is joined. Macros inside a transform expand when the Staging column is built, the same as anywhere else in the pipeline.

One habit pays off later: write per-constituent transforms in the {{this}} relative form rather than hardcoding a column name. {{this}} stands for whichever column the transform is applied to, so when a link reuses the definition on a child table, the expression re-targets onto the child’s own columns instead of the parent’s. A validation advisory, Business key constituent transform hardcodes its own column name, flags any constituent that names its own column literally and points you to the relative form.

The accelerate gate

Because a hub cannot key on nothing, DeltaVault makes sure every hub-shaped table has a designation before it builds the model. That includes the tables your source points at through foreign keys, because each of them becomes a hub and a link too. When you accelerate a source into a Data Vault, the gate asks for each table’s business key right after that table’s business name, one table at a time, and before the model is generated (see Assign a business name when accelerating):

The gate visits the staging table that will feed each hub you are accelerating, then each related table you kept ticked in the Get related tables ready for the Data Vault check, and opens the same Add a business key dialog on each one that has no designation. When more than one table needs something, the dialog header counts your progress (Table 1 of 3, and so on).
On a related table, the dialog also says which table points at it and through which column, and that its hub and the link to it are keyed on this.
The table you are accelerating has no skip. Its key step is mandatory: Cancel acceleration aborts the whole run and leaves the model untouched, although business names and keys you already saved in earlier steps stay on their tables. When you are adding a table from Add related tables or Add tables, the button reads Cancel instead, and canceling leaves that table out of the model.
A related table can be left out. Its dialog offers Leave out, and closing the dialog does the same: that table gets no hub and no link, and the foreign key column that points at it stays in the satellite as a plain column. Once the rest of the walk is done, the check opens again with the table unticked, before anything is built.
A table you accelerate that is itself a link between other tables needs no business key of its own (the check shows No key needed), but every table it connects needs one, and none of them can be left out.
If a launched source has no Stage-type table in its ingest chain, the run is blocked with No staging table found, naming the source: create the staging table or view first, then run Data Vault again.

Once you save a designation for every gated table, acceleration proceeds and each hub keys on the column you designated.

External callers, such as an import or an API-driven acceleration, are held to the same rule: a hub-shaping staging table with no designation is rejected rather than accelerated on a missing key, and so is a request that keeps a related table with no business name or no business key, naming both tables.

How links reuse the definition

A link connects hubs, and its own staging table has to produce the same key values the hubs were built on, or the joins will not line up. Rather than re-key by hand, DeltaVault re-instantiates the parent’s key expression on the far end: for a child table that references a designated parent, it rebuilds the parent’s composed key definition, in the parent’s order and with the parent’s separator and transforms, over the child’s aligned foreign-key columns. The child value then matches the parent key exactly.

The designate dialog checks this alignment while you edit and tells you where it stands:

All referencing links align with this key confirms every child that references the table can line its columns up with your definition.
A warning lists any child that cannot: it cannot align the named constituents (the child has no column that maps to them), or two or more key constituents map to the same column (an ambiguous mapping). It closes with a reminder that links referencing this table will fail to build until their foreign key columns align.

Alignment is enforced at build time, not papered over. If a link’s foreign-key columns cannot be re-instantiated against the parent’s key, the build fails loudly rather than emitting a link keyed on a value that would never join. To repair it, open the child table and make its foreign-key columns align, by mapping the reference columns or renaming so each parent constituent has a match, then rebuild. Writing the parent’s transforms in the {{this}} relative form (above) is what lets the expression re-target cleanly onto the child’s columns.

What renders

At the Staging layer, a derived designation materialises as a real column: each constituent’s transform applied (macros expanded at build time), the values joined in your saved order with the stored separator. A plain-column designation adds nothing; the existing column is the key. Either way, the staging hash key is built over exactly that one column, so the hub keys on the composed value rather than the separate parts. For a table that feeds a link, the far end renders the parent’s composed expression over its own aligned foreign-key columns, producing hash values that join the hub’s exactly.