Ein Szenario aus der Praxis sieht folgendermaßen aus. Die Koordinatoren A und B eines Datenthemas X haben die Anforderungen, dass Daten in der ArcSDE aus Dokumentationsgründen historisiert werden müssen. Zudem sollen die von mehreren Bearbeitern verändert werden können. Dabei werden mehrere Ebenen digitalisiert und in einigen Druchläufen geprüft und bearbeitet. Außerdem gibt es Daten, die sich aus den digitalisierten Daten ableiten lassen. Dies würde man in der Welt der Sachdatenbank mit einem View lösen. Auch in der ArcSDE gibt es hierzu die sogenannten Spatial Views. Diese leiten sich aus den vorhandenen Daten ab und werden auch in anderen Nicht-ESRI-Anwendungen verwendet.
Es wird hier offensichtlich: man kommt in der ArcSDE nicht an der Versionierung vorbei. Der Arbeitsablauf wird von den ESRI-Werkzeugen auch bis auf die letzte Anforderung unterstützt: die abgeleiteten Views. Das Problem bei diesem Workflow liegt darin, dass die Spatial Views nicht auf versionierte Daten zugreifen. Beim Spatial View wird in der Regel nur die Basis (oder Business) -Tabelle ausgelesen. Wenn also auf die aktuellsten Daten aus der Digitalisierung zugegriffen werden soll müssen die versionierten Daten mit dem Befehl Compress in die Basis-Tabelle geschrieben werden.
Man mag jetzt sagen: „Gut, etwas umständlich vielleicht, aber geht doch. Dann setzt man eben immer einen Compress ab, wenn man aktuelle Daten in den Views haben möchte.“
Dem würd ich Recht geben. Allerdings kommt nun Koordinator C mit dem Datenthema Y ins Spiel. Dieser möchte seinen Arbeitsablauf auch mit Hilfe der ArcSDE unterstützen. Auch hier sollen Geodaten von mehreren Bearbeitern digitalisiert werden. Bei diesem Thema sollen jetzt sogenannte Replicas eingesetzt werden.
Replicas sind Teile eines oder mehreren Datensätzen, die in filebasierte Geodatenbanken exportiert, dort bearbeitet werden und anschließend wieder zurück in die ArcSDE gespielt werden können. Voraussetzung ist hier wieder die Versionierung der Daten. Auch ne Supersache von ESRI. Aber jetzt bringen wir mal alle Anforderungen zusammen…
Das Problem ist nun, dass beim Export von Replicas des Datenthemas Y jedesmal eine Version dieser Daten erstellt wird. Diese existiert dann in der gesamten Datenbank. Ein Compress Befehl kann aber nur erfolgreich alle Add und Delete-Tabellen in die Basis-Tabelle schreiben, wenn keine offenen Versionen mehr existieren. Die beiden skizzierten Abläufe blockieren sich damit, weil keine aktuellen Daten des Themas X in den Spatial Views sichtbar werden, wenn der Compress nicht erfolgreich verläuft.
Das heisst jetzt im Klartext: in einer einzigen SDE-Instanz ist es nicht möglich, zwei (in Zahlen 2) Datenthemen zu speichern, die komplexe Anforderungen an GIS-technische Arbeitsabläufe haben.
Das Gegenargument eines ESRIaners würde natürlich heißen: „Mit unserer Software wird doch alles abgebildet. Gut, bis auf die Views, aber die werden ja auch Drittprogrammen verwendet.“
ArcSDE – eine Multiuser-Geodatenbank? Ja für ein Datenthema und Clients aus dem Hause ESRI… (weiter)