Kapitel 7 - Integrität und Transaktionskonzept

Klassifikation der Datenintegrität
Was ist semantische Integrität
Was ist operationale Integrität
Transaktionen und parallele Ausführung
Was sind Phantome?
Was bedeutet das ACID-Prinzip für Transaktionen?

Was kann zur Datenintegrität beigetragen werden?

Durch einzelne wenige fehlerhafte Daten kann der gesamte Datenbestand einer Datenbank zerstört werden. DBMS müssen deshalb einige Fehlersituationen selbstständig erkennen und entsprechend darauf reagieren.

fehlerbehaftete Bestandsänderungen durch Anwender und fehlerhafte Programmfragmente
Kollisionen im Mehrbenutzerbetrieb bei zeitgleichem Zugriff auf die Daten
Systemausfall aufgrund von Hardware- oder anderer Fehler innerhalb eines Abarbeitungsprozesses

Das Überprüfen von Randbedingungen für Attribut-Ausprägungen und das Überwachen von Beziehungen zwischen Tupeln sind zwei der wenigen Möglichkeiten des DBMS für den ersten Fall. Diese werden im Allgemeinen unter logischer Datenintegrität als Integritätsbedingungen bezeichnet.
Die wichtigste Komponente ist mit Sicherheit der Transaktionsmanager, welcher den Mehrbenutzerbetrieb abgleicht, um Kollisionen zu vermeiden.

In welche fünf Bereiche kann man Integrität klassifizieren?

Sematische Integrität
Operationale Integrität
Recovery
Datenschutz
Konsistenz (ist Synonym für Integrität)

Was ist semantische Integrität?

Das DBMS muss unabsichtliche Fehlbedienungen oder auch beabsichtigte Fehleingaben erkennen und hier Kontrollmöglichkeiten besitzen, um die Zulässigkeit der Eingaben zu prüfen.

Die Bedingungen werden im konzeptuellen Schema definiert oder im DBMS selbst etwa durch Typprüfungen für Attributwertdomänen oder Bereichsprüfungen numerischer Werte.

Das Problem von Integritätsprüfungen ist die möglich hohe Komplexität. Es muss also ein Trade-Off zwischen Veränderung der Laufzeit, der Wahrscheinlichkeit von Integritätsverletzungen und der Korrektheitsanforderung der jeweiligen Umgebung getroffen werden.

Was ist operationale Integrität?

Wenn mehrere Benutzer gleichzeitig an einer Datenbank arbeiten, können sie sich gegenseitig stören oder beeinflussen, wenn sie auf die selben Daten zugreifen. Auch wenn sich jeder Teilnehmer korrekt verhält, können durch Überschneidung von Operationen Fehler auftreten, welche die Datenbank in einen inkonsistenten Zustand versetzen könnten. Deshalb wird zur Aufrechterhaltung der operationalen Integrität eine Koordination der verschiedenen Operationen notwendig...

Deshalb wird hier der Begriff der Transaktion und der Synchronisation paralleler Transaktionen notwendig.

Was ist eine Transaktion?

Eine Transaktion ist ein Benutzerauftrag, der die Datenbank von einem konsistenten Zustand in einen anderen ebenfalls konsistenten Zustand überführen soll. Eine Transaktion ist zwingend atomar, d.h. nicht unterbrechbar durch irgendwelche anderen Prozesse bzw. Transaktionen!

Interner Ablauf eines SQL Statements

Transaktionen und korrekte Verarbeitung

Es muss eine zeitlich verzahnte Verarbeitung verschiedener Aufträge möglich sein. Dabei muss ein gewisser Grad an Fehlertoleranz garantiert werden können.

ein DB Benutzer darf nicht merken, dass er nicht alleine am System arbeitet
das DBMS muss selbstständig auftretende Konflikte lösen können

Transaktionsverarbeitung = Concurrency-Control + Recovery-Manager Wichtigstes Prinzip bei der Transaktionsverarbeitung ist das Read-Write-Transaktionen Modell, welches eine Abstrahierung erlaubt und dadurch Fehlerverarbeitung und Umgehung erleichtert. Read-Write-Transaktionen führen wiederrum zu Schedules.

