Hoort topologie structuur management
in het DBMS?
Overzicht topologische structuren
Topologie structuur
management op basis van
meta-informatie
In dit artikel zal de kadastrale kaart als voorbeeld worden
genomen, omdat de topologie een sleutelrol speelt in deze
dataset, die bestaat uit percelen die gezamenlijk heel
Nederland bedekken. Het ruimtelijke deel van het data-
model voor de kadastrale percelenlaag is gebaseerd op de
'winged-edge' topologie [10] zoals beschreven in [11] [8].
In een implementatie van topologie structuur management
hoeft niet noodzakelijk alle functionaliteit door het DBMS
te worden verzorgd. Het is ook mogelijk dat delen van de
functionaliteit in de front-end (of middleware) applicatie
worden verzorgd. Dit maakt het mogelijk om het geheel op
een standaard-relationele DBMS te bouwen zonder dat deze
behoeft te worden aangepast. Echter, de ondersteuning van
topologische structuren is vrij generiek en zou daarom toch
het beste in het DBMS kunnen worden geïmplementeerd.
Dit voorkomt het telkens opnieuw implementeren van
dezelfde functionaliteit en is tevens de beste manier om
consistentie te bewaken. Verder maakt dit het mogelijk dat
analyse-operaties gebaseerd op een topologische structuur
efficiënt kunnen worden uitgevoerd binnen het DBMS. Er
vindt dus geen onnodige data-overdracht plaats tussen het
DBMS en de front-end applicatie. Daar het implementeren
van topologische structuur management in relationele
DBMSen een onontgonnen gebied is, is het goed om eerst de
randvoorwaarden op een rijtje te zetten:
de mogelijkheid om een volledig operationele oplossing
te implementeren, die allerlei typen topologische struc
turen omvat, moet in ieder geval open blijven. We zullen
ons eerst wel concentreren op één type topologische
structuur; de planaire partitie;
de gekozen oplossing moet ook worden geïmplemen
teerd om de voordelen ten opzichte van de andere me
thoden (middleware of front-end topologie) te kunnen
onderzoeken;
de oplossing moet uitbreidbaar zijn. Gebruikers moeten
de vrijheid hebben om andere typen topologische struc
tuur management toe te voegen zonder dat dit conflic
ten binnen het DBMS oplevert;
het hebben van een abstracte specificatie of standaard is
een belangrijke voorwaarde, maar een implementatie
specificatie is de noodzakelijke vervolgstap in de prak
tijk;
als vuistregel die aangeeft of bepaalde functionaliteit
wel in het DBMS thuishoort, geldt dat deze functionali
teit generiek dan wel specifiek voor een bepaalde appli
catie is. In het eerste geval kan de programmatuur steeds
worden herbruikt en is er in deze sectie beargumenteerd
dat de functionaliteit in het DBMS thuishoort.
Zonder te willen claimen volledig te zijn, proberen we hier
een overzicht te geven van de meest voorkomende soorten
van topologische structuren. Het is inmiddels al een aantal
keren vermeld dat er verschillende manieren zijn om een
topologische structuur te implementeren. Hiervoor is de
'wiel-topologie' besproken. Andere topologie-implementa-
Fig. 2.
Kadastrale
landmeters uit
Zwolle aan het werk.
[foto Kadaster).
ties zijn mogelijk en kunnen ook bin
nen het DBMS worden gerealiseerd.
Zo gebruikt het Kadaster bijvoorbeeld
ook een planaire partitie gebaseerd op
edges and faces, maar worden er ande
re verwijzingen gebruikt, namelijk de
kettingtopologie (ook weieens winged
edge-topologie genaamd). De verschil
lende topologische structuren kunnen
worden onderscheiden aan de hand
van de volgende kenmerken:
wat is de dimensie: 2D, 2'/2D, 3D?
tijd toegevoegd?
welke topologische elementen (pri
mitieven) zijn gebruikt: node, edge,
face, volume?
zijn de elementen gericht (georiën
teerd) of niet?
welke topologische relaties worden
expliciet opgeslagen (part_of, in,
on)?
wat zijn de topologische 'regels';
kruisende edges toegestaan?, los
hangende edges toegestaan?, zelfde
topologische primitieve aan beide
kanten van een grens toegestaan?,
enzovoort.
Een eerdere poging om Postquel (het
SQL-dialect dat binnen het Postgres
DBMS wordt gebruikt) met 'prototy
pes' en het 'create layer' statement uit
te breiden voor topologie structuur
management is beschreven in [12]. Het
nadeel van deze aanpak is dat het een
uitbreiding van de DBMS-vraagtaal
(manipulatietaai) zelf vereist, dat een
serieuze invloed heeft op de kern van
de DBMS-software. Een ietwat 'minder
zware' aanpak dan het uitbreiden van
de DBMS-kern met topologische func
tionaliteit omvat het creëren van een
GEODESIA 2003-2
