Databases Reference
In-Depth Information
on the desired interfaces at the top layer. If, for instance, a solely set-oriented
interface has to be offered, it is useful to merge the upper two layers.
From a more practical point of view, most DBMS architectures have
been influenced by System R [13], which consists of two layers: the relational
data system (RDS), providing for the relational data interface (RDI), and the
relational storage system (RSS), supporting the relational storage interface
(RSI). While RDS implements SQL (including query optimization, access
control, triggers, and the like), RSS supports access to single tuples of base
relations at its interface.
12.3.2
Components and DBMS Architecture
When we are striving for reusability, extensibility, openness, and interoper-
ability in DB systems, looking at software engineering research and practice
yields helpful insights. In particular, componentware [1420] has recently
been proposed as a paradigm to address those issues. This notion is meant to
say that software systems are built in a disciplined manner out of building
blocks with specific properties, called components. There is currently no
widely agreed-upon definition of the term component ; however, the follow-
ing characteristics of components can be found in most definitions in the lit-
erature. A (software) component, then, is a software artifact modeling and
implementing a coherent and well-defined set of functions. It consists of
a component interface and a component implementation. Components are
black boxes, which means that clients can use them properly without
knowing their implementation. Component interface and implementation
should be separated such that multiple implementations can exist for one
interface, and implementations can be exchanged. Components being black
boxes also means that each component sees only the interfaces of other
components, that is, access to internal operations and structures of other
components is not permitted. A component should not have an overly high
number of relationships to other components, because that might restrict its
reuse potential.
Components usually possess a coarser granularity than objects in
object-oriented systems and models. A well-designed component supports
a coherent set of tasks (e.g., in one of our scenarios, storing and retrieving
textual documents), while objects and classes typically address only a part
thereof. Components and objects, however, are not mutually exclusive alter-
natives, but components rather leverage object-orientation to a higher level
of abstraction and granularity. In fact, components are under the hood,
often assemblies of objects.
