Relationale Datenbank

Kernidee und Grundbegriffe

Eine relationale Datenbank ist eine digitale Datenbank zur elektronischen Datenverwaltung. Sie organisiert Daten in Tabellen und beruht auf dem relationalen Datenbankmodell. Dessen mathematische Grundlage ist die Relation, also die wohldefinierte Beschreibung einer Tabelle. Operationen auf Relationen werden durch die relationale Algebra festgelegt. Das zugehörige Verwaltungssystem heißt relationales Datenbankmanagementsystem (RDBMS). Zum Abfragen und Verändern der Daten wird überwiegend SQL (Structured Query Language) verwendet. Edgar F. Codd schlug das Modell 1970 erstmals vor; trotz Kritik ist es bis heute ein etablierter Standard.

Eine Tabelle entspricht einer Relation. Jede Zeile ist ein Tupel beziehungsweise Datensatz, jede Spalte ein Attribut, also eine Eigenschaft. Eine einzelne Zelle enthält einen Attributwert. Das Relationenschema bestimmt, wie viele Attribute eine Relation besitzt und welchen Typ sie haben.

Jeder Datensatz muss eindeutig identifizierbar sein. Dazu dient ein Schlüssel, der aus einem oder mehreren Attributen bestehen kann. Er bezieht sich auf den Datensatz und nicht auf dessen Position in der Tabelle und darf sich niemals ändern. In einer Tabelle „Buch“ können beispielsweise Buch-ID, Autor, Verlag, Verlagsjahr, Titel und Datum der Aufnahme die Attribute bilden. Die Buch-ID ist der Schlüssel, weil sie jedes Buch eindeutig identifiziert.

Beziehungen und Fremdschlüssel

Mehrere Tabellen lassen sich miteinander verknüpfen, um Beziehungen zwischen ihren Datensätzen darzustellen. Eine Bibliotheksdatenbank kann beispielsweise aus den Tabellen „Buch“, „Nutzer“ und „Entliehen“ bestehen. „Buch“ enthält für jedes Buch einen Datensatz mit der Buch-ID als Schlüssel. „Nutzer“ speichert etwa Nutzer-ID, Vorname und Nachname; die Nutzer-ID identifiziert einen Nutzer eindeutig.

Die Tabelle „Entliehen“ enthält die Attribute Nutzer-ID und Buch-ID. Jede Zeile ordnet damit einem Nutzer ein ausgeliehenes Buch zu. Der Eintrag (10,300) bedeutet im Beispiel, dass der Nutzer mit der ID 10, „Hans Vielleser“, das Buch mit der ID 300, „Mein Leben mit Asterix“, entliehen hat. Der Eintrag (10,200) ordnet demselben Nutzer außerdem „Drucken leicht gemacht“ zu.

Der Schlüssel von „Entliehen“ ist die Attributmenge (Nutzer-ID, Buch-ID). Zugleich verweist die Nutzer-ID auf einen Datensatz in „Nutzer“ und die Buch-ID auf einen Datensatz in „Buch“. Solche verweisenden Attribute heißen Fremdschlüssel. Tabellen ohne Fremdschlüssel werden flache Tabellen genannt.

Im relationalen Datenbankmodell wird „Relation“ allgemein als Synonym für Tabelle verwendet und beschreibt die Zuordnung der Attribute zum Relationsnamen. Im Entity-Relationship-Modell hat der Begriff eine andere Bedeutung: Dort bezeichnet eine Relation die Beziehung zwischen Entitäten.

Relationale Algebra

Die theoretischen Grundlagen relationaler Datenbanken wurden von Edgar F. Codd in den 1960er- und 1970er-Jahren gelegt und in „A Relational Model of Data for Large Shared Data Banks“ beschrieben. Theoretisch beruhen sämtliche Operationen auf der relationalen Algebra. Dieses algebraische Modell beschreibt, wie Daten gespeichert, abgefragt und verändert werden können.

Die grundlegenden Operationen sind:

• Projektion: Auswahl bestimmter Attribute beziehungsweise Spalten.

