Database Reference
In-Depth Information
(Data Base Request Module)
Σ
RE
-statements, which subsequently becomes in-
put to the Bind component.
2. Next, the modified source program is compiled and link-edited in the normal
way. Output from this step we refer to as “Load Module P” (stored in
M
U
).
3. Now we come to the Bind step. As already suggested, Bind is really a database
compiler: It converts high-level database requests—in effect
Σ
RE
-statements—
into executable (by
M
R
) code.
4. Finally, we come to the execution time. The main program from a Load Module
is fetched by
M
U
into its program memory by initial-input function
In
U
(we use
a universal machine in order to be able to compute any computable function),
the Application Plan (set of normal forms embedded programs
P
i
defined as
n-operators) is fetched by Categorial DataBase machine
M
R
into its program
memory by initial-input function
In
R
, and the current stored image of Database
is also fetched by
M
R
into its data memory.
Since the original high-level program
P
has effectively been broken into two
pieces (Load Module
P
U
(for
M
U
) and Application Plan
P
R
(for
M
R
)), those two
pieces must somehow be brought back together again in the execution time. The
load module
P
U
is loaded into program memory of
M
U
and it starts to execute
in the usual way. Sooner or later it reaches the first of the CALLs inserted by the
Precompiler. Control goes to the Runtime Supervisor which prepares a data (with
eventually a list of values
L
(d
1
,...,d
k
)
in IO memory for a list of variables
(e
i
1
,...,e
i
k
)
; case of an simple 'INSERT INTO
r
=
[
S
]
VALUES
(e
i
1
,...,e
i
k
)
',
or 'UPDATE
r
SET
WHERE C' statement) for
a normal form
n
-operator of Application Plan (loaded into program memory of
M
R
), derived by Bind from the original embedded SQL formulae, which has to
be executed by
M
R
. This data is exported by the function
Out
U
(see Fig.
6.1
)
and is imported into
M
R
by the function
In
ER
. Then
M
U
executes the state-
ment 'CALL
n
'(
n
is a number of application plan of
M
R
) and wait for returned
data from
M
R
.The
M
R
receives this CALL, fetch the input data (with list of
values
L
[
nr
r
(i
1
)
=
e
i
1
,...,nr
r
(i
k
)
=
e
i
k
]
=
(d
1
,...,d
k
)
in the case of simple 'INSERT INTO
r
[
S
]
VALUES
(e
i
1
,...,e
i
k
)
'or'UPDATE
r
SET
WHERE C'
statement) into its IO memory, then transforms the
n
th application plan (a com-
posed
n
-operator) into an arrow of
RA
(by reduction of the variable-binding
operators of this application plan into simple
Σ
RA
algebra operators, obtained
by substitution of bounded variables with the values in
L
) and perform its exe-
cution (by
Eval
[
nr
r
(i
1
)
=
e
i
1
,...,nr
r
(i
k
)
=
e
i
k
]
DB
), and executes RETURN operation to restitute (by
the function
Out
R
) the computed data saved in its IO memory (computed rela-
tion). If an embedded SQL statement is different from the case 'SELECT...'
of Table
6.1
, then this new computed table replaces the old version of this ta-
ble in a database (data memory of
M
R
; in that moment the consistency of a
database is not guaranteed). After that it returns again into the wait state for the
next CALL from
M
U
. When
M
U
receives (by the function
In
EU
) the requested
data from
M
R
into its IO memory, it continues to execute the next statement of
its program and can use cursors to run through a set of received records in its IO
memory.
:
RA
→
