Ein Datenbanksystem ist unter normalen Umständen eine mehrbenutzerfähige Umgebung, die sehr vielen Benutzern die Möglichkeit bietet, Informationen zu lesen, zu verändern und auch neu zu erzeugen. So weit so gut.

Auch eine Geodatenbank, die mit Mechanismen ausgestattet ist, räumliche Informationen in geeigneten Speicherstrukturen abzulegen und effizient zu verwalten sollte diese Kerneigenschaft einer Datenbank eigentlich mitbringen. Mein Einblick in zwei wichtige Geodatenbanksysteme (PostgreSQL mit PostGIS und Oracle mit Oracle Spatial) bestätigte diese Eigenschaften bislang auch.

Bis vor einiger Zeit war mein Verständnis von Geodatenbanken im Lot, bis ich mich intensiver mit ArcSDE, der Middleware von ESRI beschäftigte…

ArcSDE wertet wie PostGIS und Oracle Spatial eine reguläre (Sach-) Datenbank zu einer Geodatenbank auf. Dabei kann Oracle, Informix, DB2, SQL Server und seit kurzem auch PostgreSQL verwendet werden.

Im Gegensatz zu den räumlichen Erweiterungen einer Datenbank ist ArcSDE jedoch als Middleware zu sehen, die zwischen den Clients und der eigentlichen Datenbank agiert. ArcSDE ist eine Software, die es ermöglicht, nahezu alle speziellen räumlichen Speicherstrukturen wie Knoten/Kanten-Netzwerke, topologische Strukturen oder ähnliches aus dem Hause ESRI in einer beliebigen Datenbank zu speichern und dort zu bearbeiten.

In dieser Rolle hat die ArcSDE durchaus Vorteile. Durch die zusätzliche Schicht zwischen Client und Datenbank ist es den Clients egal, welche Datenbank von ArcSDE als Speichercontainer gebraucht wird.  Sobald ArcSDE drauf steht ist ESRI drin – ohne Abstriche in der GIS-Funktionalität bei den Clients hinnehmen zu müssen.

Das Konzept „Client – ArcSDE – Datenbank“  ist jedoch auch sehr fokussiert auf spezielle Clients – was man ESRI nicht verübeln kann: diese sollten alle auf ArcObjects basieren. Soll heißen: die Kommunikation der Middleware ArcSDE ist auf Standard-ESRI-Software wie ArcMap, ArcCatalog und Konsorten abgestimmt.  Damit kristalliert sich schon einmal ein Nachteil der ArcSDE heraus: eine Unabhängigkeit zwischen der Speicherung der Geodaten in der Datenbank und den GIS-Clients ist hiermit nicht gegeben, getreu dem Motto: „Einmal ESRI – immer ESRI.“

Die fortgeschrittenen Möglichkeiten wie Network Datasets und Topology Feature Classes sind ausgereift und professionell. Allerdings würde wahrscheinlich niemand auf die Idee kommen, dafür eine ArcSDE zu lizensieren. Vielmehr ist bei größeren Organisationen doch die zentrale, mehrbenutzerfähige Geodatenbank das Kernelement der internen Geodateninfrastruktur.

Und spätestens beim Bearbeiten der Daten kommt an dieser Stelle die Versionierung von ESRI ins Spiel, die es dem Terminus „mehrbenutzerfähig“ richtig schwer macht. (weiter)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert