Eine relationale Datenbank ist eine digitale Datenbank , die zur elektronischen Datenverwaltung in Computersystemen dient und auf einem tabellenbasierten relationalen Datenbankmodell beruht. Grundlage des Konzeptes relationaler Datenbanken ist die Relation. Sie stellt eine mathematische Beschreibung einer Tabelle dar und ist ein im mathematischen Sinn wohldefinierter Begriff; siehe Datenbankrelation . Operationen auf diesen Relationen werden durch die relationale Algebra bestimmt.

Das zugehorige Datenbankmanagementsystem wird als relationales Datenbankmanagementsystem oder RDBMS (Relational Database Management System) bezeichnet. Zum Abfragen und Manipulieren der Daten wird uberwiegend die Datenbanksprache SQL (Structured Query Language) eingesetzt, deren theoretische Grundlage die relationale Algebra ist.

Das relationale Datenbankmodell wurde 1970 von Edgar F. Codd erstmals vorgeschlagen und ist bis heute trotz einiger Kritikpunkte ein etablierter Standard fur Datenbanken .

Grundlegende Konzepte [ Bearbeiten | Quelltext bearbeiten ]

Eine relationale Datenbank kann man sich als eine Sammlung von Tabellen (den Relationen) vorstellen, in welchen Datensatze abgespeichert sind. Jede Zeile ( Tupel ) in einer Tabelle ist ein Datensatz ( record ). Jedes Tupel besteht aus einer Reihe von Attributwerten ( Attribute = Eigenschaften), den Spalten der Tabelle. Das Relationenschema legt dabei die Anzahl und den Typ der Attribute fur eine Relation fest. Das Bild illustriert die Relation  R mit Attributen A ₁ bis A _n in den Spalten.

Zum Beispiel wird ein Buch in einer Bibliothek durch den Datensatz (Buch-ID, Autor, Verlag, Verlagsjahr, Titel, Datum der Aufnahme) beschrieben. Ein Datensatz muss eindeutig identifizierbar sein. Das geschieht uber einen oder mehrere Schlussel ( englisch key ). In diesem Fall enthalt Buch-ID die Schlussel. Ein Schlussel darf sich niemals andern. Er bezieht sich auf den Datensatz und nicht auf die Position in der Tabelle.

Beispiel einer Relation ?Buch“:

Buch-ID	Autor	Verlag	Verlagsjahr	Titel	Datum
1	Hans Vielschreiber	Musterverlag	2007	Wir lernen SQL	13.01.2007
2	J. Gutenberg	Gutenberg und Co.	1452	Drucken leicht gemacht	01.01.1452
3	G. I. Caesar	Handschriftverlag	?44	Mein Leben mit Asterix	16.03.?44
5	Galileo Galilei	Inquisition International	1640	Eppur si muove	1641
6	Charles Darwin	Vatikan-Verlag	1860	Adam und Eva	1862

Beziehungen zwischen Tabellen [ Bearbeiten | Quelltext bearbeiten ]

Weiterhin konnen Verknupfungen genutzt werden, um die Beziehungen zwischen Tabellen auszudrucken. Eine Bibliothekdatenbank konnte damit etwa folgendermaßen mit drei Tabellen implementiert werden:

Tabelle Buch , die fur jedes Buch eine Zeile enthalt:

• Jede Zeile besteht aus den Spalten der Tabelle (Attributen): Buch-ID, Autor, Verlag, Verlagsjahr, Titel, Datum der Aufnahme .
• Als Schlussel dient die Buch-ID , da sie jedes Buch eindeutig identifiziert.

Tabelle Nutzer , die die Daten von allen registrierten Bibliotheksnutzern enthalt:

• Die Attribute waren zum Beispiel: Nutzer-ID, Vorname, Nachname.

Relation ?Nutzer“

Nutzer-ID	Vorname	Nachname
10	Hans	Vielleser
11	Jens	Mittelleser
12	Erich	Wenigleser

Relation ?Entliehen“

Nutzer-ID	Buch-ID
10	1
10	2
10	3
12	5
12	6

Außerdem braucht man eine dritte Tabelle Entliehen , die Informationen uber die Verfugbarkeit des Buches enthalt. Sie wurde die Attribute Nutzer-ID und Buch-ID enthalten. Jede Zeile dieser Tabelle Entliehen ordnet einer Nutzer-ID eine Buch-ID zu.

Der Eintrag (10,3) wurde also heißen, dass der Nutzer mit der ID 10 (?Hans Vielleser“) das Buch mit der ID 3 (?Mein Leben mit Asterix“) entliehen hat. Derselbe Nutzer hat auch das Buch ?Drucken leicht gemacht“ entliehen, was durch den Tabelleneintrag (10,2) belegt ist. Als Schlussel nimmt man hier die Attributmenge (Nutzer-ID, Buch-ID) . Gleichzeitig verbindet die Nutzer-ID jeden Eintrag der Tabelle Entliehen mit einem Eintrag der Tabelle Nutzer sowie die Buch-ID jeden Eintrag von Entliehen mit einem Eintrag der Tabelle Buch . Deswegen heißen diese Attribute in diesem Zusammenhang Fremdschlussel (englisch foreign key ). Tabellen ohne Fremdschlussel nennt man flache Tabellen .

