Loading content
ACID ist ein grundlegendes Prinzip für Transaktionen in Datenbanksystemen; es fasst Atomicity, Consistency, Isolation und Durability zusammen, um Integrität und Wiederherstellbarkeit sicherzustellen. Es leitet Erwartungen an Fehlerszenarien, Nebenläufigkeit und Persistenz her und macht typische Design- und Performance-Trade-offs beim Systementwurf sichtbar.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was du verstehen musst, um ein Themenfeld sinnvoll zu denken.
ACID fasst vier Eigenschaften (Atomicity, Consistency, Isolation, Durability) zusammen, mit denen Datenbanktransaktionen Integrität und vorhersehbares Verhalten bei Fehlern, Nebenläufigkeit und Abstürzen gewährleisten sollen.
Als Problem stand die Frage im Mittelpunkt, wie sich ein Satz zusammengehöriger Datenänderungen trotz Fehlern, Stromausfällen und anderen Zwischenfällen als „gültige“ Einheit behandeln lässt. Das Akronym ACID wurde 1983 von Andreas Reuter und Theo Härder geprägt; es baut auf früheren Arbeiten von Jim Gray auf, der die Begriffe Atomicity, Consistency und Durability für das Transaktionskonzept benannt hatte (Isolation gehörte zunächst nicht dazu).
Stell dir eine Transaktion als „geschlossenen Arbeitsblock“ vor: Mehrere Schritte laufen zuerst in einer abgeschirmten Zwischenphase. Wenn alle Schritte die vorgesehenen Regeln erfüllen, werden die Änderungen als Einheit abgeschlossen (Commit). Wenn ein Fehler auftritt oder eine Regel verletzt wird, werden die bereits ausgeführten Schritte rückgängig gemacht (Rollback), sodass von außen nichts „halb passiert“ wirkt. Nebenläufige Transaktionen sehen die Zwischenphase nicht, sondern erst den finalen Zustand nach erfolgreichem Abschluss. Nach dem Commit müssen die Effekte auch nach einem Crash dauerhaft verfügbar bleiben—dafür wird der Abschlusszustand zuverlässig protokolliert, bevor er als „fertig“ gilt.
Eine Transaktion wirkt wie eine unteilbare Einheit: Entweder alle Schritte werden wirksam, oder keiner—damit keine partiellen Zustände entstehen.
Die Transaktion führt die Datenbank von einem konsistenten Zustand in einen anderen, indem eingeforderte Invarianten/Regeln eingehalten werden.
Gleichzeitige Transaktionen beeinflussen sich so, dass andere die unvollständigen Zwischenstände nicht sehen und das Ergebnis wie bei serieller Ausführung bleibt.
Nach einem erfolgreichen Commit bleibt die Transaktion dauerhaft wirksam—selbst wenn ein Systemfehler oder Absturz kurz danach passiert.
ACID hilft vor allem bei Architektur- und Korrektheitsentscheidungen, wenn du über Fehlerszenarien, Nebenläufigkeit und Datenintegrität nachdenken musst (z. B. bei Finanz-, Bestell- oder Buchungslogik). Dafür brauchst du eine Datenbank, die Transaktionen unterstützt und entsprechende Semantik anbietet. Grenzen zeigen sich dort, wo strengere Garantien Kosten erzeugen: Konsistenzprüfungen, Isolation und zuverlässiges Logging können zusätzliche Latenz/Last verursachen und in Fehlerfällen dazu führen, dass Transaktionen komplett fehlschlagen—statt teilweise weiterzulaufen.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.