We have developed a new concept, methods and practical ways to combine the table and network database models with the advantages of the ORM idea, so that, to refuse to use the query language in the application code, which allowed us to create a new model and database technology.

A “tabular" database refers to a "degenerate" relational model in which:

1. records are grouped into tables, and all records (tuples) in the same table have the same set of fields (in columns)
2. tables do not have identical rows
3. field values ​​can be not only atomic, but also sets

The key new concept is the hypertable (GT) - this is a database, as a set of tables:

1. a hypertable has a common set of attributes for all its tables
2. tables do not have headings: the set of columns of any table is a certain subset of hypertable's attributes, that is, two concepts of RDB: the database domain and the attribute of a separate relation "merge" into one - the hypertable attribute
3. there are two disjoint attribute classes:
   attributes with data whose values, as in the RDB, are field fields with self-defined data for the corresponding columns of the tables, which we will call the ADT - “attribute of data type ” attributes with links that we call ALT - “attribute of link type ”

The values ​​of ALT fields in the rows of the table are explicit links to any rows in any tables in the hypertable.

The concept of a hypertable introduced by us has nothing to do with the project [13], which was finished in 2016.

There is a working experimental prototype - a set of tools in Python - the HyperTable Management System (HTMS), which includes the following levels (from top to bottom):

• hypertable editor implemented as a website on the Django platform, which can connect to any server regardless of applications (functionally similar to PgAdmin utility for PostgeSQL);
• library of utilities and classes at the "logical" level - API for creating a database and manipulating data in application code (OTNM);
• library of utility functions and classes at the "physical" level, which is the basis for the logical level (this API can be used by experienced system programmers);
• Cage class and API, which is designed to create a “virtual” level of cached remote access to database files on the client (application) side;
• CageServer file server - software operating in multi-program and multi-threaded mode, which implements functions for a multi-user server for remote file access via TCP.

One can use the local file system of the OS to manage files instead of Cage, and use the Cage and CageServer APIs as an independent tool to implement remote distributed access to files on any system.