Der hier benutzte Begriff Relation beschreibt nicht die Beziehung zwischen Entitaten (wie im Entity-Relationship-Modell ), sondern die Beziehung der Attribute zum Relationennamen. So gilt im obigen Beispiel: Hans ist Vorname (Attribut) von Nutzer (Relationenname) . Außerdem wird Relation bei relationalen Datenbanken allgemein als Synonym fur Tabelle genutzt (meist aus Entitatstyp im ERM entstehend).

Abgrenzung [ Bearbeiten | Quelltext bearbeiten ]

Neben dem relationalen Datenbankmodell gibt es verschiedene alternative Konzepte, die es erlauben, Daten in anderen Strukturen zu verwalten. Diese Konzepte haben oft nur noch eine geringe Bedeutung oder haben sich noch nicht durchgesetzt. Dennoch bieten sie fur bestimmte Applikationen eine einfachere Anbindung der zu verwaltenden Daten. In den letzten Jahren haben sich vermehrt sogenannte NoSQL durchgesetzt.

Altere Ansatze [ Bearbeiten | Quelltext bearbeiten ]

In den 1960er und 1970er Jahren wurden zur betrieblichen Datenverarbeitung hierarchische Datenbanksysteme sowie Netzwerk-Datenbanksysteme verwendet. Bei diesen wird die Daten- bzw. Tabellenstruktur in der Entwurfsphase definiert und kann nicht bei der Abfrage variiert werden. Sie kommen in Spezialfallen auch heute noch zum Einsatz.

Objektorientierte Datenbanken [ Bearbeiten | Quelltext bearbeiten ]

Mit dem Aufkommen objektorientierter Programmiersprachen wurden zunehmend Objektdatenbanken angeboten. Damit konnen Objekte aus OO-Sprachen wie Java direkt in der Datenbank gehalten werden ? eine Abbildung der Objekte auf die relationale Tabellenstruktur, das objektrelationale Mapping , ist dann nicht mehr notwendig. Dieses Vorgehen hat Vorteile gegenuber dem relationalen Entwurf, wenn man komplexe Datenobjekte speichern mochte, die nur schwer auf die flachen relationalen Tabellenstrukturen abgebildet werden konnen. Objektdatenbanken haben jedoch noch immer Nachteile gegenuber relationalen Datenbanken bei der Verarbeitung großer Datenmengen. Dies ist beispielsweise durch Zugriffspfade zu Objekten uber mehrere Pfadarten (bspw. Vererbung und Assoziation) verursacht. Dies fuhrt bei Schreiboperationen in der Sperrverwaltung zu einer exponentiellen Komplexitat und somit zu schlechter Leistung. Die Leistungsprobleme wurden in den objektrelationalen Datenbanken aufgegriffen, in denen nur die Konstrukte aus objektorientierten Datenbanken mit niedrigerer Komplexitat (bspw. ${\displaystyle O(n\cdot \log(n))}$) ubernommen wurden.

Objektrelationale Datenbanken [ Bearbeiten | Quelltext bearbeiten ]

Einige Anbieter fugen ihren relationalen Datenbanken objektorientierte Eigenschaften hinzu und nennen diese dann objektrelationale Datenbanken . Diese sind jedoch nicht zur direkten Abbildung von Objekten der Programmiersprache vorgesehen ? sie benutzen lediglich das Konzept der Vererbung bei Definition und Abfrage von Tabellen mit ahnlichen Feldstrukturen und vereinfachen damit deren Handhabung. Der SQL-99-Standard wurde um objektrelationale Sprachelemente erweitert.

Semistrukturierte Datenbanken [ Bearbeiten | Quelltext bearbeiten ]

Neuere Konzepte sind die semistrukturierten Datenbanken . Sie unterscheiden sich von den herkommlichen Datenbankmodellen darin, dass sie kein fest vorgegebenes Schema haben. Die Datenbank wird hierarchisch, baumartig aufgebaut und jede Datenbankeinheit ( englisch entity ) des gleichen Typs kann verschiedene Mengen von Attributen haben.

Typische Vertreter dieses Typs sind XML-Datenbanken , welche die Daten als XML-Fragmente verwalten. Die XML-Daten sind hierbei hierarchisch geordnet und konnen beliebige Strukturen enthalten, solange diese nach XML-Definition wohlgeformt sind. Die Daten konnen uber XQuery oder XPath abgefragt werden. Zur Manipulation werden heute proprietare Spracherweiterungen verwendet. Nachteil von aktuellen XML-Datenbanken ist die im Vergleich zu relationalen Systemen geringere Performance.

