Data models are a huge subject, and in this topic we have taken a quick look at a broad variety of models. We didn’t have space to go into all the details of each model, but hopefully the overview has been enough to whet your appetite to find out more about the model that best fits your application’s requirements.
The relational model, despite being more than half a century old, remains an important data model for many applications—especially in data warehousing and business analytics, where relational star or snowflake schemas and SQL queries are ubiquitous. However, several alternatives to relational data have become popular in other domains:
-
The document model targets use cases where data comes in self-contained JSON documents and where relationships between one document and another are rare.
-
Graph data models go in the opposite direction, targeting use cases where anything is potentially related to everything and where queries potentially need to traverse multiple hops to find the data of interest (a need that can be met using recursive queries in Cypher, SPARQL, or Datalog).
-
DataFrames generalize relational data to large numbers of columns, providing a bridge between databases and the multidimensional arrays that form the basis of much machine learning, statistical data analysis, and scientific computing.
To some degree, one model can often be emulated in terms of another model—for example, graph data can be represented in a relational database—but the result can be awkward, as we saw with the support for recursive queries in SQL.
Various specialist databases have therefore been developed for each data model, providing query languages and storage engines that are optimized for that particular model. However, there is also a trend for databases to expand into neighboring niches by adding support for other data models—for example, relational databases have added support for document data in the form of JSON columns, document databases have added relational-like joins, and support for graph data within SQL is gradually improving.
Another model we discussed is event sourcing, which represents data as an append-only log of immutable events and can be advantageous for modeling activities in complex business domains. An append-only log is good for writing data; in order to support efficient queries, the event log is translated into read-optimized materialized views through CQRS.
One thing that nonrelational data models have in common is that they typically don’t enforce a schema for the data they store, which can make it easier to adapt applications to changing requirements. However, your application most likely still assumes that data has a certain structure; it’s just a question of whether the schema is explicit (enforced on write) or implicit (assumed on read).
Although we have covered a lot of ground, some data models remain unmentioned. To give just a few brief examples:
-
Researchers working with genome data often need to perform sequence similarity searches, which take one very long string (representing a DNA molecule) and match it against a large database of strings that are similar but not identical. None of the databases described here can handle this kind of usage, which is why researchers have written specialized genome database software like GenBank.
-
Many financial systems use ledgers with double-entry accounting as their data model. This type of data can be represented in relational databases, but there are also databases (such as TigerBeetle) that specialize in this data model. Cryptocurrencies and blockchains are typically based on distributed ledgers, which also have value transfer built into their data model.
-
Full-text search is arguably a kind of data model that is frequently used alongside databases. Information retrieval is a large specialist subject that we won’t cover in great detail in these notes, but we’ll touch on search indexes and vector search in “Full-Text Search”.
We have to leave it there for now. In this topic we will discuss some of the trade-offs that come into play when implementing the data models described in this topic.