Should source system technical keys be stored in the relevant satellite?
Obviously the hub should contain the business key, but would you also store the technical key as an attribute in the satellite for reference back to the source? I had a look in Patrick’s book and it refers to business keys but not technical keys in SATs (pp196-8)
Yes, technical keys are just attributes so put them in there and you can rebuild the source at any point in time.
Common dv2 practice is to put technical keys in satellite. But If the technical key appears in different dataset and you are forced to join between satellites, it will be very expensive and you will pay the prize with poor query performance. An alternative would be to model the technical key as a hub and stating that it is a part of the source centric part of your DV.
Load the technical key to a separate hub or the same hub?
It depends .
Are you asking about the model or about the physical implementation?
Hey @AHenning! I’m curious about the topic you mentioned regarding dependencies. Currently, I have a business key that is used by our business users. However, the tables in our database are linked using technical keys rather than the business key. I was wondering if you could provide me with some advice on this matter.
Thanks a bunch!
Hello Nghia! Welcome to the forum.
I would create 2 tables for hub Task: Task_id and Task_Code. A link Called Task that references task_id and Task_code. A satellite called invoices referencing task_code. Rts on link task. Rts on task_code(from invoice data). A hub called order, a link called order on task_id and orderid. Sat called order referencing link order. And the same pattern for orderline. are you with me?
I agree with you. Your solution is easily scalable and applicable to various situations.
Here’s my solution:
Do you have any thought?
Looks good but you need rts on hubs and links to be able to pass the jedi test.
@NghiaTT Looking at the question, I was thinking of the same solution that you modeled. i.e. HUB_TASK and same as link to resolve the relationship between Task Id and Task Code.