Databases Reference
In-Depth Information
bottom deals with blocks and files. Finally, a task-oriented architecture iden-
tifies the relevant modules (i.e., their purpose and interface) and relationships
to other modules, for example, in the form of exported and imported inter-
faces. Examples for such tasks include query optimization, concurrency con-
trol, and recovery. The latter two also are examples for tasks that are hard to
assign to a specific layer in the layered architecture, or that might even be
addressed by multiple layers. Although a task-oriented architecture is much
more suitable for reasoning about extensibility and DBMS construction, ref-
erence architectures hardly exist (with the strawman architecture developed
by the Computer Corporation of America (CCA) [10] as a notable excep-
tion), and concrete architectures are described at a granularity too coarse to
be helpful for our purposes.
For educational purposes, it is convenient to consider a DBMS archi-
tecture as consisting of a number of layers [11, 12]. Each layer supports a set
of data types and operations at its interface and typically consists of several
components (modules or managers of some concrete or abstract resource).
The data types and operations defined for the modules of one layer are
implemented using the concepts (data types and operations) of the next
lower level. Therefore, the layered architecture can also be considered as
a stack of abstract machines. Concretely, the layered architecture model
as introduced by Härder and Reuter [11] is composed of five layers (see
Figure 12.3):
The uppermost layer (L4) supports logical data structures such
as relations, tuples, and views. Typical tasks of this layer include
query processing and optimization, access control, and integrity
enforcement.
·
L3 implements a record-oriented interface. Typical entities are
records and sets (e.g., as found in the Codasyl data model) as well as
logical access paths. Typical components are the data dictionary,
transaction management, and cursor management.
·
The middle layer (L2) manages storage structures (internal records),
physical access paths, locking, logging, and recovery. Relevant mod-
ules include the record manager, physical access path managers (e.g.,
a hash table manager), and modules for lock management, logging,
and recovery.
·
L1 implements (page) buffer management and the page replacement
strategy. Typical entities are pages and segments.
·
