1. Introduction

Data models are fundamental entities that provide abstraction for DBMS (Data Base Management System). A DBMS is the software that handle all access to the database 

[3]

The concepts of

[4][5]

To resolve this collision, J. Zachman tried to separate clearly conceptual, logical, and physical levels of data in models 

[7]

Modern computing foundations include the topic of database management; database design and data-centered approach are the important parts of software design strategies and methods

[23][24][25]

This article is focused on logical level data models implemented by DBMS.

2. Main part

A data model can be defined as a combination of three components 

[1]

1. 

2. 

3. 

Another term definition is “A data model is a collection of conceptual tools for describing data, data relationships, data semantics, and consistency constraints” 

[2]

Data models are often confused with data (database) structural schemes. In fact, a

As of 1979, some 40 or more data models (mostly incomplete) have been proposed for the management of formatted data 

[1][15][16]

The classical approach has been suggested by C. Date in the first edition of his book 

[1]

– hierarchical model;

– network model;

– relational model.

This classification has been largely reused in the study books on data management since the middle of 1970thMissing Mark : sup and up to 2000thMissing Mark : sup

[2][4][8][3]

However, since the 1990thMissing Mark : sup and early 2000thMissing Mark : sup many non-relational data structures and models was introduced and re-introduced in different DBMS. There are several important reasons

[6][9][10][12][13]

– dominating of object-oriented approach and impedance mismatch of object-relational mapping;

– evolution of OLAP (Online Analytical Processing) DBMS;

– evolution of Internet/Web data;

– reintroducing of VLDB (Very Large Databases) storage and analysis as "Big Data".

For example, the authors of "Database System Concepts" 

[2]

– relational model;

– entity-relationship model;

– semi-structured data model;

– object-based data model.

M. Stonebraker and J.M. Hellerstein 

[11]

– hierarchical (IMS): late 1960’s and 1970’s;

–  network (CODASYL): 1970’s;

–  relational: 1970’s and early 1980’s;

–  entity-Relationship: 1970’s;

– extended Relational: 1980’s;

– semantic: late 1970’s and 1980’s;

–  object-oriented: late 1980’s and early 1990’s;

–  object-relational: late 1980’s and early 1990’s;

–  semi-structured (XML): late 1990’s to the present.

As one can see, the categorizations mentioned above:

1. Confuse data models of different levels. For example, ER (entity-relationship) was suggested in 1976

[14]

2. Do not take in account the mathematical basics like the graph theory or the set theory.

3. Do not regard schemaless/schemafull approach out of scope of semi-structured models. For example, XML data model without a schema can be considered as a semi-structured but the simple adding of an XML schema makes the model fully structured.

Database systems can be conveniently categorized according to the data structures and operators they present to the user 

[3]

The first classification axis is the theoretical basis, or the formalism which a data model is based on. The following formalisms are used since first DBMS had been developed in 1960’s:

– graph theory;

– set theory;

– higher-order function notion from the category theory (map).

Data models based on the graph theory have the following qualities:

1. Each data item is represented as a record of some type. In the modern world an object with properties may be used instead.

2. Each record can be explicitly linked to one or more records, for example, using physical pointers; the model is called "hierarchical" when cyclic links are disabled.

3. To access a data item the user should specify the path containing established links.

Data models based on the set theory have the following characteristics:

1. Each data item called "a tuple" is an ordered set of elements of different data types.

2. There are no explicit links between tuples

3. To access one or more data items user should specify an operation on the data set; for example, intersect two set of tuples

The maps are well known since introducing in the LISP programming language in 1958 

[20][19]

1. Each data item called "a value" may have any data type.

2. There is no explicit or implicit links between items.

3. To access an item user should specify other value called "a key". Every key can be associated with only one value.

The second axis identifies the class of data structuring level supported by a data model:

– structured data models;

– semi-structured data models;

– non-structured data models (out of subject).

In the structured data model, all data items should have a predefined type including complex types. For example, records of the same type should have the same set of fields 

[2]

Semi-structured data model allows the specification of data items where individual items may do not have a type at all, or the items of the same type may have different structure 

[2]

Non-structured data models are out of databases realm because of the database definition as a structured data storage

[3][8][10]

The following hierarchy seems to be good enough to include all widely used data models.

1) 

◦     Hierarchical model;

◦     Network model;

◦     Document-oriented;

◦     Object-oriented (data only);

◦     Graph model;

◦     RDF (Resource Description Framework)

[22]

2)

◦     Relational;

◦     Multidimensional 

[10]

◦     Key-object

[21]

3)

◦     Key-value

[19]

◦     EAV/CR;

◦     Column store.

Only two classes are required to distinguish data models:

1. 

2. 

Some data models allow to use both structured and semi-structured facilities. For example, XML, the modern document-oriented framework implementation, allows to define documents which are constrained by XML schema, as well as schemaless documents. Idem for JSON.

The following examples are based on a wide range of DBMS including multi-model ones, embedded, “on-premises” and cloud SaaS ones, commercial and open source ones etc. Some of DBMS like IBM IMS may be considered as discontinued but they are important at the historical perspective, and still using in business.

The classification may also be presented as a pie-chart diagram.

Understanding and comparing supported data models may be a crucial factor on DBMS technical choice.

Different data models have their own limitations that may affect the efficiency of storing and querying the data (see more details on different models in the book

[9][10]

For example, the multidimensional model may require massive recomputing when one of values has been changed. This wont be a good solution for transactional processing but will be for analytical one.

NoSQL models are indeed pre-relational, they are not closed under certain operations on the data. This means, you should write programs to extract the data instead of simple query pipelines as it is for SQL. That is why many NoSQL vendors is trying to add SQL-like query language on the top of existing low level scripting languages.

Data model classification is also useful when giving courses for students: we may concentrate on more abstract notions than the names and functions of different  DBMS brands.

3. Conclusion

The proposed classification allows to understand better contemporary DBMS features, opportunities and constraints based on the used data model. In fact, many DBMS implement more than one data model to enhance the field of use.

Some buzzwords like “NoSQL” or “NewSQL” could be formalized as a subset of corresponding models. For example, “NoSQL” can be defined as both structured and semi-structured document-oriented model or, marginally, as all non-relational data models.

The proposed classification is not exhaustive but extensible and can include future data models.

The additional file for this article can be found as follows: