Let's assume that OrderItem is a weak entity, with the natural key consisting of the OrderNumber, ProductNumber, and an Ordinal. This is weak, because the OrderNumber and ProductNumber are attributes of Order and Product, instead of being placed directly on OrderItem.
In Anchor Modeling you would model this using three anchors, OrderItem, Order, and Product. Order will have the attribute OrderNumber, Product will have the attribute ProductNumber, and OrderItem will have the attribute Ordinal. Then you need one three-way tie connecting the OrderItem anchor to the Order and Product anchors.
If an OrderItem arrives with a ProductNumber you haven't seen before, you need to choose how to handle it. You can either hold back the row, and wait for the ProductNumber to arrive at a later time, or you could create a bare-bones Product with the new ProductNumber, giving you access to a surrogate for the tie. Then you would need to complete that Product when the rest of the information arrives at a later time. So, it depends on the flow of your data, its reliability, and the business needs.
Finally, in order to determine if you have seen a specific OrderItem before or if it is new, you need access to the natural key. In Anchor Modeling we build
natural key views for every anchor. This view maps the natural key of an entity to the surrogate key of the corresponding anchor. In the case of weak entities, such a view will join to the attribute tables of other anchors. With the example above, the view will join the three anchors, the tie(s), and the attributes that contain the natural key components. The result is a view with the following columns (OrderNumber, ProductNumber, Ordinal, OrderItem_Surrogate_ID), and in the case that any of those columns are historized then also with their changing and recording time.
