orb » data modelling

What is a data model? A data model describes what your data is, how it's queried and modified, and who is authorised to do so. It describes both physical data (database, spreadsheet, etc.) and an interface with that data (developer API).

What will be familiar to anybody who has used a spreadsheet or database: tables (called structures) divided into columns (fields). It's the layout of the data—just like a database layout has its schema or a programming API, its data types.

Figure 1's structures and fields describe data in a database. Here we have Joe (in users), who last logged in on April 18 (sessions).

The structure have a number of fields: identifiers, names, e-mails, and so on. Each field is associated with a type of data (number, text, etc.). There are some implicit attributes—that email and id be unique. The sessions structure, with userid, references a row in users.

Figure 1
users (structure)
id (field)
e-mail (unique)
1 Joe joe@example.com ******
user reference
date (UTC)
1 1 2021-04-18T22:59:15Z

A data model isn't data itself—it's a description. orb is responsible for managing these models and converting them into code so you can interface with real data.

Let's take a closer look at these structures as they appear in orb.

By clicking on structure, such as users in our example, we're show its fields below the Fields box. Each field shows the name, then the type of the field, then optionally any referencing.

Further clicking on fields, in this case the reference ouserid, we see more field attributes—documentation, extra validation, and so on. The case of ouserid is special in that it's a foreign key reference to another row in the database table.

Read more about structures and fields. But what about the insert, update, and query sections above the fields? These are the how of the data model.

A data model does more than describe layout and attributes: it also describes how to access, insert, modify, and delete data. This might not be significant for database administrators or auditors, but is vital to those interfacing with real data.

Some trivial to transform Figure 1 to Figure 2:

  1. Change Joe's name to Joseph.
  2. Add another user, Alice.
  3. Get the row of joe@example.com.
  4. Add another user, Alicia, with the same e-mail as Alice. (This fails—e-mails are unique!)
Figure 2
e-mail (unique)
1 Joseph joe@example.com ******
2 Alice alice@example.com ******

There are four abstract ways of interfacing with a database: queries, which extract data; insertions, which add new data; updates, which change existing data; and deletions, which remove data.

orb displays each of these operations in the structure view. In this example, users allows insertion, an update, and a query.

Clicking on the update modname, we see that code would be generated allowing for changing the user's name based on their unique identifier.

The single query, email, allows searching for the unique user matching the given e-mail address (e-mails are marked unique in the field description). There are three types of queries: search for a single object, list all objects, and iterate over a list one-by-one.

Read more about queries, updates, deletes, and inserts. Each of these operation further shows role restrictions. This allows orb to allow or deny operations (or data) based upon the operator's role.

The concept of role-based access control, where a connection to a database is only granted specific operations according to its role, is not a new one. In orb, however, all operations and data may be grouped by role access.

Most databases are accessed in several different guises. For example, a web application system may have administrators, regular users, an automatic e-mailer, and tools for anonymous marketing analysis. Roles are set by the application and are hierarchical: one can only transition into more specific roles.

orb has a configuration panel for assigning roles. By default, there is only one global role allowed to do everything.

Clicking on the role admins, we see that this role has no sub-roles. From the panel describing the structure users, we see that this role can insert new users. In practice, this means that the users of a web application cannot add new users: only an administrator can add new users.

Beside covering all possible operations, roles also govern data export.

Read more about roles.