Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Grundlagen der Programmierung: Datenbanken

Schreibkonflikte verhindern

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Schreibkonflikte können auftreten, wenn mehrere Benutzer gleichzeitig auf eine Datenbank zugreifen. In diesem Fall sollten bestimmte Rechte gesperrt und das Aktualisieren von Informationen ausschließlich einem Benutzer erlaubt werden.

Transkript

Die Welt ist voller Konflikte und auch im Datenbankdesign da kennen wir sogenannte Schreibkonflikte. Worum es da genau geht, das zeige ich Ihnen jetzt in diesen Beispiel. Gehen wir davon aus, wir haben eine kleine Bank. Diese Bank hat lediglich 3 Konten, ein gemeinsames Konto da liegen $10000 darauf. Dieses Konto heißt Joint, weil es dies gemeinsame Konto von Alice und Bob ist. Alice hat $50 , Bob ist ein bisschen ärmer hat $45. Schauen wir uns mal an, was passiert, wenn jemand vom gemeinsamen Konto Geld auf das eigenen Konto überweisen möchte. Zunächst einmal schaue ich nach wie viel Geld ist denn auf den gemeinsamen Konto drauf, also get balance of Joint account ($10000), In Ordnung, dann schaue ich nach wie viel ist denn auf mein eigenen Konto drauf get balance of Alice account, das sind $50 Und wenn ich jetzt $1000 überweisen möchte, dann spalte ich das auf und sage zunächst einmal update balance of Joint account, also von den $10000 ziehe $1000 ab un in einem zweiten Schritt addiere diese $1000 zum meinem Konto hinzu, so das ich dann $1050 habe. So weit, so gut solang da nur einer zur selben Zeit darauf zugreift ist alles in Ordnung und wir haben gar keine Schreibkonflikte. Spannend wird es in folgendem Szenarium: Wir haben wieder unsere Bank mit den 3 Konten und jetzt sind Alice und Bob gleichzeitig vor ihren Rechnern und möchten Online Banking betreiben. Alice schaut nach; wie viel ist auf den gemeinsamen Konto drauf; $10000, alles in Ordnung. Bob macht zur gleichen Zeit das Gleiche und bekommt natürlich auch diese $10000. Dann schaut Alice bei sich nach, ich habe $50, und Bob schaut bei sich nach, ich habe $45, vielleicht kullert dann so eine Träne aus seinem Auge, ich weiß es nicht. Und jetzt wird es spannend. Wenn Alice jetzt $1000 zu sich überweisen möchte, dann sagt sie ja zunächst einmal, nimm vom gemeinsamen Konto, dass bei $10000 liegt und ziehe davon 1000 Dollar ab. Das Gleiche macht der Bob und er geht ja davon aus, dass $10000 auf diesen Konto darauf sind, also zieht er auch $1000 ab. Und es bleibt dann bei $9000 bei diesem gemeinsamen Konto. Alice bekommt dann die $1000, hat dann 1050. Bob bekommt auch $1000 und hat dann 1045. Das mag für die beiden als Paar Ideal sein, für die Bank ist es allerdings ein großes Problem, wenn $1000 zweimal ausgegeben werden. Ich weiß nicht, ob das einer der Gründe für die Bankenkrise ist, aber so kann es offensichtlich nicht funktionieren, wir müssen in unseren Datenbankdesign irgendwas etwas ändern. Das heißt wir fangen jetzt hier mit TRANSACTIONEN an. In den Moment, in den Alice anfängt auf Ihr Konto zuzugreifen und diesen Vorgang zu durchlaufen, sagen wir BEGIN TRANSACTION, Achtung ich fange jetzt hier mit einer besonderen Action an und erst wenn diese gesamte Action zu Ende ist, dann schließe ich das Ganze mit dem Wort COMMIT ab und sage hey, jetzt darf jemand anders darauf zugreifen. Wenn ich eine Datenbank habe auf der tausende von Personen gleichzeitig zugreifen, dann kann es sehr sehr schwierig werden, denn diese 4 Abfragen, also get balance of Joint account, of Alice account, dann zweimal das Update. Das kann natürlich eine zeit in Anspruch nehmen und deswegen gibt es zwei unterschiedliche Arten wie ich dafür Sorge tragen kann, dass niemand Anders gleichzeitig auf eine Datenbank zugreift, während ich darauf zugreife. Es gibt die eine Sperre, die heißt Pessimistische Sperre, die schauen wir uns mal an was damit gemeint ist. Ich habe hier wieder unsere Bank mit den 3 Konten, dann habe ich Alice und Bob und jetzt fängt Alice eine Millisekunde zuerst an mit einer Transaktion und sagt hey BEGIN TRANSACTION und sagt, zeige mir doch mal an wie viel auf den gemeinsamen Konto darauf ist, $10000. Bob macht das eine Millisekunde später, auch sagt er hier, ich möchte es mit einer Transaktion anfangen und sagt jetzt wie viel ist denn auf dem gemeinsamen Konto darauf und bekommt dann sofort die Meldung REFUSED. Das heißt, die Datenbank sagt den Bob , hey ne geht gerade nicht, es läuft gerade eine andere Transaktion, du kannst jetzt nicht auf das Konto zugreifen. Alice macht dann ganz gemütlich ihre Abbuchung, schaut nach wie viel hat sie hier drauf, nimmt die $1000 bei den Einem runter, fügt die $1000 bei sich drauf und sagt jetzt COMMIT und sagt hey, ich bin fertig, alles in Ordnung. Der Wert des Joint-Kontos hat sich jetzt auf 9000 verringert und jetzt kann Bob weitermachen und er bekommt jetzt hier eine neu Ballance zurückgeliefert von 9000, das ist die richtige und jetzt kann er hier ganz normal weitergehen und kann seinerseits $1000 von sich abheben. So weit, so gut. Wunderbar. Das ist pessimistisch. Pessimistisch bedeutet,dass in jeden einzelnen Schritt einer Transaktion ein Problem auftreten könnte. Wenn Sie sich aber vorstellen, es ist an einer großen Bank mit mehreren hunderttausend Kunden, von den viele auch gleichzeitig sich ihre Konten anschauen, dann wird es sehr sehr schwierig, weil ein Großteil dieser Bestandteile der Transaktion garnicht so kritisch ist. Wenn ich nachschaue wie viel auf mein Konto ist, dann kann das gleichzeitig jemand anders auch nachschauen. Also es gibt neben dieser Pessimistische Sperre auch die Optimistische Variante. Die sieht so aus: Wir haben wieder unsere 3 Konten, wir haben Alice und Bob und jetzt sagt Alice BEGIN TRANSACTION, wie viel ist denn auf dem gemeinsamen Konto drauf. Kurze Zeit später, also eine Millisekunde später sagt Bob das Gleiche und er bekommt auch diese $10000 zurückgeliefert, weil das reine Anschauen von Daten ja nicht irgendwie konfliktträchtig ist. Alice schaut nach, wie viel habe ich auf mein eigenen Konto, Bob schaut auch nach, wie viel habe ich auf meinem Konto. Und jetzt fängt Alice an den Kontostand vom gemeinsamen Konto zu verändern und wenn jetzt das Gleiche der Bob machen möchte, dann bekommt er hier eine Fehlermeldung dirty read detected-rollback-error und so weiter, alles ist jetzt in heller Aufregung. Warum? Weil nur dieses Update, also dieses updaten von Informationen, das führt ja zu einem geänderten Zustand in der Datenbank, und wenn seit Beginn der Transaktion so ein Update bei jemand anderen stattgefunden hat, dann habe ich hier einen, ja einen dreckigen Lesevorgang, so heißt es wörtlich übersetzt. Dirty Read hört sich schon schöner an, irgendwie, aber ich bekomme einen Fehler, weil diese 10000, die ich ursprünglich einmal gelesen hatte, nicht mehr mit den 9000 übereinstimmen. Wie geht es jetzt in diesen Millisekunden weiter? Alice bekommt diese $ 1000, fügt sie bei sich hinzu, sagt, alles klar ich bin fertig, mit COMMIT schließt sie das Ganze ab, und wenn jetzt Bob weiter macht, dann würde er eben hier nochmal auf die 9000 als Gesamtkontostand zugreifen können und kann ganz normal dann weiter machen. Das ist die Variante mit der sowohl Bob als auch die Bank auskommen können, weil der Zustand einer Datenbank sich dann immer für alle teilnehmenden Leute gleich und richtig darstellt. Schreibkonflikte treten dann zu Tage, wenn viele Leute gleichzeitig auf eine Datenbank zugreifen, aber je nach verwendetem Datenbankmanagementsystem gibt es verschiedene Schlüsselwörter und verschiedene Möglichkeiten, um mit Pessimistischen und Optimistischen Sperren umzugehen.

Grundlagen der Programmierung: Datenbanken

Fangen Sie ganz von vorne an und erfahren Sie alles über die Grundlagen zu Datenbanken und deren Einsatzzwecke, um danach eigene Lösungen und Anwendungen zu entwickeln.

3 Std. 6 min (39 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!