Partially equivalent

Zur Klasse partially equivalent gehören alle Instanzen, bei denen einerseits ein Teil der Instanzänderungen ∆_I mit den Schemaänderungen ∆_S übereinstimmen, andererseits aber sowohl ∆_I als auch ∆_S noch weitere Änderungen besitzen, die im jeweils anderen nicht enthalten sind (vgl.

3 Grundlagen und Änderungskonzepte 42

Abbildung 3.14 Instanz I4). Die Verträglichkeit einer Instanz mit dem geänderten Schema definiert sich für diese Klasse folgendermaßen:

Kriterium 6 (Verträglichkeit instanzspezifisch-geänderter Prozessinstanzen der Klasse partially equivalent)

Instanz I ist verträglich mit dem geänderten Schema S’ wenn folgende Kriterien erfüllt sind:

1. Strukturelle Korrektheit: Die Propagierung des Teils der Schemaänderungen, der nicht mit

∆I übereinstimmt, führt mit dem Teil der Instanzänderungen, der nicht in ∆S enthalten ist, zu keinem strukturellen Konflikt.

2. Zustandsbasierte Korrektheit: Durch Propagieren der Änderungen ∆S \ ∆I kommt es zu keiner Verletzung der zustandsbasierten Korrektheit von I.

Im ersten Kriterium müssen lediglich die Änderungen betrachtet werden, die im jeweils anderen ∆ nicht enthalten sind. Formal: (∆S ∪ ∆I) \ (∆S ∩ ∆I). Dies liegt daran, dass der Teil der Änderungen, der sowohl bei ∆I als auch bei ∆S vorhanden ist, keine Konflikte verursachen kann (vgl. equivalent). Für die anderen Änderungen ergibt sich eine mit den Instanzen der Klasse disjoint analoge Situation.

Folglich muss für diesen Teil geprüft werden, ob es im resultierenden instanzspezifischen Schema zu einem strukturellen Konflikt kommt.

Das zweite Kriterium schränkt die zu prüfende Menge auf diejenigen Änderungen ein, die nur auf Schemaebene zum Einsatz gekommen sind. Dies hängt damit zusammen, dass es durch die Änderungen, die auch auf Instanzebene durchgeführt wurden, nicht zu einem zustandsbasierten Konflikt kommen kann. Die hier betrachteten Instanzen verhalten sich diesbezüglich analog zu den Instanzen der Klasse subsumption equivalent (∆I < ∆S). Die dort angegebene Begründung ist somit auch hier anwendbar.

Bei der Migration verträglicher Instanzen muss beachtet werden, dass die instanzspezifischen Änderungen sehr stark variieren können. Diese reichen vom Einfügen zweier unterschiedlicher Knoten (bzw. Aktivitäten) in denselben Zielkontext auf Instanz- und auf Schemaebene, bis hin zu Schema- und Instanzänderungen, die annähernd die gleichen Auswirkungen auf das ursprüngliche Schema S besitzen [Rind04]. Weiterhin ist es in einigen Fällen überhaupt nicht möglich, eine Instanz ohne Eingriff des Benutzers auf ein geändertes Schema zu migrieren. Als Konsequenz daraus, kann für Instanzen der Klasse partially equivalent keine einheitliche Migrationsstrategie definiert werden.

Es ist allerdings möglich, die angewandten Änderungen entlang ihres Typs weiter zu unterteilen. Dies wird als Änderungsprojektion (change projection) bezeichnet. Die Idee für diese Unterteilung beruht auf der Beobachtung, dass bei vielen der hier betrachteten Instanzen die Instanzänderungen ∆_I nur insgesamt gesehen mit den Schemaänderungen ∆S teilweise äquivalent (partially equivalent) sind.

Gruppiert man jedoch die Änderungen von ∆I und ∆S jeweils nach ihrem Typ und vergleicht die resultierenden Gruppen miteinander, so lassen sich diese oft so behandeln, wie die Änderungen der Klassen disjoint, equivalent oder subsumption equivalent. Da für diese Klassen automatische Migrationsstrategien vorhanden sind, ist es in einem solchen Fall möglich, auch Instanzen der Klasse partially equivalent automatisch zu migrieren. Anhand der folgenden Abbildung wird dies näher erläutert:

3 Grundlagen und Änderungskonzepte 43

Abbildung 3.16 Vergleich zweier Änderungen ∆_I und ∆_S

Vergleicht man die Änderungen, so zeigt sich, dass eine Instanz mit den abgebildeten instanzspezifischen Änderungen ∆_I zur Klasse partially equivalent gehört. Ohne weitere Überlegungen wäre es nun nicht möglich diese Instanz auf das geänderte Schema zu migrieren. Vergleicht man die Änderungen jedoch gruppiert nach ihrem Typ, so ergibt sich das folgende Bild:

Abbildung 3.17 Gruppieren der Änderungsoperationen

