Databases Reference
In-Depth Information
grouped together into 38 components, some of which denote internal func-
tions while others refer to external (i.e., visible at the DBMS interface) func-
tions. The subcomponents are partitioned into six groups of related tasks.
For each subcomponent, procedures and interfaces are proposed. Therefore,
the view of a DBMS architecture is more service oriented, and concrete
components are proposed to implement such services (to the best of our
knowledge, however, a DBMS implementing this architecture has never
been built).
12.4.4 Configurable DBMSs
Configurable DBMSs are similar to service-oriented DBMSs in that they
also rely on unbundled DBMS tasks that can be mixed and matched to
obtain DB support. The difference lies in the possibility of adapting service
implementations to new requirements or even to define new services when-
ever needed.
For an example, configurable DBMSs have been investigated in the
KIDS project [43, 44]. KIDS aims at constructing DBMSs by developing
subsystems that implement various aspects of a DBMS (such as transaction
management or constraint enforcement) and by finally configuring those
subsystems together into a coherent and complete DBMS. The underlying
architecture model provides for constructs that are adequate for defining the
architecture of DBMSs. The tasks and functionality of a DBMS and its com-
ponents are modeled by means of services. Services are provided by reactive
components called brokers, which are responsible for services. In case of
service requests, the responsible brokers react by providing the service. The
functionality of each subsystem under construction is represented as a set of
services, and one or more brokers are designated as components implement-
ing the subsystem.
The construction process defines how to proceed to obtain a DBMS
with the desired functionality. The process consists of several phases, includ-
ing requirements analysis and design, implementation, and integration of
multiple DBMS subsystems. Some phases of the process are common to all
constructable DBMSs and independent of subsystems, for example, require-
ments analysis and architecture design. For each type of subsystem, a dedi-
cated construction subprocess is defined and integrated into the enclosing
DBMS construction process. For each subsystem, a dedicated specification
language is used to define its functionality (such as ACTA in the case of
transaction models [45] or SOS in the case of data models [46]). These speci-
fications serve as input to subsystem-specific implementation phases, which
