Das relationale Datenbankmodell

Bekanntermaßen gehören Datenbanken zu den Kernkomponenten eines jeden Computersystems. Denn jedes Computerprogramm greift in seiner Laufzeit auf Daten zurück oder generiert selbst Informationen, die zuverlässig, widerspruchsfrei und dauerhaft gespeichert werden müssen. Dies erfolgt in strukturierten Datenbanken (DB), die von sogenannten Datenbank-Managementsystemen (DBMS) verwaltet werden. Bei Datenbank-Managementsystemen handelt es sich um Software-Anwendungen, die mit End-Anwendern oder anderen Programmen interagieren und diesen eine Teilmenge der in der Datenbank gespeicherten Datenbasis zur Verfügung stellen.

Bis heute wird die elektronische Datenverwaltung vom relationalen Datenbankmodell dominiert. Zu den meistgenutzten relationalen Datenbank-Managementsystemen (RDBMS) zählen in alphabetischer Reihenfolge:

• Db2: Mit Db2 steht Anwendern ein proprietäres relationales Datenbank-Managementsystem aus dem Hause IBM unter kommerzieller Lizenz zur Verfügung.
   
• Microsoft SQL Server: Das relationale Datenbank-Managementsystem von Microsoft ist unter einer kostenpflichtigen Microsoft-Endanwenderlizenz verfügbar.
   
• MySQL: Bei MySQL handelt es sich um das meistgenutzte quelloffene RDBMS der Welt. Seit der Übernahme durch Oracle wird MySQL unter einem dualen Lizenzsystem vermarktet. Die ursprüngliche Entwicklergemeinde führt das Projekt unter dem Namen MariaDB weiter.
   
• PostgreSQL: Mit PostgreSQL können Anwender auf ein freies, objektrelationales Datenbank-Managementsystem (ORDBMS) zurückgreifen. Die Weiterentwicklung erfolgt durch eine Open-Source-Community.
   
• Oracle Database: Das relationale Datenbank-Managementsystem des gleichnamigen Unternehmens Oracle wird als proprietäre Software kostenpflichtig vermarktet.
   
• SQLite: Bei SQLite handelt es sich um eine gemeinfreie Programmbibliothek, die ein relationales Datenbank-Managementsystem enthält.

Alle genannten Systeme basieren auf einer tabellarischen Organisation von Informationen. Doch was hat es damit auf sich? Wir führen Sie in die Grundprinzipien des relationalen Datenbank-Designs ein, stellen Ihnen relationale Datenbanken anhand von Beispielen vor und grenzen den Datenbanktyp von anderen Modellen ab.

Ein zentraler Begriff des relationalen Datenbankmodells ist die Relation. Dieser geht auf den britischen Mathematiker und Datenbanktheoretiker Edgar F. Codd zurück. Nach Codd stellt eine Relation eine Menge von Entitäten mit gleichen Eigenschaften dar. Jede Relation besteht aus einer Reihe von Datensätzen (sogenannten Tupel), deren Werte bestimmten Attributen zugeordnet sind.

Welche Attribute eine Relation umfasst und welchem Datentyp die den Attributen zugeordneten Werte entsprechen, wird mithilfe eines Relationenschemas nach folgender Syntax definiert:

R = (A₁ : Typ₁, A₂ : Typ₂ , … , A_n : Typ_n)

Das Relationenschema (R) umfasst die Attribute A₁ bis A_n. Jedem Attribut ist ein Datentyp (Typ_1, Typ₂ etc.) zugeordnet. Verdeutlichen lässt sich dies an einem konkreten Beispiel.

Folgendes Schema definiert die Attribute der Relation „mitarbeiter“:

Das Beispielschema umfasst die Attribute Mitarbeiter-ID (m_id), Nachname, Vorname, Sozialversicherungsnummer (svn), Straße (str), Postleitzahl (plz) und Ort und könnte beispielsweise der unternehmensinternen Verwaltung von Personaldaten dienen. Jedem Attribut wird ein Datentyp (beispielsweise string oder integer) zugeordnet. Es gibt somit in dieser Relation Attribute, die Zeichenketten als Werte erwarten, und solche, die ausschließlich ganzzahlige Zahlenwerte akzeptieren.

