How the App's Data Is Structured
ContractManager's data structure is described below in terms of hierarchy and the relationships between data components.
Hierarchy
You can customize ContractManager's data structure according to your requirements. The allowed structure is as follows:
•At the root level of the app, you can create as many databases as you like. For example, in the structure shown in the screenshot below, there are two databases: (i) Contract Database, (ii) Company Database.
•Within each database, you can add as many top-level containers as you like. In our example database, Contract Database has one top-level container (Contract), whereas Company Database has two top-level containers (Company Group and Company).
•Within a top-level container (as well as lower level containers), you can add multiple child containers. You can continue adding child containers down multiple levels. For example, the Company container has a child container named Department, which in turn has a child container named Person.
The containers are linked together in relationships, which are described below.
Your user's contract data will be stored as the records of containers. Each container is defined by a set of fields, in which the data of records is stored. See the next topic, How Data Is Stored, for an explanation of this.
Relationships
When defining the database structure, you will be building relationships between containers. These relationships will be of importance to the hierarchy and organization of your data, and should therefore be planned well.
There are two types of relationships that can be built between containers:
•Parent–child relationships
•Loose links
Parent–child relationships
These links between containers are considered to be strong links since a child is created from a parent and cannot be created without the parent. A parent container can have multiple child containers. A child, however, can have only one parent container. The following consequences of the parent–child relationship should be noted:
•When a parent record is deleted, all child records are also deleted
•When designing forms, the fields of all ancestor containers will be available for inclusion
•Interdependencies of fields within a hierarchy of strong links are managed automatically
•Child records can be edited within parent forms
Loose links
A second type of relationship is a link that is created between two independent containers. These loose links enable records to be created independently and without reference to each other. The links are manually created during configuration. A single record can thus have multiple loose links to other records. If one record of a loosely linked pair is deleted, the other record is not affected.
Loose links can be set in the following ways:
•Define the field of a container to be of type Link To. This field provides the anchor of the link to the other container.
•Child containers can have the strong relationship to their respective parents converted to a loose link.
Also see the next topic, How Data Is Stored.