Semistrukturierte Datenbanken lassen sich uber Erweiterungen oder Server-Programmierung auch mit relationalen DB realisieren, wobei das Relationenmodell aber nicht mehr angewendet wird.

Theorie der relationalen Datenbanken [ Bearbeiten | Quelltext bearbeiten ]

Die Grundlagen der Theorie der relationalen Datenbank wurden von Edgar F. Codd in den 1960ern und 1970ern gelegt und in seiner Arbeit A Relational Model of Data for Large Shared Data Banks ^[1] beschrieben. Theoretisch basieren alle Operationen auf der relationalen Algebra.

Grundlegendes zur relationalen Algebra [ Bearbeiten | Quelltext bearbeiten ]

Die relationale Algebra ist ein algebraisches Modell , das beschreibt, wie Daten gespeichert, abgefragt und manipuliert werden konnen. Die wesentlichen Operationen, aus denen alle weiteren abgeleitet werden konnen, sind die folgenden:

• Projektion (englisch projection )
• Selektion (englisch selection )
• Kreuzprodukt oder Kartesisches Produkt (englisch cross product , cross join oder cartesian product )
• Umbenennung (englisch rename )
• Vereinigung (englisch union )
• Differenz (englisch set difference oder minus )

Alle Anfragen, die mittels SQL an eine relationale Datenbank gestellt werden, werden vom Datenbankmanagementsystem auf diese Operatoren abgebildet, das heißt ubersetzt. In der Praxis gibt es weitere Operatoren, wie zum Beispiel den Join-Operator , der jedoch ebenfalls nur eine Kombination aus Kreuzprodukt, Selektion und Projektion darstellt.

Beschrankungen der relationalen Algebra [ Bearbeiten | Quelltext bearbeiten ]

Die relationale Algebra bietet keine Unterstutzung zur Berechnung von rekursiven Anfragen ( transitive Hulle ). Das heißt beispielsweise, dass es nicht moglich ist, in einer Anfrage alle Vorfahren einer Person zu berechnen, wenn diese in einer Relation Person gespeichert sind und uber eine Relation VorfahreVon mit dem jeweiligen Vorfahren in Person verbunden ist. Die Vorfahren konnen nur durch eine Folge von Anfragen ermittelt werden.

Mit der Einfuhrung von SQL-99 wurde jedoch auch eine erweiterte relationale Algebra eingefuhrt, die eine Operation zur Berechnung der transitiven Hulle erlaubt.

Datenbankschema und Modellierung [ Bearbeiten | Quelltext bearbeiten ]

Wichtiger Bestandteil einer relationalen Datenbank ist ihr Schema . Das Schema legt fest, welche Daten in der Datenbank gespeichert werden und wie diese Daten in Beziehung zueinander stehen. Der Vorgang zum Erstellen eines Schemas nennt sich Datenmodellierung .

Zur Modellierung von relationalen Datenbanken wird auch das Entity-Relationship-Modell verwendet. Es dient zum Entwurf eines konzeptuellen Schemas, welches unter Verwendung eines Datenbankmanagementsystems (DBMS) implementiert werden kann. Dieser Schritt wird als logischer Entwurf oder auch Datenmodellabbildung bezeichnet und hat als Ergebnis ein Datenbankschema im Implementierungsdatenmodell des DBMS.

Ein wichtiger Schritt des Modellierungsprozesses ist die Normalisierung . Diese soll Redundanzen verringern und Anomalien verhindern, um so die Wartung einer Datenbank zu vereinfachen, sowie die Konsistenz der Daten zu gewahrleisten. Edgar F. Codd hat dazu vier Normalformen vorgeschlagen, die seitdem bei dem relationalen Datenbankentwurf zum Einsatz kommen und um weitere erganzt wurden.

Kritik am relationalen Datenbankmodell [ Bearbeiten | Quelltext bearbeiten ]

Segmentierung

In der relationalen Darstellung erfolgt die Abspeicherung eines Objektes segmentiert auf viele unterschiedliche Relationen. Die Anwendungsobjekte sind normalerweise komplex , bestehen also selbst wieder aus Objekten oder Listen von Objekten. Da das relationale Modell lediglich Tupelmengen kennt, die aus Werten bestehen, mussen komplexe Anwendungsobjekte bei einer Abfrage durch das DBMS mittels zahlreicher Joins aus den einzelnen Relationen wiederhergestellt werden. Dies kann zu unubersichtlichen Abfragen fuhren, die bei jeder strukturellen Anderung des Anwendungsobjekts auf Anpassungsbedarf hin uberpruft werden mussen. Die Verwendung von Joins, welche durch jeweils gut passende Datenbank-Indizes unterstutzt werden mussen, macht den Objektzugriff aufwendiger als z. B. bei einer Objektdatenbank , sowohl beim Ressourcenbedarf als auch beim Entwicklungsaufwand.

