Sharing Hubs with different BKs but the same business object

Data Vault 2.0
1

I have multiple different source types. All have transactions, some have unique TXN_IDs, some have composite BKs of varying multiple attributes. This is due to the quality of the data received from the vendors. Some actually have txn_IDs and they just are not in the extract, some don’t and you have no other option but a composite BK.

In any case, all are the exact same business object, but their BKs don’t match. So do I

  1. have to create a Hub for each set of transactions (that would make for 14 transaction hubs)
  2. Have a single composite Hub that sometimes has nulls in some of the BKs?
  3. Use ACCOUNT_ID, POSTING_DATE, and SEQUENCE_NUMBER as the BKs and ignoring the TXN_ID so they all share BKs

Actual ex:
System1: TXN_ID
System2: ACCOUNT_ID, POSTING_DATE, SEQUENCE_NUMBER

Bonus: One of my systems has no TXN_ID and no sequence number, meaning there are actual transactions that look like dupes but aren’t. Is it breaking the law to create the SEQUENCE_ID?

2
  1. No
  2. No null business keys — you need to resolve what this is
  3. No, dates are never included as a business key – account_id looks like a good candidate, sequence number and posting date look like dependent-child keys in their respective satellite tables.

Each txn table is a raw vault satellite — resolution of bk (account_id) should happen either at the source, or using a same-as-link or pre-staging

3

Thanks for the reply Patrick!

I haven’t seen any description of a lone satellite for holding transactions. What is it a satellite of? Is there a name for this kind of satellite? I assume it has no hdiff as it never changes?

When you have a transaction without a transactionID, you need posting date to identify the unique transaction. How is it dependent if the transaction isn’t an entity at all if it cannot be uniquely identified and this is required to do so?

1 Like
4

Not at all a new satellite and you need to keep the hash diff

See here

5

it’s always unique, you need to find out what that is else ask the source to make it unique.
Dates can be dependent-child keys too — aka intra-day keys