Bridging An Object Oriented GIS Application and

AN OBJECT-RELATIONAL ENVIRONMENT FOR DEVELOPING OO GIS APPLICATIONS STOIMENOV LEONID Faculty of Electronic Engineering, University of Niš Beogradska 14, 18000 Niš, Yugoslavia

ANTONIJA MITROVIĆ Dep. of Computer Science, University of Canterbury New Zealand

Keywords: object-oriented model, relational database, object-relational applications, GIS, mediator 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.

INTRODUCTION Object-oriented (OO) paradigm is established as the leading approach to the development of flexible, scaleable software systems for client/server environments. OO data models are capable of representing both the structure and behavior of data; they also provide mechanisms for handling complex objects and multiple versions of the same object. OO models are therefore perfectly suited to non-traditional application, such as GIS, CAD, multimedia or AI systems. All of these application areas use databases, thus giving rise to the need of integration of OO into the database area as well. On the other hand, relational databases have been dominating the area of data processing in the last decade, due to their firm mathematical foundations, simplicity, consistency and ease of use. Relational systems support a large number of users with relatively short queries. These two trends motivate the research on integrating the OO applications with relational databases. However, the relational and OO data models are inherently different, and their integration is all but painless. With this in mind, the aim of the research in the area is to enable each of the models to be used where it excels: OO at the conceptual and the relational model at the implementation level. A new approach is based on generating language specific object-

SLOBODANKA ĐORĐEVIĆ-KAJAN Faculty of Electronic Engineering, University of Niš Yugoslavia

MILAN PETKOVIĆ Faculty of Electronic Engineering, University of Niš Yugoslavia

wrappers for relational databases. Such systems support the development of object-oriented, client-side applications working with legacy databases. Such an object-relational (OR) system requires a class of software modules that mediate between applications and databases. Such module is called a mediator [1,2,3]. This paper presents our approach to the symbiosis of the OO GIS applications and relational databases. We developed an OR environment, called GinisNT [4], for developing OO GIS applications. GinisNT is based on Mediator [5], a special component in the system, which automatically performs mapping from OO to relational data model and vice versa. The main goal during the design of Mediator has been the achievement of good performances of applications, which is obtained by efficiently linking spatial objects in applications to relations in spatial databases.

COUPLING OO APPLICATIONS WITH DATABASES OO paradigm is a natural one for GIS applications. It is logical to represent spatial objects as objects in applications. The advantages of the OO paradigm lie in its expressiveness, understandability and reusability. The problem appears with the need for persistent storage of data. Because different data models are used in applications and databases, the structures that hold data must be mapped into structures used in applications; this is known as the impedance mismatch problem. Two different approaches have been distinguished in persistent storage for objects [6]. The direct object storage uses the same OO model for the application and the database, and the problem of impedance mismatch is thus avoided. However, OO databases still suffer from a number of difficulties, such as view integration, indexing and query optimization. The other approach is indirect base relation storage, which couples an OO application with the relational database. The impedance

mismatch problem becomes significant here, but, on the other hand, RDBMS are widely used and hardware and software platforms needed are already available. The problem of sharable concurrent access to data is solved, and the growth of the system is supported. The indirect base relation storage approach can be realized from two perspectives: object-centered and relationcentered [6]. The difference between the two comes for the primary source of data. In the object-centered perspective, relation schemas are generated from class descriptions. In the latter one, it is assumed that relation schemas already exist, and class descriptions are derived from them. Objectcentered perspective gives more freedom to the programmer. GinisNT is based on this approach. The dominant implementation of the object-centered approach is based on generating language-specific object wrappers for relational databases [8]. This approach appears to be important for developing OO, client-side applications. On the other hand, the dominant implementation of the relation-centered approach consists of extending relational database systems [9]. Such OR database systems provide objects for mainstream database applications. The atractiveness of the object wrapers technology is that it enables OO applications to be writen on the basis of existing databases, making an OO design methodology available for implementing business objects. The usage of relational database is made transparent, so that the end-user is not even aware of the existence of an additional layer. The advantages of OR systems include the protection of previous investments into relational databases, integrity, robustness, security and distributed control of databases, and the integration of conventional and OO design methodologies [10]. Because of that, OR applications require a special module called mediator, which forms an additional layer between databases and applications. A mediator provides the application/data independence. Researching in this area is intensified and there are commercial products, which support the development of OO applications on top of relational databases. Most of these products are language-and application-specific; they generate either C++ or Smalltalk classes that act as an intermediary for data in the underlying database, permitting programmers to interact with the data in a more natural way. They permit OID-to-key mapping to maintain correspondences between the objects in an application and database data. Wiederhold defines a mediator in [3] and is the first to point to the need of Mediation for contemporary database

