Datenbank und DBMS: Wer macht was?

Kapitel 1 — „Die Karte des Archivs“

Der Schnappschuss von «Kotomarket» ist kein Signal aus einem toten Sektor mehr: Er liegt in einer Quarantänekammer an Bord von Vault-9, und unter der letzten Zeile seines Dumps steht noch immer dieselbe Signatur: „K.“ Heute Morgen erscheint auf deinem Holopanel ein neuer Eintrag: „Freigabe erteilt: Archivverzeichnis. Ausgestellt von: Modul S.Q.L.“ Die Tresortür gleitet zur Seite. Dahinter brummen Serverschränke in gleichmäßigem bernsteinfarbenem Licht.

QUERY: Bevor du fremde Erinnerungen liest, musst du verstehen, wie sie aufgebaut sind. Fangen wir mit dem Wichtigsten an: Was hier der Speicher ist und wer ihn bewacht.

Datenbank und DBMS

Eine Datenbank (DB) ist ein geordneter Speicher. Im Schnappschuss von «Kotomarket» liegen Käufer, Produkte, Bestellungen und Ereignisse: nicht verstreut in einzelnen Dateien, sondern in einer klaren Struktur. Genau deshalb lassen sie sich auch nach hundertsechzig Jahren noch lesen.

Der Speicher allein beantwortet aber keine Fragen. Dafür braucht es ein Programm, das Tabellen anlegt, neue Bestellungen speichert, Daten liest und darauf achtet, dass die Verbindungen nicht reißen. Dieses Programm ist das DBMS (Datenbankmanagementsystem). Beispiele sind PostgreSQL, MySQL und ClickHouse. Unser Schnappschuss ist eine PostgreSQL-Datenbank, und sie spricht dasselbe SQL wie zu Lebzeiten des Ladens.

Du schreibst eine Abfrage in SQL → sendest sie an das DBMS → das DBMS holt die passenden Daten und gibt das Ergebnis zurück. Excel ist gut für eine persönliche Tabelle, aber nicht für einen Laden, in dem Tausende Nutzer gleichzeitig Produkte ansehen, Bestellungen aufgeben und Ereignisse im System hinterlassen.

Database and DBMS

A database is an organized store. The Kotomarket snapshot holds buyers, products, orders, and events — not scattered across files, but in a clear structure. That’s exactly why it can still be read a hundred and sixty years later.

But the store itself doesn’t answer questions. You need a program that can create tables, record new orders, read data, and make sure the links never break. That’s a DBMS (database management system). Examples: PostgreSQL, MySQL, ClickHouse. Our snapshot is a PostgreSQL database, and it still speaks the same SQL it did when the shop was alive.

You write a query in SQL → send it to the DBMS → the DBMS fetches the data you asked for and returns the result. Excel is fine for a personal spreadsheet, but not for a shop where thousands of users browse products, place orders, and leave events in the system all at once.

Was ein DBMS kann, was „bloße Dateien“ nicht können

Auf den ersten Blick könnte der Laden auch ohne DBMS auskommen: Bestellungen einfach in eine CSV- oder Excel-Datei schreiben. Für ein persönliches Notizbuch reicht das tatsächlich — bis Aufgaben auftauchen, für die DBMS überhaupt erfunden wurden.

• Gleichzeitiger Zugriff. Im lebendigen «Kotomarket» gaben viele Käufer zur selben Zeit Bestellungen auf. Zwei Prozesse, die in dieselbe Datei schreiben, können einander die Änderungen überschreiben. Ein DBMS führt Änderungen als Transaktionen aus und koordiniert parallele Vorgänge selbst. PostgreSQL nutzt dafür MVCC: Lesende blockieren Schreibende nicht, und umgekehrt.
• Wiederherstellung nach einem Absturz. Der Strom flackert mitten im Schreibvorgang: Die Datei ist beschädigt, und niemand weiß, welche Hälfte der Bestellung es auf die Platte geschafft hat. Ein DBMS hält die Änderung zuerst in einem Journal fest (in PostgreSQL im WAL, dem Write-Ahead-Log) und spielt sie nach einem Absturz wieder ein. Die Bestellung ist entweder vollständig gespeichert oder gar nicht.
• Zugriffsrechte. Eine Datei ist entweder offen oder gesperrt. In einem DBMS lassen sich Rechte fein abstufen — bis hinunter zur einzelnen Tabelle:

-- Analitykowi — tylko odczyt zamówień, bez prawa ich zmieniać
GRANT SELECT ON orders TO analyst;

• Integrität. Ein DBMS akzeptiert keine Bestellung mit einem Preis als Text oder mit einem Verweis auf einen Käufer, den es nicht gibt. Spaltentypen und Constraints werden bei jedem Schreibvorgang geprüft. Einer Datei ist egal, was in ihr steht.
• Deklarative Fragen. „Zeige die Bestellungen über 5000“ — dafür genügt eine Zeile SQL. Bei einer Datei müsste jemand ein Programm schreiben, das dieselbe Arbeit erledigt und dabei auch wirklich stimmt.