• Selektion: Auswahl der Tupel, die eine Bedingung erfüllen.

• Kreuzprodukt oder kartesisches Produkt: Kombination der Tupel zweier Relationen.

• Umbenennung: Änderung von Bezeichnungen innerhalb des algebraischen Ausdrucks.

• Vereinigung: Zusammenfassung geeigneter Relationen.

• Differenz: Ermittlung der Tupel, die in einer Relation, aber nicht in der anderen enthalten sind.

Ein RDBMS übersetzt SQL-Anfragen in solche Operatoren. In der Praxis gibt es weitere Operatoren. Der Join verknüpft beispielsweise zusammengehörige Daten aus mehreren Tabellen, lässt sich aber auf eine Kombination aus Kreuzprodukt, Selektion und Projektion zurückführen.

Die ursprüngliche relationale Algebra unterstützt keine rekursiven Anfragen beziehungsweise keine Berechnung der transitiven Hülle. Daher lassen sich etwa alle Vorfahren einer Person nicht in einer einzigen Anfrage bestimmen, wenn Personen in der Relation „Person“ und ihre Verbindungen in „VorfahreVon“ gespeichert sind; dafür ist eine Folge von Anfragen nötig. Mit SQL-99 wurde eine erweiterte relationale Algebra eingeführt, die eine Operation zur Berechnung der transitiven Hülle erlaubt.

Schema und Datenmodellierung

Das Datenbankschema legt fest, welche Daten gespeichert werden und wie sie miteinander in Beziehung stehen. Seine Erstellung heißt Datenmodellierung. Beim Entwurf relationaler Datenbanken wird häufig das Entity-Relationship-Modell verwendet. Es beschreibt zunächst ein konzeptuelles Schema. Dieses wird anschließend in das Implementierungsdatenmodell eines Datenbankmanagementsystems übertragen. Dieser Schritt heißt logischer Entwurf oder Datenmodellabbildung; sein Ergebnis ist das im DBMS umsetzbare Datenbankschema.

Ein wichtiger Teil der Modellierung ist die Normalisierung. Sie soll Redundanzen, also unnötige Mehrfachspeicherungen derselben Information, verringern und Anomalien verhindern. Dadurch werden die Wartung vereinfacht und die Konsistenz der Daten gesichert. Edgar F. Codd schlug vier Normalformen vor, die beim relationalen Datenbankentwurf eingesetzt und später um weitere Normalformen ergänzt wurden.

Die wichtigsten Begriffe verschiedener Darstellungsweisen entsprechen sich ungefähr: Eine Tabellenzeile ist im Relationenmodell ein Tupel, im Entity-Relationship-Modell eine Entität und in der Unified Modeling Language (UML) ein Objekt beziehungsweise eine Instanz. Eine Spalte heißt in allen drei Modellen Attribut. Eine Tabelle entspricht einer Relation, einer Entitätsmenge beziehungsweise einer Objekt- oder Instanzmenge. Ein Fremdschlüssel stellt eine Verbindung her, die im Entity-Relationship-Modell als funktionale Beziehung und in UML als Assoziation erscheint.

Alternative Datenbankmodelle

Neben relationalen Datenbanken existieren Modelle mit anderen Datenstrukturen. Manche älteren Konzepte haben nur noch geringe Bedeutung, können für bestimmte Anwendungen aber eine einfachere Anbindung bieten. In den letzten Jahren haben sich außerdem vermehrt sogenannte NoSQL-Datenbanken durchgesetzt.

Hierarchische Datenbanksysteme und Netzwerk-Datenbanksysteme wurden besonders in den 1960er- und 1970er-Jahren zur betrieblichen Datenverarbeitung eingesetzt. Ihre Daten- beziehungsweise Tabellenstruktur wird bereits beim Entwurf festgelegt und kann während einer Abfrage nicht variiert werden. In Spezialfällen werden sie weiterhin verwendet.