Eine Relation mit dem soeben definierten Schema könnte nun folgendes Tupel enthalten:

Die Beispieltabelle dient der Speicherung von Personaldaten und besteht aus vier Datensätzen. Jeder Datensatz beinhaltet Informationen zu genau einem Mitarbeiter.

Die Datenbank eines relationalen Datenbanksystems bildet die tabellarisch strukturierte Datenbasis. Definiert wird deren Datenstruktur vom Datenbank-Managementsystem, das zudem für die Verwaltung der Schreib- und Lesezugriffe verantwortlich ist. Anwender interagieren mit dem Datenbank-Managementsystem mithilfe einer Datenbanksprache. Jedes relationale Datenbank-Managementsystem unterstützt mindestens eine formale Sprache, mit der sich folgende Datenbank-Operationen vornehmen lassen:

• Datenstruktur definieren: Im Rahmen der Datendefinition wird eine Beschreibung der Datenstruktur über Meta-Daten im Data-Dictionary des Datenbanksystems abgelegt. Erstellt ein Anwender beispielsweise eine neue Tabelle, wird ein entsprechendes Relationenschema im Data-Dictionary gespeichert. Das Vokabular einer Datenbanksprache, das der Datendefinition dient, wird Data Definition Language (DDL) genannt.
  
  
• Berechtigungen definieren: Jede Datenbanksprache stellt eine Syntax zur Verfügung, die es ermöglicht, Berechtigungen zu vergeben oder diese zu entziehen. Man spricht in diesem Zusammenhang von der Data Control Language (DCL) – einem Teilvokabular der Datenbanksprache.
  
  
• Integritätsbedingungen definieren: Unter Integritätsbedingungen versteht man Anforderungen an den Zustand einer Datenbank. Werden Bedingungen für die Integrität definiert, stellt die Datenbank sicher, dass diese zu jedem Zeitpunkt erfüllt sind. Man spricht von einem konsistenten Zustand. Eine grundlegende Integritätsbedingung in relationalen Datenbanksystemen ist beispielsweise, dass sich jeder Datensatz (Tupel) eindeutig identifizieren lässt.
  
  
• Transaktionen definieren: Wird eine Datenbank von einem konsistenten Zustand in einen anderen überführt, spricht man von einer Transaktion. Transaktionen beinhalten eine Reihe von Anweisungen und müssen stets vollständig durchgeführt werden. Kommt es zum Abbruch einer Transaktion, wird die Datenbank in den Ausgangszustand zurückgesetzt (Rollback). Jede Transaktion beginnt mit der Anweisung, eine Verbindung zur Datenbank herzustellen. Dieser folgen Befehle, die die eigentliche Datenoperation einleiten, sowie ein Prüfschritt (Commit), der die Integrität der Datenbank sicherstellt. Integritätsgefährdende Operationen werden nicht committet (permanent in die Datenbank geschrieben). Abschließend wird die Verbindung zur Datenbank geschlossen. Das der Datenmanipulation zugrundeliegende Vokabular der Datenbanksprache nennt man Data Manipulation Language (DML).
  
  
• Views definieren: Bei einem View handelt es sich um eine virtuelle Ansicht ausgewählter Daten. Das Datenbank-Managementsystem erstellt im Fall eines Views eine virtuelle Tabelle (logische Relation) auf Basis physischer Tabellen. Auf diese Views können Nutzer dieselben Datenbank-Operationen anwenden wie auf physische Tabellen. Man unterscheidet je nach Funktion der Datenansicht verschiedene Arten von Views. Gängig sind Views, die bestimmte Zeilen (Selektionssicht) oder Spalten (Projektionssicht) aus einer ausgewählten Tabelle herausfiltern, sowie Views, die verschiedene Tabellen miteinander verknüpfen (Verbundsicht).

Als Standard-Schnittstelle für die oben aufgeführten Datenbank-Operationen nutzt man im relationalen Datenbankmodell die auf der relationalen Algebra basierende Datenbanksprache SQL (Structured Query Language).

Datenbank-Operationen wie das Abfragen, Erstellen, Aktualisieren oder Löschen von Daten erfolgen mithilfe sogenannter SQL-Statements – eine Kombination ausgewählter SQL-Befehle. Diese sind semantisch an die englische Sprache angelehnt und somit weitgehend selbst erklärend. Folgende Tabelle enthält zentrale Begriffe des relationalen Datenmodells und deren Entsprechung in der SQL-Terminologie.

