Transaktionsprogrammierung

Zusammenfassung

Bislang haben wir ausschließlich Fragen an unsere Datenbank gestellt. Es gibt durchaus Anwendungen, an die nach einmaligem Erstellen einer Datenbank fast nur noch Anfragen gestellt werden. Wollen wir zu wissenschaftlichen Zwecken etwa alle bekannten Maler und Werke vom Mittelalter bis zum Impressionismus katalogisieren, so ist die Datenbank nach ihrer Erstellung statisch. Im Idealfall kommt nichts mehr dazu und nichts geht verloren. Andererseits gibt es Datenbanken, die sich nahezu pausenlos ändern, da sie stets den aktuellen Zustand eines sich ständig wandelndes Systems repräsentieren sollen. Beispiele für solche Transaktionssysteme gibt es reichlich. Buchungssysteme aller Art, Lagerverwaltungen und natürlich auch beliebige Miet- und Leihgeschäfte, wie unsere Bibliothek. Eine derartige Datenbank soll zu jedem Zeitpunkt den korrekten Zustand für die Anwendung widerspiegeln. Welche Bücher haben wir, welcher Leser hat welches Buch, wieviel Gebühren hat ein Leser zu zahlen? All das ändert sich in einer großen Bibliothek mit mehreren Terminals bei Hochbetrieb unter Umständen mehrmals pro Sekunde. Immer wenn wir jemandem mit freundlichem Lächeln ein Buch für einen Monat lang in die Hände drücken, ist unsere Datenbank solange veraltet, bis die Tatsache “Leser X hat Buch Y” in der Verleihtabelle erscheint. Hier wird das Problem der Konsistenz einer Datenbank berührt.