21.1. Orientation to Extended Relational Model

One of the main points of the relational data model is the requirement of normalizing relations: tuple fields can contain only atomic values. For traditional applications of relational DBMS - banking systems, backup systems, etc. - this is not a limitation at all, but even an advantage, which allows designing economical databases with extremely clear structure. Requests with connections in such systems are relatively rare, and appropriate SQL tools are used to dynamically maintain integrity.

However, with the advent of effective relational DBMS, they began to try to use them in less traditional application systems - CAD systems, artificial intelligence systems, etc. Such systems usually operate with complexly structured objects, for the reconstruction of which from flat tables of a relational database, it is necessary to perform queries that almost always require connecting relations. In accordance with the requirements of developers of non-traditional applications, the direction of research of databases of complex objects appeared. The main point of this direction is that the designers are given the same powerful and flexible means of structuring data as those that were inherent in the hierarchical and network database systems.

However, the important difference is that in database systems that support complex objects, there is a clear boundary between the logical and physical representations of such objects. In particular, for any complex object (of arbitrary complexity) it should be possible to move or copy it as a whole from one part of the database to another part of it or even to another database. This is a very broad area of ​​research that addresses data model issues, data structures, query languages, transaction management, logging, etc. In many ways, this area is in contact with the area of ​​object-oriented databases. (And in this area things are just as bad with a theoretical rationale.)

A close, but generally speaking, direction based on other principles is represented by database systems based on a relational model, in which the first normal form of relationships is not necessarily supported. Recall that the requirement of atomicity of values ​​that can be stored in the elements of relations tuples is the basic requirement of the classical relational model. Bringing the original tabular representation of the domain to a "flat" form is an obligatory first step in the process of designing a relational database based on the principles of normalization. On the other hand, it is absolutely obvious that such a “flattening” of tables, although a necessary condition for obtaining a non-redundant and “correct” relational database schema, later potentially causes the execution of numerous connections, the presence of which can negate all the advantages of a “good” database schema. data.

So, in the "non-normalized" relational data models, storage of tuples (records), arrays (regular indexed data sets), regular sets of elementary data, and relationships is allowed as an element of a tuple. Moreover, this nesting can be essentially unlimited. If you carefully consider these ideas, it becomes clear that they lead (only) to logically separate (from the physical representation) capabilities of the hierarchical data model. But this is not so little if we consider that by now the theoretical basis of relational databases with a rejection of normalization has been almost completely formed. Most likely, there are still dark places in this theory (they are present even in the classical relational theory), but nevertheless most of the known theoretical results of the relational theory are already extended to the unnormalized model, and even such a purist of the relational model, such as Date, considers it possible to use limited and controlled relational model in SQL-3.