Heurist Help

Manage | Structure

A database structure (schema definition) comprises the following key building blocks:

• Record types. The entities or research objects you wish to capture. For example: Article. You need to specify and define a record type for each entity that comprises your data
• Field types. The attributes that describe the information or data that can be stored in any record of that type. For example, Title, Author, Year, Journal, Volume etc.

You can quickly get started building your database structure by choosing from the extensive base of predefined record and fields types that cover a wide range of typical data requirements: constrained or free text, numeric, date, y/n, enumerated lists, geographic objects etc. You can acquire additional record types by importing them from an existing database (see Import Templates).

You can update the database structure to suit your research needs, as follows:

• Hide or remove existing records types (unless locked).
• Update any record type: add existing base field types and position them in the record and remove unneeded field types.
• Create and add new field types. If a suitable predefined field type does not exist, you can create a new one based on the core set of underlying data types (see Define Field Type) and reuse this across the database or other databases.

• Replace generic field type names with specific names appropriate to your database.

• Update record type and field type properties with more relevant details: name, description, context help etc.
• Edit title masks. Composite titles for a record can be constructed from field values (e.g. Author-Year-Title). (See Define Record Type | Constructing a Title Mask.)

About modifying your database structure

You are recommended to re-use generic field types (e.g. Name, Title, Thumbnail Image, Short Summary etc.) and to reuse the same generic field type for similar purposes in different record types. This reduces complexity since you are using one field definition for several record types in place of one for each. It also promotes equivalence between similar fields in different record types. For example, the title of a book, a chapter, a journal article or a painting all use the same field definition and are used as a main component of the record constructed title. Similarly, thumbnail images, short textual summaries, geographic locations, attached files, URLs and dates typically use the same field definition for which special handling has been developed (e.g. the display of thumbnails in record views). Even if you do need to create a new field definition, try as far as possible to reuse this between record types, for the same reasons as above.

If you decide to change your data model later you can update the record/field types, without having to rebuild the database or re-enter data. In this way the database can grow as your research progresses. Changing database definitions does not invalidate existing data.

If you have already populated your database, you need to be careful about the changes you make to your record structures:

• Data will be carried across into the updated record structure as long as the existing set of fields in the record structure is maintained. That is, if you include the same set of fields in the new record structure as were in the original record structure, then the data will be maintained.
• If you remove a field, then data will be lost for that field.
• If you remove a field type property, then data will be lost for that field type property.
• You cannot update (in most cases) field type data types. In other words, you cannot change a date field to a text field.

Suggested workflow for defining your database structure

Created with the Personal Edition of HelpNDoc: Produce electronic books easily