Attribute in Satelite tables vs plain Link tables


we are pretty new to data vault and currently doing some first steps.

A question that came up was about if there are any best practices when it comes to Sat-Links

When I have lets say a transaction hub and an employee Hub and link them with a Transaction_2_Employee Link table I have an additional field percentage in my source table.
Would I now put this into a seperate SAT table or include directly into the Link.

In this case the percentage is the only additional data in my source, but there might be cases with two or three fields

Any advise?


What would you say they are?

What’s in a transaction hub?

I think he means there are 2 hubs: Transaction and Employee

Not sure, maybe: if only one, then put it in the Link

In the transaction Hub I have executed orders (revenues in the Sat)
I then have employees involved in the transaction. There is then the LNK from Transaction Hub to Employee Hub.
Each employee is involved in the transaction by a certain percentage. So now the question: Where to store the perecentage

Clear so far?

Is a transaction a business object or is it recording a relationship between business objects?

In this context, the transaction is a business objects. The Hub has the transaction number as key and the satelite some details (like amounts, currencies, a comment, some flags)
The other hub is the sales person involved in the transaction

and the link assigns one or more salesperson(s) to one transaction. And to be able to sum up measures correctly later in the infor mart, I have an involvement percentage - this is what I wanted to save as attribute either in the Link-Satellite or directly in the Link

A txn is not a business object mate, Business Capabilities are based on one or more business objects, transactions record the interactions between business objects.

I normally would agree, but the situation is special

The main data source is a transaction information system which collects data about transactions. A lot of attributes, comments, flags and so on. This data is not static and changes over time. The transaction number is the main identifier in the system and well known tongue users. In this context I would see the transaction as dimension.

Yes… transactions between business objects, what are they? Accounts, Customers, Products… how does the transaction number relate to the customers/accounts you care about?

Txn would not be a dimension either — it would likely populate a fact table, eventually.

I see your point, but I do have an additional layer coming from the source for bookings.
A transaction ( or let it name deal) is linked du a customer, a product and a salesperson and some additional data about the deal. There can be up to n bookings related to one deal
A booking has a date, a status, an execution person, a portfolio and some facts
The bookings I modelled as Link table between deal hub, person hub and a portfolio hub
The deal is now the topic.

In the final information layer I will combine deal and booking table into one fact table only