imported>SchlurcherBot: Bot: http → https

2025-12-13T11:33:42Z

Bot: http → https

Neue Seite

Eine '''relationale Datenbank''' ist eine digitale [[Datenbank]], die zur elektronischen [[Datenverarbeitung|Datenverwaltung]] in [[Computer]]systemen dient und auf einem [[Datenbanktabelle|tabellenbasierten]] [[Relation (Mathematik)|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 [[Wohldefiniertheit|wohldefinierter]] Begriff; siehe [[Relation (Datenbank)|Datenbankrelation]]. Operationen auf diesen Relationen werden durch die [[relationale Algebra]] bestimmt.

Das zugehörige [[Datenbank]]managementsystem wird als '''relationales Datenbankmanagementsystem''' oder '''RDBMS''' (Relational Database Management System) bezeichnet. Zum Abfragen und Manipulieren der Daten wird überwiegend 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 für [[Datenbank]]en.

== Grundlegende Konzepte ==
[[Datei:Begriffe relationaler Datenbanken.svg|mini|Begriffe relationaler Datenbanken]]

Eine relationale Datenbank kann man sich als eine Sammlung von [[Datenbanktabelle|Tabellen]] (den Relationen) vorstellen, in welchen Datensätze abgespeichert sind. Jede Zeile ([[Tupel (Informatik)|Tupel]]) in einer Tabelle ist ein [[Datensatz]] (''record''). Jedes Tupel besteht aus einer Reihe von Attributwerten ([[Attribut (Datenbank)|Attribute]] = Eigenschaften), den Spalten der Tabelle. Das [[Relationenschema]] legt dabei die Anzahl und den Typ der Attribute für eine Relation fest. Das Bild illustriert die Relation ''R'' mit Attributen ''A<sub>1</sub>'' bis ''A<sub>n</sub>'' 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 über einen oder mehrere [[Schlüssel (Datenbank)|Schlüssel]] ({{enS|key}}). In diesem Fall enthält ''Buch-ID'' die Schlüssel. Ein Schlüssel darf sich niemals ändern. Er bezieht sich auf den Datensatz und nicht auf die Position in der Tabelle.

{| class="wikitable"
|+ Beispiel einer Relation „Buch“:
! Buch-ID|| Autor || Verlag || Verlagsjahr || Titel || Datum
|-
| 100 || Hans Vielschreiber || Musterverlag || 2007 || Wir lernen SQL || 13.01.2007
|-
| 200 || J. Gutenberg || Gutenberg und Co. || 1452 || Drucken leicht gemacht || 01.01.1452
|-
| 300 || G. I. Caesar || Handschriftverlag || −44 || Mein Leben mit Asterix || 16.03.−44
|-
| 400 || Galileo Galilei || Inquisition International || 1640 || Eppur si muove || 1641
|-
| 500 || Charles Darwin || Vatikan-Verlag || 1860 || Adam und Eva || 1862
|}

== Beziehungen zwischen Tabellen ==
Weiterhin können Verknüpfungen genutzt werden, um die Beziehungen zwischen Tabellen auszudrücken. Eine Bibliothekdatenbank könnte damit etwa folgendermaßen mit drei Tabellen implementiert werden:

Tabelle ''Buch'', die für jedes Buch eine Zeile enthält:
* Jede Zeile besteht aus den Spalten der Tabelle (Attributen): ''Buch-ID, Autor, Verlag, Verlagsjahr, Titel, Datum der Aufnahme''.
* Als Schlüssel dient die ''Buch-ID'', da sie jedes Buch eindeutig identifiziert.

Tabelle ''Nutzer'', die die Daten von allen registrierten Bibliotheksnutzern enthält:
* Die Attribute wären zum Beispiel: Nutzer-ID, Vorname, Nachname.

{| class="wikitable float-left" style="float:left; margin-right:3em;"
|+ Relation „Nutzer“
! Nutzer-ID|| Vorname || Nachname
|-
| 10 || Hans || Vielleser
|-
| 11 || Jens || Mittelleser
|-
| 12 || Erich || Wenigleser
|}
{| class="wikitable" style="float:left;" >
|+ Relation „Entliehen“
! Nutzer-ID|| Buch-ID
|-
| 10 || 300
|-
| 10 || 200
|-
| 10 || 500
|-
| 11 || 100
|-
| 12 || 400
|}
<div style="clear:both"></div>

Außerdem braucht man eine dritte Tabelle ''Entliehen'', die Informationen über die Verfügbarkeit des Buches enthält. Sie würde die Attribute ''Nutzer-ID'' und ''Buch-ID'' enthalten. Jede Zeile dieser Tabelle ''Entliehen'' ordnet einer Nutzer-ID eine Buch-ID zu.

Der Eintrag ''(10,300)'' würde also heißen, dass der Nutzer mit der ID ''10'' („Hans Vielleser“) das Buch mit der ID ''300'' („Mein Leben mit Asterix“) entliehen hat. Derselbe Nutzer hat auch das Buch „Drucken leicht gemacht“ entliehen, was durch den Tabelleneintrag ''(10,200)'' dargestellt ist. Als Schlüssel 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 [[Fremdschlüssel]] (englisch {{lang|en|''foreign key''}}).
Tabellen ohne Fremdschlüssel nennt man [[flache Tabelle]]n.

Der hier benutzte Begriff ''Relation'' beschreibt die Beziehung der Attribute zum Relationennamen. So gilt im obigen Beispiel: Hans ist ein Attribut der Relation
„Nutzer“. Somit wird ''Relation'' bei relationalen Datenbanken allgemein als Synonym für ''Tabelle'' genutzt. Im Gegensatz dazu beschreibt die Relation bei einem [[Entity-Relationship-Modell]] die Beziehung zwischen Entitäten.

== Abgrenzung ==
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 für bestimmte Applikationen eine einfachere Anbindung der zu verwaltenden Daten. In den letzten Jahren haben sich vermehrt sogenannte [[NoSQL]] Datenbanken durchgesetzt.

=== Ältere Ansätze ===
In den 1960er und 1970er Jahren wurden zur betrieblichen Datenverarbeitung [[hierarchische Datenbank]]systeme sowie [[Netzwerkdatenbankmodell|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 Spezialfällen auch heute noch zum Einsatz.

=== Objektorientierte Datenbanken ===
Mit dem Aufkommen [[Objektorientierte Programmierung|objektorientierter Programmiersprachen]] wurden zunehmend [[Objektdatenbank]]en angeboten. Damit können Objekte aus [[Objektorientierte Programmiersprache|OO-Sprachen]] wie [[Java (Programmiersprache)|Java]] direkt in der Datenbank gehalten werden – eine Abbildung der Objekte auf die relationale Tabellenstruktur, das [[Objektrelationale Abbildung|objektrelationale Mapping]], ist dann nicht mehr notwendig. Dieses Vorgehen hat Vorteile gegenüber dem relationalen Entwurf, wenn man komplexe Datenobjekte speichern möchte, die nur schwer auf die flachen relationalen Tabellenstrukturen abgebildet werden können. Objektdatenbanken haben jedoch noch immer Nachteile gegenüber relationalen Datenbanken bei der Verarbeitung großer Datenmengen. Dies ist beispielsweise durch Zugriffspfade zu Objekten über mehrere Pfadarten (bspw. Vererbung und Assoziation) verursacht. Dies führt bei Schreiboperationen in der Sperrverwaltung zu einer exponentiellen Komplexität und somit zu schlechter Leistung. Die Leistungsprobleme wurden in den objektrelationalen Datenbanken aufgegriffen, in denen nur die Konstrukte aus objektorientierten Datenbanken mit niedrigerer Komplexität (bspw. <math>O(n \cdot \log(n))</math>) übernommen wurden.

=== Objektrelationale Datenbanken ===
Einige Anbieter fügen ihren relationalen Datenbanken objektorientierte Eigenschaften hinzu und nennen diese dann [[objektrelationale Datenbank]]en. Diese sind jedoch nicht zur direkten Abbildung von Objekten der Programmiersprache vorgesehen – sie benutzen lediglich das Konzept der [[Vererbung (Programmierung)|Vererbung]] bei Definition und Abfrage von Tabellen mit ähnlichen Feldstrukturen und vereinfachen damit deren Handhabung. Der SQL-99-Standard wurde um objektrelationale Sprachelemente erweitert.

=== Semistrukturierte Datenbanken ===
Neuere Konzepte sind die [[Semistrukturierte Daten|semistrukturierten Datenbanken]]. Sie unterscheiden sich von den herkömmlichen Datenbankmodellen darin, dass sie kein fest vorgegebenes Schema haben. Die Datenbank wird hierarchisch, baumartig aufgebaut und jede Datenbankeinheit ({{enS|entity}}) des gleichen Typs kann verschiedene Mengen von ''Attributen'' haben.

Typische Vertreter dieses Typs sind [[XML-Datenbank]]en, welche die Daten als XML-Fragmente verwalten. Die XML-Daten sind hierbei hierarchisch geordnet und können beliebige Strukturen enthalten, solange diese nach XML-Definition wohlgeformt sind. Die Daten können über [[XQuery]] oder [[XPath]] abgefragt werden. Zur Manipulation werden heute proprietäre Spracherweiterungen verwendet. Der Nachteil von aktuellen XML-Datenbanken ist die im Vergleich zu relationalen Systemen geringere Performance.

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

== Theorie der relationalen Datenbanken ==
Die Grundlagen der Theorie der relationalen Datenbank wurden von Edgar F. Codd in den 1960ern und 1970ern gelegt und in seiner Arbeit {{lang|en|''A Relational Model of Data for Large Shared Data Banks''}}<ref name="Codd1970">{{Literatur |Autor=[[Edgar F. Codd]] |Titel={{lang|en|A Relational Model of Data for Large Shared Data Banks}} |Sammelwerk={{lang|en|Communications of the ACM}} |Verlag=ACM Press |Ort=New York |Datum=1970-06-13 |ISSN=0001-0782 |Seiten=377–387 |Sprache=en |Online=http://www.acm.org/classics/nov95/}}</ref> beschrieben. Theoretisch basieren alle Operationen auf der relationalen Algebra.

=== Grundlegendes zur relationalen Algebra ===
Die [[relationale Algebra]] ist ein [[Algebra|algebraisches Modell]], das beschreibt, wie Daten gespeichert, abgefragt und manipuliert werden können. Die wesentlichen Operationen, aus denen alle weiteren abgeleitet werden können, sind die folgenden:

* [[Relationale Algebra#Projektion|Projektion]] (englisch {{lang|en|''projection''}})
* [[Selektion (Informatik)|Selektion]] (englisch {{lang|en|''selection''}})
* [[Relationale Algebra#Kartesisches Produkt (Kreuzprodukt)|Kreuzprodukt]] oder [[Relationale Algebra#Kartesisches Produkt (Kreuzprodukt)|Kartesisches Produkt]] (englisch {{lang|en|''cross product''}}, {{lang|en|''cross join''}} oder {{lang|en|''cartesian product''}})
* [[Relationale Algebra#Umbenennung|Umbenennung]] (englisch {{lang|en|''rename''}})
* [[Relationale Algebra#Vereinigung|Vereinigung]] (englisch {{lang|en|''union''}})
* [[Relationale Algebra#Differenz|Differenz]] (englisch {{lang|en|''set difference''}} oder {{lang|en|''minus''}})

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

=== Beschränkungen der relationalen Algebra ===
Die relationale Algebra bietet keine Unterstützung zur Berechnung von [[Rekursion|rekursiven]] Anfragen ([[Transitive Hülle (Relation)|transitive Hülle]]). Das heißt beispielsweise, dass es nicht möglich ist, in einer Anfrage alle Vorfahren einer Person zu berechnen, wenn diese in einer Relation ''Person'' gespeichert sind und über eine Relation ''VorfahreVon'' mit dem jeweiligen Vorfahren in ''Person'' verbunden ist. Die Vorfahren können nur durch eine Folge von Anfragen ermittelt werden.

Mit der Einführung von SQL-99 wurde jedoch auch eine erweiterte relationale Algebra eingeführt, die eine Operation zur Berechnung der transitiven Hülle erlaubt.

== Datenbankschema und Modellierung ==
[[Datei:Er-diagramm.svg|mini|Ein ER-Diagramm in [[Chen-Notation]]]]

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 [[Datenbankmanagementsystem]]s (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 (Datenbank)|Normalisierung]]. Diese soll [[Redundanz (Informationstheorie)|Redundanzen]] verringern und [[Anomalie (Informatik)|Anomalien]] verhindern, um so die [[Wartung]] einer Datenbank zu vereinfachen, sowie die [[Konsistenz (Datenspeicherung)|Konsistenz]] der Daten zu gewährleisten. Edgar F. Codd hat dazu vier Normalformen vorgeschlagen, die seitdem bei dem relationalen Datenbankentwurf zum Einsatz kommen und um weitere ergänzt wurden.

== Kritik am relationalen Datenbankmodell ==
; 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, müssen komplexe Anwendungsobjekte bei einer Abfrage durch das DBMS mittels zahlreicher [[Relationale Algebra#Join|Joins]] aus den einzelnen Relationen wiederhergestellt werden. Dies kann zu unübersichtlichen Abfragen führen, die bei jeder strukturellen Änderung des Anwendungsobjekts auf Anpassungsbedarf hin überprüft werden müssen. Die Verwendung von Joins, welche durch jeweils gut passende [[Datenbankindex|Datenbank-Indizes]] unterstützt werden müssen, macht den Objektzugriff aufwendiger als z. B. bei einer [[Objektdatenbank]], sowohl beim Ressourcenbedarf als auch beim Entwicklungsaufwand.
; Künstliche Schlüsselattribute
: Zur eindeutigen Identifizierung von [[Tupel]]n müssen in manchen Fällen [[Surrogatschlüssel|künstliche Schlüssel]] eingesetzt werden. Dies dient z. B. dazu, die Größe des Schlüssels zu reduzieren, wenn er als Fremdschlüssel eingesetzt werden soll, oder dazu, gehört-zu-Beziehungen zu implementieren. Es werden also Attribute in die Relation aufgenommen, die mit der abstrakten Beschreibung eines Anwendungsobjekts nichts zu tun haben, sondern „nur“ Verwaltungsinformationen sind.
; Externe Programmierschnittstelle
: Da in vielen relationalen Datenbanken nur Datenmanipulationssprachen eingeschränkter Mächtigkeit vorhanden sind, werden meist Schnittstellen zu mächtigeren Programmiersprachen notwendig. Diese Verbindung führt ggf. zu einer ungünstigen 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 mächtigen Programmiersprachen, etwa [[PL/SQL]] in [[Oracle (Datenbanksystem)|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 ermöglicht z. B. die Verwendung von Java-Programmen oder C++-Programmen innerhalb von PL/SQL-Programmen. PL/pgSQL ermöglicht wiederum die Server-Programmierung mit anderen Sprachen wie [[PHP]], [[Tcl]] oder [[Python (Programmiersprache)|Python]].
; Objekteigenschaften und -verhalten häufig 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 führen.
Mit dem Sammelbegriff [[NoSQL]] werden '''nicht-relationale Datenbankmodelle''' bezeichnet, die Probleme wie die genannten durch alternative Herangehensweisen zu lösen beabsichtigen.

== Gegenüberstellung von Grundbegriffen ==
{| class="wikitable" style="text-align:center"
|-
! Relationale Datenbank !! Relationen-Modell !! [[Entity-Relationship-Modell]] (ERM) !! [[Unified Modeling Language]] (UML)
|-
|colspan="4"| Wertebereich (Domäne, Domain)
|-
| Kopfzeile || Relationstyp/Relationsformat || Entitätstyp || Klasse, Objekttyp
|-
| Spalte || [[Attribut (Programmierung)|Attribut]]||[[Attribut (Programmierung)|Attribut]]|| [[Attribut (UML)|Attribut]]
|-
|Tabelle || [[Relation (Datenbank)|Relation]] || Entitätsmenge(-set) || Objektmenge, Instanzmenge, Klasse
|-
| Spaltenüberschrift(en) || [[Schlüssel (Datenbank)#Fremdschlüssel|Fremdschlüssel]] || funktionale Beziehung (Relationship) || Assoziation
|-
| Zeile || [[Tupel (Informatik)|Tupel]] || [[Entität (Informatik)|Entität]] || [[Objekt (Programmierung)|Objekt]], Instanz
|-
| Zelle ||colspan="3"| Attributwert
|}

== Siehe auch ==
* [[Relationale Entwurfstheorie]]
* [[Datenbank-Muster]]
* [[Datenbankoperator]]
* [[Deduktive Datenbank]]
* [[Liste der Datenbankmanagementsysteme]]
* [[Referentielle Integrität]]
* [[Online Analytical Processing#12 Regeln nach Codd|Codd’sche Regeln]]

== Literatur ==
* Edgar F. Codd: ''The Relational Model for Database Management. Version 2.'' Addison-Wesley, Reading u. a. 1990, ISBN 0-201-14192-2.
* [[Alfons Kemper]], André Eickler: ''Datenbanksysteme. Eine Einführung.'' R. Oldenbourg Verlag, München 2004, ISBN 3-486-27392-2.
* Andreas Meier: ''Relationale und postrelationale Datenbanken''. 7. Auflage. Springer-Verlag, Heidelberg 2010, ISBN 978-3-642-05255-2 ([https://www.springer.com/computer/database+management+%26+information+retrieval/book/978-3-642-05255-2 online]).

== Weblinks ==
* [http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap6.htm Kriterien für relationale Datenbanksysteme] mit ausführlicher Beschreibung der 12 Regeln
* [http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/RDBMS ''RDBMS''.] In: ''Datenbanken Online Lexikon'', FH Köln
* [https://www.datenbanken-verstehen.de/ Datenbanken-verstehen] – Umfangreiches Portal

== Einzelnachweise ==
<references />

[[Kategorie:Relationales Datenbankmanagementsystem| ]]

Relationale Datenbank - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https