Situation 2: association to non-root table using foreign key.

Relationship between root and non-root tables - situation 2:

The address is a typical ‘associated non-root table’ case. Compared to the previous situation, the relationship direction has changed: the root table refers to the non-root table.

Note: According to this model, a one-to-many relationship exists between the tables. A single Address row can in theory be used in multiple Orders. However, if the Address is modeled as a non-root table, it will be regarded as an aggregated object. That is: for each order that requires an address, a new address row is generated, and that address is changed or deleted if the order is changed or deleted. Addresses won’t be reused.

The BII must make sure that addresses are not reused. If the data can also be changed inside LN, the application must also make sure that addresses are not reused. Otherwise unpredictable results will occur. For example, if an address will be linked to multiple orders, if the Change method is used to change the address for order 1, the address for order 2 will accidentally be changed as well.

If you don’t want the Address to be created, changed and deleted automatically with the Order, do not model the Address as a non-root table. Instead, model it as an associated business object, and/or handle the address-related attributes in hooks.