2.2. Typical organization of modern DBMS

Naturally, the organization of a typical DBMS and the composition of its components corresponds to the set of functions considered by us. Recall that we have identified the following main functions of the DBMS:

• data management in external memory;
• managing memory buffers;
• transaction management;
• logging and restoring the database after failures;
• maintenance of database languages.

Logically, the most internal part can be distinguished in a modern relational DBMS - the DBMS kernel (often called the Data Base Engine), the database language compiler (usually SQL), the runtime support subsystem, the set of utilities. In some systems, these parts are allocated explicitly, in others - not, but logically such separation can be carried out in all DBMSs.

The database engine is responsible for managing data in external memory, managing memory buffers, managing transactions, and logging. Accordingly, it is possible to distinguish such components of the kernel (at least logically, although in some systems these components are explicitly distinguished), such as the data manager, buffer manager, transaction manager and log manager. As it was possible to understand from the first part of this lecture, the functions of these components are interconnected, and to ensure the correct operation of the DBMS, all these components must interact according to carefully thought-out and proven protocols. The DBMS kernel has its own interface, which is not directly accessible to users and is used in programs produced by the SQL compiler (or in the subsystem supporting the execution of such programs) and database utilities. The database engine is the main resident part of the database management system. When using the client-server architecture, the kernel is the main component of the server part of the system.

The main function of the database language compiler is to compile database language statements into some executable program. The main problem of relational DBMS is that the languages ​​of these systems (and this, as a rule, SQL) are non-procedural, i.e. the operator of such a language specifies a certain action on the database, but this specification is not a procedure, but only describes in some form the conditions for performing the desired action (recall the examples from the first lecture). Therefore, the compiler must decide how to execute a language statement before producing a program. Rather complicated methods of operator optimization are used, which we will examine in detail in the following lectures. The result of the compilation is an executable program that is represented in some systems in machine code, but more often in executable internal machine-independent code. In the latter case, the actual execution of the operator is performed with the involvement of the run-time support subsystem, which is essentially the interpreter of this internal language.

Finally, in separate database utilities they usually distinguish such procedures that are too expensive to perform using the database language, for example, loading and unloading the database, collecting statistics, global database integrity checking, etc. Utilities are programmed using the DBMS kernel interface, and sometimes even with penetration inside the kernel.