next up previous contents
Next: 4.2 Implementierung Up: 4.1 Entwurf Previous: 4.1.6 Zusammenfassung

4.1.7 Korrektheit

  Für viele Transaktionskonzepte existieren Korrektheitsbeweise ([Wei88,RMB93,CHM92]). Hierbei wird meist gezeigt, daß die Verfahren eine Serialisierung erreichen bzw. die Datenkonsistenz erhalten. Das Prinzip der Serialisierbarkeit wurde für dieses Konzept jedoch fallengelassen und die Datenkonsistenz wird per Definition erhalten, da vor jedem Transaktionsende die Konsistenzbedingungen der Datenbank überprüft werden. Es erscheint darum fraglich, ob ein formaler Korrektheitsbeweis möglich oder auch nötig ist.

Ich möchte darum informell die wichtigsten Maßnahmen zur Erhaltung der ACID--Eigenschaften aufzählen:

Atomarität
wird durch die Ansammlung aller Datenänderungen einer Transaktion in einem temporären Speicher erreicht, der erst nach erfolgreichem Konflikt- und Konsistenztest in die Hauptdatenbasis überspielt wird.
Konsistenz
wird mit Hilfe der in das jeweilige Modell integrierten Konsistenzbedingungen sichergestellt, die vor jedem Transaktionsende von dem in ConceptBase enthaltenen Integritätstester überprüft werden.
Isolation
wird in drei verschiedenen Ausprägungen zur Verfügung gestellt. Die 'No dirty read'-Eigenschaft wird durch den schon erwähnten temporären Speicher und eine Beschränkung der Zugriffe auf die Datenbank während der Rückspielzeit einer abgeschlossenen Transaktion gewährleistet. 'Lost updates' können in ConceptBase , wie bereits mehrfach erwähnt, nicht auftreten, und 'Repeatable reads' werden für 3 Isolation durch das Aufbewahren alter Propositionen zur Verfügung gestellt.
Dauerhaftigkeit
umfaßt in diesem Konzept nur die Sicherstellung, daß Ergebnisse einer Transaktion nicht einfach verloren gehen dürfen. Erreicht wird dies durch die Eigenschaft von ConceptBase , jeder Proposition eine neue ID zuzuordnen, so daß sich das Problem der 'lost updates' gar nicht erst stellt.



Markus Baumeister
Fri Jun 9 15:38:00 MET DST 1995