Comelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München Andernach

Die in den bisherigenArtikeln beschriebenen Aktivitäten innerhalb der Datenbank waren relativ kurz, sodass Überlegungen über Implikationen, die mit diesen Aktivitäten in Zusammenhang stehen, gar nicht in den Vordergrund traten. Eine einfache Abfrage bereitet tatsächlich keine Schwierigkeiten für ein DBMS. Einerseits erfüllt es den Grundtatbestand einer Transaktion, dass die Datenbank von einem konsistenten oder korrekten Zustand in einen anderen solchen Zustand überführt wird, aber Aktionen bauen nicht aufeinander auf. Grundprinzip von Transaktionen

Eine Überweisung von einem Konto auf ein anderes Konto besteht aus zwei grundlegenden Vorgängen: 1. Geld auf dem Quell-Konto abbuchen 2. Geld auf das Zielkonto buchen. Stürzt der Rechner ab, nachdem das Geld vom 1. Konto abgebucht wurde und unterstützt das System keine Transaktionen, so ist das Geld verloren, da es ja von Konto 1 abgebucht wurde, aber nie auf Konto 2 gutgeschrieben wurde. Unterstützt das System dagegen Transaktionen, so wird der Fehler erkannt und der Status vor der misslungenen Transaktion wieder hergestellt, d.h. das Geld wird wieder auf Konto 1 zurückgebucht. Der Zustand vor der Transaktion ist wieder hergestellt.

Eine Transaktion stellt wie in der Abbildung eine Reihe von einzelnen Aktionen dar, die in einem logischen und inhaltlichen Zusammenhang stehen. Dabei können diese Aktionen sowohl vom Benutzer als auch im Rahmen eines Programms ausgeführt werden. Letzterer Fall ist im Zusammenhang mit SQL-Erweiterung von besonderer Bedeutung, weil mit ihnen Programme entwickelt werden können, die komplexe Vorgänge mit Vergleichen, Entscheidungen und fallweiser Datenmanipulation selbstständig ausführen können.

Als Beispiel für ein Programm, das mit Transact SQL möglich ist, soll folgende Überlegung dienen: Eine Firma kontrolliert die Abverkäufe von Produkten in einem Webshop oder in einem angeschlossenen Ladennetz. Dabei setzt man eine einfache Heuristik als Controlling-Werkzeug ein, um Neubestellungen und Preise zu kontrollieren. Als kritische Schwelle wurde ein Nachfragerückgang von 25 % ermittelt, der nur über einen gewissen Zeitraum akzeptiert wird. Neben dem Preisrückgang wird also in einer ersten analysierenden Abfrage auch der Zeitpunkt erfasst, seit wann dieser Nachfragerückgang anhält. Die eigentliche Analyse besteht dann aus drei einfachen Faustregeln, die ein Vielfaches des vorgegebenen Zeitraums wie eine Woche oder einen Monat einbeziehen: Grundprinzip von Transaktionen

Unschwer erkennen Sie an diesem Beispiel, dass eine Vielzahl von einzelnen DB-Aktionen mit den Befehlen SELECT, UPDATE oder DELETE zu einer größeren Anwendung, also einer klassischen Transaktion zusammengefasst werden. Während die Fallunterscheidung bereits ganz typisch nach einer if-else-Verzweigung aussehen, sind die einzelnen Aktionen wie Preisreduktion oder Bestellungsverminderung in den einzelnen Anweisungsblöcken gespeichert. Grundprinzip von Transaktionen

Zwei Problemkreise bzw. gemäß der Abbildung zwei Gewitterwolken schweben über DB-Transaktionen: Wie bei allen Anwendungen und insbesondere Anwendungen in größeren Netzwerken kann es durch Komplexitäten innerhalb der Anwendung oder Datenübertragungen zu Problemen im Bereich des Datenerhalts und Strukturerhalts gehen. Unter gar keinen Umständen darf es geschehen, dass im Rahmen der Transaktion ein Fehler geschieht, der einen ungewollten Datenverlust oder eine Strukturänderung der Datenbank selbst nach sich zieht. Grundprinzip von Transaktionen

Ein weiteres Problemfeld, das vom DBMS gelöst werden muss, ist die zeitgleiche Anfrage für die Abarbeitung von Transaktionen unterschiedlicher Benutzer. Hierbei muss insbesondere darauf geachtet werden, dass eine konkurrierende Abfrage während der Abarbeitungszeit nicht das Grundprinzip zerstört, dass die Datenbank von einem konsistenten Zustand in einen anderen überführt wird.

Gerade bei Mehrbenutzerbetrieb und umfangreichen Transaktionen, die über einfache Abfragen oder kurzen Eintragungsvorgängen hinausgehen, und somit längere Zeit in Anspruch nehmen, muss das DBMS die Abfragen in einer geeigneten Reihenfolge abarbeiten, dass Abfragen mit überschneidenden Befehlen wie Lösch- und Einfügevorgänge in die gleiche Tabelle oder aufgrund gleicher Suchkriterien nicht zu Inkonsistenzen führen. Prinzipiell setzt das DBMS dabei parallele Anfragen so um, dass sie in eine geeignete Reihenfolge gebracht und damit eigentlich nicht wirklich gleichzeitig abgearbeitet werden. Die beiden entscheidenden SQL-Befehle sind COMMIT und ROLLBACK:

Comelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München AndernachComelio GmbH Datenbanken: Transaktionen ACID DB-Anomalien SQL DBMS Datenbank Anleitung Tutorial Handbuch Relationale Wolfsburg Freiburg Hamburg Berlin Magdeburg Aachen Lübeck Leipzig Bochum Hannover Stuttgart Ol Göttingen Bremen Würzuburg Heidelberg Kiel Bonn Ingolstadt Koblenz Ludwigshafen Rügen Erlangen Zwickau Koblenz Köln Kassel Mannheim Frankfurt München Andernach

Übersicht über Transaktionen

Kontakt

Transaktionen in Datenbanken