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.
| Name | Date of Birth | Address |
|---|---|---|
| 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.