Eine relationale Datenbank organisiert Daten als mathematische Relationen, die meist als Tabellen dargestellt werden. Eine Tabelle enthält Tupel mit festgelegten Attributen; sie kann etwa Kunden oder Bestellungen beschreiben. Verknüpfungen zwischen Tabellen sind häufig nützlich, aber keine Voraussetzung dafür, dass eine Datenbank relational ist.
Eine Tabelle kann man zunächst wie eine sehr große, streng geregelte Liste verstehen: Spalten beschreiben Eigenschaften, Zeilen einzelne Datensätze. In einer Kundentabelle wären Kundennummer, Name und E-Mail-Adresse mögliche Spalten; jede Zeile stünde für einen Kunden. Eine Bestelltabelle enthält dagegen beispielsweise Bestellnummer, Datum und Kundennummer.
Der entscheidende Punkt ist die Kundennummer. Sie erscheint als eindeutiger Schlüssel in der Kundentabelle und kann in der Bestelltabelle auf diesen Kunden verweisen. Die Tabellen müssen dadurch weder denselben Aufbau haben noch alle Angaben doppelt speichern. Eine Anwendung kann die passenden Informationen bei Bedarf zusammenführen. Oracle beschreibt relationale Datenbanken entsprechend als Datenbanken für Datenpunkte, die zueinander in Beziehung stehen, und als tabellarische Darstellung des relationalen Modells.Oracle
„Relational“ bedeutet hier nicht einfach, dass Daten irgendwie ähnlich aussehen. Gemeint sind ausdrücklich definierte Beziehungen zwischen Tabellen und Datenwerten. Das unterscheidet eine relationale Datenbank von einer bloßen Sammlung unabhängiger Tabellenkalkulationsdateien.
In einem relationalen Schema werden Tabellen, Spalten, Datentypen und Regeln festgelegt. Ein Primärschlüssel identifiziert einen Datensatz innerhalb seiner Tabelle eindeutig. Ein Fremdschlüssel kann aus einem oder mehreren Attributen bestehen und auf einen Schlüssel derselben oder einer anderen Tabelle verweisen. So kann etwa Bestellung.Kunden_ID auf Kunde.Kunden_ID zeigen.
Beim Abfragen wird häufig SQL eingesetzt, die Structured Query Language. Mit einer Abfrage lassen sich Tabellen verknüpfen, filtern, gruppieren oder zusammenfassen. IBM erläutert, dass Daten typischerweise auf mehrere Tabellen verteilt sind und über Primär- oder Fremdschlüssel verbunden werden; SQL-Abfragen können diese Datenpunkte kombinieren.IBM Eine Abfrage beantwortet dann nicht nur „Welche Bestellungen gibt es?“, sondern zum Beispiel: „Welche Bestellungen eines bestimmten Kunden wurden im letzten Monat aufgegeben?“
Zur Datenmodellierung gehört auch, Informationen nicht unnötig mehrfach abzulegen. Wird eine Kundenadresse in jeder Bestellung wiederholt, entstehen leicht widersprüchliche Versionen. Liegt sie an einer klaren Stelle, können Bestellungen über den Schlüssel auf den passenden Kundendatensatz verweisen. Welche Regeln sinnvoll sind, hängt jedoch vom Anwendungsfall ab: Datenmodelle müssen lesbar, leistungsfähig und für spätere Änderungen geeignet sein.
Ein Fahrradladen verwaltet Kundinnen und Kunden, Artikel und Bestellungen. Die Tabelle Kunden enthält pro Person eine Kundennummer. Die Tabelle Artikel führt Artikelnummer, Bezeichnung und Preis. In Bestellungen stehen Bestellnummer, Kundennummer und Datum; in Bestellpositionen stehen Bestellnummer, Artikelnummer und Menge.
Gibt eine Kundin zwei Artikel in einer Bestellung auf, werden nicht ihr Name und ihre Adresse in jeder Position neu eingetragen. Die Bestellpositionen verweisen auf die Bestellung, die Bestellung auf die Kundennummer und die Positionen zusätzlich auf Artikelnummern. Eine Auswertung kann daraus die gekauften Artikel mit Kundendaten verbinden. Ändert sich die Anschrift, wird sie nicht rückwirkend zum historischen Lieferbeleg umgedeutet: Ob Lieferadressen separat versioniert werden müssen, ist eine fachliche Modellierungsentscheidung.
Relationale Datenbanken werden dort verwendet, wo Informationen eindeutig zugeordnet, wiederholt abgefragt und verlässlich geändert werden sollen. Typische Beispiele sind Warenwirtschaft, Buchungen, Kundenverwaltung, Reservierungen, Personalverwaltung oder Content-Systeme. Auch eine Anwendungsschnittstelle kann Daten aus einer Datenbank lesen oder schreiben; wie sie Daten bereitstellt, erläutert der Beitrag zur Application Programming Interface.
Besonders passend ist das Modell, wenn mehrere Arbeitsabläufe auf dieselben fachlichen Objekte zugreifen: Eine Bestellung betrifft etwa Kunde, Produkte, Zahlung und Lieferung. Gute Schlüssel und Regeln helfen, ungültige Verweise zu vermeiden. Zusätzlich können Datenbanken Transaktionen anbieten. Dabei werden mehrere zusammengehörige Änderungen als Einheit verarbeitet. Bei einer Überweisung wäre es problematisch, wenn nur die Belastung, nicht aber die Gutschrift gespeichert würde. ACID-Eigenschaften beschreiben verbreitete Anforderungen an solche Transaktionen; sie sind kein Ersatz für ein sorgfältiges Datenmodell oder die Prüfung der Anwendung.
Für Analysen werden relationale Daten häufig mit anderen Systemen kombiniert. Eine Datenvisualisierung zeigt Ergebnisse verständlich, ersetzt aber weder eine korrekte Abfrage noch die Bewertung der Datenqualität.
Eine relationale Datenbank ist weder automatisch schnell noch automatisch korrekt. Schlechte Indizes, unpassende Abfragen, unklare Berechtigungen oder widersprüchliche Anforderungen können auch in einem relationalen System Probleme verursachen. Regeln wie eindeutige Schlüssel und referenzielle Integrität verringern bestimmte Fehler, ersetzen jedoch keine fachliche Kontrolle.
Nicht jede Information lässt sich am besten als feste Tabelle modellieren. Sehr unterschiedlich aufgebaute Dokumente, stark vernetzte Graphdaten oder große unstrukturierte Medienbestände können andere Speicher- oder Datenmodelle erfordern. In der Praxis sind Kombinationen üblich: Eine relationale Datenbank hält Kerndaten, während Suchsysteme, Objektspeicher oder Analyseplattformen ergänzende Aufgaben übernehmen.
Ebenso wichtig: „Datenbank“ und „Datenbankmanagementsystem“ sind nicht dasselbe. Die Datenbank ist die organisierte Datenbasis; ein relationales Datenbankmanagementsystem (RDBMS) ist die Software, die sie anlegt, abfragt, schützt und verwaltet. Bekannte Produkte sind keine Synonyme für das Konzept. Schließlich entsteht Datenschutz nicht allein durch Tabellenstruktur: Bei personenbezogenen Daten sind Zweck, Zugriff, Aufbewahrung und rechtliche Anforderungen gesondert zu prüfen.
Eine Tabellenkalkulation kann ebenfalls Zeilen und Spalten enthalten, erzwingt aber nicht automatisch die Beziehungen, Schlüsselregeln und Mehrbenutzer-Verarbeitung einer relationalen Datenbank. Ein Data Warehouse kann relationale Tabellen nutzen, ist aber auf Analyse und historische Auswertung ausgerichtet, nicht einfach ein anderer Name für jede relationale Datenbank. NoSQL bezeichnet zudem keine einheitliche Gegenkategorie, sondern mehrere Datenmodelle mit unterschiedlichen Stärken und Einschränkungen.