Node store

Metrici stores data in a very specific way.

An understanding of this data storage approach is required to understand how to develop solution with Metrici.

Relational databases

Most modern computer systems store data in relational databases.

Conceptually, data is stored in tables.

Each object is represented by a row on the table.

Each piece of data is represented by a cell on the table.

NameDate of BirthAddress
Bill 14 January 1957 15 Sunny Terrace
Ben 19 August 1976 21 Sea View Road
Jane 23 September 1969 12 Acacia Avenue

Triple stores

In a triple store, the data is broken down further so that each individual piece of data is represented by a triple.

Bill Date of Birth 14 January 1957
Bill Address 15 Sunny Terrace
Ben Date of Birth 19 August 1976
Ben Address 21 Sea View Road
Jane Date of Birth 23 September 1969
Jane Address 12 Acacia Avenue

The advantage of a triple store is that the same structure can be used to represent any data. In the first example, the table can only be used to hold information about people. The triple store can hold anything.

Using a triple store also makes it easy to hold metadata, i.e. data about the data you are holding.

In the triple store examples, the three columns (known as the subject, predicate and object) are not necessarily strings. The predicate and the object may in fact be links to other subjects which are themselves defined on the triple store.

So, on the same triple store, we might define date of birth and address, and even that Bill, Ben and Jane are people.

Bill Is a Person
Ben Is a Person
Jane Is a Person
Person Has A Date of Birth
Person Has A Address
Address Is a String
Date of Birth Is a Date

In this way, a triple store can hold indefinitely complicated data and metadata, in the same structure.

Why Metrici uses a triple store

Metrici uses a triple store so that it can store data for any application within the same structure, and so that it can cope with complex data structures and data structures that need to change through time.

For example, many Metrici applications involve assessment. These application require flexible data (e.g. answers), and flexible metadata (e.g. questions). However, different types of solution require different metadata: the definition of an employee survey is very different from the definition of a consultancy tool. We therefore need further layers of metadata above the initial metadata. Also, the data from one activity may become the metadata for the next. For example, a survey creation tool will initially ask questions about what questions should be in the survey, and then use the answers to those questions to create the survey questions.

Triple store optimisations

Metrici implements its triple store on top of a relational database, and uses the term node store for this structure. Each subject is termed a node, and each of the triples is termed a member.

The Metrici node store implements some specific optimisations to the basic triple store model:

  • For each node, the node store maintains a link to a node which represents its data type.
  • The node store holds a reference for each node, and enforces a structured naming convention for these references.
  • The node store can hold multiple versions of each node.
  • Members are accessed through their subject node (termed the owner), and the predicate of each member (termed the member type) is implemented as a link to another node.
  • A sequence number is maintained for each member within a member type.
  • The object of the triple is implemented as any combination of a string (termed the value or text), a number (termed the scale or number) and a link to a version of another node (termed the target or link). This and the inherent sequencing reduces the number of nodes significantly, as there is no need to create extra nodes for example to hold a sequenced list of links, or a list of weighted links, or to associate a textual answer with a link to a target node such as a grade, all of which are common structures within applications.
  • The node store automatically generates an additional set of members (termed the derived members) based on the original members whenever the original members change. By default the derived members are identical to the original members. However, processes can modify the derived members. For example, inheritance between nodes is implemented by copying derived members from the parent nodes to the child.
  • Audit information is maintained automatically. This includes the time when each node and each member was first created and last modified and the user who created it and last modified it. It includes any user comments for each node or member. For derived members, it includes the node from which the member was derived.
  • For each node, an owner is maintained, to provide a consistent user identity for processing.
  • Access to the node store is controlled with a comprehensive set of permissions. These control who can read and update the node (either all members or by member type), who can administer the node, who can link to the node as a target, who can use the node as a type for creating new nodes, who can execute scripts defined for the node, and who can use this node's reference as the basis for another reference. Using the reference naming conventions, permissions can be set over a group of nodes with similar references, rather like directory-based permissions on a file system.