Eine einfache Abfrage ausgewählter Daten ließe sich mit SQL beispielsweise nach folgendem Schema umsetzen:

Wir nutzen zunächst den Befehl SELECT, um das RDBMS anzuweisen, Daten abzufragen. Anschließend definieren wir, welche Daten wir abfragen möchten, indem wir die Tabelle sowie die gewünschte Spalte angeben. Darüber hinaus integrieren wir mit WHERE eine Bedingung in das SQL-Statement. Wir möchten nicht sämtliche in der Spalte gespeicherten Attributwerte abrufen, sondern lediglich den Wert eines bestimmten Datensatzes.

Bezogen auf unsere Beispieltabelle „mitarbeiter“ könnte ein solches SQL-Statement folgendermaßen aussehen:

Das SQL-Statement weist das RDBMS an, aus der Tabelle „mitarbeiter“ einen Wert aus der Spalte svn abzurufen. Als Bedingung haben wir definiert, dass der Wert aus dem Datensatz entnommen werden soll, bei dem der Attributwert der Spalte m_id dem Wert 3 entspricht.

Als Ergebnis liefert uns die Datenbank 25 091225 M 463 – die Sozialversicherungsnummer von Günther Meyer, dem Mitarbeiter mit der ID 3.

Ein solcher Schlüssel mit den Werten

wäre somit geeignet, den Datensatz zum Angestellten Günther Meyer widerspruchsfrei zu identifizieren. Man spricht bei Schlüsseln dieser Art von Superschlüsseln. Superschlüssel haben in der Praxis jedoch nur eine geringe Bedeutung. Ein Grund dafür ist, dass Superschlüssel oft mehr Attribute beinhalten, als für die Identifikation notwendig wären. Mit anderen Worten: Superschlüssel sind nicht minimal.

In relationalen Datenbanken arbeitet man daher mit kleinstmöglichen Teilmengen eines denkbaren Superschlüssels – sogenannte Schlüsselkandidaten. Eine Tabelle kann dabei durchaus mehrere Schlüsselkandidaten aufweisen, mit denen sich Datensätze eindeutig identifizieren lassen.

Bereits das Abfragebeispiel im vorhergehenden Abschnitt hat gezeigt, dass die Datensätze der Tabelle „mitarbeiter“ allein durch die Mitarbeiter-ID widerspruchsfrei zu identifizieren sind. Ein weiterer Schlüsselkandidat der Beispieltabelle ist die Sozialversicherungsnummer. Ein Schlüssel {nachname, vorname} wäre hingegen kein geeigneter Schlüsselkandidat, da diese Kombination von Attributen nicht eindeutig einem Mitarbeiter zugeschrieben werden kann. Denn in einem Unternehmen können durchaus mehrere Angestellte mit dem Namen Günther Meyer beschäftigt sein. Die Identifikation über einen solchen Schlüssel wäre also nicht eindeutig. Dass sich zwei Angestellte dieselbe Mitarbeiter-ID oder Sozialversicherungsnummer teilen, ist hingegen ausgeschlossen.

Für die oben dargestellte Beispieltabelle lassen sich somit folgende Schlüsselkandidaten bestimmen:

Relationale Datenbanktabellen werden in der Regel so strukturiert, dass einer der möglichen Schlüsselkandidaten die Reihenfolge der Datensätze vorgibt. Dieser Schlüsselkandidat wird Primärschlüssel (Primary Key) genannt. In der Praxis handelt es sich bei Primärschlüsseln meist um fortlaufende IDs. Mit der m_id weist auch unsere Beispieltabelle eine solche ID auf.

Da Schlüssel Datensätze in relationalen Datenbanktabellen eindeutig identifizieren, eigenen sich diese hervorragend, um verschiedene Tabellen einer Datenbank miteinander in Beziehung zu setzen. Dazu nimmt man den Primärschlüssel der einen Tabelle als Fremdschlüssel (Foreign Key) in die andere Tabelle auf.

