Beitragsseiten

Seite 5 von 6

 

7.5 Die Erweiterung des räumlichen Modells auf temporale Geo-Objekte

Zur Abbildung des zeitlichen Bezugs sind für die STObject-Klassen zwei Assoziationen in dem in Abbildung 53 dargestellten Klassendiagramm relevant. Zunächst ermöglicht es ein Zeiger auf eine andere Instanz vom Typ STObject, eine Versionenkette zu bilden, mit deren Hilfe jedes Objekt die zeitlich vorhergehende und die nachfolgende Version ermit­teln kann. Innerhalb dieser Kette gilt die Integritätsbedingung, daß sich zwei unmittelbar aufeinanderfolgende Versionen zeitlich nicht überlappen dürfen. Um Speicherplatz zu sparen und um den Verwaltungsaufwand zu minimieren, ist diese Kette nur in eine Richtung über Zeiger festgelegt, wobei sie bei der ältesten Version beginnt und immer zum nächsten Nachfolger zeigt. Das letzte Element zeigt dann wiederum auf die erste Ver­sion und anhand des Zeitstempelvergleichs läßt sich feststellen, daß es sich hierbei nicht um einen Nachfolger, sondern um den Ausgangspunkt handelt (vgl. Abbildung 58). Über diesen Ring läßt sich auch der Vorgänger bestimmen, ohne daß ein zusätzlicher Zeiger notwendig ist. Darüberhinaus sind Einfüge- und Löschoperationen in einem solchen Ring einfach zu bewerkstelligen, da jeweils nur ein Pointer im Vorgänger-Objekt korrigiert werden muß.

Abbildung 58: Versionenring zur Abbildung temporaler Vorgänger und Nachfolger



Quelle: Eigener Entwurf

Mit Hilfe der Verknüpfung zu einem TValidTime-Objekt kann für jedes räumliche Objekt eine Festlegung hinsichtlich der temporalen Dimension erfolgen. Für die Klassen der Spaghetti-Ebene bedeutet dies, daß die vollständige geometrische Beschreibung für den durch das TValidTime-Objekt beschriebenen Zeitraum gültig ist. Da sich in diesem Zu­sammenhang die Klasse STObject als eine Assoziation interpretieren läßt, die ein unab­hängiges Geometrie-Objekt mit einer Zeitangabe verknüpft, kann diese Geometrie auch in anderen Zeitabschnitten verwendet werden.

Während sich die Versionierung in den Spaghetti-Klassen unmittelbar immer nur auf eine Objektinstanz auswirkt, sind in den topologisch strukturierten Klassen immer mehrere Instanzen von einer Änderung betroffen. Ergibt sich beispielsweise für eine Kante ein neuer Verlauf, so bedeutet dies für die angrenzende Fläche, daß sich zumindest ihre Geo­metrie geändert hat und damit eine neue Version der Fläche vorliegt, da die Fläche selbst über keine eigene geometrische Beschreibung verfügt, sondern diese anhand der referenzierten Kanten zu ermittlen ist. Einen Sonderfall stellen die Knoten dar: hier ist die Registrierung unterschiedlicher Versionen aufgrund einer geometrischen Veränderung nicht sinnvoll, da die Interpretation, ob ein Knoten der Vorgänger eines anderen ist, oder ob hier zwei völlig voneinander unabhängige Knoten vorliegen, nur schwer zu führen ist. In der Regel führt das Einfügen eines neuen Knotens auch dazu, daß neue Kanten gebildet werden müssen. Deshalb kann man hier von folgenden Regeln ausgehen:

  1. Zwei Knoten, die durch unterschiedliche geometrische Punkte festgelegt sind, können dann als zwei zusammengehörige Versionen angesehen werden, wenn sie unmittelbar vor und nach der Änderung identische Kanten verbinden.

  2. Zwei Kanten mit unterschiedlichen Verbindungslinien sind dann Versionen von­einander, wenn sie durch identische Anfangs- und Endknoten markiert sind.

  3. Referenziert eine neu hinzugefügte Version einer Kante dieselbe rechtsliegende Fläche wie ihre Vorgängerin, dann muß ebenfalls eine neue Version dieser Fläche angelegt werden, die einen Zeiger auf die entsprechende Kante enthält.

