The scheme developed for the unit uses a recursive structure to avoid fixed hierarchical levels. This allows for a very flexible approach, accommodating simple storage data as well as highly recursive information such as cultivation histories. However, retrieving the data for a particular unit may be considerably complicated by having to step through a recursive structure of undefined depth. This problem is caused by data model itself and must therefore be addressed here.
The application program should always offer the possibility to trace the events that led to the unit's creation, and to look at the parent unit's data. However, the derived unit should be able to stand on its own, i.e. data which refer to both, parent unit and derived unit, should be accessible from the derived unit without having to recurs to the parent unit's data. For field data, this is achieved by the shortcut link to the gathering or field unit. Unit-specific data, and those stored in entities linked to the unit may or may not be copied from the parent to the derived unit (i.e. "inherited" by the latter).
Within the creation event, one of the following procedures applies to every datum of the parent unit:
A revision of all attributes of the unit and of its linked entities shows that the criterion of "biological similarity" (attribute inheritance type similar flag) is most important to decide which of the above procedures must be applied.
To automate the derived unit creation process an entity can be implemented which determines the inheritance procedure for every combination of attribute (or entire entity), inheritance type, and derived unit creation method. This implementation has the advantage of being easily adaptable to varying implementations of the data structure (e.g. different descriptor sets attached to the gathering).