Lecture
Systems for managing remote (distributed) databases are DBMSs (distributed DBMSs) that provide simultaneous access to information for multiple users.
Let us examine the terms used in distributed database management systems.
Database architecture — the organization of interaction among hardware resources.
Types of database architecture: client—server, two-tier and three-tier client-server, and file—server.
ODBC (Open DataBase Connectivity) architecture — an open interface for accessing databases, i.e., the interaction of the Jet database engine (core) with external data sources.
Data models — schemas that characterize databases from different perspectives in order to determine the optimal design of an information system.
Database engine (core) — the internal structure of a DBMS that provides access to all components of the database. In newer versions of the Access DBMS it is called the Microsoft Data Engine (MSDE); in earlier versions the database engine was called the Microsoft Jet database engine. The database engine provides support for characters from various alphabets, SQL syntax, and other tools for processing various data types.
Database user — a program or a person accessing a database.
Query — the process by which a user accesses a database in order to enter, retrieve, or modify information.
Transaction — a sequence of data modification operations in a database that moves it from one consistent state to another consistent state.
Logical database structure — the definition of a database at a physically independent level, which most closely corresponds to its conceptual model.
Database topology, or the structure of a distributed database, — the scheme by which the physical organization of a database is distributed across a network.
Local autonomy — a concept meaning that the information in a local database and the associated data definitions belong to, and are managed by, the local owner.
Remote query — a query to databases residing on resources of a corporate local area network or the Internet.
The ability to implement a remote transaction — the processing of a single transaction, consisting of multiple SQL queries, at a single remote node.
Support for a distributed transaction — the processing of a transaction consisting of several SQL queries executed at several network nodes (remote or local), where each query is nevertheless processed at only one node.
Distributed query — a query whose processing uses data from databases located at different nodes of the network.
Distributed data processing systems are mainly associated with the first generation of databases, which were built on multiprogramming operating systems, were stored on the external storage devices of a central mainframe, and used a terminal-based multi-user access mode. In this setup, user terminals had no resources of their own — no processors or memory — that could be used for storing or processing data. The first fully relational system operating in multi-user mode was IBM's SYSTEM R DBMS. It was in this system that both the SQL data manipulation language and the basic synchronization principles used in distributed data processing were implemented — principles that remain fundamental in virtually all commercial DBMSs to this day.
The client-server computing model originally arose alongside the emergence of open systems in the 1990s. The term client—server was applied to a software architecture consisting of two information-processing processes: a client process and a server process. The client process requested certain services, while the server process ensured that they were carried out. It was assumed that a single server process could service many client processes. Given that the hardware implementation of this database management model is tied to the creation of a corporate local area network, this way of organizing the information-processing workflow is called client—server architecture.
The basic principle of the client—server model, as applied to database management technology, consists in splitting the functions of a standard interactive application into five groups of differing nature:
data input and display functions (Presentation Logic);
application functions that define the core algorithms for solving the application's tasks (Business Logic);
functions for processing data within the application (DataBase Logic);
functions for managing information resources (DataBase Manager System);
service functions that act as links between the functions of the first four groups.
The structure of a typical application working with a database in a client—server architecture is shown in fig. 1.1.
As can be seen from fig. 1.1, the client part of the application includes the following parts:
presentation logic;
business logic, or the application's own logic proper;
data processing logic;
the data management processor.
Presentation logic (Presentation Logic), as part of an application, is defined by what the user sees on their screen — that the application is running. This includes all the interface screen forms that the user sees or fills in while the application is running, as well as everything displayed to the user on screen as the result of solving certain interme-
Client
Fig. 1.1. Structure of a typical application working with a database
diate tasks, or as reference information. Consequently, the main tasks of presentation logic are:
generating screen images;
reading and writing information to and from screen forms;
managing the screen;
processing mouse movements and keyboard keystrokes.
Business logic, or the application's own logic proper (Business
Processing Logic), — is the part of the application code that defines the actual algorithms for solving its specific tasks. This code is usually written using various programming languages, such as C, C++, Visual Basic, and others.
Data manipulation logic (Data Manipulation Logic) — is the part of the application code directly related to processing data within the application. The data itself is managed by the DBMS, and the SQL language is used to provide access to it.
The data management processor (DataBase Manager System Processing) — is essentially the DBMS itself, which provides storage and management of databases. Ideally, the DBMS's functions should be hidden from the application's business logic; however, when examining application architecture, we will single them out as a separate part of it.
Fig. 1.2. Distribution of application component functions across models of
client—server
In a centralized architecture (Host-Based Processing), the aforementioned parts of the application reside in a single environment and are combined within a single executable program. In a decentralized architecture, these parts of the application can be distributed in various ways between the server and client processes.
Depending on the nature of task distribution, the following models can be distinguished (fig. 1.2):
distributed presentation (Distribution Presentation);
remote presentation (Remote Presentation);
distributed business logic (Remote Business Logic);
remote data management (Remote Data Management);
distributed data management (Distributed Data Management).
This conventional classification shows how individual tasks can be distributed between the server and client processes. This classification does not include an implementation of remote business logic, since it is considered that business logic cannot be moved away entirely — it can only be distributed among different processes that can interact with one another.
Two-tier database management models are essentially the result of distributing the five previously mentioned groups of functions of a standard interactive application between two processes running on two platforms: the client computer and the server. None of them exist in pure form, but let us examine the most characteristic features of each two-tier model.
The remote data management model, or the file server model (File Server — FS). In this model, the presentation logic and business logic reside on the client side. The server holds the data files and provides access to them. The functions for managing information resources in this model reside on the client side.
The distribution of application component functions in client—server models is shown in fig. 1.3.
In this model, the database files are stored on the server, the client accesses the server with file commands, and the mechanism for managing all information resources — the actual metadata (selected data) base — resides on the client's computer.
Fig. 1.3. The file server model
T 
he advantage of this model is that the application is split into two interacting processes. In this case the server
(server process) can service many clients that send it requests. In this model, the DBMS itself must reside on the client's computer.
The algorithm for executing a client request comes down to the following.
The request is formulated using data manipulation language (DML) commands.
The DBMS translates this request into a sequence of file commands.
Each file command triggers the transfer of a block of information to the client's computer, and the DBMS analyzes the information received; if the received block does not contain the answer to the request, a decision is made to transfer the next block of information, and so on.
Information is transferred from the server to the client computer until an answer to the client's request is obtained.
The model examined has the following drawbacks:
high network traffic, caused by the transmission over the network of the many blocks and files needed by the application;
a narrow range of data manipulation operations, limited to file commands only;
the lack of adequate data access security tools (protection only at the file system level).
Fig. 1.4. Structure of the remote data access model
The remote data access model (Remote Data Access — RDA). In this model the database is stored on the server. The DBMS engine is also located there. The client computer holds the application's presentation logic and business logic. The client accesses the server with requests in the SQL language. The structure of the remote data access model is shown in fig. 1.4.
The advantages of this model are as follows:
moving the presentation component and the application component to the client computer significantly offloads the database server, minimizing the total number of processes running on the operating system;
the database server is freed from functions that are not properly its own, and the server's processor or processors are fully devoted to processing query and transaction data;
network load is sharply reduced, since what is transmitted over the network from clients to the server are not file-level input/output requests but SQL-language requests, whose volume is significantly smaller. In response to these requests the client receives only the data corresponding to the query, not blocks of files.
The main advantage of the RDA model is the unification of the client—server interface, i.e., SQL becomes the standard language for communication between the client application and the server.
The drawbacks of this model:
SQL requests, under intensive operation of the client part of the application, can significantly load the network;
since in this model both the presentation logic and the application's business logic reside on the client computer, when similar functions are repeated in other applications, the corresponding business logic code must be repeated for each client application, causing unnecessary duplication;
since the server plays a passive role in this model, information resource management functions must be performed on the client computer. The database server model. To eliminate the drawbacks of the remote data access model, the following conditions must be met.
At every moment in time, the database must reflect the current state of the subject domain, which is determined not only by the data itself but also by the relationships between data objects, i.e., the data stored in the database must be consistent at every moment in time.
The database must reflect certain rules of the subject domain and the laws by which it operates (Business Rules). For example, a factory can operate normally only if the warehouse holds a sufficient (safety) stock of parts of a certain range, and a part can be released into production only if the warehouse has enough material to manufacture it, and so on.
Ensuring continuous monitoring of the database's state, tracking all changes, and reacting to them appropriately. For example, when some measured parameter reaches a critical value, certain equipment should be shut down; when inventory falls below the allowed norm, a purchase order should be generated to a specific supplier for the corresponding goods, and so on.
The occurrence of a certain situation in the database must clearly and promptly affect the course of execution of the application task.
Improving the DBMS's data type checking. Currently a DBMS syntactically checks only standard, permitted data types, i.e., those defined in the DDL (Data Definition Language) — the data definition language that is part of SQL. However, in real subject domains there is data that also carries a semantic component, such as the coordinates of objects or units of measurement.
The database server model is supported by most modern DBMSs: Informix, Ingres, Sybase, Oracle, MS SQL Server. This model is built around: the stored procedure mechanism as a means of programming the SQL server, the trigger mechanism as a mechanism for tracking the current state of the information store, and the mechanism of constraints on user-defined data types, which is sometimes called the domain-structure support mechanism.
The active database server model is shown in fig. 1.5. In this model business logic is split between the client and the server. On the server, business logic is implemented as stored procedures — special program modules that are stored in the database and managed directly by the DBMS. The client application accesses the server with a command to run a stored procedure, and the server executes this procedure and logs all the fore-
Fig. 1.5. The active database server model
seen changes to the database. The server returns to the client the data produced by the executed request, which the client needs either for display on screen or for carrying out part of the business logic. In doing so, the traffic exchanged between client and server is sharply reduced.
Centralized control in the database server model is carried out using the trigger mechanism, which is likewise part of the database.
The term «trigger», borrowed from electronics, very precisely characterizes, in semantic terms, the mechanism for tracking special events related to the state of the database. A trigger is like a kind of switch that is thrown when a certain event occurs in the database. The DBMS engine monitors all events that can activate the triggers created and defined in the database, and when such an event occurs, the server fires the corresponding trigger. Each trigger is itself also a kind of program that is executed against the database. Triggers can be used to invoke stored procedures.
The mechanism of trigger use implies that when one trigger fires, events may arise that will cause other triggers to fire in turn.
In this model the server is active, since in it not only the client, but the server itself, using the trigger mechanism, can initiate data processing in the database.
Stored procedures and triggers are stored in the database dictionary and can therefore be used by several clients, which significantly reduces duplication of data-processing algorithms across different client applications.
The drawback of this model is the very heavy load placed on the server, since it services many clients and performs the following functions:
• monitors events related to the execution of the triggers that have been defined;
ensures the automatic firing of triggers when the events associated with them occur;
ensures the execution of the internal program of each trigger;
launches stored procedures at users' requests;
launches stored procedures from triggers;
returns the requested data to the client;
ensures the execution of all DBMS functions (data access, control and maintenance of data integrity in the database, access control, and ensuring correct concurrent operation of all users with a single database).
If most of the applications' business logic is moved to the server, the requirements placed on clients in this model drop sharply. Such a model is sometimes called a thin-client model, while the models examined earlier are called thick-client models.
The application server model. This three-tier model, which is an extension of the two-tier model — that is, with an additional intermediate tier introduced between the client and the server — was proposed in order to offload the server.
The architecture of the three-tier model is shown in fig. 1.6. The intermediate tier can contain one or several application servers.
In this model the application's components are divided among three participants: the client, the application server, and the database server.
The client provides presentation logic, including the graphical user interface and local editors. The client can run local client application code, which may include calls to a local database residing on its own computer. The client carries out the communication functions of the application's front-end part, providing it with access to a local or wide-area network. In addition, the implementation of interaction between the client and the server may include distributed transaction management, corresponding to cases where the client is also a client of the distributed transaction manager.
Fig. 1.6. The application server model
Application servers, which make up the new intermediate tier of the model's architecture, are designed to carry out common functions that need not be loaded onto clients. Application servers support the functions of clients as members of interacting workgroups, a networked domain operating environment, and data directories, and they also store and execute the most general business-logic rules, provide messaging, and support queries (especially in distributed transactions).
Database servers in this model deal exclusively with DBMS functions: they provide the functions of creating and maintaining the database, maintain the integrity of the relational database, and provide data warehouse services. In addition, they are responsible for creating database backups and recovering the database after failures, managing transaction execution, and supporting legacy applications.
This model offers greater flexibility than the two-tier models. The advantages of the application server model are most apparent in cases where complex analytical computations are performed in the database, belonging to the field of OLAP applications (On-line analytical processing). In this model, most of the client's business logic is isolated from the capabilities of the SQL language built into a particular DBMS and can be implemented in programming languages such as C, C++, Smalltalk, Cobol, which improves the system's portability and scalability.
Database server models. When the first DBMSs were being created, client—server technology was only just emerging, so the architecture of these systems initially lacked an adequate mechanism for organizing the interaction between client and server processes. In modern DBMSs, this mechanism is in fact fundamental, and the effectiveness of the system as a whole depends on how effectively it is implemented.
Let us examine the evolution of such mechanisms. Essentially, such a mechanism is determined by the structure of the server-process implementation and is often called the database server architecture.
As already noted, at first there existed a model in which data management (the server function) and interaction with the user were combined in a single program. This stage of database server development can be called stage zero.
Then the data management functions were separated out into an independent group — the server. However, the model of user interaction with the server still corresponded to a "one-to-one" relationship structure between database tables (fig. 1.7), i.e., the server served the requests of only one user (client), and to serve several clients it was necessary to launch a corresponding number of servers.
Fig. 1.7. Interaction of client and server processes in the
"one-to-one" model
Separating the server out into its own program was a revolutionary step, which made it possible, in particular, to place the server on one machine and the user program interface on another, and to have them interact over a network. However, the need to launch a large number of servers to serve many users severely limited the capabilities of such a system. To serve a large number of clients, the server had to run a large number of server processes simultaneously, which sharply increased the demand on machine resources.
Moreover, each server process in this model was launched as an independent process, so a request that had just been executed by one server process would be executed again when formed by another client. In such a model it is difficult to ensure interaction between server processes. This is the simplest database server model, and historically it was the first to appear.
The problems arising in the "one-to-one" information model are solved in the architecture of systems with a dedicated server capable of processing requests from many clients. In this system the server alone holds a monopoly on data management and interacts simultaneously with many clients (fig. 1.8). Logically, each client is connected to the server by a separate
Fig. 1.8. Multi-threaded single-server architecture
thread, along which requests are sent. This architecture, known as multi-threaded single-server architecture, makes it possible to significantly reduce the load on the operating system that arises when a large number of users are working (thrashing).
Moreover, the ability provided in this model for many clients to interact with a single server allows shared objects to be used to the fullest extent (ranging from open files to data from system catalogs), which significantly reduces the memory requirement and the total number of operating system processes. For example, in the "one-to-one" model the DBMS creates 100 copies of processes for 100 users, whereas a system with a multi-threaded architecture requires only a single server process for the same purpose.
However, such a solution has its drawbacks. Since the server can run on only one processor, this naturally limits the use of the DBMS on multiprocessor platforms. If a computer has, for example, four processors, a DBMS with a single server uses only one of them, leaving the other three idle.
Comments