Attempting Data Vault for the first time - How to determine Satellites granularity?

Hi all - I’m attempting to draw up a Data Vault model for the first time using MS Visio. I have almost a decade of experience with star schemas and just finished reading Dan L’s DV 2.0 book however I’m still trying to get my head around the basics of determining what is supposed to go into my Satellites (Hubs appear to be fairly obvious).

I’ve created a very basic example that represents my problem…

The first diagram shows a very simple star schema of a fact table for an insurance claim:
Insurance Claims - Star Schema

The second diagram, shows my attempt at modelling this using a Data Vault approach:


The thing I’m really not sure about is the level of granularity / division best appropriate for the satellite/s. In Dan L’s DV 2.0 book for the airport example, it appears that he’s put virtually every possible attribute into their own Satellite however there’s couple of things about this approach that have me slightly stumped (as per my own diagram):
– Where would $$ amounts and business transactional milestone dates typically go? Especially in regards to my own example. As these aren’t what you’d classify as “attributes” or dimensional objects in a regular star schema; they are transactional.
– In DV 2.0, is there a clear best practice way to model / store attributes vs. transactional values (e.g. business dates, cost amounts / payments)? Are these treated differently?

Any feedback and even draw-ups / diagrams in response would be hugely appreciated (as I’m just trying to get my head around the basics first before going deep into building a large model).

Any value that is not a key, and is not basic metadata, goes into a satellite. This is one of the first things that you have to get your head on when coming from dimensional modelling. Hubs and links are not fact tables and satellites are not dimensions. A dimension table could be built from a hub and a number of sats, and it could also include link / link sats if it is getting complex. A fact table is usually built from one or more links (and maybe more hubs if needed) and their related satellite tables (plus both may have pits or bridges to support query)

You may decide that it is worthwhile splitting the sats out for some logical reason - e.g. you have a sat that contains PII and a sat that doesn’t. The examples you have in your diagram, I would challenge for each are they unique to the claim granularity or do they belong at a lower level (can you have multiple payments to a claim? Can you have multiple line types?) You might need another link / sat / hub / sat combo.