Folgende Tabelle umfasst Daten, die ein Unternehmen zum firmeneigenen Fuhrpark erfasst haben könnte. Primarschlüssel der Tabelle „kfz“ ist eine fortlaufende kfz_id.

Um abzubilden, welche Mitarbeiter welchen Firmenwagen benutzen, muss man die Tabelle „kfz“ mit der Tabelle „mitarbeiter“ verknüpfen – beispielsweise, indem der Primärschlüssel der Kfz-Tabelle (die kfz_id) als Fremdschlüssel in die Mitarbeiter-Tabelle integriert wird.

Der Mitarbeiter-Tabelle ist nun zu entnehmen, dass Angestellter Schmidt einen Firmenwagen mit der kfz_id 3 benutzt. Angestellter Krause fährt ein Fahrzeug mit der kfz_id 2. Müller und Meyer hingegen teilen sich den Wagen mit der kfz_id 1.

Soll nun ermittelt werden, welcher Mitarbeiter seinen Firmenwagen wann das nächste Mal warten lassen muss, müsste man dazu sowohl die Tabelle „mitarbeiter“ als auch die Tabelle „kfz“ abfragen. Da beide Tabellen über Fremdschlüssel miteinander in Beziehung stehen, lässt sich dies mit nur einer Abfrage bewerkstelligen. Datenbank-Operationen, die sich über mehrere Tabellen erstecken, werden im relationalen Datenbankmodell mithilfe eines JOINs realisiert.

Bei einem JOIN (auf Deutsch: Verbund) handelt es sich eine Datenbank-Operation, die es ermöglicht, mehrere Datenbanktabellen gleichzeitig abzufragen. Dabei werden die Daten ausgewählter Tabellen zu einer Ergebnismenge zusammengefasst und nach benutzerdefinierten Bedingungen gefiltert ausgegeben.

Mathematische Grundlage des SQL JOINs sind zwei Operationen der relationalen Algebra: das kartesische Produkt und die Selektion. Welche Daten der abgefragten Tabellen in die Ergebnismenge aufgenommen werden, bestimmen Anwender durch die Wahl des JOIN-Typs sowie mithilfe einer Selektionsbedingung.

Zu den wichtigsten JOIN-Typen zählen:

• INNER JOIN
• OUTER JOIN
• SELF JOIN

Unabhängig davon sind EQUI JOINs und NON EQUI JOINs zu unterscheiden.

Wie SQL JOINs über relationale Datenbanktabellen funktionieren und was bei der Wahl des JOIN-Typs zu beachten ist, ist Thema des weiterführenden Artikels zum SQL JOIN.

Abzugrenzen sind relationale Datenbanken auf SQL-Basis von solchen Konzepten, die mit der starren Tabellenstruktur brechen und alternative Ansätze zur Datenstrukturierung verfolgen. Zu den prominentesten Konzepten dieser Art zählen Objektdatenbanken und dokumentenbasierte Systeme.

Ende der 1980er-Jahre trat mit Objektdatenbanken ein bis dahin neues Datenbankmodell auf den Plan, das Konzepte der objektorientierten Programmierung aufgriff und eine Datenspeicherung in Form von Objekten ermöglichte. Durchsetzen konnte sich dieser Ansatz bis heute jedoch kaum. Stattdessen sind Konzepte der Objektorientierung in die Entwicklung relationaler Datenbanksysteme miteingeflossen. Das Ergebnis sind Produkte mit objektrelationalen Erweiterungen, die eine Speicherung abstrakter Datentypen im relationalen Datenbankmodell ermöglichen.

Mit der veränderten Nutzung des Internets im Rahmen des Web 2.0 geriet das relationale Datenbankmodell zur Jahrtausendwende erneut unter Beschuss. Im Rahmen der NoSQL-Bewegung (kurz für Not Only SQL) wurden Alternativmodelle wie dokumentenorientierte Datenbanken entwickelt. Ziel dieser Bewegung war es, leistungsstarke Datenbankkonzepte für datenintensive Anwendungen zu entwickeln.

Vom relationalen Datenbankmodell unterscheiden sich Objektdatenbanken und dokumentenorientierte Datenbanken vor allem darin, wie der Datenbestand gespeichert wird und wie auf gespeicherte Daten zugegriffen werden kann.

