Database Reference
In-Depth Information
In the next sections, we will consider in more details this Relational DBMS archi-
tecture represented in the two bottom boxes in Fig.
6.1
.
6.2
The Categorial RBD Machine
The synchrony of the conversations between a universal and the categorial RDB
machines can be schematically represented by Fig.
6.2
:
•
The
Runtime Supervisor
of
M
U
oversees SQL programs (embedded formulas)
during execution. When such a program requests some database operation, con-
trol goes first to the Runtime Supervisor, thanks to the CALL inserted by the
Precompiler. It transforms the values from
M
U
memory (constants and values
of variables used in the main program) into a well-defined list
L
of values to
be transferred to
M
R
, where the tuples of relations will be generated to be in-
serted or updated. After that it executes the statement 'CALL
n
' as a request to
the categorial RDB machine
M
R
, to execute the program (Application Plan)
P
n
,
and waits for the resulting relational table (after the execution of the statement
RETURN by
M
R
). Analogous operations are executed for the statements COM-
MIT and ROOLBACK used for a transaction processing and consistent database
updating (Synchpoints), which are not embedded SQL formulas. Thus, Runtime
Supervisor is a part of a program memory which starts with statements in COM-
MIT, ROOLBACK, CALL
n
and waits for return of data from
M
R
.
•
The
Stored Data Manager
of
M
R
manages the stored database, retrieving and
updating records as requested by Application Plans. It is part of a program mem-
ory, and corresponds to the instructions
(i,f,j)
in the Load Module P of
M
U
,
where
i
is the current program address (i.e., value of Program Counter),
j
is the
address of the next instruction, and
f
In
∗
EU
(see Definitions
38
and
36
), and
hence, by execution of this instruction,
M
U
takes back from
M
R
the relation with
the tuples of one 'SELECT...' statement in the source program
P
.
=
•
The
Buffer Manager
of
M
R
is the component responsible for a physical trans-
ferring of data between the disk and
M
R
system/data memory; it performs the
actual I/O operations (for example, during COMMIT and ROLLBACK) toward
a persistent Database. The abstract view of the Buffer Manager is limited to the
specific definition for the input/output functions
In
R
,
Out
R
,of
M
R
, and not as a
codification of specific programs:
1.
In
R
is the initial input for
M
R
program: the initial state of
M
R
is determined
by
st
(
0
)
=
In
R
(z)
, a database is a part of data in
z
and hence the physically
stored (consistent) image of database is loaded into a data memory of
M
R
to
be subsequently updated by the application programs.
It is used also for each 'ROLLBACK' statement of the main program, so
that after the execution of this statement, the current state of
M
R
is reimposed
to be the last physically stored (consistent) image of a database.
2.
Out
DB
—for each 'COMMIT' statement of the main program
P
the new
con-
sistent
version of database is physically transferred to the disk memory.
Let us now define these two machines in order to support the previously described
type of the synchrony conversations:
