Altova ContractManager

How the App's Data Is Structured

Home Prev Top Next

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.

Click to expand/collapse

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.

 

© 2016-2022 Altova GmbH