Das objektorientierte Datenbankmodell sieht die Speicherung von Daten als Objekte vor. Die Modulation von Objekten erfolgt dabei analog zur objektorientierten Programmierung. Ein Objekt definiert eine Entität und enthält:

• die zur Beschreibung der Entität benötigten Eigenschaften (Attribute),
• Verweise (Beziehungen) zu anderen Objekten sowie
• Funktionen, die den Zugriff auf die gespeicherten Daten ermöglichen (Methoden).

Ein Objekt ist somit ein Verbund von Daten, in dem zudem die Schnittstelle definiert ist, über die man auf diese Daten zugreift. Objekte zählt man zu den abstrakten Datentypen.

Jedem Objekt wird vom objektorientierten Datenbank-Managementsystem (ODBMS) automatisch eine ID zugewiesen. Die ermöglicht es, das Objekt eindeutig zu identifizieren und mit Methoden anzusprechen. Diese Objekt-ID ist zustandsunabhängig, d.h. von den Objektwerten entkoppelt. Es ist somit möglich, zwei Objekten mit denselben Daten (d.h. mit demselben Zustand) zwei unterschiedliche IDs zu geben. Damit grenzt sich das objektorientierte Datenbankmodell deutlich vom relationalen Modell ab, bei dem jeder Tupel anhand seiner Daten identifiziert werden kann (z. B. durch einen Primärschlüssel).

Ein weiteres Merkmal des objektorientierten Datenbankmodells ist die Datenkapselung. Auf gespeicherte Daten kann man ausschließlich über die zuvor definierten Methoden zugreifen. Die im Objekt gekapselten Daten sind somit vor Änderungen über nicht definierte Schnittstellen geschützt.

Datenbankstrukturen werden im objektorientierten Datenbankmodell über ein hierarchisches Klassensystem definiert. Unter einer Klasse versteht man in der objektorientierten Programmierung eine Menge von Objekten, die dieselben Merkmale besitzen. Jeder Objektklasse liegt eine Klassendefinition zugrunde. Dieses Schema gibt die Attribute und Methoden aller Objekte der Klasse vor und bestimmt somit, wie diese erzeugt und geändert werden.

Anwender interagieren mit dem ODBMS mit einer an SQL angelehnten Abfragesprache für Objektdatenbanken: der Object Query Language (OQL). Das Ergebnis einer OQL-Abfrage ist nicht wie bei SQL eine Ergebnismenge, sondern eine Liste jener Objekte, die den Bedingungen des OQL-Statements entsprechen.

Bekannte Implementierungen des objektorientierten Datenbankmodells sind Realm, ZODB und Perst.

Entwickelt wurden objektorientierte Datenbanken als Lösung auf ein Problem in der Anwendungsentwicklung, das als Object-relational impedence mismatch (objektrelationale Unverträglichkeit) bezeichnet wird.