Die auf Instanzebene angewendeten Einfügeoperationen sind eine Teilmenge der Einfügeoperationen von ∆S. Die Einfügeoperationen von ∆I sind somit subsumption equivalent zu den Einfügeoperationen von ∆S. Die Löschoperationen sind sogar bei beiden Änderungen identisch. Folglich ist ∆I und ∆S

diesbezüglich equivalent. Weiterhin ist ∆_I bzgl. Datenflussänderungen eine Teilmenge von ∆_S (subsumption equivalent ∆I < ∆S) und ∆S eine Teilmenge⁶ von ∆I bzgl. Verschiebeoperationen (subsumption equivalent ∆S < ∆I). Durch diese Einteilung kann die Instanz automatisch auf das geänderte Schema migriert werden, da alle Änderungen mit Hilfe der Mechanismen aus equivalent und subsumption equivalent behandelt werden können.

Trotz der Projektionen ist es nicht möglich, alle Instanzen der Klasse partially equivalent automatisch zu migrieren. Dies ist z.B. dann der Fall, wenn beim Vergleich der Änderungen von ∆_S und ∆_I einer der folgenden Konflikte erkannt wird:

- Konkurrierender Zielkontext (conflicting target context): Eine Änderung aus ∆_S \ ∆_I vom Typ Einfüge- oder Verschiebeoperation (insert bzw. move) verwendet denselben Zielkontext wie eine insert- oder move- Operation aus ∆_I \ ∆_S. Diese Situation erfordert den Eingriff des Benutzers. Nur dieser kann entscheiden, welche Reihenfolge die eingefügten bzw.

6 Es wird immer die Teilmengenbeziehung verwendet, obwohl die Teilmenge wie im hier gezeigten Fall auch

„leer“ sein kann. Dies hängt damit zusammen, dass keine Migrationsstrategie für Änderungen existiert, die ausschließlich auf Instanzebene und nicht auf Schemaebene durchgeführt wurden.

3 Grundlagen und Änderungskonzepte 44

verschobenen Knoten im resultierenden instanzspezifischen Schema einnehmen sollen. Das folgende Beispiel zeigt eine solche Situation.

Abbildung 3.18 Konkurrierender Zielkontext

In beiden Fällen wird im Zuge der jeweiligen Änderungen ein neuer Knoten in den gleichen Kontext eingefügt. Während es sich bei der Schemaänderung um den Knoten X handelt, wird auf Instanzebene der Knoten Z eingefügt. Wie man sieht, besitzen beide Knoten als Zielkontext die Knoten A und B. Dies hat zur Folge, dass ohne Benutzereingriff nicht entschieden werden kann, welche Form das aus der Migration resultierende instanzspezifische Schema in Abbildung 3.18 besitzen soll.

- Zerstörung des Zielkontextes (context destroying change): Dieser Konflikt tritt immer dann auf, wenn entweder eine Änderungsoperation aus ∆_S den Zielkontext einer Änderungsoperation aus

∆I zerstört oder dies umgekehrt der Fall ist. Es können die folgenden 5 Situationen unterschieden werden:

1. Kontext wird verschoben (moving context away): ∆I verschiebt einen Knoten, der für eine Einfüge- oder Verschiebeoperation aus ∆S als Teil des Zielkontextes fungiert.

Gleiches gilt, wenn ∆_I einen Quell- oder Zielknoten verschiebt, der in ∆_S von einer createSyncEdge oder einer createDataEdge Operation benötigt wird. Beides gilt analog mit vertauschtem ∆I und ∆S.

2. Kontext wird gelöscht (deleting context): Die Situation ist grundsätzlich mit derjenigen aus Punkt 1 vergleichbar. Der Unterschied besteht jedoch darin, dass hier der Zielkontext nicht verschoben sondern gelöscht wird.

3. Aufheben einer Knotenattributänderung (overriding activity attribute change): ∆S bzw.

∆I löscht einen Knoten, bei dem eine Operation aus ∆I bzw. ∆S ein Attribut ändert.

4. Aufheben einer Kantenattributänderung (overriding edge attribute change): ∆_S bzw. ∆_I löscht einen Knoten, der bei einer Kantenattributänderung in ∆_I bzw. ∆_S als Quell- oder Zielknoten fungiert.

5. Datenkontext wird gelöscht (deleting data context): ∆S bzw. ∆I löscht ein Datenelement, das bei einer createDataEdge Operation aus ∆I bzw. ∆S verwendet wird.

Es wird an dieser Stelle nicht näher erläutert, wie Instanzen mit solchen Konflikten zu behandeln sind.

Hier genügt die Erkenntnis, dass sich zwar nicht alle Instanzen der Klasse partially equivalent ohne

3 Grundlagen und Änderungskonzepte 45 Eingriff des Benutzers migrieren lassen, die Konflikte, die dies verhindern, aber zuverlässig erkannt werden können. Daraus resultiert der Vorteil, dass der Benutzer bei der manuellen Migration besser unterstützt werden kann. Welche Mechanismen dazu vom Änderungsrahmenwerk bereitgestellt werden, wird in Abschnitt 7.7 (Migration von partially equivalent Instanzen) detailliert erläutert.