Altova ContractManager

Data about contracts is stored in multiple containers, each of which represents one component of contract information. These containers can be organized in a hierarchy. For example, your ContractManager app might have a simple hierarchy that contains two databases named Contract Database and Company Database, as shown below:

Contract Database

|

|--Contract

|

Company Database

|

|--Company

|  |

|  |--Department

|  |  |

|  |  |--Person

Records and fields

In each container, you will enter records. Each record is defined by a number of fields (which are specific to that container). When you enter a record, what you will be doing is entering values for these fields. You can visualize a container as follows:

So when you enter data in the ContractManager app, you will be entering records for the different containers of the app. For example, you could add new company records, or department records, or person records, or contract records. In this way you build up the data in your ContractManager database.

Identity fields

In each container, one or more fields will have been configured (by your system administrator) to be Identity Fields. These fields will uniquely identify records. For example, employees will typically have unique ID numbers, so the ID number field can be used to identify records in the Person container. In the case of some containers, more than one field might be necessary to come closer to uniqueness (for example, a persons's Name and Date of Birth fields).

Linking records across containers

During database configuration, your system administrator/s will have built links across the containers. For example, a parent–child link might have been created between company and department, and another parent–child link between department and person. In this case, when you enter a new record for a child container, one of the field values you would need to add would be for the parent of this (child) record. For example, when adding a new department record (say for a Legal department), you will be prompted for this department's company parent (where you could enter, say, a company named Altova). By selecting the parent Altova, you have established a link between this Legal department and the company Altova. In this record, then, you are effectively describing the legal department of Altova.

In a similar way, your system administrator/s could have built links between containers that are not directly linked in a vertical hierarchy. For example, a link could have been created between a contract and the contracted company. There is no direct hierarchical connection between the Contract container and the Company container. But if an explicit link is configured between the two, then, while entering, say, the contract data, you will be asked to enter the name of the contracted company. Doing so links the current contract not only with the selected company, but also to that company's (hierarchically descendant) departments and persons.

So, although you are entering data record-by-record for different containers, the ContractManager app is building a network of connections across records in different containers. This networked nature of the data enables you to generate reports and charts about your contracts, contract dates, and the companies and people involved.