Distributed relational database processing
A relational database is a set of data stored in one or more tables in a computer.
A table is a two-dimensional arrangement of data consisting of horizontal rows and vertical columns as shown in the following table. Each row contains a sequence of values, one for each column of the table. A column has a name and contains a particular data type (for example, character, decimal, or integer).
Item | Name | Supplier | Quantity |
---|---|---|---|
78476 | Baseball | ACME | 650 |
78477 | Football | Imperial | 228 |
78478 | Basketball | ACME | 105 |
78479 | Soccer ball | ACME | 307 |
Tables can be defined and accessed in several ways on the system. One way to describe and access tables on the system is to use a language like Structured Query Language (SQL). SQL is the standard IBM database language and provides the necessary consistency to enable distributed data processing across different systems.
Another way to describe and access tables on the system is to describe physical and logical files using data description specifications (DDS) and access tables using file interfaces (for example, read and write high-level language statements).
SQL uses different terminology from that used on the IBM i operating system. For most SQL objects, there is a corresponding IBM i system object. The following table shows the relationship between SQL relational database terms and system terms.
|
A distributed relational database consists of a set of tables and other objects that are spread across different but interconnected databases. The database management system may use DRDA protocols to access any of these interconnected databases. An application connection to a database in such an environment is one of two types: local or DRDA. There is, at most, only one local optimized database connection per activation group. Any additional database connections must use DRDA.
In DRDA terminology, an application requester (AR) is the code that handles the application end of a distributed connection. The AR is the application that is requesting data.
An application server (AS) is the code that handles the database end of the connection.
A simple distributed relational database is shown in the following figure where the application runs on one system, and the database is located on another system.
DRDA also supports multi-tier connections between an application requester and a server. In this topology, the server that an application requester connects to is an application server, but any other server further downstream is called a database server (DS) as it does not interact directly with the application requester. In addition, to highlight its role as neither the system where a database request originates nor the system that performs the database function for the request, each application server or database server between an application requester and the final database server is also called an intermediate server.
A more complex distributed relational database is shown in the following figure where the application runs on one system, and the database management system running on a second system routes a request to a database server located on a third system.
The term client is often used interchangeably with AR, and server with AS or DS.
A unit of work is one or more database requests and the associated processing that make up a completed piece of work as shown in the following figure. A simple example is taking a part from stock in an inventory control application program. An inventory program can tentatively remove an item from a shop inventory account table and then add that item to a parts reorder table at the same location. The term transaction is another expression used to describe the unit of work concept.
In the preceding example, the unit of work is not complete until the part is both removed from the shop inventory account table and added to a reorder table. When the requests are complete, the application program can commit the unit of work. This means that any database changes associated with the unit of work are made permanent.
With unit of work support, the application program can also roll back changes to a unit of work. If a unit of work is rolled back, the changes made since the last commit or rollback operation are not applied. Thus, the application program treats the set of requests to a database as a unit.