International Journal of Geographic Information Systems, Special Issue on System Integration, Vol. 12, No 3, 1998page 1O n s p a t i a l d a t a b a s e i n t e g r a t i o n Thomas Devogele,Institut Géographique National - COGIT, F 94100 Saint Mandé[email protected] Parent, and Stefano SpaccapietraSwiss Federal Institute of Technology, EPFL-DI-LBD, CH 1015 Lausanne(parent, spaccapietra)@di.epfl.ch,http://lbdwww.epfl.chAbstract. This paper investigates the problems that arise whenapplication requirements command that autonomous spatial databases beintegrated into a federated one. The paper focuses on the most critical issuesraised by the integration of databases of different scales. A short presentationof approaches to interoperability and of the main steps composing theintegration process is given first. Next, a general format is proposed forprecisely defining correspondences between objects of two databases. Theformat can deal with a wide range of discrepancies in GIS data. Last, asolution is presented for aggregation conflicts which arise when one object ofone database corresponds to a set of objects in the other database, a veryfrequent case when the databases are of different scales. The method isapplied to excerpts of real cartographic databases.1. IntroductionOne of the major problems that the development of GIS applications is facing todayis data acquisition. Not that data is not available: geographic data collection has beengoing on for centuries. Some of that is still stored on paper, including maps, some hasbeen digitized and is stored in current GIS systems (at best) or in traditional files ordatabases. However, too often their reuse for new applications is a nightmare, due to poordocumentation, obscure semantics of data, diversity of data sets (what information isstored, how it is represented and structured, what quality it has, which date it refers to,which scale is used, ...), heterogeneity of existing systems in terms of data modelingconcepts, data encoding techniques, storage structures, access functionalities, etc.Despite such obstacles, reusability of existing data is a must, simply because of thehigh cost of acquiring new geographical data from scratch. Once application requirementsanalysis has identified what data is needed, the modern designer has to look around to alldata stores of potential interest to find out which ones may already have some of the data(s)he needs. Most likely, part of that will indeed exist, spread into pieces over variousheterogeneous data stores, part of it will not exist and will have to be acquired.Eventually, the newly acquired data and the many pieces of reused data will be integratedinto a single, uniform, non-redundant data store, which will serve as the underlyingdatabase for the new applications. The process of unifying existing data sources into asingle framework is called database integration. It takes as input a set of databases(schemas and data instances), and produces as output a single unified description of theInternational Journal of Geographic Information Systems, Special Issue on System Integration, Vol. 12, No 3, 1998page 2input schemas (called the integrated schema) and the associated mapping informationsupporting integrated access to existing data instances through the integrated schema(Batini et al. 1986) (Parent et al. 1998). Please note that we use the usual databaseterminology. The term data model refers to the set of abstract data modeling concepts in use(e.g. object type, relationship type, attribute), otherwise termed the meta-model in the GIScommunity. The term schema refers to a description of application specific object types,relationship types, etc., for a given database (otherwise termed the data model). The termdata instance refers to the data in the database which physically describes an applicationobject or relationship.Database integration is the most sophisticated and most powerful approach to datainteroperability. Simpler alternatives exist and it is worthwhile mentioning them toprovide a clear understanding of the issue. A very first basic approach, not attempting anyintegration, is to provide users with a global catalog of accessible information sources,where each source is described by some associated meta-data, e.g.: representation mode,scale, last update date, data quality level (Stephan et al. 1993) (Uitermark 1996). TheAlexandria Digital Library project (Frew et al. 1995) is one of the major efforts to buildsophisticated tools for such catalogs. A variant to this solution is the use of dedicated Webbrowser services to explore GIS data available at different sites (GEO2DIS 1997).A first step into integration is to integrate the existing data by hand, specifying andimplementing ad-hoc solutions. This may be done by splitting the new applications intopieces, so that each piece is tailored to access only one data store and to pass the local datain an appropriate format over to a global application which performs any globalprocessing and synthesizes the result. Alternatively, the data of interest can be extractedfrom the local sources and copied through ad-hoc routines into a new single database,which is then made available to the new applications. An example of this approach is theEuropean project MEGRIN (Illert and Wilski 1995). Both ways have evident drawbacksrelated to lack of scalability and consistency, and duplication.The second path to interoperability is through standardization. The definition ofstandard data modeling and manipulation features provides a reference point whichfacilitates data exchange among heterogeneous systems. Two kinds of standards can bedeveloped:- data model standards specify which abstract modeling concepts have to be used. For nonspatial data, standards exist for relational databases and are currently being developedfor object-oriented databases (by ISO committees on SQL-3 and by the ObjectManagement Group). Data model standards for spatial databases are being developed byISO/TC 211 (ISO/TC 211 1996), CEN/TC 287 (CEN/TC 287 1996) and by the OpenGISconsortium (OGIS)).- schema standards: these recommend a predefined data/process design (a template) for aspecific application area, e.g., water management or facilities management. Such astandard provides a fixed schema in a given data model.Standards, however, only define a target for data conversion. They do not addressthe problem of how to convert existing data into the standard format and how
View Full Document
Unlocking...