orb concepts: data models

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) number	name text	e-mail e-mail (unique)	password hash
1	Joe	joe@example.com	******

`sessions`
id number	userid user reference	created 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:

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

Figure 2

id number	name text	e-mail e-mail (unique)	password hash
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.