Altova RecordsManager

Data is stored in multiple data tables, each of which represents one component of information. These data tables can be organized in a hierarchy. For example, your RecordsManager 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 data table, you will enter records. Each record is defined by a number of fields (which are specific to that data table). When you enter a record, what you will be doing is entering values for these fields. You can visualize a data table as follows:

So when you enter data in the RecordsManager app, you will be entering records for the different data tables 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 the RecordsManager database.

Identity fields

In each data table, 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 would typically have unique ID numbers, so the ID number field can be used to identify records in the Person data table. In the case of some data tables, 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 data tables

During database configuration, your system administrator/s will have built links across the data tables. 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 a new record is entered for a child data table, one of the field values you would need to add would be a value for the parent of this (child) record. For example, when adding a new department record (say the record is 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, system administrator/s can build links between data tables that are not directly linked in a vertical hierarchy. For example, a link could be created between a contract record and the contracted company. There is no direct hierarchical connection between the Contract data table and the Company data table. But if a link has been explicitly configured between the two by a system administrator, then, while entering the contract data, users 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 users are entering data record-by-record for different data tables, the RecordsManager app is building a network of connections across records in different data tables. This networked nature of the data enables you to generate reports and charts about your data in multiple data tables—even if these data tables are not linked hierarchically. For example, a database can contain data tables for contracts, companies, departments, and people, and build connections between them through a network of links.