Versionierte Tabellen in einer Geodatabase in Oracle

Eine Enterprise-Geodatabase muss Unterstützung für viele Benutzer bieten, die gleichzeitig große Mengen von geographischen Informationen erstellen und aktualisieren. Deshalb muss eine Geodatabase eine Bearbeitungsumgebung bereitstellen, die die gleichzeitige Bearbeitung durch mehrere Benutzer unterstützt, ohne mehrere Kopien der Daten zu erstellen. Aufgrund dieser Funktion muss die Bearbeitungsumgebung außerdem Bearbeitungssitzungen unterstützen, die sich normalerweise über mehrere Tage erstrecken, sowie die Möglichkeit bieten, Änderungen an der Datenbank rückgängig zu machen oder zu wiederholen, das Testen und Entwickeln von Datenmodellen und alternativen Anwendungsentwurfsvorschlägen ohne Auswirkungen auf die veröffentlichte Datenbank und die Möglichkeit zur Überwachung der Entwicklung von Daten und Datenbanken im Laufe der Zeit unterstützen.

Um diese Anforderungen zu erfüllen, können Enterprise-, Arbeitsgruppen- und Desktop-Geodatabases versioniert werden. Registrieren Sie zu Beginn Feature-Datasets, Standalone-Feature-Classes und Tabellen als versioniert. Erstellen Sie anschließend Versionen der Geodatabase, in der Sie die Bearbeitungen vornehmen. Diese Versionen sind virtuell; es werden keine Kopien der Geodatabase erstellt. Die Versionen werden durch Delta-Tabellen dargestellt, die mit jedem versionierten Dataset verbunden sind, sowie einigen Systemtabellen, um Versionszustände aufzuzeichnen.

Informationen zu Versionen finden Sie unter Kurzer Überblick über die Versionierung.

Versionierte Tabellen in ArcGIS for Desktop

Im Katalogfenster werden versionierte Datasets genauso wie nicht versionierte Datasets dargestellt. Sie können herausfinden, ob eine Feature-Class oder Tabelle versioniert ist, indem Sie das entsprechende Dialogfeld Eigenschaften öffnen. Auf der Registerkarte Allgemein ist angegeben, ob die Feature-Class oder Tabelle als versioniert registriert ist.

Sie können über mehrere Geodatabase-Versionen verfügen. Im Katalog können Sie separate Verbindungen zur Spatial-Database zu jeder Version herstellen. Wenn Sie ein versioniertes Dataset in der DEFAULT-Version als Vorschau anzeigen, sieht es möglicherweise anders aus oder enthält weniger Datensätze, als wenn Sie dieselbe Feature-Class in einer anderen Version als DEFAULT als Vorschau anzeigen. (Informationen zum Herstellen einer Verbindung zur Spatial-Database zu einer anderen Version als DEFAULT finden Sie unter Verbindung zu einer bestimmten Geodatabase-Version.)

Genauso gilt, wenn Sie eine versionierte Feature-Class in einer Version in ArcMap anzeigen und die Feature-Class dann in einer anderen Version in ArcMap anzeigen, sieht sie möglicherweise anders aus. Das liegt daran, dass eine Tabelle oder Feature-Class, die in einer Version angezeigt wird, eine bestimmte Anzahl von Zeilen enthält, und dieselbe Feature-Class in einer anderen Version eine andere Anzahl von Zeilen enthalten kann.

Tipp:

Um zu sehen, welche Version der Daten in der Karte vorhanden ist, klicken Sie im Inhaltsverzeichnis von ArcMap auf die Schaltfläche Nach Quelle auflisten.

Im folgenden Beispiel wird die Feature-Class "Fire hydrants" in der DEFAULT-Version der Geodatabase in ArcMap veranschaulicht:

Wenn Sie zu einer anderen Version der Geodatabase wechseln (Version wo2557), enthält die Feature-Class "Fire hydrants" einen zusätzlichen Hydranten und eine Zuleitung. Das bedeutet, dass ein Hydrant zur Feature-Class "Fire hydrants" und eine Zuleitung zur Feature-Class "Water laterals" hinzugefügt wurde, während Sie Bearbeitungen mit "wo2557" als Quell-Geodatabase-Version vorgenommen haben.

Scheinbar ist jede Version eine separate Kopie der Daten. Doch statt eine neue Kopie zu erstellen oder die ursprünglichen Daten zu ändern, lässt die Geodatabase die versionierte Tabelle oder Feature-Class in ihrer ursprünglichen Form und speichert alle Änderungen an den Daten in separaten Geodatabase-Systemtabellen. Die Geodatabase-Tabellen, die Versionsänderungen enthalten, werden als Delta-Tabellen bezeichnet. Für jede Tabelle oder Feature-Class, die versioniert wurde, werden zwei neue Delta-Tabellen erstellt – eine Adds(a)- und eine Deletes(d)-Tabelle.

Versionierte Tabellen in einer Oracle-Datenbank

