Non-historized or Sat Dependent Child Key


I need to design for Orders, Order Lines, Shipment. In summary, they all from sales order process.

These table contains main key details such as
Order number
Customer Number
Order Type, Order Date, etc

**Order Line:**
    Order number 
    Order Line Number
    Customer Number 
    Item Number

I am inclined to implement Sat Child Dependent Child key, rather than non-historized as this is good candidate for streaming use case or single business concept - Hub.

In addition to above, should i also create a Link_SALES_ORDER_CUSTOMER_ITEM to connect with Hub_Customer and Hub_Item? Link table ensure unique relationship across hub’s, then what are the implications on the dependent child key - Order Line Number in the exmaple?

Can you please share your thoughts / ideas!

Thank you.

non-historised = streaming / near-real time ingestion; kind of why it was renamed from t-links to emphasize that
link-sat with a dep-key = batch ingestion works best, it’s idempotent

Thanks @patrickcuba . Are you saying create a Link table with link-sat with a dep-key like below?

Dep-Key - Order Line number - should be part of Lnk_HK calculation?

I generally don’t include dep-keys in link-hash calc, because it isn’t a business/primary object. It also means I can reuse that same relationship for other pipelines to load to the same link table and thus have the same link-hash-key.

Order line makes a good dep-key, it needs the order to live!

So this means exclude Order Line from link-hash-key, rather keep order line as dep-key in Sat table, and this process will be idempotent.

Hope I’m following you correctly!

1 Like

Yes, if you execute the load twice the outcome is still the same

1 Like

Thank you so much for your inputs @patrickcuba

1 Like