Konsistenz

Ein Datenbankzustand wird als konsistent bezeichnet, wenn die gespeicherten Daten alle Anforderungen der semantischen Integrität, die sich aus der Anwendung ergeben, erfüllen. Auf fehlerhafte Daten kann mit einer Fehlermeldung und dem Zurückweisen dieser Daten reagiert werden oder, falls möglich, auch mit einer automatischen Korrektur. Das Gegenteil einer konsistenten Datenbasis ist eine inkonsistente.

Die Aufgabe der Konsistenzsicherung kann sehr verschieden gelöst werden.

Die Prüflogik für die Daten kann in den Anwendungen selbst programmiert werden. Vorteil hier ist, das fehlerhafte Daten nicht erst zur DBS übermittelt werden müssen. Nachteilig ist, dass bei mehreren Programmen, die die gleichen Daten erfassen oder pflegen, sichergestellt werden muss, dass sie auch die gleiche Prüflogik ausführen. Zudem besteht dann auch immer die Gefahr, dass Daten mittels DB-Administrationstools (wie z.B. Oracle SQL-Developer, Toad von Quest) direkt und gänzlich ohne Prüfung manipuliert werden.
Eine wirklich bedenkenswerte Alternative bietet sich mit der Konsistenzprüfung im Datenbanksystem selbst, mit dem Vorteil, dass die gesamte Prüflogik nur einmal im DBS programmiert werden muss. Zu diesem Zweck stehen in den meisten relationalen Datenbanksystemen Werkzeuge wie TRIGGER und CONSTRAINTS zur Verfügung. Wesentlicher Vorteil dieser Strategie ist die zentrale Durchführung der Datenprüfung an nur einer Stelle, die von keinem Anwendungsprogramm umgangen oder "vergessen" werden kann. Die Korrektheit der Daten ist damit absolut garantiert. Das Konzept der Transaktionen gewährleistet, dass bei Datenmanipulationen (INSERT, UPDATE, DELETE) ein konsistenter Datenbankzustand wieder in einen ebenfalls konsistenten Zustand überführt wird.

In der Welt relationaler Datenbanksysteme herrscht ein sehr strikter Konsistenzbegriff vor basierend auf Transaktionen mit den ACID-Eigenschaften ?. Hier ist die Konsistenz der Daten oberstes Postulat.

Anders sieht es bei den NoSQL-Datenbanksystemen aus, die sich seit Anfang dieses Jahrtausends immer mehr entwickeln. Sie bieten sich für Anwendungen an, bei denen die Konsistenz vor den Anforderungen nach schnellen Antwortzeiten und immerwährender Verfügbarkeit zurücktritt (vgl. CAP-Theorem). Bei ihnen wird die Konsistenz eher als ein Zustand betrachtet, der irgendwann erreicht wird (vgl. Eventually Consistent, BASE).

Quellen:

Edlich, Friedland, Hampe, Brauer: „NoSQL – Einstieg in die Welt der nichtrelationalen Web2.0- Anwendungen“, Hanser-Verlag, 2010, ISBN 978-3-446-42355-8
Elmasri, Ramez/Navathe, Shamkant B.: "Grundlagen von Datenbanksystemen" , Pearson Studium, München, 2002, ISBN 3-8273-7021-3
Faeskorn-Woyke, Heide/Bertelsmeier, Birgit/Riemer, Petra/Bauer, Elena: "Datenbanksysteme - Theorie und Praxis mit SQL2003, Oracle und MySQL", Pearson Education, München, 2007, ISBN 978-3-8273-7266-6
Frey, M.: „Etablierte Datenmodelle der NoSQL-Familie und ihre spezifischen Eigenschaften im Kontext von Cloud-Datenbanken“, Bachelorarbeit, FH Köln, Institut für Informatik, 08/2010
Kemper, Alfons/Eickler, André: "Datenbanksysteme", Oldenbourg, München, 2009, 978-3-486-59018-0
Saake, Gunter/Sattler, Kai-Uwe/Heuer, Andreas: "Datenbanken - Konzepte und Sprachen", mitp-Verlag, Redline GmbH, Heidelberg, 2007, ISBN 3-8266-1664-2
Vossen, Gottfried: "Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme", Oldenbourg, München, 2008, ISBN 978-3-486-27574-2

Kategorie Allgemeines, Transaktionen, NoSQL, K