Connect Data

A powerful feature of Heurist is the ability to relate or link records together to connect your data in a meaningful way without the complexity one might be familiar with in relational systems.

Relationships are immediately available between ANY record types, without any further work, but these can also be constrained through a constraints menu so that only particular relationship types are allowed between particular pairs of record types, and this also allows constraint of the number of relationships allowed (e.g. one can only have two parents or a specimen bag can only belong to one context).

However we also have two powerful methods for embedding connections directly in the records so that they appear contextualised in the data entry form: Record Pointers & Relationship Markers.

Record Pointer

A record pointer is a field within a record that defines or references a one-way link to one or more specific record types. You define pointers between data when you create the database structure. The type of a pointer can be constrained so you can only select a record of a particular type (or types).

Similar to term lists, pointers allow a field to be populated from a controlled list, but in this case the list is all records in the database of a particular type, or types. This effectively ‘embeds’ all the information from the chosen record in your current record (but it is only stored once, however often it is ‘embedded’).

Typically, record pointers are used when there is a specific known relationship. For example, to identify people (authors, owners, actors, ..), multimedia items (pdf, images, video), events, places, organisations etc. with specific relationships to a record.

Record pointers can define relationships between heterogeneous records (e.g. event with person, building with date etc.).

For example, imagine a record about a chapter in an edited book. It has one or more authors and it belongs to a book. But it may share the author(s) with many other books, book chapters, articles and so forth, and the book with a dozen or so other chapters, each with different authors.

Rather than entering the author(s) as text fields and repeating this information for every chapter in the book, you can create records for each of these Author entities and link them into the record for the chapter.

The field definition would look something like this:


The record in User View would look something like this:


You can then use the Author(s) field (which in this cases is a repeatable field) to select exciting authors in the database, or if they do not already exist, create them.

In the same way you can create book records, series records, publisher records and so forth, and simply point to these records instead of re-entering the data.

Using pointers saves typing, reduces data entry errors, and ensures a continuous connection between records that share the same source material (e.g. authors, books, publishers etc.).

Relationship Marker

A relationship marker is a record that defines a two-way link between two records that you wish to connect.

Relationship markers allow connections to be established between any two types of entity, but also allow the type of connection to be recorded via a separate relationship record. What the relationship marker does is build in the relationship to the databases structure and prompts the user as they build their database. It provides structure as to what relationships the user can build.

Note. Relationship pointers differ from relationship markers in that they create a direct one-to-one link between records, without an intermediate relationship record, which in some instances may be the preferable solution. (See ‘When to use a pointer and when a relationship?’ below).

The relationship marker is implemented as a separate record that links two records together, regardless of type. All relationship details are stored in the relationship record itself, which has two fields that point to the source record and the target record of the relationship.

The relationship marker field is embedded directly in the data entry form – it does not actually contain any data itself, instead it acts as a marker (or prompt) to the user to create a new relationship record (‘show this type of relationship at this point in the form’).

Relationship markers may be further constrained to specific record types and a limited set of relationship types appropriate to that point in the form; the constraints restrict the term list (of relationships available) and the target record types.

Relationship markers are useful in recording connections that are less standardised. For instance, have lots of different options (such as stratigraphic relationships or family relationships by birth) or have a time-limited component (such as museum loans or personal relationships by marriage or association) or otherwise require additional information (such as assignments of connections which require interpretation and explanation).

For example, the relationship Jack (Person record) is brother of (Relationship type) Jill (Person record type) is stored in the relationship record like this:

Jack (Person record record) isBrotherOf (Relationship Type) Jill (Person record type).


This relationship is stored in the relationship record like this:


You can also create a (unconstrained) relationship record via the Relationship Tab

Pointer or Relationship?

Relationship Marker Advantages

The main advantage to using relationship markers.

  • Relationships details are stored in the intermediate relationship record, which are implemented as a standard Heurist record type, inheriting all the characteristics of a Heurist record and searchable/editable like any other record. This provides greater control over the relationship usage. (e.g. specifying the type of relationship, title, date range, label, annotations, tags, notes, visibility and access, even a geographic location). This can be extremely useful with historical data in order to represent differing views or to tag a set of relationships in order to present a cluster of events in a timeline.
  • They can link any two records, regardless of type; no prior knowledge or specialise programming is needed. With this simple function, Heurist provides much of the power of many-to-many relationships in a conventional database, with a fraction of the effort (with relational databases a separate linkage table, and programming, is generally required for every pair of record types to be linked). Users can create relationships on-the-fly between any two records.
  • They include, by default, fields for relationship type (required) and time-period (optional) over which the relationship applies (many real-world relationships have a limited duration).
  • The relationship marker builds the relationship directly into the databases structure and prompts the user as they build their database. It enforces structure as to what relationships the user can build.
  • Relationships can be constrained in different ways to ensure that only valid relationships can be created (for example, a building cannot be ‘FatherOf’ a person. This provides a lot of flexibility to build controlled networks of relationships between entities. Note: There is no reason why two records cannot have several relationships, which may reflect alternative views on the relationships between the records, or relationships which have different time periods. For instance, scholars may disagree on the start and end dates of a relationship or a person may be employed by the same institution on more than one occasion.

The primary difference (as shown in the diagram opposite) between a record pointer and a relationship marker is that in the first instance the relationship details are stored in the record whereas in the second instance the relationship details are stored in the intermediate relationship record, which gives you more control over the relationship (e.g. specifying the type of relationship, date range, label, annotations etc.).

The simple rule is, if you simply need to identify a fixed type of relationship, such as an incontrovertible whole-part or a specific function such as Excavator, use a Pointer field. If you want greater richness, such as specifying an open-ended list of roles, e.g. for a film Director, Producer, Gaffer, Actor, Cinematographer, etc. and to enrich those roles with temporal limits, annotation and so forth, then use a Relationship Marker field.


When to use record pointers

  • Where some entity (e.g. an author), is referenced by many records. The data about that entity (name, title, date of birth, location, roles etc.) can be entered once into the record describing the entity and then referenced from as many other records as you wish.
  • For resource pointer fields, where you wish to constrain the pointers to one or more specific record types. This is useful, for example, if you want a pointer to a person or organisation (e.g. as the owner of copyright), and want to make sure that this pointer can only point to one of these entities and not to, say, a website or an artefact.

When to use relationship markers

Relationships provide a richer method for linking different types of record, and should be used in preference to pointer fields in the following circumstances:

  • If the relationship is not permanent (i.e. it has a time range, such as a person as emperor of an empire);
  • There are several different types of relationship possible between any pair of entity types (for example, an organisation can be related to people as director(s), owners(s), member(s), student(s) etc. Rather than creating separate pointer fields for each of these relationships, they can be created as relationship records with a range of relationship types)
  • The relationship is not unequivocal or has rich information associated with it, and therefore requires commentary, justification or bibliographic references (which can be entered as Interpretations or notes in the relationship record – there is nowhere to store additional information in a pointer field);
  • The set of relationships is open-ended or requires complex constraints, such as genealogical relationships which might be extended with new relationships, and where one might wish to specify, for example, that a person can have no more than four grandparents, only two of whom can be grandfathers.
  • By using relationships, you can record additional information about the relationship, including the type of relationship (from a list of allowable types), the date range of the relationship and notes about the relationship.

Heurist Registration

Registration allows creation of Heurst databases and subscribes you to occasional news updates (single-click to unsubscribe).

We will not share your email information with any third party.

Thank you for registering. We have sent you an email, allowing you to confirm your registration and create your first Heurist database.