Download Updatable Views in Object-Oriented Database Systems

Mapping Heterogeneous Ontologies
Through Object Views
Kazimierz Subieta
Polish-Japanese Institute of Information Technologies &
Institute of Computer Science PAS, Warsaw, Poland
Poland [email protected]
defined by joins). Moreover, database applications are
written in programming languages (such as C/C++),
which are tightly coupled with physical data structures.
The level of data independence of such languages is too
low to process imaginary data. Additionally, various
kinds of semantic, representational and schematic
discrepancies among heterogeneous data require other
features of views (such as full algorithmic power, access
to metadata, reflective capabilities, recursion, and others)
which are beyond the intellectual scope of the relational
model, relational DBMS, and current theoretical
approaches to databases.
Hence the mentioned above qualities of views are
actually wishes. They are not available for majority of
applications. Most frequently, in addition to views written
in SQL and stored in a database, the applications involve
proprietary solutions written in lower-level languages. For
instance, such an approach is assumed in OMG CORBA
[OMG95], where interfaces in IDL can be considered
virtual views, but mappings between stored and virtual
objects (i.e. adaptors and wrappers) are to be written in a
regular programming language.
In Oracle new ideas are implemented; in particular
views with a check option (preventing undesirable side
effects during view updating) and special options ("do
instead of" triggers) making it possible to control
translations of view updates. Perhaps Oracle is also
pioneering the integration of views into fully-fledged
language for programming database applications
(PL/SQL). There is also an advanced proposal concerning
views in the emerging SQL3 standard [SQL99]. The user
can define views with a check option, updatable,
insertable and recursive. Many very particular details of
the proposal (10 pages of specification), unclear
compatibility with the specification of other constructs of
the language (ca. 1100 pages) and the eclectic nature of
the standard cause doubts if the idea is reasonable and
implementable. Recently significant research is also done
into object-relational mapping through special views, e.g.
[BKSW91, FaRi97, HaKe95, PMSL94, VeAp95]. The
approaches address current need to integrate relational
databases with object-oriented programming languages
and other tools, e.g. CORBA ORBs.
The development of object views is still in the
research stage. To the best of our knowledge, no
commercial OODBMS offers views. Some capabilities
are introduced in the ODMG standard [ODMG00], but
Abstract - The traditional concept of a database view
is currently under influence on new ideas, in particular
the CORBA approach to distributed objects, objectoriented databases, XML and other Web technologies,
semistructured data, and autonomous mobile agents.
These new trends cause widening the scope of database
views by novel features, which are beyond the current
theoretical and conceptual paradigms of database
systems. New concepts related to database views are
wrappers, adaptors, mediators and ontologies. The paper
discusses features of object-oriented views, which have
to fulfill new needs and expectations. The discussion is
focused on integrating heterogeneous databases into a
federated database. Emphasis is put on relaxing the
database view concept from limitations induced by
stereotypes inherited from the relational data model, to
fulfill nowadays requirements concerning efficient
integrating heterogeneous data sources and services.
1 Introduction
A database view defines virtual data that are derived
from stored data and are compliant to the assumed data
model. Such virtual data have to be queried and updated
similarly to stored data. From the user viewpoint there
should be no differences concerning retrieval and
manipulation of stored and virtual data; this property is
known as transparency of views. Virtual transparent
database views are considered very important for current
and future database technologies. The literature presents
many expectations concerning such views, which include
their potential as an integration tool for heterogeneous
database federations. Views allow the designers to map
(heterogeneous, autonomous) local databases according to
a common federated schema [ChMe97, DGS94, Elia95,
JoRi98, KDN90, Paep93, SIMB94, SST92]. Further
expectations concerning views concern a higher level of
data independence, known as schema evolution [Bell97b,
Brat92, BFK95, KaEa98, LDB97]. Views enable the
designers to change a database schema without affecting
already written applications.
Views are a standard functionality of SQL-based
DBMS-s. However, many conceivable mappings between
stored and virtual data cannot be expressed due to the
limited computational power of SQL. View updating is
usually limited to views defined as vertical/horizontal
restrictions of stored relations (plus other limitations;
Oracle, however, allows limited updating of views
1
 Local, autonomous databases supported by local
database management systems.
essentially reduced to macro-definitions (the “define”
clause of OQL). The approach has many limitations and
open issues [Rupp98]. There are several prototypes, in
particular, a prototype for O2 [Souz95], MultiView
[Rund94, Rund96, KuRu96] and stored functions in Loqis
[SMA90, Subi91]. There are also many other papers
(mostly theoretical), in particular, [AbBo91, ABS97,
BaKe93, Bell97a, Bert92, BuFa99, Daya90, GeZi94,
GBCG97, GPZ88, HeZd90, KiKe95, LaSc91, LTY93,
MaBa91, SLT90, SLT91, SuMi89, SAD94]. The
proposals are incompatible and tightly bound to a
particular data model or formalism; thus comparing and
evaluating them is not easy; see [Mots96].
In our opinion, the state-of-the-art concerning
utilization of object views as tools for developing
heterogeneous database federations should be considered
premature at this time. In this paper we try to recognize
major issues that has to be considered and discuss various
research aspects of object views.
The rest of the paper is organized as follows. In
Section 2 we present architectural issues concerning
federated databases. Section 3 is devoted to novel
concepts: wrappers, mediators and ontologies. Section 4
discusses the potential of object models as abstract
canonical ontologies. The section presents also various
aspects of object views. Section 5 discusses the view
updating problem. Section 6 concludes.
 A local database is accessed by a local application
programming interface (API), which exists before
integrating the database within the federation.
 A local API is used by a wrapper, which is dedicated
to a federated database. The role of a wrapper is to
map a local API into a programming interface
expected by the federated system.
 A wrapper makes it possible to build a schema
mapping between API of a federated system and API
of a local system.
 On the side of the federated system there is an API_f
of a federated system. API_f is used by global
applications to access resources stored in local
databases. The access supports transparency: from the
point of view of a programmer all local resources are
seen as a single centralized database.
 There is some network protocol, which is prepared to
connect a global application to local resources.
 Global applications may need an own working
database. In particular, it is necessary for storing
copies of data sent from local databases.
Fig.2 present a more detailed view on the architecture
from the position of an administrator of a local database.
2 Architectural Issues
Local
database
Local
export schema
(schema mapping)
Export
subschema 2
Export
subschema 3
R
Forbidden
Forbidden
Forbidden
Forbidden
R/W
Interface IB1
R/W
Forbidden
R/W
...
...
...
...
View V1
Forbidden
R
R
R/W
Forbidden
Forbidden
Interface IA2
API
Wrapper
...
Export
subschema 1
Interface IA1
Obiekty A
Obiekty A
Obiekty
Data A A
Obiekty A
Obiekty A
Obiekty
Data B A
Local export subschemata
(accessibility matrix)
Ob.wirt. V3
Ob.wirt.
V3V
Virt. data
1
Ob.wirt. V3
Ob.wirt.
V3V
Virt. data
View V2
2
defines
s
ne
mi
ter
de
Local Administrator
User 1
User 2
User 3
Fig.2. More detailed architecture of a local database
In Fig.2 we have shown an API and a wrapper which
adapt the local database to external requests. Assuming
autonomicity of a local database the local database
administrator (DBA) is an authority having two kinds of
functionalities:
Fig.1. Architecture of a federated databases
 Define a part of the local database, which can be
The basic architecture of a federated system is
presented in Fig.1. It consists of the following parts:
accessed from global applications. The functionality
restricts accesses to the local database from the side of
2
 The global application collects results from all sub-
federation. Moreover, it customizes (adapts) the local
database to the standard of the federated schema.
requests; then integrates the particular result into a
global result.
 Determine rights of particular users to access
particular resources of the local database (R - read,
R/W - read and write, etc.).
This scenario is a bit idealistic. For various reasons,
e.g. optimization, it can be modified. The scenario may
assume sequential processing of sub-requests: a next subrequest is generated when previous sub-requests have
returned results (in order to make the next sub-request
more precise, c.f. processing based on semi-joins). It is
also possible to send the result of a sub-request addressing
local database A to a local database B; then, send a subrequest to B; it addresses data stored in B plus data sent
from A. Another method: for the given global request the
federated DBMS collects all the data from local
databases, which are sufficient and minimal for
accomplishing the request. This method implies
generating for the given request sufficient and minimal
sub-views addressing local databases.
Taking a bit idealistic view1, the local DBA has two
kinds of facilities to determine the local export schema:
 Interfaces. DBA can define many interfaces to the
same data. Interfaces are understood as primitive
views, which only restrict and rename stored
properties.
 Views. They enable DBA to define more sophisticated
mapping of local database into federated schema.
Views having the properties of interfaces (mentioned
above) plus selection capabilities are referred to as
data-preserving views. In many cases such views are
insufficient.
3 Wrappers, Mediators and
Ontologies
Interfaces and views defined by the local DBA
implicitly define a local export schema. Such a schema
must be also written explicitly (e.g. by some automatic
facility) as a part of a schema repository. The repository
has the same role as the interface repository in CORBA.
The schema repository is necessary for global
applications e.g. to decompose a global query into subqueries addressing particular local databases.
Another functionality of the local DBA is presented
conceptually in the form of an accessibility matrix. It
enables the administrator to grant access rights for
particular users. In this way each user sees the local
database through its own export sub-schema. For some
applications this functionality might be omitted, i.e. from
the position of the local DBA all users of global
applications have the same rights.
The sum of all local exported schemas constitutes the
entire federated schema. Analogously, the sum of all
exported sub-schemata for a particular user constitutes
his/her external schema to the entire federated database.
The general scenario of processing requests (queries)
which uses this architecture is the following:
Recently Internet, Web and development of fast and
wide computer networks have caused a big pressure to
integrate heterogeneous, geographically distributed data,
which are not necessarily under the control of some
DBMS. New terms are coined to denote various situations
related to integrating heterogeneous data sources.
Wrappers or adaptors (coming from the CORBA and
Internet camps) are specialized program modules making
it possible to map an internal API to the external API
expected by some global application. Usually the
mapping rises the level of abstraction, for instance, in
CORBA applications the internal API is a collection of
some C++ functions while an external API is an IDL
interface. Wrappers are considered non-sophisticated
programs for changing data representation, names of
functions, etc. Moreover, wrappers are usually dealing
with data units of low granularity (e.g. tuples rather than
tables) and mapping is 1:1, i.e. one "internal" data granule
(e.g. a relational tuple plus subordinated tuples) is
conceptually mapped into one "external" data granule
(e.g. a CORBA object). A wrapper can be considered a
"physical bridge" between local databases and global
applications.
Another concept is mediator [Wied92]. It comes from
the camp of data warehouses and integrating semistructured data. Till now, however, the concept is intuitive
and defined pragmatically rather than semantically or
theoretically. A mediator has to resolve (semantic,
representational, structural, schematic) incompatibilites
among data to be integrated. A similar role is assigned to
database views; moreover, there are proposals, which
treat mediators as virtual views [BRU96]. Perhaps the
conceptual border between database views and mediators
is difficult to define, but there are essential pragmatic
 A global application's request (a query) refers to the
global view (the federated schema).
 The request is decomposed into sub-requests
addressing particular local object views.
 Each sub-request is mapped by a local view mapping
mechanism and wrapped into a request addressing
local data.
 Such a request is executed within a local database.
The result is mapped through the wrapper, then
through the local view and returned to the global
application.
1
In many cases the local DBA uses specific facilities, which cannot be
classified as interfaces or views.
3
 Performance concerning data accesses and processing;
differences, which allow us to consider mediators as a
new quality:
 Privacy, safety and security issues; transaction
processing;
 Mediators can act on irregular data and can produce
irregular data, while database views act on formatted
data (e.g. tables) and produce formatted data
 Exceptions, error messages, extreme cases, null values,
side effects, and other exceptional issues;
 According to (false) stereotypes of the relational
model, a database view is to be defined by a single
query (e.g. in SQL). However, current query languages
have the power much below the algorithmic power.
Mediators do not assume such limitations. The
designers of mediators can use the full power of
algorithmic programming languages as well as
advanced higher-level methods, including methods
attributed to artificial intelligence.
 Associations and other semantic dependencies among
data;
 Issues related to API to data and data services, in
particular, syntax, semantics and operational
pragmatics of a query language;
 Data naming conventions; meaning of data names in
the reality;
 Peculiarities of data representation.
 Mediators can use any resources from the computer
environment (e.g. data written in files) while database
views can use only resources stored in a database.
 Metadata information related to data and services.
Formally, an ontology is defined as a specification of
conceptualization [GrOl94], i.e. a description (like a
formal specification of a program) of the concepts and
relationships that can exist in a particular data/service
environment. The postulated "formal specification" is an
idealistic (and obviously utopian2) assumption promoted
by AI theoreticians. As a matter of fact, current
data/service environments are too complex to specify
them by a formal logic (or even by any mathematical
framework). In reality some elements of an ontology can
be defined formally (for instance, schema and metaschema), some half-formally (for example, the semantics
of object interfaces), and some informally (for example,
mappings between objects and the business domain).
Nevertheless, ontology is a useful concept, because it
allows us to denote the real scope of issues that the
designers of heterogeneous systems have to deal with,
without binding them to current limited database models
and theories.
Different data servers have different ontologies. Even
if the servers are supported by the same DBMS, the
differences may concern semantics of data in the business
domain, structuralization of data, representation of data,
etc. Having a common ontology enables collaborators to
work together with minimal risk of misunderstanding
each other [Wied94].
The task of designers of federated applications based
on heterogeneous data/service sources can be subdivided
into the following steps:
 Database views themselves are stateless: each
invocation of a view cannot utilize information from
previous invocations of the same view. (Stateful views
are referred to as capacity-augmenting views; they are
considered yet as a research topic.) Stateful mappings
cannot be avoided in many global (federated)
applications. Mediators can be stateful with no
limitations.
 Database views are self-contained named entities
defined in a special syntax of a query language and
stored in the database as identifiable persistent units. In
contrast, mediators are programs written in a regular
programming language and stored as a part of an
application program in main memory. Thus, mediators
have much lower abstraction level and maintenance
potential than database views.
Another term related to integrating heterogeneous data
sources is ontology. An ontology is a formal theory or
description of a being or reality. The term has a long
history in philosophy, but it comes to the database world
from the world of artificial intelligence. In this context the
term has a technical meaning. It is understood as a formal
description of everything that the designer or programmer
has to know about some particular data/service
environment to use it correctly and efficiently in a
particular application. Note that ontology is a more
general term than a database schema or a database view.
From the database perspective an ontology includes
formalization of the following issues:
 Understanding ontologies of all participating
data/service sources and describe it (formally, semiformally or informally);
 The meaning, pragmatics and behaviour of data and
data services in the (business) reality;
 Developing a common ontology which will satisfy the
needs of future global applications, and on the other
 Static and dynamic constraints among data; causeeffect relationships;
 Associations among data and services (methods,
procedures, etc.) acting or utilizing data;
 Peculiarities
utilization;
of
data
access,
maintenance
2
Papers concerning mapping between heterogeneous ontologies for
autonomous mobile agents (considered by AI) remain early theoretical
ideas discussed by the database camp in late 70-ties. From that time the
database domain has made important steps to full awareness of the
problem. It seems not to be fully recognized yet by the AI camp.
and
4
hand, will correspond to all participating data/service
sources; such a common ontology is called canonical.
non-normalized relations (NF2), a variety of object
algebras, F-logic, comprehensions, monoid calculus, and
other, see e.g. [AHV95, AlAr93, BNPS92, BRU96,
Clue98, DaDe91, FeMa95, GKGH+97, HeSc91, KiLa89,
LaSc93, LMSV+93, ShZd90]. There is little agreement
which model is adequate for investigations concerning
object views.
In general, capabilities of view definitions can be a
subject of various assumptions. The most comfortable
case is when views are provided as an additional facility
for retrieval. In this case the user can use the new
possibility or not, depending on the problem, familiarity
with the new option, his/her customs, etc. On the opposite
extreme we have a non-comfortable case, when views are
to be used for integrating hundreds heterogeneous
databases, according to some federated ontology, which
includes data model, programming interfaces, naming
conventions, representation of values, semantics of values
in the business domain, exchange formats, etc. In such a
case the capabilities of view definitions are to be
comparable to the capabilities of universal programming
languages, including access to metadata, reflection,
recursion, full algorithmic power, advanced view
updating, complex data structures, and many other
features. For instance, resolving schematic discrepancies
among heterogeneous databases [KLK91] requires access
to metadata and reflection. Similarly, dynamic
invocations within CORBA environments require
accesses to an interface repository, which is a recursive
structure. Assuming it will be seen through database
views, it should be possible to use recursive views,
queries with transitive closures or other equivalent
facilities.
A basic misconception concerning object views is that
proponents of ideas do not realize that the second, noncomfortable extreme presents a very wide and unexplored
terra incognita. The typical paper at the beginning
contains promises addressing the non-comfortable
extreme. Then, there is a concrete syntax and semantics,
which is frequently advanced and complex, but obviously
close to the first extreme: a view definition is reduced to a
single query in some limited query language (much below
the algorithmic power), with a lot of additional options,
perhaps important, but secondary. This style of research
papers cause that the progress in the domain is difficult to
evaluate and cause frustrations [DVB93].
Generality of object-oriented views requires many
features:
 Developing a formal mapping between ontologies of
participating databases and a canonical ontology.
Any low-level or unspecified details of ontologies
decrease the potential of common understanding. Hence
the requirement that a canonical ontology has to be
defined on a high abstraction level, which hides
implementation details of participating ontologies. This
point of view is taken by OMG CORBA, which uses
some variant of an object model as a basis for a canonical
ontology.
In OMG CORBA the mapping between a particular
ontology and a canonical ontology is determined through
wrappers and adaptors written in regular programming
languages. The CORBA object model, although powerful,
is not sufficient from the database perspective. A more
powerful object model, which includes collections,
relationships and other features of databases, is proposed
by ODMG [ODMG00]. Still, the ODMG object model is
considered limited for many applications. Moreover, it is
recently under some critics concerning the insufficient
level of precision and consistency (see papers by the
authors of the IRO DB project, papers by Suad Alagic,
and other sources).
Developing a mapping between a particular ontology
and a canonical ontology is frequently a difficult task. For
various types of discrepancies between data and services
the mapping cannot be reduced to defining views in some
query language. The mapping requires deep
understanding of formal properties of data and services,
as well as understanding of the meaning of data in the
business domain. This goal requires query/programming
languages and tools, which will be either powerful
(universal), abstract, and simple to use. In the following
we discuss the potential of object views to fulfill this role.
4 Object Models as Abstract
Canonical Ontologies
The object-orientedness is currently the major
paradigm of many domains of computer technologies,
including the analysis and design of software systems,
programming languages, interoperability, componentbased software, databases, visual programming interfaces,
and others. Thus the natural expectation that the objectoriented paradigm is a viable candidate for developing a
canonical ontology for heterogeneous database
federations. There are also expectations that the research
into object views will result into a powerful and simple
tool for determining mappings between ontologies.
Object database models introduce many notions thus
the formalization of their features (data structures, query
languages, views, etc.) is more complex than in the
relational case. There are many proposals: the ODMG
object model and approaches to formalization of OQL,
 Restricting and renaming attributes in virtual objects
(cf. SQL);
 Possibility to define virtual attributes;
 Views joining information from two or more (stored or
virtual) objects;
 Views with parameters, recursive, and higher-order;
views defined by complex algorithms, with the
5
possibility of access to metadata and reflective
capabilities.
Other optimization techniques, known as materialized
views, assume various forms of caching results returned
by view invocations.
 Updatable views supporting the transparency principle.
The correct translation of view updates is a big
problem, which till now has no proper treatment.
Majority of approaches to object-oriented queries is
unable to correctly formulate this problem, because
updating operations are not expressible in proposed
formal frameworks, e.g. an object algebra.
4.2
In principle, views are virtual, i.e. they exist only as a
definition of a mapping between stored data and
imaginary data. For several reasons (optimization,
security, accessibility, parallelization, etc.) many authors
have proposed materialized views. They assume that the
result returned by view invocation is calculated in
advance. A disadvantage of materialized views concerns
updating of stored data, which implies updating
materialized views. To cope with this issue various
techniques are proposed. The majority of them assume
incremental updating, i.e. updating the minimal part of a
materialized view, which is to be influenced by updating.
To accomplish this kind of algorithm the view definition
must satisfy the distributivity property. It can be roughly
formulated as:
 Integration of notions such as strong typing, classes,
encapsulation, inheritance, methods, etc.
 Development of methods to avoid performance penalty
due to view processing.
To be more close to the non-comfortable extreme of
view definition capabilities there is a need to extend the
scope in which object views are typically set. Object
views should follow the paradigms of programming
languages rather than traditional database concepts, such
as relational/object algebras or calculi. Assuming queries
are programming languages’ expressions, the concept of
programming languages that is analogous to database
views is a functional procedure (i.e. a procedure returning
an output) [SKL95, Subi97]. If a first-class, dynamically
bound procedure is stored in a databases and returns a
collection, then an invocation of the procedure is
semantically equivalent to execution of a query. Such a
procedure will be defined by queries and can be called
within queries.
The goal of the research into such object views is to
integrate the above idea with query languages into a
homogeneous, semantically simple, consistent and
universal system.
4.1
Virtual vs. Materialized
v(s1  s2) = v(s1)  v(s1)
where v(s) is the result returned by the view v for
database state s; s1, s2 are any data states that the view v
concerns; and  is a state composition operator (e.g.
union of sets). The distributivity property makes it
possible to keep a 1:1 relationships between database
objects and elements of a materialized view.
An interesting variant of a materialized view is when
it stores not newly calculated data, but references to
stored data. For instance, this kind of view can be defined
in Loqis as a function:
function RichEmp
begin return EMP where SAL > 2000 end;
Performance of Object Views
The function returns references (OIDs) to object of
employees earning more than 2000. Such a view shares
(to some extent) advantages of virtual and materialized
views. In particular, updating of any attribute (except
SAL) in EMP objects causes no changes in the
materialized view. Actions on the view are necessary in
the case of deleting and inserting EMP objects and in the
case of updating the SAL attribute in any object. The idea
can be generalized to materialized views which return not
only references to objects, but also references to attributes
and methods.
The majority of approaches to object views assume
(sometimes implicitly) that virtual objects are eventually
calculated when the corresponding view is used in a
query. For many applications such an approach will result
in very bad performance. Relational systems use a query
modification technique, which practically avoids any
performance/storage overhead related to processing
views. Query modification assumes macro-substitution of
view invocations [SuPl00] and then optimizing resulting
queries by rewriting [PlSu99, PlKr99, Plod00]. A big
advantage of query modification is that in many cases it
enables using other very efficient techniques, for example
indices and other access support data structures.
Another optimization technique, known as predicate
move-around [LMS94], is similar to query modification,
but works in otherwise direction. The technique assumes
that a predicate occurring in a query invoking a view
modifies the view definition. The technique can be
efficient when a view is defined by a complex algorithm
(thus query modification is not applicable).
4.3
Views Defined by Complex Algorithms
Traditionally, a database view is to be defined by a
single query. For complex mappings between local and
federated ontologies this assumption leads to severe
limitations, because the power of all known query
languages (including SQL and OQL) is much below the
algorithmic power. In Loqis this limitation is avoided. For
example, the WellPaid function has a parameter JobPar
and a local variable a:
6
function WellPaid( JobPar )
begin
real a := avg(EMP.SAL);
return EMP where JOB = JobPar and SAL > 2*a;
end;
as a rule - are not sufficiently general and not well
understood. In effect, view updating was limited to
particular cases. Another disadvantage of the relational
research into view updating concerns some naive
(implicit) assumptions that the transformation of view
updates has to be done into some auto-magical way, e.g.
by utilizing functional dependencies and other properties
of relations stored in the database. In general,
transformations of view updates have to be controlled by
the view definer by special options dedicated to this
purpose. This is eventually accomplished in Oracle-8, but
the solution is not sufficiently general yet and has no
theoretical or conceptual background.
Object databases open new horizon for the view
updating problem. Some part of the object databases
camp follows more general theoretical paradigms based
on the semantics of programming languages rather than
(obsolete and inefficient) paradigms based on algebras,
calculi or logic. From the position of the programming
languages' semantics (including operational and
denotational semantics) updating operators are regular
operators, thus the research concerning view updating can
be based on a stable fundament.
Concerning updating of object views we can
distinguish two cases:
Get companies where well-paid clerks used to work
previously:
WellPaid( "clerk ").PREV_JOB.COMPANY
Although the presented "algorithm" is very simple, in
general there are no limitations. A wider discussion
concerning various features of object views implemented
in Loqis (views defined by joins, virtual attributes, virtual
links, etc.) can be found in [SuPl00].
4.4
Object Views as Database Modules
The relational model has introduced some ambiguity
concerning the term "view". Essentially, database design
methodologies as well as the ANSI/SPARC architecture
regard a view as some part of the database schema, or
(more precisely) as some mapping between a database
schema and an external (user) schema. In contrast, an
SQL view is essentially a programming function (like
functions or functional procedures in Pascal or C) which
maps stored tables into a virtual table.
In general the SQL approach to views is limited. A
view should be defined as a module, which stores several
named functions (a la SQL views). Such a module should
follow the maintenance semantics of SQL views, i.e. it
can be stored in a database and deleted from the database.
A module being a view can store other run-time entities,
in particular:
 Common private functions;
 Public and private classes necessary for the view
definition; methods within these classes;
 Constraints and rules; for instance, rules for view
updating;
 Public and private persistent data; for instance, data
necessary for capacity-augmenting views.
a)
Data can be updated by generic operations, i.e.
assignment, deleting and inserting.
b) Data cannot be updated by generic operations. Any
updating of data objects has to be done by methods
(following
the
narrow
understanding3
of
encapsulation).
The case b) implies no special conceptual problems
with view updating. In this case the view definer has to
define a view together with a class that virtual objects will
belong to. The class stores all the methods (written or
adopted by the view definer) necessary for updating
virtual objects. During writing the methods the view
definer has full access to stored data objects, thus can
update them with no limitations. There is some danger of
inconsistent updates, thus one research problem concerns
automatic discovering of them. Another problem concerns
connecting the objects generated by a view invocation to
the methods stored within the class. Assuming views are
dynamically bound and methods are statically bound this
can imply technical difficulties.
In majority of cases we cannot avoid generic updating
operations. However, the case a) is more challenging for
researchers. The simplest solution we obtain assuming
that a view invocation returns references to stored objects
rather than new objects. These references can be used as
l-values in assignment and deleting statements. (Inserting
is problematic.) The case is generalized in Loqis, where a
5 Updatable Views
The majority of research and development devoted to
heterogeneous database federations assume that global
applications are based purely on retrieval from local
databases. Some applications, however, strongly depend
on updating. In case of heterogeneous database
federations this updating is to be done through local views
and wrappers.
Updatable views, which follow the transparency
principle (i.e. the user does not know whether she is
working with stored or virtual data) are still in infancy.
Typical theoretical paradigms (relational algebras,
relational calculi and formal logics) do not deal with
updating operations. Thus updating is to be introduced by
some ad hoc enhancements to these formalisms, which -
3
The understanding of the concept of encapsulation can be different.
Originally (as proposed by D.Parnas) it means subdividing object's
properties into public and private, independently of the property's kind
(c.f. Modula-2 and C++). Many authors are trying to promote the narrow
view, where only some methods are public; other properties are private.
7
view invocation can also return structures built upon
references to attributes. This allows one to update views
defined by complex queries, including queries defined by
joins. Such an updating, however, may lead to undesirable
side effects, thus additional syntactic and semantic
features are necessary to prevent them.
The most general case (currently under investigations)
is based on virtual object identifiers. They are returned by
view invocations. Virtual identifiers are complex
structures storing all the information about the "origin" of
the virtual object. Virtual identifiers make it possible to
overload generic view updating operations by specific
methods defined by the view definer [SuMi89]. During
writing the methods the view definer has full access to
stored data objects, thus can update them with no
limitations (similarly to the case b)). The overloading
methods are fully transparent for the view user: she is
using generic updating operations with no differences.
Although conceptually the method seems to be viable and
implementable, there are many details (optimization, in
particular), which so far are not sufficiently investigated.
[BaKe93] Barclay, P.J., J.B. Kennedy. Viewing Objects.
British National Conf. on Databases, Springer LNCS 696,
1993.
[BKSW91] Barsalou, T., A.M. Keller, N. Siambela, G.
Wiederhold: Updating Relational Databases through
Object-Based Views. SIGMOD Conf., 248-257, 1991
[Bell97a] Bellhasene, Z. Identifying Virtual Composite
Objects: a Step Forward to Updated Object Views.
DEXA Conf., 523-528, 1997
[Bell97b] Bellahsene, Z. Extending a View Mechanism
to Support Schema Evolution in Federated Database
Systems. Proc of DEXA Conf., 573-582, 1997
[Bert92] Bertino, E. A View Mechanism for ObjectOriented Databases. Advances in DB-Technology,
EDBT Conf., Springer LNCS 580, 136-151, 1992
[BNPS92] Bertino, E., M. Negri, G. Pelagatti, L. Sbatella.
Object-Oriented Query Languages: The Notion and
the Issues. IEEE TKDE 4, 223-237, 1992
[Brat92] Bratsberg, S.E. Unified Class Evolution by
Object-Oriented Views. ER Conf., 423-439, 1992
[BFK95] Breche, P., F. Ferrandina, M. Kuklok:
Simulation of Schema Change Using Views. DEXA
Conf., 247-258, 1995
[BRU96] Buneman, P., L. Rashid, J. Ullman. Mediator
Languages - a Proposal for a Standard. Report of an
I3/POB Working Group, University of Maryland, April
1996
[BuFa99] Busse, R., P. Fankhauser. Declarative and
Procedural Object-Oriented Views. ICDE Conf., 1999
[ChMe97] Chen, R., W. Meng. Efficient View
Maintenance in a Multidatabase Environment. Proc of
DASFAA Conf., 391-400, 1997
[Clue98] Cluet, S. Designing OQL: Allowing Objects to
be Queried. Information Systems 23(5), 279-305, 1998
[DaDe91] Davis, K.C., L.M.L. Delcambre. A
Denotational Approach to Object-Oriented Query
Language Definition, Intl. Workshop on Specifications
of Database Systems, Workshops in Computing Series,
Springer-Verlag 1991.
[Daya90] Dayal, U. Queries and Views in an ObjectOriented Data Model. 2nd DBPL Workshop, Morgan
Kaufmann, 80-102, 1990
[DVB93] de Graaff, J.M., R. J. Veldwijk, M. Boogaard:
Logical Data Independence Via Views: A
Misapprehension? DASFAA Conf. 313-323, 1993
[DGS94] Durant, J., M. Ganti, R. Salinas. Object View
Broker: A Mediation Service And Architecture to
Provide Object-Oriented Views of Heterogeneous
Databases. ADB Conf. 412-428, 1994
[Elia95]Eliassen, F. Managing Identity in Global
Object Views. RIDE-DOM, 70-77, 1995
6 Conclusion
The paper is presents a research agenda concerning
objects views considered as a tool for mapping
heterogeneous ontologies into a federated ontology. We
have tried to show that many research efforts devoted to
this topic present too narrow understanding of the
problem, thus the produced results we consider
premature. The complexity of database ontologies
requires novel approaches, which are going far beyond
the traditional paradigms known from the relational
model. These approaches should assume a rich and
abstract canonical object model, in order to cover all
conceptual issues that may occur in local databases to be
integrated. Moreover, object views should be defined as
complex database modules, having full algorithmic power
and dealing with complex data structures and abstractions.
7 References4
[AbBo91] Abiteboul, S., A. Bonner. Objects and Views.
SIGMOD Conf., 238-247, 1991
[AHV95] Abiteboul, S., R.Hull, V. Vianu. Foundations
of Databases. Addison-Wesley, 1995
[AlAr93] Alhajj, R., M.E. Arkun. A Query Model for
Object-Oriented Databases. ICDE Conf., 163-172, 1993
[ABS97] Amer-Yahia, S., P. Breche, C. Souza dos
Santos. Object Views and Updates. Engineering of
Information Systems Journal 5(1), 1997
4
Acronyms of journals and conferences according to the M. Ley DBLP
Bibliography, http://www.informatik.uni-trier.de/~ley/db/index.html
8
[FaRi97] Fahl, G., T. Risch. Query Processing Over
Object Views of Relational Data. VLDB Journal 6(4),
261-281, 1997
[FeMa95] Fegaras, L., D. Maier. Towards an Effective
Calculus for Object Query Languages. SIGMOD
Conf., 47-58, 1995
[GeZi94] Gentile, M., R. Zicari. Updating Views in
Object-Oriented Database Systems. Intl. Symposium on
Advanced Database Technologies and their Integration,
Nara, Japan, 1994
[GPZ88] Gottlob, G., P. Paolini, R. Zicari. Properties
and Update Semantics of Consistent Views. ACM
Transactions on Database Systems, 13(4), 1988
[GrOl94] Gruber, T.R., G. Olsen. An Ontology for
Engineering Mathematics. 4th International Conference
on Principles of Knowledge Representation and
Reasoning, Bonn, Germany. Morgan Kaufmann 1994.
[GKGH+97] Grust, T., J. Kröger, D. Gluche, A. Heuer,
M.H. Scholl. Query Evaluation in CROQUE - Calculus
and Algebra Coincide. Advances in Databases. 15th
British National Conference on Databases. Springer
LNCS 1271, 84-100 , 1997
[GBCG97] Guerrini, G., E. Bertino, B. Catania, J. GarciaMolina. A Formal Model of Views for Object-Oriented
Database Systems. Theory and Practice of Object
Systems, 3(3), 157-183, 1997
[HaKe95] Hamon, C., A.M. Keller: Two-Level Caching
of Composite Object Views of Relational Databases.
ICDE Conf., 428-437, 1995
[HeZd90] Heiler, S., S. Zdonik. Object Views:
Extending the Vision. ICDE Conf., 1990
[HeSc91] Heuer, A., M.H. Scholl. Principles of ObjectOriented Query Languages. GI Conf. on Database
Systems for Office, Engineering and Scientific
Applications, Springer-Verlag, 178-197, 1991
[JoRi98] Josifovski, V., T. Risch: Calculus-Based
Transformations of Queries over Object-Oriented
Views in a Database Mediator System. CoopIS, 218231, 1998
[KDN90] Kaul, M., K. Drosten, E.J. Neuhold:
ViewSystem: Integrating Heterogeneous Information
Bases by Object-Oriented Views. ICDE Conf. 2-10,
1990
[KaEa98] Kaushal, R., B. Eaglestone. View-Based
Support for Transparent Schema Evolution in
Federated Database Systems. IADT Conf., 160-167,
1998
[KiLa89] Kifer, M., G. Lausen. F-logic: A Higher-Order
Language for Reasoning About Objects, Inheritance
and Scheme. SIGMOD Conf., 1989
[KiKe95] Kim, W., W.Kelley. On View Support in
Object-Oriented Database Systems. (In) Modern
Database Systems, Addison-Wesley, 108-129, 1995
[KLK91] Krishnamurthy, R., W. Litwin, W. Kent.
Language Features for Interoperability of Databases
with Schematic Discrepancies. SIGMOD Conf., 40-49,
1991
[KuRu96] Kuno, H.A., E.A. Rundensteiner. The
MultiView OODB View System: Design and
Implementation. Theory and Practice of Object Systems.
Special Issue on Subjectivity in Object-Oriented Systems,
1996
[LaSc91] Laasch, C., M.H. Scholl, M.Tresch. Updatable
Views in Object-Oriented Databases. 2nd DOOD
Conf., Springer LNCS 566, 1991
[LaSc93] Laasch, C., M.H. Scholl. A Functional Object
Database Language. 4-th Intl. Workshop on Database
Programming Languages, Springer Workshops in
Computing, 1993, 136-156, 1993
[LDB97] Lacroix, Z., C. Delobel, P. Brèche. Object
Views and Database Restructuring. DBPL Conf., 1997
[LMSV+93] Leung, T.W., G. Mitchell, B. Subramanian,
B. Vance, S.L. Vandenberg, S.B. Zdonik. The AQUA
Data Model and Algebra. 4-th Intl. Workshop on
Database Programming Languages, Springer Workshops
in Computing, 157-175, 1993
[LMS94] A.Y.Levy, I.S.Mumick, Y.Sagiv. Query
Optimization by Predicate Move-Around. 20th VLDB
Conf., 1994, pp.96-107
[LTY93] Ling, T.W., P.K. Teo, L.L. Yan. Generating
Object-Oriented Views from an ER-Based Conceptual
Schema. DASFAA Conf., 148-155, 1993
[MaBa91] Mamou, J.-C., C. Bauzer-Medeiros.
Interactive Manipulation of Object-Oriented Views,
ICDE Conf., 1991
[Mots96] Motschnig-Pitrik, R. Requirements and
Comparisons of View Mechanisms for ObjectOriented Databases. Information Systems, 21(3), 229252, 1996
[ODMG00] ODMG Team. The Object Data Standard
ODMG 3.0. R.G.G. Cattel, D.K. Barry, Eds., Morgan
Kaufmann, 2000
[OMG95] OMG Team. Object Management Group,
CORBA: The Common Object Request Broker
Architecture and Specification. July 1995, Release 2.0.
[Paep93] Paepcke, A. An Object-Oriented View Onto
Public, Heterogeneous Text Databases. Proc of ICDE
Conf. 484-493, 1993
[PMSL94] Pirahesh, H. B. Mitschang, N. Südkamp, B.G.
Lindsay. Composite Object Views in Relational
DBMS: An Implementation Perspective. EDBT Conf.,
23-30, 1994 (also) IS 19(1): 69-88 (1994)
[PlSu99] Płodzień, J., K. Subieta. Optimization of
Object-Oriented
Queries
by
Factoring
Out
Independent Subqueries. Institute of Computer Science
Polish Academy of Sciences Report 889, Warsaw,
November 1999
9
[PlKr99] Płodzień, J., A. Kraken. Object Query
Optimization in the Stack-Based Approach. 3rd Conf.
on Advances in Databases and Information Systems
(ADBIS’99) Springer LNCS 1691, 303-316, Sept. 1999
[Plod00] Płodzień, J. Optimization Methods in Object
Query Languages. PhD Thesis. Institute of Computer
Science Polish Academy of Sciences, Warsaw, February
2000
[Rund94] Rundensteiner, E.A. A Classification
Algorithm for Supporting Object-Oriented Views.
CIKM, 18-25, 1994
[Rund96] Rundensteiner, E.A. Object-Oriented View
Technology: Challenges and Promises, Intl. Symposium
on Cooperative Database Systems for Advanced
Aplications, Kyoto, Japan, 1996.
[Rupp98] Rupp, S. A Critique of Release 2.0 of ODMG93
Standard.
http://gameboy.gia.rwthaachen.de/odmgbugs
[SIMB94] Sarriguren, A.G., A. Illarramendi, E. Mena,
J.M. Blanco: Query Processing in a Multidatabase
System with an Integrated View Based on Description
Logics. FQAS Conf., 87-100, 1994
[SLT90] Scholl, M.H., C. Laasch, M. Tresch. Views in
Object-Oriented Databases. FMLDO, 37-58, 1990
[SLT91] Scholl, M.H., C. Laasch, M. Tresch. Updatable
Views in Object-Oriented Databases. 2nd DOOD Conf.
Springer LNCS 566, 1991
[SQL99] ISO-ANSI Working Draft. Database Language
SQL - Part 1: SQL/Framework, March 1999
[SST92] Scholl, M.H., H.-J. Schek, M. Tresch. Object
Algebra and Views for Multi-Objectbases. Intl.
Workshop on Distributed Object Management,
Edmonton, Canada, 1992
[ShZd90] Shaw, G.M., S.B. Zdonik. A Query Algebra
for Object-Oriented Databases. ICDE Conf., 152-162,
1990
[Souz95] Souza dos Santos, C. Design and
Implementation of Object-Oriented Views, DEXA
Conf. 1995, Springer LNCS 978, 91-102, 1995
[SAD94] Souza dos Santos, C., S. Abiteboul, C. Delobel.
Virtual Schemas and Bases, EDBT Conf., Springer
LNCS 779, 81-94, 1994
[SuMi89] Subieta, K., M. Missala. View Updating
Through Predefined Procedures. Information Systems
14(4), 291-305, 1989
[SMA90] Subieta, K., M. Missala, K. Anacki. The
LOQIS System. Institute of Computer Science Polish
Academy of Sciences, Report 695, Warszawa, Nov. 1990
[Subi91] Subieta, K. LOQIS: The Object-Oriented
Database Programming System. 1st Intl. East/West
Database Workshop, Kiew, USSR 1990, Springer LNCS
504, 403-421,1991
[Subi97] Subieta, K. Object-Oriented Standards: Can
ODMG OQL be Extended to a Programming
Language? (In) Cooperative Databases and Applications,
World Scientific, 459-468, 1997
[SKL95] Subieta, K., Y. Kambayashi, J. Leszczyłowski.
Procedures in Object-Oriented Query Languages. 21st VLDB Conf., 182-193, 1995
[SuPl00] Subieta, K., J. Płodzień. Object Views and
Query Modification. 4th IEEE Intl. Baltic Workshop on
Databases and Information Systems, June 2000.
[VeAp95] Vermeer, M.W.W., P.M.G. Apers. ObjectOriented Views of Relational Databases Incorporating
Behaviour. DASFAA Conf. 26-35, 1995
[Wied92] Wiederhold, G. Mediators in the Architecture
of Future Information Systems, IEEE Computer
Magazine, March 1992
[Wied94] Wiederhold, G. An Algebra for Ontology
Composition. ARPA and Standford University Report,
1994
10