Letztendlich muß es dem Anwender überlassen bleiben, hier zwischen den Alternativen zu wählen, da sich die Entscheidung zwischen Versionierung einerseits und Modellierung als völlig unabhängige Geo-Objekte andererseits auf den Anwendungskontext auswirkt. In einem Kanalnetz läßt sich beispielsweise einen bauliche Veränderung sowohl als Ver­schiebung eines bestehenden Schachtes als auch als Erneuerung durch einen neuen Schacht interpretieren, so daß hier die Entscheidung nicht schematisch nach geometrisch-topologischen Kriterien erfolgen kann, sondern einer Überprüfung anhand der Thematik bedarf.

Lediglich die Flächenversionierung für die topologisch strukturierten Klassen läßt sich automatisieren. Sobald eine neue Kante in das System eingefügt wird, kann nach einer Überprüfung, ob für den in der Kante angegebenen Zeitabschnitt eine geschlossene Flä­chenumrandung zur Verfügung steht, eine neue Version der Fläche erzeugt werden. Moderne serverbasierte Datenbanksysteme bieten für diese Automatisierungen sogenannte Trigger-Funktionen an, die durch das Eintreten eines bestimmten Bedingung - hier das Einfügen einer neuen Kante - ausgelöst werden.

Abbildung 59: Versionierung einer Fläche durch hinzugefügte Kanten



Quelle: Eigener Entwurf

Wie aus Abbildung 59 ersichtlich, erzwingt eine neue Kante nicht in allen Fällen eine weitere Flächenversion. Vielmehr kann nur anhand aller Veränderungen seit einem Aus­gangszustand die Anzahl der notwendigen Versionen bestimmt werden. Die Abbildung zeigt in fünf Teilschritten die Auswirkungen, wie sie sich aus dem Einfügen der Kanten k1 bis k5 auf die angrenzende Fläche ergeben, wobei angenommen wird, daß durch die neue Kante bzw. Kantenversion jeweils für die angegebene Zeitspanne eine gültige Flächenum­schreibung entsteht. Anhand der Zeitachse ist ersichtlich, für welchen Zeitraum die Kanten gültig sind, und wie sich analog dazu der durch eine Flächenversion beschriebene Zeitraum verhält. Während die Veränderung durch die Kante k2 zu zwei zusätzlichen Ver­sionen führt, wirkt sich k3 lediglich auf bereits bestehende Versionen aus. Letztendlich erzwingt jeder Start- und Endzeitpunkt in der Gültigkeitsdauer aller Kanten einer Fläche einen Versionsübergang.

Für die Navigation in der durch die topologisch strukturierten Klassen definierten Knoten-Kanten-Struktur bedeutet die Erweiterung auf die temporale Dimension, daß die ent­sprechenden Funktionen jeweils durch eine parametrisierte Version ersetzt werden müs­sen. Der eingeführte Parameter gibt einen Zeitraum bzw. einen Zeitpunkt an, für den die gültige Verbindung gesucht ist. Beispielsweise besitzt die neue Funktion zu GetInverse() dann folgende Signatur:

SEdge* GetInverse(TValidTime* time = 0);

Das Standardargument 0 wird hier so interpretiert, daß ohne die Übergabe eines TValidTime-Objektes der konstante Wert NOW verwendet wird, d.h. das System sucht die für den aktuellen Zeitpunkt gültige Kante.

Für Geo-Objekt-Mengen gilt, daß sich der zeitliche Bezug aus den einzelnen Elementen ergibt, so daß sich eine zusätzliche temporale Referenzierung hier erübrigt.