Objektorientierte Datenbanken speichern Objekte aus objektorientierten Sprachen wie Java direkt. Dadurch entfällt das objektrelationale Mapping, also die Übertragung von Objekten auf relationale Tabellen. Das ist bei komplexen Datenobjekten hilfreich, die sich nur schwer in flachen Tabellen abbilden lassen. Bei großen Datenmengen haben Objektdatenbanken jedoch Nachteile. Mehrere mögliche Zugriffspfade, etwa über Vererbung und Assoziation, können bei Schreiboperationen in der Sperrverwaltung exponentielle Komplexität und damit schlechte Leistung verursachen.

Objektrelationale Datenbanken ergänzen relationale Systeme um bestimmte objektorientierte Eigenschaften. Sie bilden Programmobjekte nicht direkt ab, sondern nutzen beispielsweise Vererbung für die Definition und Abfrage von Tabellen mit ähnlichen Feldstrukturen. Dabei wurden nur Konstrukte geringerer Komplexität, etwa O(n · log(n)), übernommen. SQL-99 enthält objektrelationale Sprachelemente.

Semistrukturierte Datenbanken besitzen kein fest vorgegebenes Schema. Sie sind hierarchisch beziehungsweise baumartig aufgebaut, und Einheiten desselben Typs dürfen unterschiedliche Attributmengen haben. Typische Vertreter sind XML-Datenbanken. Sie verwalten wohlgeformte XML-Fragmente mit beliebigen hierarchischen Strukturen und werden über XQuery oder XPath abgefragt; zur Manipulation dienen derzeit proprietäre Spracherweiterungen. Gegenüber relationalen Systemen ist ihre Leistung geringer. Semistrukturierte Datenbanken können auch durch Erweiterungen oder Server-Programmierung auf relationalen Datenbanken umgesetzt werden, wenden dann aber das Relationenmodell nicht mehr an.

Kritik und Grenzen

Ein Kritikpunkt ist die Segmentierung komplexer Anwendungsobjekte auf viele Relationen. Da das relationale Modell nur Mengen von Tupeln aus einzelnen Werten kennt, muss ein Datenbankmanagementsystem zusammengesetzte Objekte bei Abfragen durch zahlreiche Joins wiederherstellen. Das kann Abfragen unübersichtlich machen. Änderungen an der Objektstruktur können Anpassungen erfordern, und die Joins benötigen passende Datenbankindizes. Dadurch können Ressourcenbedarf und Entwicklungsaufwand höher sein als beispielsweise bei einer Objektdatenbank.

Manchmal sind künstliche Schlüsselattribute notwendig, obwohl sie nicht zur eigentlichen Beschreibung des Anwendungsobjekts gehören. Sie können etwa einen als Fremdschlüssel verwendeten Schlüssel verkürzen oder Gehört-zu-Beziehungen ermöglichen, stellen aber reine Verwaltungsinformationen dar.

Viele relationale Datenbanken besitzen nur Datenmanipulationssprachen mit eingeschränkter Mächtigkeit und benötigen deshalb Schnittstellen zu umfassenderen Programmiersprachen. Dabei kann ein sogenannter Object-relational impedance mismatch entstehen, etwa wenn das mengenorientierte SQL in dem satzorientierten C++ verarbeitet werden muss. Einige Systeme bieten jedoch mächtige eigene Sprachen: Oracle verwendet PL/SQL, PostgreSQL PL/pgSQL und Microsoft SQL Server T/SQL. PL/SQL kann Java- oder C++-Programme einbinden; PL/pgSQL ermöglicht Server-Programmierung unter anderem mit PHP, Tcl oder Python.

Außerdem kann eine relationale Datenbank das anwendungstypische Verhalten eines Objekts nicht beschreiben. Dieses Verhalten muss in der Anwendungssoftware umgesetzt werden. Nutzen mehrere Anwendungen denselben Datenbestand, kann dies zu mehrfacher Implementierung führen. Unter dem Sammelbegriff NoSQL werden nicht-relationale Modelle zusammengefasst, die solche Probleme mit anderen Ansätzen lösen sollen.