Building object oriented applications which access relational data introduces a number of technical issues for developers who are making the transition to C++. We describe these issues and discuss how we have addressed them in Persistence, an application development tool that uses an automatic code generator to merge C++ applications with relational data. We use client-side caching to provide the application program with efficient access to the data. 1. INTERFACING C++ CLASSES WITH RELATIONAL DATA Object orientation promises dramatic benefits in software productivity, quality and reusability. Yet as with most technology innovations, it requires a significant break from the development practices of the past. Specifically, the difficulty of integrating objects with relational databases has emerged as a major barrier to adoption of object technology by developers who have a significant existing base of hierarchical or relational data. Today, C++ developers have to hand code an interface...

. The relational model supports the view concept, but relational views are limited in structure. OODBMSs do not support the view concept, so that all applications must share the same arrangement of object classes and inheritance. We describe the Penguin system and its support for the view concept. Each application can have its own arrangement of object classes and inheritance, and these are defined as views of an integrated, normalized conceptual data model, in our case the Structural Model. We define view-objects in a language-independent manner on top of the conceptual data model. These view-objects can be complex objects supporting a composite structure. We discuss the extension of Penguin to support PART-OF (reference) and IS-A graphs for composite view-objects. We also discuss the C++ binding to Penguin, where C++ code is generated for object classes corresponding to the view-objects along with basic operations on them (creation, query, navigate, browsing, and update). 1 Introduct...

Client applications usually hold #derived# subsets of the database contents under their control. The incremental maintenance of such externally materialized views is an important open problem. In addition to some necessary changes in the known view maintenance procedures the issue of translating updates through an API and away for clients to accept such updates have to be de#ned. This paper presents the properties of an incremental view maintenance procedure which is able to handle externally materialized views and is implemented in the deductive and object-oriented database system ConceptBase. In particular we describe the concepts for supporting direct modi#cations of data structures representing the materialized views on the client side. Keywords: incremental view maintenance, view materialization, API generation, active noti#cation, deductive and object oriented databases 1 Introduction A view on a data or knowledge base is called materialized if its contents - derived...

Many information systems are implemented as application programs connected to a database system. A characteristic problem of such systems is the famous impedance mismatch, i.e., the conceptual distance between the programming and the database languages. The traditional solution is to implement an interface that transforms one representation into the other. Commercial database systems offer preprocessors that allow to embed the database language (e.g., SQL) into the programming language (e.g., C). Such an approach frees the application programmer from the task to specify details of the communication. However, the impedance mismatch is not solved but aggravated. The set-oriented database language is intermixed with the element-oriented programming language, a notorious cause for programming errors. Moreover, there is no support in mapping the restricted data representation of databases into the more complex type system of programming language. This paper proposes an intermediate language...

Abstract: This paper presents the underlying philosophy of GinisNT, an object-relational framework for developing OO, scaleable GIS applications. GinisNT is based on a mediator and is implemented on top of the relational data model. The Mediator automatically maps between the two data models, thus making the usage of a RDBMS transparent to the user, who can concentrate on the application itself.

In this paper we examine the concepts of object-oriented paradigm and characteristics of spatial data management in order to argument their compatibility. Most problems with GIS applications come from inadequacies and low expressiveness of computational models used and the impedance mismatch problem. The OO paradigm is a natural one for highly complex domains such as ones involving spatial entities, because it maintains a direct correspondence between real-world and application objects. The paradigm also supports all phases of software development. We analyze two different approaches to OO development of GIS applications, based on OO and relational DBMSs. The conclusion is reached that as the OO databases has still a number of problems to be solved, the approach based on relational DBMSs provides the necessary effectiveness, ease of use and reusability of existing resources.

. A common problem within most large corporations nowadays is the diversity of database systems that are employed by their many departments in the development of a product. Usually, the total corporate data resource is characterized by multi-vendor database servers which, unfortunately, have no ability to relate data from heterogeneous data sources. In this paper, we present a database access interface which allows users to formulate SQL2 queries in a homogeneous way against a federation of heterogeneous databases. The database heterogeneity is not only completely hidden from the user, but what the user really perceives is a global database schema which can be queried as though all data reside in a single local database when, in fact, most of the data are distributed over heterogeneous, autonomous, and remote data sources. Further, the users can navigate through the database complex and compare, join, and relate information via a single graphic interface. 1