Hi Matt,
It depends on whether you consider a Benefit Plan to be a business concept?
If yes, then HUB for Payor, HUB for Benefit Plan, a LINK to show the relationship between the two, and if you want to split your attribute information because of the dependency you can have a HUB_SAT for Benefit plan which holds the information about the Plan that is specific to the plan itself regardless of the relationship, and then a LINK_SAT for the attribute information that is solely based on the relationship between Payor and Benefit Plan.
Alternatively, if Benefit Plan is not a business concept, then the Benefit Plan ID (or whatever your unique identifier is) can be considered a dependent child. From previous posts on this Forum there are a number of considerations regarding this:
- Should the dependent child exist in the LINK (Payor to something else), or, should the dependent child exist in the LINK_SAT
- If chosen to exist in the LINK, then should the dependent child be included in the LINK_HASHKEY generation?
In my opinion, it depends on your situation and what you can get from Source. What is your grain, does Source provide deletions or do you have to infer this, do you need peripheral tables such as Status Tracking Satellite or Status Effectivity Satellite.
If you search for ‘Dependent Child’ on the Forum you’ll find numerous related previous posts. Below are a couple of discussions which relate to the questions above:
Good Luck.
Carl