systems. Mediator is therefore seen by Wiederhold as an intermediate abstraction layer between databases and applications that use them. Such a layer is needed because of a few important reasons. However, Wiederhold stresses the fact that data in different domains have different semantics that need to be exploited through the use of mediators to be useful for an inter-domain application. In a way, his view of mediators encompasses all other reasons for their existence, which stretch from simple security reasons to the more complex concepts of amalgamating contradictory or incomplete semantics from different DBMS. Mediators have far more to do than just being simple interfaces because they have to include in themselves some knowledge that cannot exists in data they work on. They have to aggregate underlying data depending on criteria dictated by the application layer so that the process of understanding which domain contain the best information for answering a query is delegated to the automatic AI engines built in the mediators themselves. Mediators originated in the distributed DB area, but they rapidly moved to both object-oriented systems and, especially, knowledge base systems. Mediators are a good mean for integrating completely different data types, thus representing a good way for building the ultimate distributed multimedia system. Mediation is primary an architectural concept therefore the precise implementation of a module is less important [3]. The mediator architecture is therefore introduced as a three layers system: (1) applications, (2) mediators, and (3) DBMS. A mediator interfaces with different DBMSs, and at the same time contains knowledge for abstracting and aggregating data and dealing with uncertain data and semantic inconsistences. The user interface must be based on a high level language, which must be flexible and provide the control of information flow. The mediator's interface is oriented to computers and communications, and users applications need to provide different types of functions for its manipulations. The second mediator interface is utilized to direct database. In designing mediators, it is not necessary to develop functions for working with data on the level of files and records.

GinisNT ENVIRONMENT GinisNT is an OR platform for the development of scalable, end-user GIS applications. Main goal of the proposed approach is to provide a framework for developing GIS applications using an object-oriented methodology, while the underlying database is actually stored and maintained by a RDBMS. GinisNT provides support in OO modeling and

design of the GIS applications; it then maps the OO model into the relational schema and creates necessary relations. GinisNT also provides run-time support for the applications, by interpreting user's request, invoking appropriate methods and generating database statements based the metadata repository.

library is a set of project definition classes, which hold general information about the project, such as the date of creation, the name(s) of the designer, purpose and similar. Metadata and project classes are not extensible. The class library also contains an extensible hierarchy of attributes and an extensible feature hierarchy. The feature hierarchy contains both spatial and non-spatial classes; its root is the GNTFeature class, which provides object identification and the basic support for non-spatial classes. Spatial classes make the bulk of this hierarchy, and are organized in three layers: geometrical, describing the shape of spatial objects, topological, describing relations of a spatial objects to other objects, and user-defined. User-defined schemas are stored in the Metadata Repository (MDR). Mediator is the most important component of this architecture. It interfaces end-user, metadata repository and the database. Mediator manages attribute data (alphanumeric and other descriptive data), while spatial data is handled exclusively by the Spatial Data Manager (SDM). Mediator uses M-SDM module for communicating with SDM. The Mediator's architecture is also shown in figure 1. Its components can not be treated as independent, because some of them are set of classes and methods for performing some of the functions of Mediator.

FIGURE 1: THE ARCHITECTURE OF GINISNT GinisNT is based on the relational DBMS at the implementational level, the usage of which is made transparent to the user completely. This transparency is achieved by using a mapping algorithm [5] implemented within Mediator, one of the most important components of GinisNT. GinisNT provides the basic GIS functionality found in commercial GIS software, with the additional advantages of flexibility and the ease of development of end-user applications. The architecture of GinisNT is shown in Figure 1. ObjectWizard is an OO CASE tool in which end-users can develop OO applications. Users define applications by developing their OO models. In order to do that, users select classes from a predefined class library and adapt them to the application's needs, or develop completely new classes with no relations to other classes in the library. ObjectWizard supports the modeling phase, performs automatic mapping of the OO model of an application into the relational schema, creates all the necessary structures in the relational database and also stores the definition of the application in the metadata repository explained below. The class library consists of four groups of spatial and nonspatial classes. The first group contains the classes used in the metadata repository, which correspond to the concepts of the underlying OO model. Another part of the class

