Non-historized or Sat Dependent Child Key

Hello,

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
Orders:
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