Sollen Objekte aus einer objektorientierten Programmiersprache (z.B. C#, C++ oder Java) in einer relationalen Datenbank gespeichert werden, kommt es unweigerlich zu Inkompatibilitäten, die durch grundlegende Unterschiede beider Programmierparadigmen begründet sind.

• Relationale Datenbanken unterstützen keine objektorientierten Konzepte wie Klassen und Vererbung.
• Die zustandsunabhängige Objektidentifikation lässt sich im relationalen Datenbankmodell nicht realisieren.
• Der Schutzmechanismus der Datenkapselung steht im relationalen Datenbankmodell nicht zur Verfügung.

Ein Ansatz, die genannten Inkompatibilitätsprobleme zu vermeiden, besteht darin, auf relationale Datenbanken zu verzichten und im Rahmen der objektorientierten Anwendungsprogrammierung stattdessen auf eine Objektdatenbank zu setzen. Dies geht jedoch zwangsläufig mit dem Nachteil einher, dass in Objekten gekapselte Daten nicht unabhängig von der dazugehörigen Anwendung zur Verfügung stehen. Hinzu kommt die geringe Verbreitung von Objektdatenbanken. Die meisten Tools und Schnittstellen zur Analyse von Datenbeständen sind nach wie vor auf relationale Datenbanken ausgelegt und unterstützen das objektorientierte Datenmodell nicht.

Anwendungsentwickler, die auf die Vorteile einer relationalen Datenhaltung nicht verzichten möchten, haben allerdings die Möglichkeit, Inkompatibilitäten mithilfe objektrelationaler Mapper (O/R-Mapper) zu kompensieren. Funktionalitäten zur objektrelationalen Abbildung (object-relational mapping, ORM) werden über Bibliotheken implementiert. Diese erzeugen eine Abstraktionsschicht zwischen der objektorientierten Anwendung und den in Tabellen gespeicherten Daten.

Auch zahlreiche Hersteller relationaler Datenbanksysteme statten ihre Produkte mit Funktionen aus, die Inkompatibilitäten zur objektorientierten Programmierung kompensieren. Datenbanksysteme dieser Art werden „objektrelational“ genannt.

Objektorientierte Datenbanken übertragen Grundprinzipien der Objektorientierung auf Datenbanktechnologien und bieten sich daher vor allem im Rahmen der objektorientierten Anwendungsprogrammierung an. Entsprechende Datenbanksysteme sind jedoch rar und zum Teil noch nicht marktreif.

Bei einem objektrelationalen Datenbanksystem handelt es sich um ein relationales Datenbanksystem, das man um Konzepte der Objektorientierung erweitert hat. Die bewährten Prinzipien des relationalen Datenbankmodells sollen dadurch auf abstrakte Datentypen wie Objekte ausgeweitet werden.

Um eine Verwaltung abstrakter Datentypen zu ermöglichen, erweitern objektrelationale Datenbanken das relationale Datenbankmodell um

• komplexe, benutzerdefinierte Datentypen,
• Typkonstruktoren sowie
• Funktionen und Methoden.

Während relationale Datenbanken im Wesentlichen auf alphanumerische Datentypen beschränkt sind, lassen sich mit benutzerdefinierten Datentypen auch komplex strukturierte Multimedia-Dateien verwalten. Typkonstruktoren ermöglichen es, neue Datentypen aus vorhandenen Basistypen abzuleiten. Da die Datenbanksprache SQL keine Möglichkeit bietet, Funktionen zu erzeugen, müssen objektrelationale Datenbanksysteme Erweiterungen bereitstellen, mit denen sich Zugriffs- und Verarbeitungsfunktionen für komplexe Datentypen definieren lassen.

Ab der Jahrtausendwende wurden objektrelationale Erweiterungen wie strukturierte Typen in neuere Versionen des SQL-Standards aufgenommen. Diese werden jedoch nicht von allen DBMS unterstützt. Bekannte Datenbanksysteme, die entsprechende Erweiterungen zur Verfügung stellen, sind IBM Db2, Oracle Database und Microsoft SQL Server.

Während die Datenspeicherung bei relationalen Datenbanken in Datenbanktabellen erfolgt, liegt dem dokumentenorientierten Datenbankmodell eine heterogene Datenbasis aus Einzeldokumenten zugrunde. Dabei kann es sich sowohl um strukturierte Dokumente wie JSON-, YAML- oder XML-Dateien handeln als auch um unstrukturierte Dateien wie Binary Large Objects (BLOBs) – beispielsweise Bild-, Video- oder Audiodateien. Liegen strukturierte Dokumente vor, erfolgt die Speicherung von Daten in Form von Schlüssel/Wert-Paaren. Jedem Schlüssel wird ein konkreter Wert zugeordnet. In diesem Zusammenhang wird der Schlüsselbegriff synonym zum Begriff Attribut verwendet und hat nichts mit den Schlüsseln im relationalen Datenbanksystem zu tun. Bei Werten kann es sich um beliebige Informationen handelt. Auch Listen und Arrays mit geschachtelten Daten sind mögliche Werte. Ein Dokument im JSON-Format (JavaScript Object Notation), das der Speicherung von Mitarbeiterdaten dient, könnte beispielsweise folgendermaßen aussehen:

Mehrere Dokumente lassen sich zu Dokumentensammlungen (sogenannten Collections) zusammenfassen. Das dargestellte Mitarbeiterdokument könnte beispielsweise zusammen mit anderen Teil der Collection „Mitarbeiter“ sein.

Abfragen werden mithilfe von Funktionen realisiert – beispielsweise via JavaScript. Auch Datenbank-Managementsysteme, die dokumentenorientiert arbeiten, vergeben an jedes Dokument eine eindeutige ID. Anders als im relationalen Datenbankmodell existiert jedoch kein die ganze Datenbank umfassendes Datenbankschema. Dokumente einer dokumentenbasierten Datenbank müssen weder einer Normalform gerecht werden noch gibt es vorgegebene Strukturmerkmale, die auf alle Dokumente zutreffen müssen. Prinzipiell kann also jedes Dokument anders aufgebaut sein. Im Rahmen der Anwendungsentwicklung empfiehlt es sich jedoch, Dokumente in einem der Anwendung entsprechenden Schema anzulegen, um die Voraussetzung für gezielte Abfragen zu schaffen.

Beziehungen wie die Verknüpfung von Datenbanktabellen im relationalen Datenbankmodell lassen sich mit dokumentenorientierten Datenbanken nicht umsetzen. Es ist zwar möglich, die ID eines Dokuments als Referenz manuell in ein anderes Dokument einzutragen, dokumentenorientierte Datenbank-Managementsysteme bieten jedoch keine JOINs. Entsprechende Abfragemöglichkeiten müssten Sie somit selbst programmieren.

Dokumentenorientierte Datenbanksysteme bieten sich vor allem dann an, wenn große Datenmengen mit heterogener Struktur und geringer Vernetzung verarbeitet werden sollen. Damit ist dieses Modell der Datenhaltung vor allem für Big-Data-Szenarien sinnvoll.

Relationale Datenbanksysteme stellen zu jeden Zeitpunkt sicher, dass die in den Tabellendefinitionen angegeben Bedingungen erfüllt sind. Das führt bei der Bearbeitung großer Datenmengen zu vergleichsweise langsamen Schreibgeschwindigkeiten. NoSQL-Datenbanksysteme haben keine so strengen Anforderungen an die Datenkonsistenz und eigenen sich daher für große Architekturen, bei denen viele Datenbankinstanzen parallel betrieben werden.

Auch Web-Anwendungen greifen immer häufiger auf dokumentenorientierte Datenbanken zurück. Ist jedoch eine starke Vernetzung erforderlich, ist die dokumentenbasierte Datenspeicherung mit größerem Aufwand verbunden. Anwender sollten in diesem Fall besser relationale Datenbanksysteme nutzen.

Beispiele für dokumentenorientierte Datenbanken sind BaseX, CouchDB, eXist, MongoDB und RavenDB.

Relationale Datenbanken haben sich nicht ohne Grund als De-Facto-Standard in der elektronischen Datenverarbeitung durchgesetzt. Folgende Punkte sprechen für das relationale Datenbankmodell.

• Einfaches Datenmodell: Relationalen Datenbanken liegt ein Datenmodell zugrunde, das sich vergleichsweise einfach implementieren und verwalten lässt. Zahlreiche Informationen – wie Kundendaten, Bestelllisten oder Kontobewegungen –, die Unternehmen langzeitig speichern wollen, lassen sich mit der dem relationalen Datenbankmodell zugrundeliegenden Tabellenstruktur ideal abbilden.
  
  
• Geringe Datenredundanz: Das relationale Datenbankmodell gibt mit den verschiedenen Normalformen genau definierte Regelungen zur Redundanzvermeidung vor. Werden die Vorgaben zur Normalisierung konsequent umgesetzt, ermöglichen relationale Datenbanksysteme eine nahezu redundanzfreie Datenhaltung. Dies erleichtert vor allem die Pflege und Wartung von Datenbeständen, da Änderungen lediglich an einer Stelle vorgenommen werden müssen.
  
  
• Hohe Datenkonsistenz: Normalisierte relationale Datenbanken ermöglichen eine widerspruchsfreie Datenhaltung und tragen somit zur Datenkonsistenz bei. Relationale Datenbanksysteme bieten zudem Funktionen, mit denen sich Integritätsbedingungen definieren und automatisch überprüfen lassen. Transaktionen, die die Datenkonsistenz gefährden, sind ausgeschlossen.
  
  
• Mengenorientierte Datenverarbeitung: Das relationale Datenbanksystem beruht auf einer mengenorientierten Datenverarbeitung, bei der jede Entität in atomare Werte zerlegt wird. Dies ermöglicht eine Verknüpfung verschiedener Entitäten über den Inhalt sowie komplexe Datenbankabfragen wie JOINs.
  
  
• Einheitliche Abfragesprache: Für Abfragen relationaler Datenbanken hat sich die durch ein Gremium von ISO und IEC standardisierte Datenbanksprache SQL etabliert. Zweck dieser Standardisierung ist, dass sich Anwendungen weitgehend unabhängig vom darunterliegenden Datenbank-Managementsystem entwickeln und ausführen lassen. Nach wie vor fällt der Support von SQL je nach DBMS jedoch sehr unterschiedlich aus.

Je nachdem, in welchem Szenario relationale Datenbanksysteme zum Einsatz kommen, lassen sich Vorteile wie das einfache auf Tabellen basierende Datenmodell sowie die Aufteilung von Daten auf mehrere miteinander verknüpfte Tabellen auch als Nachteil interpretieren. Zudem sind zentrale Merkmale des relationalen Datenmodells mit modernen Anforderungen an die Anwendungsprogrammierung (wie Objektorientierung, Multimedia und Big-Data) nur schwer vereinbar.

• Tabellarische Abbildung von Daten: Nicht alle Datentypen lassen sich in ein starres Schema miteinander verknüpfter zweidimensionaler Tabellen pressen (Impedance Mismatch). Abstrakte Datentypen und unstrukturierte Daten, die im Zusammenhang mit Multimedia-Anwendungen und Big-Data-Lösungen auftreten, lassen sich im relationalen Datenbankmodell nicht abbilden.
   
• Kein hierarchisches Datenbankschema: Relationale Datenbanken bieten – anders als Objektdatenbanken – keine Möglichkeit, Datenbankschemata mit hierarchisch strukturierten Klassen zu realisieren. Konzepte wie untergeordnete Entitäten, die Eigenschaften von übergeordneten Entitäten erben, lassen sich mit ihnen nicht umsetzen. So kann man mit ihnen beispielsweise keine Sub-Tupel anlegen. Alle Tupel einer relationalen Datenbank befindet sich auf derselben Hierarchie-Ebene.
   
• Segmentierung von Daten: Das Grundprinzip relationaler Datenbanksysteme, Informationen auf separate Tabellen aufzuteilen (Normalisierung), führt unweigerlich zu einer Segmentierung der Daten. Zusammengehöriges wird nicht zwangsläufig auch zusammen gespeichert. Dieses Datenbankdesign führt auf der Anwendungsebene zu komplexen Abfragen über mehrere Tabellen. Die daraus resultierende höhere Anzahl abgefragter Segmente wirkt sich meist auch negativ auf die Performance aus.
   
• Schlechtere Performance in Vergleich zu NoSQL-Datenbanken: Das relationale Datenbankmodell stellt hohe Anforderungen an die Datenkonsistenz, die bei Transaktionen zulasten der Schreibgeschwindigkeit gehen. Hier können beispielsweise Graphdatenbanken punkten.

Das relationale Datenbankmodell ist übersichtlich, mathematisch fundiert und hat sich seit mehr als 40 Jahren im Praxiseinsatz bewährt. Und dennoch ist die Datenhaltung in strukturierten Tabellen nicht allen Anforderungen der modernen Informationstechnologie gewachsen.

Vor allem die Verwaltungen großer Datenmengen im Rahmen von Big-Data-Analysen und die Speicherung abstrakter Datentypen bringen klassische relationale Systeme an ihre Grenzen. Hier punkten spezialisierte Systeme wie Objektdatenbanken oder Konzepte, die im Rahmen der NoSQL-Bewegung entwickelt wurden. Gänzlich abschreiben kann man das relationale Datenbankmodell jedoch nicht. Gerade in Unternehmensbereichen, in denen die Verarbeitung von Transaktionsdaten im Vordergrund steht, bringen relationale Datenbanken zahlreiche Vorteile.

Daten zu Kundenaktionen oder Marketingmaßnahmen lassen sich in tabellarischen Systemen ideal abbilden. Zudem profitieren Anwender von einer Syntax, die trotz ihrer Einfachheit komplexe Abfragen ermöglicht.