Relationships are used to relate two entities to each other. One entity in a relationship will inherit elements from the other. The type of relationship will dictate the nature of this inheritance and how the entities are implemented in the LANSA Repository.
Relationships influence the file fields, file keys, logical files, referential integrity validation rules and access routes that are generated when an entity is built.
The different types of relationship available in the Logical Modeler are:
For more details, refer to 7. Relationships.
One entity is said to be the Parent of another if the data of the Child entity belongs to (is contained within) the Parent.
For example, an Ordered Product cannot exist on its own. The Ordered Product must have a parent, Order, before it can exist.
The identifying elements of the Parent entity are inherited by the Child entity. These elements are often called Parent Keys or Foreign Keys. They become the file's primary key when the entity is physically implemented in the LANSA Repository.
One entity is said to be joined (or to refer) to another if a data (that is, non-key) element or group of elements from the first entity can be used to access an occurrence in the second entity.
The Join relationship differs from the Parent/Child relationship in that the element(s) used to access the referenced entity are not necessary to identify the primary (or referencing) entity. However, they are still inherited to become Foreign Keys.
For example, an Order is placed by a Customer. The Order is identified by its Order Number. Order will look up a Customer Code in the Customer entity. Hence, the Order file will contain the Customer Code element when it is physically implemented in the LANSA Repository.
The Include relationship allows elements from one entity to exist in many different entities. However, unlike a Parent/Child and Join relationships, no foreign keys result. The elements become part of the entity.
For example, a conceptual entity called Address is created with attributes of Street, State, City, Country and Post Code. This entity has no identifying element. The Address entity could be included into a Customer entity or Supplier entity. The Address elements will become part of the Customer and Supplier files when they are physically implemented in the LANSA Repository.
This type of relationship can be used between a Data or External entity and a Variant entity where the Data or External entity is the source or the relationship and the Variant entity is the target.
As such, the Target entity inherits the Source entity's identifying elements. These elements become the Target entity's primary key when it is physically implemented in the LANSA Repository. The Variant entity can not have an identify element of its own.