Wozu Parallelität bei Transaktionsverarbeitung?

Ein DBMS könnte Konsistenz bewahren, wenn es alle ankommenden Transaktionen in einen Buffer legen würde, um sie dort sequentiell abzuarbeiten. Dies ist aber auf Grund extremer Wartezeiten nicht akzeptabel. Deshalb müssen Transaktionen so weit wie möglich Parallel verarbeitet werden. Dies kann ohne Bedenken geschehen, wenn folgende beiden Bedingungen zutreffen:

alle Transaktionen sind nur lesend
alle Transaktionen greifen auf keine gemeinsamen Elemente zu

Sind diese Bedingungen nicht gegeben kommt es zu Konflikten.

Was sind Phantome?

Phantome sind Objekte in einer Datenbank, welche zu einem bestimmten Zeitpunkt noch nicht existieren, die aber nicht illegal sind. Sie treten bei mehrphasigen Operationen, wie beim Erstellen von Statistiken auf. Wird in der ersten Phase eine Anzahl bestimmt, danach Datensätze hinzugefügt, so treten diese im weiteren Verlauf der Berechnungen als Phantome auf. Das DBMS muss dies irgendwie verhindern. Die Technik hierfür wird später erklärt. (Einführung von LOCK und UNLOCK)

Was bedeutet das ACID-Prinzip?

Atomicity (Atomar)

Aus Sicht des Nutzers wird seine Anfrage (bzw. Programm) komplett oder gar nicht ausgeführt. Falls ein Fehler während der Ausführung auftritt, erscheint die Datenbank in dem Zustand, als wäre der Code nie ausgeführt worden. Der Recovery Manager biegt es wieder gerade :-)

Consistency (Konsistenz)

Alle Integritätsbedingungen der DB werden eingehalten und die DB wird in einem konsistenten "Zustand" gehalten, falls sie vor Ausführung der Transaktion in einer solchen war.

Isolation

Das Programm läuft völlig unabhängig von eventuell parallel laufenden Prozessen in einem gesicherten Pufferbereich ab. Zur Verarbeitung bekommt des Programm nur sichere konsistente Daten aus der DB. Die Isolation verhindert somit Konflikte im Mehrbenutzerbetrieb.

Durability (Persistenz)

Falls eine "Befehl erfolgreich ausgeführt" Meldung angezeigt wird, muss sichergestellt sein, dass die geänderten Daten auch nach jedem Hard- oder Softwarefehler permanent in der Datenbank erhalten bleiben. Sogar wenn die Daten sich zu diesem Zeitpunkt noch im Puffer und nicht auf dem Sekundärspeicher befinden.

Was sind die Kostenkriterien einer Transaktion?

CPU-Intensität und I/O-Intensität.

Kann eine Transaktion zwischen BOT und EOT ein rechtliches Dokument erzeugen?

Nein, die Daten sind erst nach EOT bzw. nach dem abschließenden Commit 'amtlich'. Falls eine Dokument zwischen BOT und EOT amtlich wäre, dann wäre im übrigen die Rücksetzbedingung verletzt.

Inhalt

Anfang

zurück

vor

Kapitel 1	DBMS Konzept
Eigenschaften, Bestandteile, Ebenen...
Kapitel 2	DB Entwurf
Qualitätsmerkmale, funktionale Abhängigkeiten, ER...
Kapitel 3	Normalformen
Übersicht Normalformen, Anomalien...
Kapitel 4	Relationalität
Regeln und Vorgehensweisen...
Kapitel 5	Sprachen
relationale Sprachen, SQL, Query...
Kapitel 6	Datenorganisation
Tertiärspeicher, Adressierung, Indexe, ISAM...
Kapitel 7	Transaktionskonzept
Datenintegrität, Serialisierbarkeit, ACID...
Kapitel 8	Concurrency Control
Read-Write Modell, Schedules, Prinzip...
Kapitel 9	Scheduler & Recovery
2-Phasen-Sperren,Deadlocks,Recovery...