Kunstliche Schlusselattribute

Zur eindeutigen Identifizierung von Tupeln mussen in manchen Fallen kunstliche Schlussel eingesetzt werden. Dies dient z. B. dazu, die Große des Schlussels zu reduzieren, wenn er als Fremdschlussel eingesetzt werden soll, oder dazu, gehort-zu-Beziehungen zu implementieren. Es werden also Attribute in die Relation aufgenommen, die mit der abstrakten Beschreibung eines Anwendungsobjektes nichts zu tun haben, sondern ?nur“ Verwaltungsinformationen sind.

Externe Programmierschnittstelle

Da in vielen relationalen Datenbanken nur Datenmanipulationssprachen eingeschrankter Machtigkeit vorhanden sind, werden meist Schnittstellen zu machtigeren Programmiersprachen notwendig. Diese Verbindung fuhrt ggf. zu einer ungunstigen Handhabung, z. B. wenn das mengenorientierte SQL in dem satzorientierten C++ zu verarbeiten ist, siehe Object-relational impedance mismatch .

Es gibt jedoch auch relationale Datenbanken mit machtigen Programmiersprachen, etwa PL/SQL in Oracle oder PL/pgSQL in PostgreSQL oder T/SQL in Microsoft SQL Server ; bei beiden Datenbanksystemen erlauben die jeweiligen Datenmanipulationssprachen das Einbinden von anderen Programmiersprachen. PL/SQL ermoglicht z. B. die Verwendung von Java-Programmen oder C++-Programmen innerhalb von PL/SQL-Programmen. PL/pgSQL ermoglicht wiederum die Server-Programmierung mit anderen Sprachen wie PHP , Tcl oder Python .

Objekteigenschaften und -verhalten haufig nicht abbildbar

In der relationalen Datenbank kann das anwendungstypische Verhalten eines Objektes nicht beschrieben werden. Diese Beschreibung kann somit erst außerhalb der Datenbank in einer Anwendungssoftware erfolgen. Wenn mehrere Anwendungen den gleichen Datenbestand nutzen, kann das zu einer redundanten Implementierung fuhren.

Mit dem Sammelbegriff NoSQL werden nicht-relationale Datenbankmodelle bezeichnet, die Probleme wie die genannten durch alternative Herangehensweisen zu losen beabsichtigen.

Gegenuberstellung von Grundbegriffen [ Bearbeiten | Quelltext bearbeiten ]

Relationale Datenbank	Relationen-Modell	Entity-Relationship-Modell (ERM)	Unified Modeling Language (UML)
Wertebereich (Domane, Domain)
Kopfzeile	Relationstyp/Relationsformat	Entitatstyp	Klasse, Objekttyp
Spalte	Attribut	Attribut	Attribut
Tabelle	Relation	Entitatsmenge(-set)	Objektmenge, Instanzmenge, Klasse
Spaltenuberschrift(en)	Fremdschlussel	funktionale Beziehung (Relationship)	Assoziation
Zeile	Tupel	Entitat	Objekt , Instanz
Zelle	Attributwert

Siehe auch [ Bearbeiten | Quelltext bearbeiten ]

• Relationale Entwurfstheorie
• Datenbank-Muster
• Datenbankoperator
• Deduktive Datenbank
• Liste der Datenbankmanagementsysteme
• Referentielle Integritat
• Codd’sche Regeln

Literatur [ Bearbeiten | Quelltext bearbeiten ]

• Edgar F. Codd: The Relational Model for Database Management. Version 2. Addison-Wesley, Reading u. a. 1990, ISBN 0-201-14192-2 .
• Alfons Kemper , Andre Eickler: Datenbanksysteme. Eine Einfuhrung. R. Oldenbourg Verlag, Munchen 2004, ISBN 3-486-27392-2 .
• Andreas Meier: Relationale und postrelationale Datenbanken . 7. Auflage. Springer-Verlag, Heidelberg 2010, ISBN 978-3-642-05255-2 ( online ).

Weblinks [ Bearbeiten | Quelltext bearbeiten ]

• Kriterien fur relationale Datenbanksysteme mit ausfuhrlicher Beschreibung der 12 Regeln
• RDBMS . In: Datenbanken Online Lexikon , FH Koln
• Datenbanken-verstehen ? Umfangreiches Portal

Einzelnachweise [ Bearbeiten | Quelltext bearbeiten ]

1. ↑ Edgar F. Codd : A Relational Model of Data for Large Shared Data Banks . In: Communications of the ACM . ACM Press, 13. Juni 1970, ISSN   0001-0782 , S.   377?387 (englisch, acm.org ).