Kapitel 7 - Integrität und Transaktionskonzept
|
Inhalt
|
- 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!
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.
|
|
|
|
|
| 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...
|
|
|
|
|
|
|
|
|
Quellen:
|
Gottfried Vossen
Datenbankmanagementsysteme
|
Heuer und Saake
Konzepte und Sprachen
|
Prof. Benn
Skript und Vorlesung
|
Relationale Datenbanken
Andreas Kelz
|
Word Wide Web
Verschiedenste Seiten
|
|
|
|
|
|
|
Home 
Normalformen