Aside

The following picture shows a situation without a relation between root and non-root table. This situation is not possible, because we will never be able to determine which non-root row belongs to the root row.

Relationship between root and non-root tables - prohibited scenario:

This situation is unsupported, because although no reference needs to be defined in the data model, a join relationship must always be defined in the BII. If multiple tables are linked to a component without such a relationship being defined, then the implementation will not work for either List/Show or Change/Delete methods. For example, a List/Show query will result in the so-called Cartesian product, containing duplicate order numbers, because every task row is joined to every order row. And when changing the date attribute, we won’t be able to find the row in the Task table if no join is specified.

For example, when first creating an Order having orderNumber 1 and taskNumber 100, and then creating an Order having orderNumber 2 and taskNumber 200, the database will contain:

Order	Task
1	100
2	200

But since the relationship is undefined, a List will result in four instances (Cartesian product). We don’t know whether task 100 or task 200 is related to order 1. And when changing the date attribute for order 1, we don’t know what task row to change.