Next: 4.2 Implementierung
Up: 4.1 Entwurf
Previous: 4.1.6 Zusammenfassung
Für viele Transaktionskonzepte existieren Korrektheitsbeweise
([Wei88,RMB
93,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