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, 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. When you accelerate a source into a Data Vault, the gate runs right after the business-name prompts and before the model is generated:

For each staging table that will feed a hub, the gate opens the same Add a business key dialog on that table. The dialog header counts your progress (Table 1 of 2, and so on).
The gate is mandatory. There is no skip. Cancel acceleration aborts the whole run and leaves the model untouched.
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.

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.