ObjectManager processes users run-time demands expressed over the OO schema, and maps them into corresponding database statements. In doing this, Mediator uses the definition of the application stored in MDR and generates appropriate database statements. The component that generates SQL statements and communicates with relational database is SQLGenerator. Mediator uses MDR to instantiate objects from relations. When the user updates some object, Mediator determines which tables and tuples need to be updated, and generates appropriate database statements. MDR also supports schema evolution. OIDGenerator is a component which works with object identifiers. The ObjTab table contains information about all objects in the memory (). Users can easily change schemas without even having to change the underlying code manually. Mediator provides data persistence, version control and schema evolution, as well as the run-time application support by interpreting user demands, invoking appropriate methods and generating database operations. The user interface provides means for communication between end-users and their applications, including functions for displaying data (both attribute and spatial data). The user interface is configured automatically using information from MDR. The existence of MDR frees the user from the burden of memorizing database schemas and corresponding access mechanisms. ObjectWizard stores the definitions of classes and corresponding information

about tables in MDR when the classes are mapped into the relational data model. The main goal during the design of Mediator is to achieve good performances of applications, which are assured by efficient linkages between spatial objects in applications and relations in spatial databases.

CONCLUSIONS Both relational and OO data models have advantages and disadvantages for modeling complex applications such as GIS. Object-relational applications use the OO data model for modeling applications and the relational data model for modeling databases. The essence of GinisNT, which we presented in this paper, is that the OO model is utilized on external level, and relational model on a conceptual, but so that the relational DBMS is completely transparent for users. Existing relational DBMS is hidden by providing automatic mappings from the object-oriented to the relational data model and in the opposite direction. In such way, it is possible to use existing infrastructure with the development environment having a purely object-oriented look-and-feel. We believe that this approach is going to accelerate development of OO GIS applications, with possibility of the using existing data resources (i.e. existing relational databases). The advantages of this approach are numerous: 1. Hardware and software platforms use relational DBMS which are widespread and known for users and there is no need for additional training costs. 2. Mediator encapsulates access to databases for MS Visual C/C++ classes and it provides higher productivity, quality and reusability of classes. 3. The most important characteristic of Mediator is the increased productivity and efficiency of object-oriented applications, which have access to the persistent storage. 4. Mediator reduces changes to models of application. The changes in the class hierarchy a user makes do not influence the database because those changes are only reflected in the metadata repository. 5. High quality of developed applications. GinisNT provides all classes for realization of GIS applications. You can just add data attributes to these classes when developing a simple application. 6. The environment is simple and runs on cheap hardware platforms.

GinisNT is currently under development, as well as the first GIS application based on it, which is a telephone network maintenance system. We believe that the sound foundation of the framework will ensure fast development of highquality GIS applications.

REFERENCE [1] G. Gattorna, Chapter 23: Mediation in DB Systems, http://www.cs.rpi.edu/~gattorng/db1.htm1 [2] G. Wiederhold, Mediation in Information Systems, ACM Computing Surveys, Vol. 27, No. 2, June 1995, pp. 265-267. [3] G. Wiederhold, Mediators in the Architecture of Future Information Systems, IEEE Computer, Vol. 25, No. 3, March 1992, pp. 38-49. [4] A. Mitrovic, D. Mitrovic, S. Djordjevic-Kajan, D. Rancic, A GIS solution for developing countries, In Proc. of AURISA-95, Melbourne, Australia, 1995, pp. 262-271. [5] L. Stoimenov, et all, Bridging An Object Oriented GIS Application And Relational DBMS, 18th Int. Cartographic Conf. ICC 97, Stockholm, Sweden, June 1997, pp.215-219. [6] B.S. Lee, G. Wiederhold, Outer Joins and Filters for Instantiating Objects from Relational Databases Trugh Views, IEEE Trans. on Knowledge and Data Engineering, Vol.6, No.1, Feb 1994, pp.108-119. [7] M. Carey, D. DeWitt, Of Object and Databases: A Decade of Turmoil, In Proc. 22nd Int. Conf. on VLDB, Mumbai (Bombay), India, 1996, pp. 3-14. [8] S. Agarwal, C. Keene, A. Keller, Architecting Object Applications for High Performance with Relational Databases, OOPSLA Workshop on Object Database Behavior, Benchmarks, and Performance, Austin, 1995, http://www-stanford.edu/pub/keller/1995/high-perf.ps [9] M. Blaha, W. Premerlani, H. Shen, Converting OO Models into RDBMS Schema, IEEE Sotware, 11(3), 1994, pp.2839. [10] T. Ek, Working with objects, ORACLE Magazine, 7(3), 1994, pp.40-44.