Geographic Information System
Spatial Support Layer
Standard Relational DBMS
Geographic Information System
Extensible
DBMS
Handling of
Spatial Data
Geometrische gegevenstypen
ries) niet mogelijk is. Een relationeel DBMS biedt trans
acties die atomair, bestendig en te serialiseren zijn. Het
opslaan van gegevens buiten de relationele DBMS kan
uitmonden in het verlies van semantische aspecten van
de transactie (een transactie wordt geheel of geheel niet
uitgevoerd), omdat de twee ,,opslag"-beheerprogram-
ma's elk hun eigen afsluitprotocol hebben.
Als laatste nadeel kan worden genoemd de mogelijkheid
tot overtreding van de integriteitsbeperkingen. Een enti
teit kan bijvoorbeeld nog steeds blijven voortbestaan in
een ruimtelijk subsysteem voor opslag, nadat het is ver
wijderd uit de relationele DBMS.
Gelaagde architectuur
De meeste nadelen van een tweeledige architectuur
worden veroorzaakt door het feit dat er twee opslagmana
gers bestaan, die elk hun eigen verantwoordelijkheden
kennen. Het is mogelijk om ruimtelijke gegevens in het
zuiver relationele gegevensmodel op te slaan [11]. Dit
impliceert dat de ondersteuning van de semantiek van de
transacties en de integriteitsbeperkingen worden her
steld. Echter, om de gegevens in te passen in het relatio
nele model, dienen de coherente geografische entiteiten
te worden gesplitst in meerdere delen, die vervolgens in
aparte tabellen worden opgeslagen. Het terugzoeken van
de oorspronkelijke geografische entiteiten vereist het uit
voeren van dure ,,join" operaties op relaties, hetgeen het
systeem langzamer maakt en moeilijker om te gebruiken.
Fig. 2. Gelaagde GIS-architectuur.
De gebruiker kan worden gevrijwaard van het formuleren
van ingewikkelde vragen door een aantal „intelligente"
vertalingen in de laag bovenop de standaard relationele
gegevensbank. Deze laag vertaalt de geografische
vragen (in „GeoSQL"; Geographic Structured Query
Language) in standaard SQL-vragen en kan tevens
ruimtelijke indices implementeren. Deze indices worden
geïmplementeerd met behulp van hulprelaties die de be
nodigde indexgegevens bevatten. De indices vormen een
hulpmiddel om het zoeken in een bepaalde ruimtelijke
gegevensstructuur sneller te maken; de vragen echter
worden zo mogelijk nog gecompliceerder, daar ze hulp
relaties moeten gebruiken. Deze indirecte implementatie
van een toegangsmethode is minder efficiënt dan een
directe implementatie in de kern (kernei) van de DBMS
(fig. 2). System 9 (ComputerVision), GEOVIEW (Universi
teit van Edinburgh en SIRO-DBMS (CSIRO Australië)
vormen karakteristieke voorbeelden van systemen met
een gelaagde architectuur.
Geïntegreerde architectuur
De omslachtige en inefficiënte vertaling en overdracht
(mapping) van het gebruikersgegevensmodel naar de
relatietabellen kan worden vermeden door het toevoegen
van meer gegevenstypen en toegangsmethoden.
Voor deze oplossing is gekozen in de geïntegreerde GIS-
architectuur. In tegenstelling tot de andere twee architec
tuurtypen kan deze architectuur niet worden gebaseerd
op een standaard relationele DBMS. Hiervoor is een uit te
breiden (en vaak objectgeoriënteerde) DBMS nodig. Dit
wordt geïllustreerd in fig. 3, waar de ruimtelijke uitbrei
ding volledig is ingepast in de DBMS.
Fig. 3. Geïntegreerde GIS-architectuur.
De gebruikers kunnen de DBMS met zelf definieerbare
Abstracte Data Typen (ADT's) uitbreiden. Een duidelijk
nadeel van deze aanpak is dat de gebruikers hun ADT's
in de DBMS-omgeving moeten implementeren, hetgeen
behoorlijk gecompliceerd kan zijn. Als deze taak echter is
volbracht, worden de voordelen van deze benadering
zichtbaar.
De implementatie van het gegevensmodel is gemakke
lijker, omdat de juiste geometrische gegevenstypen nu
voorhanden zijn. De formulering van ruimtelijke vragen
wordt direct ondersteund in de uit te breiden vraagtaal
door middel van toegevoegde ruimtelijke operatoren, zo
als afstand, gebied en intersectie. Wellicht het grootste
voordeel is de goede prestatie van deze systemen.
De directe implementatie van de gegevenstypen in de
kemel van de DBMS is zeer efficiënt. De prestatie van het
systeem wordt verder ondersteund, doordat men zelf
ruimtelijke toegangsmethoden kan invoeren. De ontwik
keling van geïntegreerde DBMS-structuren hangt af van
de aanwezigheid van open relationele gegevensbanken.
Karakteristieke voorbeelden van geïntegreerde GIS-
architecturen zijn TIGRIS (Intergraph) en het onder-
zoeksgeoriënteerde systeem GéoTropics (Universiteit
van Parijs VI en IGN France). Ook GEO bezit een
geïntegreerde architectuur [8]. De systeemcomponent
„Handling of spatial data" (fig. 3) is geïmplementeerd in
de open Postgres-omgeving.
De eerste stap bij het implementeren van een GIS met
een geïntegreerde architectuur is het uitbreiden van de
DBMS met geometrische gegevenstypen en operatoren.
In ons geval biedt Postgres zelf een aantal geometrische
mogelijkheden. Het bezit de op een R-Tree gebaseerde
ruimtelijke indexstructuur en biedt de volgende gege
venstypen: point, Iseg, path, en box. Het type Iseg
implementeert een segment met een enkele lijnstuk.
Polylijnen en polygonen kunnen worden vertegenwoor
digd door path, hetgeen een array met variabele lengte
is van Iseg. In het speciale geval van een tweedimensio
nale as-parallelle rechthoek kan het type box worden
gebruikt.
Er is voorzien in een aantal nuttige functies en operatoren
(een test voor overlappende „boxes", het testen of een
punt in een box ligt, de afstand tussen twee punten).
Maar er zijn meer functies en operatoren nodig om tot
NGT GEODESIA 93 6
275