Intern wird die Versionierung durch eine Reihe von Datenbanktabellen verwaltet: Dataset-Tabellen, Delta-Tabellen und Systemtabellen, um Vorgänge in Versionen aufzuzeichnen.

Delta-Tabellen

Beim Registrieren eines Feature-Datasets, einer Standalone-Feature-Class oder einer Tabelle als versioniert werden Delta-Tabellen – die Adds- und Deletes-Tabellen – in der Datenbank erstellt. Die Delta-Tabellen zeichnen alle Einfügungen, Aktualisierungen und Löschungen in einer versionierten Tabelle oder Feature-Class in jedem Zustand der Datenbank auf. 

Hinweis:

Nur der Besitzer des Datasets kann dieses als versioniert registrieren.

a_<registration_id>

In der Tabelle "a<registration_id>" (Adds-Tabelle) werden Informationen zu jedem eingefügten oder aktualisierten Datensatz (Feature) in einer versionierten Business-Tabelle verwaltet. Sie wird abgefragt, um die hinzugefügten oder geänderten Datensätze in einem bestimmten Datenbankzustand zu identifizieren. Die "registration_id" im Namen der Adds-Tabelle entspricht dem Wert im Feld REGISTRATION_ID der Tabelle TABLE_REGISTRY, der der versionierten Tabelle entspricht. Im obigen Beispiel des Hydranten ist REGISTRATION_ID der Feature-Class "Fire hydrants" in der Tabelle TABLE_REGISTRY 161. Die Adds-Tabelle für die Hydrants-Feature-Class heißt daher "a161".

Die Adds-Tabelle enthält dieselben Felder wie die zu bearbeitende versionierte Business-Tabelle plus col_stateid.

Die Adds-Tabelle

Feldname	Feldtyp	Beschreibung	NULL?
<alle Felder aus der versionierten Business-Tabelle>	<alle zugehörigen Typen für die Felder in der versionierten Business-Tabelle>	Alle Attribute des neuen Features
SDE_STATE_ID	NUMBER(38)	Kennung des Zustands (State), in dem das neue Feature hinzugefügt oder aktualisiert wurde	NOT NULL

Wenn Sie beispielsweise während einer versionierten Bearbeitungssitzung einen Hydranten zur Feature-Class "Fire hydrants" hinzufügen, wird ein Datensatz für den neuen Hydranten zur Adds-Tabelle hinzugefügt.

d<registration_id>

In der Tabelle "d<registration_id>" (Deletes-Tabelle) werden Informationen zu allen gelöschten oder aktualisierten Zeilen in einer versionierten Business-Tabelle verwaltet. Sie wird abgefragt, um die gelöschten oder geänderten Zeilen in einem bestimmten Zustand zu identifizieren. Wenn eine Zeile gelöscht wird, wird der Datensatz nicht physisch entfernt. Er wird als gelöscht markiert und in nachfolgenden Datenbankabfragen nicht mehr zurückgegeben.

Die Deletes-Tabelle

Feldname	Feldtyp	Beschreibung	NULL?
DELETED_AT	NUMBER(38)	Zustand (State), in dem das Feature gelöscht wurde	NOT NULL
SDE_DELETES_ROW_ID	NUMBER(38)	Eindeutige Kennung des gelöschten oder aktualisierten Features	NOT NULL
SDE_STATE_ID	NUMBER(38)	Kennung des Zustands (State), in dem das neue Feature hinzugefügt oder aktualisiert wurde	NOT NULL

Systemtabellen

Zusätzlich zu den Delta-Tabellen erfassen die Systemtabellen versionierte Tabellen und Bearbeitungen. Dazu gehören die Tabellen STATES, STATE_LINEAGES, VERSIONS und MVTABLES_MODIFIED.

Eine versionierte Datenbank enthält normalerweise zusätzlich zur DEFAULT-Version eine Reihe von Versionen. Diese zusätzlichen Versionen können Dinge wie Arbeitsabfolgen, Entwurfsalternativen, entkoppelte Bearbeitungssitzungen oder vergangene Momentaufnahmen enthalten. Die Tabelle VERSIONS enthält eine beschreibende Liste dieser Versionen, wobei jede Version durch einen eindeutigen Namen und eine ID gekennzeichnet ist (IDs werden automatisch von ArcGIS erzeugt). Darüber hinaus hat jede Version einen Besitzer, eine Beschreibung, eine Parent-Version, einen verknüpften Datenbankzustand und eine Benutzerzugriffsebene.

Wenn die Tabelle VERSIONS erstellt wird, werden die Details der DEFAULT-Version automatisch in dieser Tabelle aufgezeichnet. Der Geodatabase-Administrator ist der Besitzer der DEFAULT-Version, und die anfängliche ID des zugehörigen Datenbankzustands ist auf 0 gesetzt. Im Folgenden sehen Sie ein Beispiel für den Eintrag DEFAULT in der Tabelle VERSIONS:

