Tabular-network data model


1. The relational model has lost its exclusivity

In the last decade, active work is underway to create alternative database management systems (DBMS), which are so simply called - NoSQL. Under this concept very different systems now fall that are very different from each other. It is interesting that the "old" network and hierarchical models are not included in the concept of NoSQL! Good reviews in this area can be found in [2,3,4].

In the NoSQL category include “graph” databases [5], which are abstractly close to the canonical network model CODASYL [6]. As the name implies, such systems are two unorganized sets - nodes (vertices) and edges (arcs). The main advantage of network databases is that navigation is “determined” not at the time of query processing , as in the RDB, but at the time of adding new data (for graphs - vertices and edges), it is completely true and for graph systems. But the graph database is not structured before it is populated, unlike the CODASYL database.

Other most popular NoSQL database classes are “key-value” (example - Redis [7]) and “document storage” (example - MongoDB [8]). Since a detailed review of such systems is not the purpose of this article, it is important to note only the following.

NoSQL systems, as a rule, operate on the basis of distributed file systems providing scalability and reliability [9]. But the problem that is mathematically rigorously solved within the framework of the relational model is the integrity and consistency of the database (provided, of course, professionally competent design of the normalized scheme) is not set at all in most NoSQL systems .

As a result, today the situation is approximately the following: 75% of databases are relational, NoSQL in its pure form is used in highly specialized systems, and combinations of various database models are used in highly loaded global network projects: Google, Facebook, Instagram, WhatsApp and the like.