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