A Universal Schema

In traditional, relational databases data models are fairly rigid. Tables are designed for storage and retrieval and they require the application layer to transform incoming data into a format that fits the schema. There are NoSQL schemas, but they give up on type safety and schemitization for flexibility.

The two tiered system between the application layer and the database layer is helpful in allowing the schema to evolve independently of the external data interface. This type safety and interface regidity comes at the cost of slower evolution.

Triple Stores

I discovered the notion of a triplestore↗. Effectively it’s a model where data as an entity-attribute-value set. An entity is a unifying indentifier to group the concept of a thing. The attribute/value combination is essentially just a triaditional key/value pair. Conceptually most databases use key/value pairs under the hood, so it’s just an extension of that notion.

Broadly the idea is that data can be stored without having to adhere to a schema. Often these systems are schema on read instead of schema on write.

Datomic’s Universal Schema

Datomic↗ is a database written in closure that operates on triples. Their documentation covers the notion of a universal schema↗, a snippet I’ve included below.

In a relational database, you must specify a table schema that enumerates in advance the attributes (columns) an entity can have. By contrast, Datomic requires only that you specify the properties of individual attributes. Any entity can then have any attribute. Because all datoms are part of a single relation, this is called a universal schema.

For example, consider storing an inventory database in Datomic. All inventory items have a unique string identifier, so you create an /id attribute. In addition, you create other named attributes, specifying the types and cardinalities of each.

This exploration is part of the Personal Data Store research project.