4.1.2 Gruppen -- jedem die seine

  Im Abschnitt über Gruppenstrukturen (Kap. 3.2.3) wurde darauf hingewiesen, daß zwischen der Aufteilung von Projekten auf Entwickler einschließlich der unterschiedlichen Isolationsanforderungen und dem Aufbau eines Baumes (als Datenstruktur) eine natürliche Äquivalenz besteht. Dieser von vielen Konzepten ausgenutzte Umstand wird auch hier verwendet. Die Transaktionen werden auf eine Hierarchie von Gruppen verteilt, die den Aufbau des Projektes nachbildet. Im Gegensatz zu Konzepten wie z.B. den Geschachtelten Transaktionen besteht die Hierarchie aus zwei verschiedenen Komponenten:

• Den Gruppen, die als passive Elemente hauptsächlich für die Verwaltung der Objekte und Zugriffsbeschränkungen (s.u.) zuständig sind. (Nach der Definition von [US92] sind sie also ,,service transactions``.)
• Den Transaktionen, die als ,,operational transactions`` Anfragen und Änderungswünsche über ihre Gruppe an die Datenbank stellen.

Diese Zweiteilung ähnelt der von [NRZ92] verwendeten Einteilung in ,,transaction groups`` und ,,cooperative transactions``.

Auch die verschiedenen Isolationsbedürfnisse werden berücksichtigt. So besteht zwischen den Transaktionen innerhalb einer Gruppe nur eine 0 oder 2 Isolation während die Gruppen gegeneinander auf Grad 3 isoliert sind. Um dies zu erreichen, wird folgendermaßen vorgegangen: Jede Gruppe erhält bei ihrer Erzeugung eine logische Kopie aller Objekte aus ihrer Obergruppe. ``Logische Kopie`` bedeutet, daß keine wirkliche Kopie der Daten angelegt wird, sich die sichtbaren Daten aber so verhalten, als wären sie kopiert worden. Die durch das Kopieren erhaltene Sicht wird weder durch Änderungen in der Obergruppe noch durch solche in etwaigen Untergruppen beeinflußt. Sichtbar werden lediglich die Endergebnisse der in der Gruppe ablaufenden Transaktionen sowie die von den Untergruppen explizit ``hochgespielten`` Daten. Soll die Sicht einer Gruppe mit der der Obergruppe in Einklang gebracht werden (sollen also die in der Obergruppe sichtbar gewordenen Änderungen übernommen werden), so muß dies ebenfalls explizit angefordert werden. Zudem kann sowohl das ``Hoch-`` als auch das ``Runterspielen`` von Änderungen natürlich Konsistenzverletzungen auslösen, die vom Integritättester erkannt und vom Benutzer behoben werden müssen.

In der Gruppe bekannt gewordene Änderungen beliebigen Ursprungs werden für alle Transaktionen in der Gruppe sofort sichtbar, da diese höchstens Isolationsgrad 2 haben. Soll also eine Transaktion mit Isolationsgrad 3 ablaufen, so muß für sie eine eigene Gruppe erzeugt werden, die keine Untergruppen besitzt und während der Laufzeit der Transaktion keine Anpassung an den Zustand der Obergruppe vornehmen darf. Inkonsistenzen zwischen den Änderungen der 3 isolierten Transaktion und den übrigen werden allerdings erst beim ``Hochspielen`` der Änderungen entdeckt.

Bei den 0 isolierten Transaktionen sind noch zwei Besonderheiten zu beachten. Zum einen ergeben sich, wie bereits weiter oben erwähnt, durch die geringe Isolation Probleme mit der Rücksetzbarkeit einzelner Transaktionen. Aus diesem Grund können alle 0 isolierten Transaktionen nur gemeinsam zurückgesetzt oder erfolgreich beendet werden. Zum anderen besitzen lediglich alle 0 isolierten Transaktionen gegeneinander diesen niedrigen Isolationsgrad. Gegenüber 2 isolierten Transaktionen beträgt ihr Isolationsgrad 2. Dieses der Definition etwas widersprechende Verhalten soll verhindern, daß zusätzlich zu den eben genannten Rücksetzproblemen noch Abhängigkeiten der 0 isolierten von den 2 isolierten Transaktionen auftreten. Die derzeitige Implementation geht sogar noch weiter und läßt nur entweder 0 oder 2 isolierte Transaktionen innerhalb einer Gruppe zu, der Isolationsgrad der Transaktionen ist also eine Eigenschaft der Gruppe.

 
Figure 4.3: Struktur aus Gruppen und Transaktionen

Jeder Gruppe sind gewisse Attribute zugeordnet, die neben einem eindeutigen Namen, der Ober- und den Untergruppen auch die Möglichkeit bieten, den Zugriff auf diese Gruppen lediglich für bestimmte Personen zu gestatten. Zwar besitzt ConceptBase kein Authentisierungssystem, so daß von einem sicheren Zugriffsschutz keine Rede sein kann, aber wenigstens in einer wohlwollenden Umgebung bietet sich -- insbesondere in Zusammenhang mit den in Abschnitt 4.1.5 vorgestellten Verfahren -- die Möglichkeit, den Datenzugriff zu beschränken.

Die Gruppenhierarchie muß natürlich auch dynamisch veränderbar sein und sich visualisieren lassen. Letzteres kann sehr einfach mit den bereits in ConceptBase vorhandenen Tools (Graphbrowser) erfolgen, wenn die grundlegenden Daten der Gruppenstruktur zur Verfügung stehen. Entweder blendet der Transaktionsmanager diese Daten virtuell in die Datenbank ein, ohne diese selbst zu verändern, oder er legt sie tatsächlich dort ab. Zwar hätte das zweite Verfahren den Vorteil, daß sich die Gruppenhierarchie durch 'TELL's und 'UNTELL's ändern ließe. Andererseits ergäben sich aber Probleme sowohl mit der Synchronisierung der vom Transaktionsmanager intern gehaltenen Strukturdaten mit den in der Datenbank vorhandenen, als auch mit der Sichtbarkeit und Zugriffsbeschränkung für diese Daten. Das Verschwinden einer bereits benutzten Gruppe durch das Rücksetzen der die Gruppe erzeugenden Transaktion stellt einen der möglichen GAUs dar.
Aus diesen Gründen ist es vorzuziehen, die Daten lediglich intern im Transaktionsmanager zu halten, der diese bei entsprechenden Anfragen in Propositionsform zur Verfügung stellt. Hierarchieänderungen lassen sich dann durch spezielle Befehle außerhalb einer Transaktion vornehmen.