An introduction to data modeling and modeling terminology common to relational and graph databases.
The correct organization of data and the correct definition of the underlying database model or schema are critical to a business. TerminusDB organizes data in an object structure to facilitate modeling a business and the real world generally.
Using a small organization as an example, use the steps below to model and define a schema for the organization
and its elements - team
, project
, task
, and employee
.
Data modeling steps
Step 1. Identify the elements of the organization
Step 2. Identify the properties of each element
Step 3. Identify the relationships between elements
For relational and graph databases, an entity or element relationship model is a good way of implementing these steps. This helps to identify the components of the schema - its elements, properties, and relationships.
Elements are similar to entities in relational database terminology.
Properties are similar to attributes in relational database terminology. A property is an item of data describing the element.
Relationships are the same in graph and relational database terminology. Relationships define the associations or interactions between elements.
Element
Description
organization
The main organization.
team
The teams within the organization.
employee
The employee assigned to task
.
project
The projects that a team
creates.
task
The tasks of the project
.
Element
Properties
organization
name
, desc
, start-date
team
name
, desc
, start-date
employee
name
, date-of-birth
, start-date
, role
project
name
, start-date
, end-date
, desc
, status
task
name
, start-date
, end-date
, desc
, status
Element
Element
Relationship (phrasal verb)
Relationship description
organization
team
consists-of
An organization
consists of
team
s
team
project
collaborates-on
A team
collaborates-on
project
s
project
task
divided-into
A project
is divided-into
task
s
task
employee
assigned-to
A task
is assigned-to
an employee
How to model data in TermiusDB & TerminusX
Use the Data Product Model view of the TerminusDB dashboard to visually build simple or complex data models. The diagrams further below illustrate two possible implementations of the organization model introduced in the previous section. In addition to visually building models, the dashboard enables:
Flexible relationships between elements such as documents and sub-documents, and classes and sub-classes.
Enumeration objects related to document elements.
A comprehensive set of properties (XSD data types) for elements.
JSON views of product models and properties.
The diagram below illustrates an implementation of the organization model using a simple document structure. The enumeration objects hold status values applicable to projects and tasks.
Documents and elements are identical.
The diagram below illustrates a more intuitive implementation of the organization model using documents and sub-documents, or classes or sub-classes. This approach enables sub-documents to inherit the properties of the parent document - similar to inheritance in Object-Oriented Programming. See Data modeling using JSON for more information.
TerminusDB supports the creation of data models using JavaScript Object Notation (JSON.) TerminusDB also generates JSON for models created visually using the dashboard.
JSON supports the definition of classes and subclasses. Classes define types of complex data structures. Sub-classes inherit all parent data type definitions. Examples below.
Class
Subclass
Properties for team
JSON for the organization model
A summary of relational and TerminusDB graph database terms.
A comparative introduction to organizing and querying data in relational and graph databases.
Relational and graph databases organize data is distinctly different ways.
Traditional relational databases divide data into tables, columns, and rows.
Similar to other graph databases, TerminusDB organizes data in objects. Objects have properties, properties link to other objects. A network of interlinked objects forms a graph structure - the foundation of graph databases.
Using objects rather than cells enables the creation of databases that closely model the real world.
A family tree database stores data representing individuals, their parents, and grandparents.
The table below represents a model for storing this scenario in a relational database.
The diagram further below illustrates the equivalent graph database model. An advantage of the graph model is that it represents real-world objects more accurately, making the model intuitive and easier to understand.
Many relational databases use the Structured Query Language (SQL.) The example below uses a two-query approach to get the name of mother, then grandmother. Note the second query uses two nested sub-queries.
TerminusDB's purpose-built Web Object Query Language (WOQL) is an easier-to-use alternative to SQL. The example below demonstrates the same query using WOQL. WOQL uses triple patterns to get both names in one short query. There are no joins - joins are implied by using the same ID in different parts of the query. Using v:mother_id
multiple times creates the chain:
v:person_id = mother => v:mother = mother => v:grandmother
In TerminusDB and TerminusCMS, every particle or piece of information, including objects and documents, is stored and accessed as collections of triples. All objects are broken down deterministically, or reliably, into a precise set of triples. Also, Terminus products adhere to the RDF standard, ensuring triples have a standardized structure and interpretation. This means you can write queries based on the data patterns you are interested in, without requiring knowledge of low-level data structures such as tables and columns.
A triple is a simple data structure with three positions, often rendered as subject, predicate, object.
In TerminusDB terminology, slots are defined as: subject-id
, property
, followed by objectid
or value
.
Every triple with the same subject-id
is interpreted as being related to the same object, entity, or thing. This is how TerminusDB holds information about all things.
As shown in Example# 2 above, the object position can hold another id. This is how data relationships are defined in TerminusDB.
WOQL stores query results in variables. WOQL variables can be declared with by starting a string with the prefix v:
, such as with v:person-id
or by using a Vars
declaration, such as Vars('person-id')
.
As per the variable triple patterns listed below, a triple may consist of one, two, or three WOQL variables. When using a variable in a triple query, TerminusDB will retrieve all data, into that variable, that are relevant to the variable's position in the triple.
A single variable triple pattern consists of one WOQL variable in any one triple slot.
A two-variable triple pattern consists of two variables in any two slots.
A three-variable triple pattern consists of variables in all three slots.
Examples of a single WOQL variable in a triple slot.
Description:
Select every subject-id
into v:person-id
where the property
date-of-birth
has the value
1935-01-01
Interpretation:
Select every person born on 1935-01-01
.
Note that we must explicitly mark Date as being a value object, to make sure we do not interpret it as a node.
Description:
Select every property
into v:property-list
where object-id
jake
has the value
10
.
Interpretation:
Select all of Jake's properties with the value
10
.
Description:
Select every value
into v:jakes-parent
where object-id
jake
has the value
parent
.
Interpretation:
Select Jake's parents.
Examples of two WOQL variables in all combinations are listed below.
Positions 1 and 2
Positions 1 and 3
Positions 2 and 3
Select every subject-id
and property
into variables subject
and property
respectively with the value 10
.
Select every subject-id
and object value
into varibles subject
and date_of_birth
such that the property is date-born
.
Select every object-id
and property
into varibles joe-property
and property-value
respectively using a subject-id
of joe
.
Select every triple.
Query expressions using single triple pattern matching only are simple but limited. WOQL provides logical operators enabling you to combine multiple patterns into sophisticated queries with simple syntax **** using various operators.
We will demonstrate these operators with the following schema and database.
Schema:
Documents:
and
To look for every person who is friends with someone named "Jane", we can write:
This query connects person1
with person2
via the friend
relationship. We recover the name of the original person:
Notice, we use the select
to limit our results to only the variable of interest.
or
TO find every person who is friends with 'Jane', or 'Kim', we can write:
The or
operator allows you to combine results form multiple multiple paths. Notice, that we looked up the two people Jane
and Kim
first, and then recover the person of interests afterwords. Logically this can also be done in the reverse order:
However, the former query will likely be faster since we are starting with only two possibilities.
order_by
If we would like to get the people from our database in order of birthdate, we can use order_by
The results will be a table of name and date of birth, with ascending order for the date of birth. To sort in the reverse order:
WOQL provides several math operators for data entry and retrieval. The Python Client documentation has the full list of math operators. WOQL math operators include plus
, multiply
, times
, divide
, exp
, and div
(for integer division.)
To use a WOQL math operator, encapsulate it in WOQL.eval
shown in the examples below. Use variables for holding the values in all math operators.
Bind the value of 1
plus
2
to the variable x
. The variable x
is reusable in later queries.
Bind the value of 3
times
2
to the variable product
and
bind the value of product
divided by (div
) 2
to the variable result
.
WOQL queries are converted to the JSON-LD document format for transmission over the network. You can access the JSON-LD format for a query in JavaScript or Python as follows. Refer to the WOQL JSON-LD Reference for a full list of WOQL JSON-LD classes.
WOQL is a powerful query language that enables you to concisely query complex data patterns and structures. WOQL is based on a small set of simple concepts making it easy to use. There are just three fundamental concepts to WOQL - , and WOQL operators as illustrated in Diagram: The three core WOQL concepts.
You can assign any meaning/definition/terminology to each position, however, all positions can be nodes represented by an , but the value position can also be a data type.
Example | Object-id | Property | Value | Interpretation |
---|
name1 |
---|
person_id | name | DOB | mother_id | father_id |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| NULL | NULL |
|
|
| NULL | NULL |
|
|
| NULL | NULL |
|
|
| NULL | NULL |
1 |
|
|
| Jake's date of birth is 01-jan-1935 |
2 |
|
|
| Jake's mother is Mary |
3 |
|
|
| Jake's mother's date of birth is 01-jan-1900 |
Kim |
Relational database term | TerminusDB/graph database term |
Property |
Data type | Data type |
Database | Database or Data Product |
Entity Relationship Model (ERM) | Element Relationship Model (ERM) |
Schema |
Structured Query Language (SQL) |
or Table
Element, Document, Object, , or
Relationship or
Web Object Query Language ()