Name	Besitzer	Version_ID	Status	State_ID	Beschreibung	Parent_name	Parent_owner	Parent_version_ID	Creation_time
DEFAULT	SDE	1	1	0	Instanzstandardversion	NULL	NULL	NULL	2009-02-12 08:40:2

DEFAULT-Datensatz

Zur Verwaltung der an den Daten vorgenommenen Bearbeitungen behält eine versionierte Geodatabase eine Sammlung von Datenbankzuständen bei, oder Einheiten der Änderungen an der Datenbank. Ein Zustand stellt eine separate Momentaufnahme der Datenbank dar, immer dann, wenn eine Änderung vorgenommen wurde. Jeder Bearbeitungsvorgang erzeugt einen neuen Datenbankzustand. (Ein Bearbeitungsvorgang ist ein Task bzw. eine Abfolge von Tasks [Hinzufügungen, Löschungen oder Aktualisierungen], die an Features oder Zeilen vorgenommen werden.) Alle Geodatabase-Versionen verweisen auf einen dieser Datenbankzustände und durchlaufen im Laufe der Zeit verschiedene Zustände.

Alle Geodatabase-Zustände haben dasselbe Schema und unterscheiden sich nur in der Anzahl der Zeilen, die die jeweils bearbeitete Tabelle oder Feature-Class darstellen. Zur Identifikation von Konflikten, die auftreten können, wenn dasselbe Feature in denselben oder verschiedenen Versionen bearbeitet wird, werden die Herkunftszustände der Versionen beim Versionsabgleich auf Unterschiede oder Zeilenkonflikte überprüft.

Alle Informationen, die sich auf die Zustände beziehen, werden in der Tabelle STATES verwaltet. VERSIONS und STATE_LINEAGES werden abgefragt, um festzustellen, auf welchen Datenbankzustand jede Version verweist.

Die Zustände werden in einer Baumstruktur verwaltet, wo die Beziehungen zwischen Parent- und Child-Objekt aus dem State-Lineage (Herkunftszustand) abgeleitet werden können. Informationen zum State-Lineage jeder Version werden in einer separaten Tabelle verwaltet: STATE_LINEAGES. Diese Tabelle enthält einen Index mit mehreren Einträgen zu zustandsübergreifenden Parent-Child-Beziehungen; sie wird für alle Versionsabfragen verwendet.

Für die Rückkehr zur richtigen Ansicht einer Version wird die State-Lineage abgefragt, um alle States zu identifizieren, die jede Änderung dieser Version aufgezeichnet haben. Aus dieser Liste von States können die Tabellenzeilen, die die Version korrekt darstellen, bestimmt werden. Wenn die Geodatabase bearbeitet wird und die Versionen sich im Laufe der Zeit ändern, wird die State-Struktur immer komplexer.

Bei jeder Änderung einer Feature-Class oder Tabelle in einem Zustand wird in der Tabelle MVTABLES_MODIFIED ein neuer Eintrag erstellt. Beim Abgleichen von zwei Versionen besteht der erste Schritt darin, die Zustände zu identifizieren, auf die diese beiden Versionen verweisen: den aktuellen Zustand der Editierversion und den Zustand der Zielversion. Von diesen Zuständen wird durch Rückverfolgung bis zur State-Lineage dieser beiden Versionen ein gemeinsamer Vorgängerstatus identifiziert. Die Tabelle MVTABLES_MODIFIED wird dann abgefragt, um alle Tabellen zu identifizieren, die zwischen dem gemeinsamen Vorgängerzustand und dem Zielversionszustand geändert wurden. Aus dieser Liste der geänderten Tabellen wird eine zweite Liste von Tabellen, die beiden State-Lineages gemeinsam ist, erzeugt. Für alle gemeinsamen Tabellen in dieser zweiten Liste wird eine Reihe von Versionsunterschiedsabfragen ausgeführt: INSERT, UPDATE, DELETE, UPDATE_UPDATE, UPDATE_DELETE.

Die in die versionierte Feature-Class einbezogenen Tabellen sind im folgenden Diagramm dargestellt:

Die gestrichelten Linien geben implizite Beziehungen zwischen Spalten an.

Die Zahl in den Namen der Adds- und Deletes-Tabellen ist die REGISTRATION_ID der Business-Tabelle aus der Tabelle TABLE_REGISTRY.

Versionierte Tabellen in einem XML-Dokument

Ein Eintrag in XML-Dokumenten gibt an, ob eine Feature-Class oder Tabelle versioniert ist. Er ist in versionierte Tags eingeschlossen. Für eine versionierte Feature-Class oder Tabelle ist der Wert "true".

Tipp:

Obwohl der versionierte Tag für Feature-Datasets festgelegt ist, gibt er nicht unbedingt den Versionswert für die Feature-Classes im Feature-Dataset wieder. Um zu bestimmen, ob die Feature-Classes in einem Feature-Datasets als versioniert registriert sind, werden die einzelnen Feature-Classes abgefragt.

<Versioned>true</Versioned>