AN OVERVIEW OF THE OBJECT-ORIENTED DATABASE
PROGRAMMING LANGUAGE DBPQL
Markus Kirchberg
Information Science Research Centre and Department of Information Systems
Massey University, Private Bag 11 222, Palmerston North 5301, New Zealand
Keywords:
Database Programming Language, Object-Oriented Programming, Query Language, Impedance Mismatch,
and Object Database Management System.
Abstract:
In this paper, we present a new approach to the integration of object-oriented programming languages, database
programming languages and query languages. While object-oriented programming languages and languages
that are supported by object database systems appear to be closely related, there are a number of significant
differences that affect language design and implementation. Such issues include the degree of encapsulation,
persistence, the incooperation types and classes, inheritance, concurrency,
NULL
values, garbage collection etc.
In this paper, we outline the respective challenges that affect language design and provide a brief overview of
the integrated object-oriented database programming and querying language DBPQL.
1 INTRODUCTION
Traditionally, programming languages (PLs) focus on
processing. In turn, data storage and data sharing only
play a minor role. Long-term data is ‘exported’ to a
file system or database system (DBS). DBSs, on the
contrary, have been built to support large bodies of ap-
plication programs that share data. The emergence of
object-oriented PLs (OOPLs) have brought those two
concepts closer together, i.e. data is at the centre of
attention. Nevertheless, in OOPLs, the messages ob-
jects accept are most important while DBSs largely
evolve around object persistence and data sharing.
This, of course, results in a number of common (i.e.
object-related) concepts being dealt with differently.
Such concepts include the degree of encapsulation,
treatment of transient and persistent data, incorpora-
tion of types and classes, inheritance, concurrency,
NULL
values, garbage collection etc.
In todays database (DB) marketplace, (object-
)relational DBSs ((O)RDBSs) are dominant. Object-
oriented DBSs (ODBSs) were originally thought of to
replace RDBSs because of their better fit with object-
oriented programming. However, high switching
costs, the inclusion of object-oriented (OO) features
in RDBSs, and the emergence of object-relational
mappers (ORMs) have made RDBS successfully de-
fend their dominance in the DB marketplace. ODBSs
are now established as a complement, not a replace-
ment for (O)RDBSs. Especially the open source com-
munity has created a new wave of enthusiasm that is
fuelling the rapid growth of ODBS installations.
In general, DBSs provide support for query lan-
guages (QLs), most commonly SQL-like languages.
It has been common practice for decades to link
the PLs and DBSs domains by embedding QLs into
PLs. However, the embedded approach suffers from
problems collectively known as impedance mismatch.
Alternative integrated approaches circumvent these
problems. While the majority of them either represent
a PL with added query constructs (e.g. DBPL (Atkin-
son and Buneman, 1987)) or a QL with added pro-
gramming abstractions (e.g. Oracle PL/SQL (Feuer-
stein and Pribyl, 2002)), only a few research projects
(e.g. LOQIS (Subieta, 1991)) have attempted a seam-
less integration of programming and querying lan-
guages. We follow the latter line of research.
In this paper, we briefly discuss issues that af-
fect the integration of OOPLs and DB languages.
Subsequently, an overview of the integrated object-
oriented database programming and querying lan-
guage DBPQL is presented.
573
Kirchberg M. (2007).
AN OVERVIEW OF THE OBJECT-ORIENTED DATABASE PROGRAMMING LANGUAGE DBPQL.
In Proceedings of the Ninth International Conference on Enterprise Information Systems - DISI, pages 573-576
DOI: 10.5220/0002371205730576
Copyright
c
SciTePress
2 PRELIMINARIES
In this section, we first discuss the impedance mis-
match. Subsequently, attention shifts to issues that
affect the integration of DB languages and OOPLs.
2.1 The Impedance Mismatch
The term impedance mismatch refers to an inadequate
or excessive ability of one system to accommodate
input from another. The object-relational impedance
mismatch is often named a central problems of DB
research. It refers to a set of conceptual and tech-
nical difficulties, which are often encountered when
an (O)RDBS is being used by a program written in
an OOPL. Robert Greene highlights in (Cook et al.,
2006) that Objects in the language and Relations in
the database have always been at odds, as articu-
lated in the classic problem known as “impedance
mismatch”. Two fundamental ways in which this
mismatch materialises, i.e. as developer burden and in
slower performance, are identified. While standardis-
ation of mapping has brought relief to the former, the
latter still poses a significant burden.
2.2 On the Integration of PLs and QLs
The relationship between QLs and PLs has been stud-
ied for decades. Among others, (Leontiev et al., 2002)
reviews existing integrated DBPLs. The review was
written as part of the TIGUKAT project (
¨
Ozsu et al.,
1995), which aimed at developing a novel ODBS.
TIGUKAT researchers proposed a novel object model
whose identifying characteristics include a purely be-
havioural semantics and a uniform approach to ob-
jects. However, research has been terminated without
addressing problems that arise when including data
creation, data manipulation and programming lan-
guage constructs into a behavioural DBPL.
Another, from a practitioners point of view, more
interesting approach is presented in (Subieta et al.,
1993). The seamless integration of a QL with a PL
is investigated. Researchers follow an extended ap-
proach to stack-based machines as known from clas-
sical PLs such as Pascal. This Stack-Based Approach
(SBA) includes the SBQL language.
While the TIGUKAT project is based upon a pow-
erful type system (resulting in implementation chal-
lenges and performance problems), the SBA approach
rejects any type checking mechanism that originates
from type theory. In addition, SBA lacks of any ef-
forts that aim towards efficient evaluation. Concepts
such as concurrent processing, transactions and distri-
bution are neglected by both approaches altogether.
2.3 DBPLs Vs. Conventional PLs
Fundamental issues that are dealt with differently in
OOPLs and in DB languages have been discussed in
various papers (Bloom and Zdonik, 1987; Atkinson
et al., 1989; Kim, 1993).
While OOPLs evolve around the messages an ob-
ject accepts, DBSs expose both the structure and be-
haviour of objects. Hence, encapsulation is inter-
preted differently. Without relaxing the encapsulation
property support for ad-hoc querying is impossible.
(Atkinson et al., 1989) suggests that the support of
encapsulation is essential but it may be violated un-
der certain conditions.
The interpretation of the terms class and type
largely vary even in the OOPL domain. However, we
focus on corresponding differences between ODBSs
and OOPLs. While types / classes commonly serve
as data structuring primitive, they also serve as means
of object access. Hence, types / classes must have
(system-maintained) collections of objects associated.
This is not the case in OOPLs, in fact, such a property
is not even desired. Not only does it disable garbage
collection it may also violate data abstraction. The
latter is true since objects become accessible through
the type / class even though they were meant to be ac-
cessible only through an abstract layer. In addition, a
collection approach does not make sense for all type
/ class definitions since there might be no meaningful
relationship between the respective objects.
Support of inheritance is an essential feature in
both domains. However, there is no agreement on
which inheritance types to support. Most arguments
evolve around the question whether multiple imple-
mentation inheritance has its advantages. While mod-
ern OOPLs (e.g. Java and C#) chose not to support it,
DBSs consider it as a necessary language feature.
Another issue concerns the life-time of objects.
Persistence was always at the core of DBSs in con-
trast to PLs. The latter tended to rely on file systems
or DBSs to maintain long-term data. This resulted
in a non-uniform treatment of transient and persis-
tent data. It is commonly accepted that persistence
should be orthogonal (i.e. each object, independent
of its type or class, is allowed to become persistent
without explicit translation) (Atkinson and Buneman,
1987).
Further issues encompass the inclusion of
NULL
values and the different focus of concurrency sup-
port. The former has only recently found its way into
OOPLs, i.e. into the second release of C#. The lat-
ter is commonly centred around transactions in DBSs
(i.e. competition for resources) and around multi-
threading in PLs (i.e. cooperation).
ICEIS 2007 - International Conference on Enterprise Information Systems
574
3 A DISTRIBUTED OBJECT BASE
(Kirchberg et al., 2007) proposes the architecture of
a distributed ODBS that is based on a sound theoret-
ical framework. The lack of standard object seman-
tics still is one of the main disadvantages of ODBSs.
Research in previous decades has investigated com-
plex values and references between data. The OO data
model OODM from (Schewe and Thalheim, 1993) al-
lows these different aspects to be combined. Starting
from an arbitrary underlying type system a schema
is defined as a set of classes, each of which com-
bines complex values and references. In a distributed
DBS, the fragmentation and allocation of an OODM
schema will be still an OODM schema, but each class
will be allocated to exactly one DBS node. Thus, each
global object is now represented by multiple local ob-
jects. However, the structure of these local objects is
still complex whereas efficient storage and retrieval
requires to provide just records stored on pages. This
implies to further decompose objects. The operational
system adopts the basic idea of the SBA approach
to implement DBS functionality. Stack-based ma-
chines are extended in a way that they execute simul-
taneously, support transactions and orthogonal persis-
tence, and reflect operations on higher DBS levels.
4 OVERVIEW OF DBPQL
In a truly distributed ODBS, users are not aware of the
distributed nature of the system. In fact, data indepen-
dence and network and fragmentation transparency
are key system properties. Thus, user requests are
free of location- and communication-specific infor-
mation. Only during the compilation, fragmentation,
code rewriting, linking and optimisation processes
such information is added.
Assume that user requests arrive in the form of
DBPQL
1
programs / modules. The DBS component
that processes requests consists of a DBPQL com-
piler, code optimisers, code rewritters (e.g. to map
operations on global OODM objects to local OODM
objects) etc. Here, we follow a black box approach
assuming that incoming DBPQL modules are trans-
formed into optimised evaluation plans, which are
formulated in iDBPQL code.
iDBPQL code is then evaluated by a network of
agents, which are realised as stack-based machines.
1
DBPQL is a high-level DBPL based on the lower-level
iDBPQL language. DBPQL is a modular language that sup-
ports transactions, query processing, generic requests, type,
class and object creation / manipulation commands etc. We
only refer to DBPQL aspects that stem from iDBPQL.
MetaData
Optimisation, Target Code Generation,
Code Analysis, Type Checking, Code
(Query) Optimisation, Fragmentation,
Reflection Support, Code Translation, ...
MetaDataFormulated in iDBPQL Code
(Optimised) Evaluation Plan
Network of Agents
DBPQL Module
DBS Run−Time
iDBPQL
DBPQL
Object−Oriented
global
Data Model
fragmented
Imported
DBPQL Modules
DBPQL Module InterfaceDBPQL Module Interface
Collection of
(global)
values / objects
Collection of
(fragmented)
values / objects
Reverse
Fragmentation
Figure 1: User Requests, Data Models and (i)DBPQL.
Agents are aware of the distributed DBS nature, know
about transactions and utilise simultaneous and dis-
tributed processing. While agents process evaluation
plans, they also interpret annotations that have been
added by the optimiser.
Figure 1 provides a more abstract view of the rela-
tionship between DBPQL, iDBPQL, conceptual data
models and associated processes. A high-level user
is exposed to a few of these elements only (refer to
dotted rectangles in Figure 1), which are as follows:
A programmer codes a DBPQL Module and
its DBPQL Module Interface(s). Modules are
compile-time abstractions that support the devel-
opment of large-scale programs through the sup-
port of service imports and exports. Hence, infor-
mation hiding is supported naturally.
Within a module, DBPQL module interfaces of
existing modules are imported. A DB schema
is regarded as just another module interface with
(possibly) a reduced degree of encapsulation. Fol-
lowing our discussions in Section 2.3, we may
have regular module interfaces that strictly follow
the traditional PL-interpretation of encapsulation
while DB schemata expose both structure as well
as behaviour. Thus, desired support for ad-hoc
querying can be provided.
Modules return results (i.e. collections of (global)
object / values) as specified in their interface(s).
When processing DBPQL modules, code is anal-
ysed, type checked, fragmented, optimised etc. We
will not consider such processes but only their result:
DBPQLs
MAIN
method that initiates the execution
is transformed into an optimised evaluation plan,
the Main Evaluation Plan. An Evaluation Plan
may have an Initialisation Block, which permits
the initialisation of global and local elements be-
fore the start of the evaluation, an evaluation block
and a number of associated metadata structures.
An Evaluation Block consists of iDBPQL state-
ments and expressions. Concepts such as mod-
AN OVERVIEW OF THE OBJECT-ORIENTED DATABASE PROGRAMMING LANGUAGE DBPQL
575
ules, interfaces, type and class definitions, code
structuring primitives etc. have been removed.
One or more schemata from the DBS metadata
catalogue may be associated with the main eval-
uation plan. The DBS MetaData catalogue is a
collection of compiled DB schemata. All schema
imports result in such associations. Due to frag-
mentation, a single DBPQL import may result in
a number of associated iDBPQL schemata.
One or more run-time metadata catalogue entries
are associated with each evaluation plan. The
Run-Time MetaData catalogue is a collection of
type and class definitions introduced in the user’s
source code or its imported modules. While
DBS metadata catalogue entries describe persis-
tent, shared data, run-time metadata catalogue en-
tries relate to transient, non-shared data.
Evaluation plans are associated with every non-
abstract behaviour specification. Classes may have
static variables declared outside of any method. Such
declarations are captured in the class’s initialisation
block. When invoking a method, the corresponding
evaluation plan is executed.
Finally, we want to underline some important
properties of evaluation plans. They differ from the
original DBPQL modules in the following ways:
iDBPQL code refers to DBS metadata or transient
data (i.e. run-time metadata). Original code frag-
ments have been amended in a way that references
to higher-level features have either been removed
or replaced by macros formulated in iDBPQL.
A user program is translated into a main evalu-
ation plan together with associated metadata en-
tries. In turn, these metadata entries and refer-
ences to iDBPQL library features may have fur-
ther evaluation plans associated. Thus, program
execution results in an evaluation of the main eval-
uation plan together with all evaluation plans that
are encountered during its evaluation.
Data definitions are removed from evaluation
plans and now part of the metadata catalogues.
iDBPQL statements and expressions are allocated
to DBS nodes. Thus, an indication about the loca-
tion of the evaluation is provided.
Evaluation plans consist of
DO
...
ENDDO
blocks,
which are used to group statements together,
form atomic execution units, model local and
distributed transactions and support simultaneous
processing.
Indices and other information used to optimise
processing are added (i.e. as annotations) to sup-
port the evaluation of iDBPQL statements.
5 CONCLUSION
We presented an overview of the DB program-
ming and querying language DBPQL. This integrated
language circumvents the impedance mismatch and
unites properties from OOPLs, QLs and DBPLs.
REFERENCES
Atkinson, M., Bancilhon, F., DeWitt, D., Dittrich, K.,
Maier, D., and Zdonik, S. (1989). The object-oriented
database system manifesto. In Proceedings of the 1st
International Conference on Deductive and Object-
Oriented Databases, pages 223–240, Kyoto, Japan.
Atkinson, M. P. and Buneman, P. (1987). Types and per-
sistence in database programming languages. ACM
Computing Surveys (CSUR), 19(2):105–170.
Bloom, T. and Zdonik, S. B. (1987). Issues in the design
of object-oriented database programming languages.
In Conference proceedings on Object-oriented pro-
gramming systems, languages and applications, pages
441–451, New York, NY, USA. ACM Press.
Cook, W. R., Greene, R., Linskey, P., Meijer, E., Rugg, K.,
Russell, C., Walker, B., and Wittig, C. (2006). Objects
and databases: State of the union in 2006. Panel at
the International Conference on Object-Oriented Pro-
gramming, Systems, Languages, and Applications.
Feuerstein, S. and Pribyl, B. (2002). Oracle PL/SQL Pro-
gramming. O’Reilly & Associates, Inc., Sebastopol,
CA, USA.
Kim, W. (1993). Object-oriented database systems:
Promises, reality, and future. In Proceedings of the
19th International Conference on Very Large Data
Bases, pages 676–687, San Francisco, CA, USA.
Morgan Kaufmann Publishers Inc.
Kirchberg, M., Schewe, K.-D., Tretiakov, A., and Wang,
B. R. (2007). A multi-level architecture for dis-
tributed object bases. Data & Knowledge Engineer-
ing, 60(1):150–184.
Leontiev, Y.,
¨
Ozsu, M. T., and Szafron, D. (2002). On
type systems for object-oriented database program-
ming languages. ACM Computing Surveys (CSUR),
34(4):409–449.
¨
Ozsu, M. T., Peters, R. J., Szafron, D., Irani, B., Lipka, A.,
and Mu
˜
noz, A. (1995). TIGUKAT: A uniform behav-
ioral objectbase management system. VLDB Journal,
4(3):445–492.
Schewe, K.-D. and Thalheim, B. (1993). Fundamental con-
cepts of object oriented databases. Acta Cybernetica,
11(1-2):49–84.
Subieta, K. (1991). LOQIS: The object-oriented database
programming system. Lecture Notes in Computer Sci-
ence, 504:403–421.
Subieta, K., Beeri, C., Matthes, F., and Schmidt, J. W.
(1993). A stack-based approach to query languages.
Technical Report 738, Institute of Computer Science
Polish Academy of Sciences, Warszawa, Poland.
ICEIS 2007 - International Conference on Enterprise Information Systems
576