Entities are linked together with associations, one specific association points out how two entities are related to each other. An entity usually has one or more associations defined. Associations can be used to explore connections between entities in the model. Associations can also be used to verify that only values from the associated entity can be stored in the attribute, and that no other values are accepted. Associations are also used to define how to handle delete behavior for an entity and any associations. In IFS Applications there is a system service in the framework that controls the delete behavior following a association, this system service is called Reference_SYS.
An association is a logical connection between two entities. This can be modeled in four ways; Parent Association, Reference, Dependency or Based On. An association in the model can impact on the generated code, views and runtime behavior. Associations are added on the entity definition in the server model. This can be done on the entity text file (*.entity) or in a graphical overview diagram (*.overview). You define the delete behavior on the reference.
There are four different association types that can be used.
A parent association (or aggregate) is modeled between TstOrder and TstOrderLIne and named OrderRef in the example. The TstOrder entity is the Parent or Master and the TstOrderLine is the Child or Detail entity. The child entity will have the same key attributes as the parent plus at least one additional child key attributes. The TstOrder entity has a primary key called OrderNo and that key is inherited to the TstOrderLine entity. The TstOrderlIne is dependent on an existing TstOrder but a TstOrder may exist without a TstOrderLine
A reference or foreign key reference (FK) is modeled between TstOrder and TstCustomer. TstOrder refers to a TstCustomer. The key attributes on TstCustomer are connected to corresponding attributes on TstOrder. In the example we have a Foreign Key reference in the TstOrder entity that points to another entity TstCustomer using the referenced entities Primary key as the Foreign keys. In the example the attributes Company, CustomerNo is the FK and they are pointing to a specific entity row in the TstCustomer entity. By following such references you can fetch information about the TstCustomer to the TstOrder entity.
A dependency is modeled for documentation purposes. It normally has a text connected to it in the model describing what kind of dependency it is. This is added in cases where the software implementation uses another entity but with no reference in the data model. This dependency has no impact on generated code. views or tables.
A based on (or generalization) link is modeled to support inheritance between entities. This can be used when the entities are very similar and share the major part of the attributes. The master entity defines all common attributes and the derived entities adds on specific attributes not applicable for all other entities that derive from the same master entity. All entities will share the same storage which is a union of all attributes, but will get their own Logical Units with separate implementation files.
A view reference is a light weight reference which is added only for the purpose of having a left outer join in base view in between base tables of the current entity & the referencing entity. Contrary to a reference mentioned above, a view reference neither creates a foreign key constraint in between two entities nor any validation checks, which are listed in next section. No record would be added to Reference_SYS system service related to delete behavior.
New or Modify
When saving an entity, reference validation is automatically performed. If the reference attributes are set in the record, a check is performed that the referenced entity exists. When saving a TstOrder and the reference attributes to TstCustomer are set in the record the framework validates that the referenced TstCustomer exists.
When a referenced entity is removed a validation is performed if there are any other entities having references to the entity that is removed. The default behavior is that the validation will throw an Error that the object cannot be removed if it is referenced from other entities. This is called "Restrict" delete behavior. There are 3 more delete behaviors, Cascade, Nocheck and Custom. You define the delete behavior on the reference in the model. The delete behavior is controlled by the system service Reference_SYS.
When you try to remove an instance of an entity that other entities have restricted references to, it will be validated that no occurrences of this instance exists in any of the referencing entities. If it does, an error will be raised saying that you are not allowed to remove this instance. To be able to delete it, you need to remove all occurrences in (restricted) referencing entities first.
Example: An instance of TstCustomer is to be removed but three TstOrder instances are referencing to this TstCustomer instance. An error is raised and TstCustomer cannot be removed. The three TstOrder instances needs to be removed first.
A cascade delete removes all instances of entities that has a cascade reference to the the entity being removed. This is especially common to use for a Parent Association reference, since it is likely that you want to remove the parent you also want to remove the children.
Example: An instance of ProductCatalog is to be removed removed and three Product instances are referencing to this ProductCatalog instance. When cascade delete option is enabled, the Product instances are removed together with the ProductCatalog instance. But, if the TstOrderLine records have Product records and restrict delete behavior is specified on the Association between TstOrderLine and Product, this will raise an error and the whole transaction is rolled back.
Nocheck means that no check will be performed. The record is removed without any check performed. This delete behavior allows a broken reference.
Custom or Customlist
If you have defined a custom behavior you need to implement your own delete method that should be referred to in the reference. The delete method should handle the validation.
Note: When adding references it is good to verify with the Business Systems Analyst (BSA) what delete behavior that should be used to make it possible for the users to remove objects efficiently. At the same time you do not want to have unreachable data left in the database due to missing reference controls.
Read more about Validations.
The reference definitions are stored in Reference Sys tables that are updated when refreshing the Reference Cache. This can be done manually in the Manage Server Caches window in IFS Cloud / Solution Manager.
References that are defined in the wrong way can cause problems in the Application that are not always expected. Since Reference validation checks are performed recursively for each reference throughout the entire reference link tree an error in one place can lead to problems in another part of the application.
In the same way references with restrict delete option, which are defined as a circular reference, leads to objects which should not be possible to delete.