Relational Database (Relationale Datenbank)

Eine relationale Datenbank legt Daten in Tabellen aus Zeilen und Spalten ab und verknüpft diese Tabellen über gemeinsame Kennungen (Schlüssel, etwa eine Kunden-ID). Abgefragt wird sie mit SQL (Structured Query Language, einer standardisierten Abfragesprache). Sie geht auf das relationale Modell zurück, das E. F. Codd 1970 veröffentlicht hat, und sichert die Konsistenz der Daten über [ACID-Transaktionen](/insights/glossar/acid-transactions/) (Regeln, die Änderungen entweder ganz oder gar nicht wirksam werden lassen).

Was ist eine relationale Datenbank?

Der Begriff geht auf Edgar F. Codds Aufsatz „A Relational Model of Data for Large Shared Data Banks" (1970, IBM Research) zurück. Codd beschrieb darin, wie sich Daten sauber in Tabellen (Relationen) ordnen lassen und wie sich Beziehungen zwischen diesen Tabellen über gemeinsame Werte ausdrücken lassen (etwa eine Kunden-ID, die in mehreren Tabellen auftaucht) statt über technische Verweise auf Speicheradressen. Die ersten Umsetzungen entstanden Ende der 1970er Jahre mit IBM System R und der Berkeley-Datenbank Ingres; daraus gingen die heute verbreiteten Systeme Oracle Database, DB2, Sybase SQL Server (später Microsoft SQL Server) und PostgreSQL hervor.

Eine relationale Datenbank definiert ein festes Schema: jede Tabelle hat eine Menge von Spalten mit typisiertem Wertebereich, jede Zeile ist ein Tupel dieser Spalten. Der Primärschlüssel identifiziert eine Zeile eindeutig, ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle und stellt referentielle Integrität her. Redundanz und Update-Anomalien reduziert die Normalisierung (Normalformen 1NF bis 5NF), die redundante Daten in eigene Tabellen auslagert und über Joins wieder zusammenführt.

Abgefragt wird die Datenbank per SQL (Structured Query Language), einer deklarativen Sprache, die im ISO/IEC-9075-Standard festgeschrieben ist. Der Nutzer beschreibt das gewünschte Ergebnis, der Query-Optimierer der Datenbank plant die Ausführung. ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability) sichern zu, dass mehrere Änderungen entweder vollständig oder gar nicht wirksam werden, auch bei parallelen Zugriffen und Ausfällen. Verbreitete Systeme sind PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server, IBM Db2 und SAP HANA; im analytischen Umfeld arbeiten Snowflake, Amazon Redshift, Google BigQuery und [Databricks SQL](/insights/glossar/databricks-sql/) mit derselben relationalen Semantik, speichern die Daten aber spaltenorientiert.

Abgrenzung zu NoSQL, Data Warehouse, Lakehouse und Vector Database

Der Begriff wird in vier Richtungen häufig verwechselt. Die folgende Übersicht klärt, was eine relationale Datenbank von benachbarten Systemtypen unterscheidet.

NoSQL-Systeme wie MongoDB, DynamoDB, Cassandra oder Neo4j verzichten auf ein festes Schema und meist auch auf Joins; sie skalieren horizontal und akzeptieren dafür schwächere Konsistenzgarantien. Ein [Data Warehouse](/insights/glossar/data-warehouse/) ist im Regelfall relational, aber spaltenorientiert und für aggregierende Reads über große Datenmengen optimiert (OLAP-Profil) statt für Punktzugriffe (OLTP-Profil). Ein [Data Lakehouse](/insights/glossar/data-lakehouse/) speichert Rohdaten als Parquet-Files auf Objektspeicher und legt darüber ein Table-Format wie [Delta Lake](/insights/glossar/delta-lake/) oder Iceberg; die relationale Semantik entsteht in der Query-Engine, nicht in einem klassischen Datenbank-Server. Eine Vector Database speichert Embeddings für Ähnlichkeitssuche und ist kein Ersatz für relationale Systeme, sondern ergänzt sie um einen anderen Abfrage-Typ.

Beispiel: relationale Datenbank hinter einer Bestellplattform

Eine typische Bestellplattform betreibt eine PostgreSQL-Datenbank als operatives System. Die Tabelle kunden enthält Kundenstammdaten mit id als Primärschlüssel, die Tabelle bestellungen referenziert diese ID über kunde_id als Fremdschlüssel, und bestellpositionen verweist per bestellung_id auf die zugehörige Bestellung. Eine Abfrage wie SELECT k.name, SUM(bp.menge * bp.preis) FROM kunden k JOIN bestellungen b ON b.kunde_id = k.id JOIN bestellpositionen bp ON bp.bestellung_id = b.id GROUP BY k.name liefert den Umsatz je Kunde über drei verknüpfte Tabellen. Der Query-Optimierer entscheidet über die Join-Reihenfolge und nutzt Indizes auf den Schlüsselspalten.

Architektonisch sitzt eine relationale OLTP-Datenbank meist am Anfang der Datenstrecke: sie trägt die Anwendung und liefert konsistente Punktzugriffe. Für Reporting und Analytik werden die Daten per Change-Data-Capture oder Batch-Ingest in ein analytisches Zielsystem repliziert, häufig ein Data Warehouse oder ein Lakehouse. Beide behalten SQL als Abfragesprache bei, aber das Speicherformat wechselt von zeilenorientiert auf spaltenorientiert, weil aggregierende Queries über viele Zeilen dort effizienter laufen.