Wie bereits in Kapitel 3.3.2 gezeigt, führt das Verhindern oder Hinauszögern von Lesezugriffen in deduktiven Datenbanken zu unannehmbaren Leistungseinbußen. Wenn in diesem Abschnitt also von Zugriffsbeschränkungen die Rede ist, so handelt es sich immer um die Beschränkung des schreibenden Zugriffs.
Das Gruppenkonzept (S.
) bezieht einige seiner
Vorteile aus der Annahme, daß sich die Daten größtenteils disjunkt auf die
verschiedenen Gruppen verteilen lassen. Da dies in ConceptBase
für
lesenden Zugriffe nicht durchführbar ist, bleibt nur noch die Möglichkeit übrig,
Änderungsbefugnisse aufzuteilen. Dies ist auch sinnvoll, da die
Zahl möglicher Konflikte zwischen den Gruppen abnimmt, je weniger Objekte
von
mehreren Gruppen aus geändert werden können.
Zur Verwirklichung dieser Idee wird ein dem aus SCCS bekannten 'Check Out' ähnlicher Mechanismus eingeführt. Bevor ein Objekt von einer Transaktion geändert werden kann, muß es zuerst von der entsprechenden Gruppe zum Schreiben angefordert worden sein. Diese vom eigentlichen Schreiben unabhängige Operation kann nur Erfolg haben, wenn das Objekt in der Obergruppe mit Schreiberlaubnis vorhanden ist. Ein automatisches mehrstufiges Anfordern solcher Berechtigungen -- wie z.B. im Tool Kit Ansatz vorgesehen -- findet nicht statt, da dies der Idee der Zugriffsbeschränkung widersprechen würde. Weil dieses Verfahren auch nicht zur Synchronisation genutzt wird, können im Gegensatz zum 'Check Out' von SCCS mehrere Untergruppen gleichzeitig eine Schreibberechtigung anfordern. Eine genauere Betrachtung, wer am sinnvollsten Schreibberechtigungen für eine Gruppe anfordern darf (alle Gruppenmitglieder, der Gruppenerzeuger, bestimmte Personen mit einem ausreichenden Rechtestatus) bleibt einer eventuellen Ausarbeitung über ein Authentisierungskonzept für ConceptBase überlassen.
Eine Erweiterung auf verschiedene Arten von Berechtigungen für Schreiben, Löschen, Einfügen von Instanzen und das Erzeugen ein- oder auslaufende Kanten, wie sie z.B. von [US92] vorgeschlagen werden, wäre eine passender Ausbau. Es bleibt auch zu überlegen, wie die Anforderung von Schreibberechtigungen über das Anfordern jeweils einzelner Objekte hinausgehend erweitert werden kann.
Von verschiedenen Personen wurden Zweifel geäußert, ob das optimistische Konzept in gewissen Situationen das Arbeiten nicht dadurch unmöglich macht, daß sämtliche Inkonsistenzen erst zum Transaktionsschluß geballt bekannt werden. Insbesondere treten diese Situationen bei gleichzeitigen Änderungen an einer Klasse und ihren Instanzen durch zwei verschiedene Transaktionen auf. Werden in der Klasse enthaltene Regeln geändert, so kann es u.U. vorkommen, daß die Ergebnisse der Transaktionen sich so stark widersprechen, daß eine der beiden Transaktionen zurückgesetzt werden muß, was natürlich unerwünscht ist.
Abhilfe versprächen ``echte``
Schreibsperren, die im Gegensatz zu obigen Schreibberechtigungen nur an
jeweils einen Benutzer vergeben würden. Bei Änderungen an einer Klasse
würden alle abhängigen Klassen und Instanzen gesperrt, so daß die Zahl unerwartet
auftretender Inkonsistenzen verringert wird.
Aufgrund der in Abbildung
3.7 sichtbaren, sowohl nach oben als auch nach unten
verzweigenden Klassenhierarchie erscheint aber bereits das Sperren aller von einer
Klasse abhängenden Unterklassen und Instanzen schwierig. Zudem können die
Regeln und Konsistenzbedingungen einer Klasse auch Instanzen völlig
anderer Klassen benutzen, so daß durch Änderungen an diesen
Instanzen ebenfalls die oben erwähnten Inkonsistenzen
entstehen können. Es läßt sich also kaum ermitteln, welche
Objekte gesperrt werden müßten, um die unbeeinflußte Änderung einer
Klasse zu garantieren.
Es erscheint darum sinnvoller, Änderungen am Schema, die solche Effekte
hervorrufen könnten, extern zu koordinieren.