Previous Topic: Adding Virtual Fields to File-to-file Relations

Next Topic: Creating/Defining Your Data Model

Circularity

This topic addresses how circularity manifests itself and how to avoid virtualizing a field back onto the originating file.

If you can follow the path of relations from a file and end up returning to that file, you have an instance of circularity within the model. This does not necessarily mean that the series of relations is invalid, but that you must check the sequence of relations to ensure that the sequence will allow you to pass the virtual fields that you require. Circularity manifests itself in the disappearance and duplication of virtual fields.

Although the following three relations are acceptable, they can lead to circularity:

Here is an example of a model containing these relations:

Account details Owned by Customer

Account details Has Account opened date

Customer Known by Customer code

Customer Extended by Account details

Customer Has Customer type

Virtualizing against the Owned by relation would allow you to declare Customer type as a virtual field on the Account details file, and you could declare Account opened date as a virtual field on the Customer file over the Extended by relation. The file entries would now look like this:

Account details Customer code Key

Customer type Virtual

Account opened date Attributes

Customer Customer code Key

Account opened date Virtual

Customer type Attributes

If you then resynchronize the model, the virtual entry Account opened date no longer appears on the Customer file. During resynchronization, the relations are expanded into file entries. When expansion occurs, the Account details file relations will be expanded into entries before the Customer relations.

The expansion of relations would occur in this sequence:

  1. Expand the relation, Account details Owned by Customer. The Customer file is still to be expanded, which you must do now before any virtual can be defined.
  2. Expand the relation, Customer Known by Customer code. This results in the key entry Customer code on the Customer file.
  3. Expand the relation, Customer Extended by Account details. The Account details file is not to be expanded, as the expansion started in step 1.

    No entries that exist on Account details can be virtual fields on the Customer file, since the relation, Account details Has Account opened date, has not been expanded.

  4. Expand the relation, Customer Has Customer type. This results in the attribute entry, Customer type, on the Customer file.

    The expansion of Customer has finished, so it returns to Account details.

  5. One entry exists on Customer that can be a virtual field on Account details: Customer type. This results in the field Customer type becoming a virtual entry on the Account details file.
  6. Expand the relation, Account details Has Opened date. This results in the attribute entry, Account opened date, on the Account details file.

Expansion ends here. Two further steps are needed:

  1. The Customer file must be expanded before the Account details file. You could do this by renaming the Customer file so that it comes before Account details alphabetically. This is not always satisfactory or easy. It would be better to add a file to the model that Refers to Customer, and itself has a name alphabetically lower than Account details. For example, a file name beginning with an asterisk (*) would serve this purpose. This file does not need to exist physically, because its sole purpose is to alter the expansion sequence within the model.
  2. The Extended by relationship must be the last relation in the Customer file. You could do this simply by giving the Extended by relation a sequence number.

The model relations would now look like this:

*Force Sequence Refers to Customer

Account details Owned by Customer

Account details Has Account opened date

Customer Known by Customer code

Customer Has Customer type

Customer Extended by 99 Account details

The expansion of relations would happen in this sequence:

  1. Expand the relation, *Force sequence Refers to Customer. The Customer needs to be expanded now before any virtual fields can be defined.
  2. Expand the relation, Customer Known by Customer code. This results in the key entry, Customer code, on the Customer file.
  3. Expand the relation, Customer Has Customer type. This results in the attribute entry, Customer type, on the Customer file.
  4. Expand the relation, Customer Extended by Account details. The Account details file needs to be expanded now before any virtual fields can be defined.
  5. Expand the relation, Account details Owned by Customer. The Customer file expansion started in step 1. One entry exists on Customer that can be virtualized on Account details: Customer type. This results in the virtual entry, Customer type, on the Account details file.
  6. Expand the relation, Account details Has Account opened date. This results in the attribute entry, Account opened date, on the Account details file.

The expansion of Account details has finished, so it returns to *Force sequence. No virtuals will have been specified on the *Force sequence Refers to Customer relation. Expansion ends here.

If you find that virtuals have disappeared due to circularity in your model, you will also find that if you try to put them on again they will appear twice in the file entries. If this happens, repeatedly remove the virtuals until they do not appear in the file entries. Follow the steps above before adding them again.