Relationale Datenbank
Eine relationale Datenbank ist eine Datenbank, die auf dem relationalen Datenbankmodell basiert. Das Datenbankmodell wurde von Edgar F. Codd 1970 erstmals vorgeschlagen und ist heute, trotz einiger Kritikpunkte, ein etablierter Standard zum Speichern von Daten. Das zugehörige Datenbankmanagementsystem wird als das relationale Datenbankmanagementsystem (RDBMS) bezeichnet. Bekannt im Zusammenhang mit relationalen Datenbanken ist die Datenbanksprache SQL, zum Abfragen und Manipulieren der Daten in der Datenbank.
Grundlage des Konzeptes relationaler Datenbanken ist die Relation, ein im mathematischen Sinn wohldefinierter Begriff. Dabei handelt es sich im Wesentlichen um eine mathematische Beschreibung für eine Tabelle (siehe dazu Datenbank Relation). Operationen auf diesen Relationen werden durch die Relationale Algebra bestimmt, diese Operationen finden im Sprachumfang von SQL Berücksichtigung.
Trotz der mathematischen, abstrakten Definition des Datenbankmodells, sind Relationale Datenbanken vergleichsweise einfach und flexibel zu handhaben. Dies hatte großen Einfluss auf den Erfolg dieser Datenbanktechnik.
Inhaltsverzeichnis |
Grundlegende Konzepte
Im Allgemeinen kann man sich eine relationale Datenbank als eine Kollektion von Tabellen (den Relationen) vorstellen, in welchen Datensätze abgespeichert sind. Jeder Datensatz ist somit eine Zeile (Tupel) in einer Tabelle. Jeder Tupel besteht aus einer Menge von Attributwerten (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 A1 bis An in den Spalten und den in Zeilen angeordneten Werte.
Zum Beispiel beschreibt der Datensatz (Buchnummer, Autor, Verlag, Verlagsjahr, Titel, Datum der Aufnahme) ein Buch in der Bibliothek. Die Datensätze müssen eindeutig identifizierbar sein. Das geschieht über einen oder mehrere Schlüssel (engl. Key). Schlüssel sind Attributmengen, die einen Tupel in der Tabelle eindeutig identifizieren. In diesem Fall ist Buchnummer ein Schlüssel.
|
Beispiel
Eine Bibliothekdatenbank könnte also folgendermaßen implementiert werden.
Tabelle Bücher, die für jedes Buch eine Zeile enthält:
- Jede Zeile besteht aus Attributen (Spalten der Tabelle): Buchnummer, Autor, Verlag, Verlagsjahr, Titel, Datum der Aufnahme.
- Als Schlüssel dient die Buchnummer, da sie jedes Tupel eindeutig identifiziert.
Tabelle Nutzer, die die Daten von allen registrierten Bibliotheksnutzern enthält:
- Die Attribute wären zum Beispiel: Nutzernummer, Vorname, Nachname.
|
|
Außerdem braucht man eine Tabelle Entliehen, die Informationen über die Verfügbarkeit des Buches enthält. Sie würde folgende Attribute erhalten:
- Nutzernummer
- Buchnummer
Jede Zeile dieser Tabelle ordnet einem Nutzer ein von ihm entliehenes Buch zu.
Der Eintrag (3546,123458) würde also heißen, dass der Nutzer mit der Nummer 3546 ("Hans Vielleser") das Buch mit der Nummer 123458 ("Mein Leben mit Asterix") entliehen hat. Derselbe Nutzer hat auch das Buch "Eppur si muove" entliehen, was durch den Tabelleneintrag (3546, 123459) belegt ist. Als Schlüssel nimmt man hier die Attributmenge (Nutzernummer, Buchnummer). Gleichzeitig verbindet die Nutzernummer jeden Eintrag der Tabelle Entliehen mit einem Eintrag der Tabelle Nutzer, sowie die Buchnummer jeden Eintrag von Entliehen mit einem Eintrag der Tabelle Bücher verbindet. Deswegen heißen diese Attribute in diesem Zusammenhang Fremdschlüssel (engl. Foreign Key).
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.
Ältere Ansätze
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 Spezialfällen auch heute noch zum Einsatz.
Objektorientierte Datenbanken
Mit dem Aufkommen objektorientierter Programmiersprachen wurden zunehmend objektorientierte Datenbanken angeboten. Damit können Objekte aus OO-Sprachen wie Java direkt in der Datenbank gehalten werden - eine Abbildung der Objekte auf die relationale Tabellenstruktur, das objekt-relationale 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.
Objektrelationale Datenbanken
Einige Anbieter fügen ihren relationalen Datenbanken objektorientierte Eigenschaften hinzu und nennen diese dann Objektrelationale Datenbanken. Diese sind jedoch nicht zur direkten Abbildung von Objekten der Programmiersprache vorgesehen. Jedoch wurde der SQL-99-Standard um objektrelationale Sprachelemente erweitert, die es erlauben, Objekte aus der Datenbank bequemer zu lesen oder zu speichern.
Semistrukturierte Datenbanken
Neuere Konzepte sind die semistrukturierten Datenbanken. Sie unterscheiden sich von den herkömmlichen Datenbankmodellen insofern, dass sie kein fest vorgegebenes Schema haben müssen.
Die Datenbank wird hierarchisch, baumartig aufgebaut und jede Datenbankeinheit (engl. Entity) des gleichen Typs kann verschiedene Mengen von Attributen (siehe Attribut) haben. Typische Vertreter von semistrukturierten Datenbanken sind XML-Datenbanken. Die Daten hier werden als XML-Fragmente verwaltet. 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 der Daten werden heute proprietäre Spracherweiterungen verwendet. Nachteil von aktuellen XML-Datenbanken ist jedoch die im Vergleich zu relationalen Systemen sehr schwache Performance.
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 A Relational Model of Data for Large Shared Data Banks [1] beschrieben. Theoretisch basieren alle Operationen auf der relationalen Algebra.
Relationale Algebra
Die Relationale Algebra ist ein 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:
- Projektion (engl. projection)
- Selektion (engl. selection)
- Kreuzprodukt oder Kartesisches Produkt (engl. cross product, cross join oder cartesian product)
- Umbenennung (engl. rename)
- Vereinigung (engl. union)
- Differenz (engl. 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 übersetzt. 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.
Beschränkungen der Relationalen Algebra
Die Relationale Algebra bietet keine Unterstützung zur Berechnung von rekursiven Anfragen (Transitive Hülle). Das heißt bespielsweise, daß 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
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 Modellierung.
Zur Modellierung von relationalen Datenbanken wird auch das Entity-Relationship-Modell oder Varianten davon 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. Der Sinn der Normalisierung besteht darin, Redundanzen zu verringern und Anomalien zu verhindern, um so die Wartung einer Datenbank zu vereinfachen, sowie die 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.
Eigenschaften eines RDBMS
Die wesentlichen Eigenschaften eines relationalen Datenbankmanagementsystems lassen sich wie folgt beschreiben:
- Speichern der Daten
- Verwaltung der Metadaten
- Datensicherheit
- Mehrbenutzerbetrieb durch Transaktionen
- Sicherstellen der Datenintegrität
- Anfrageoptimierung
- Bereitstellen von Indizes
- Bereitstellung von Triggern
- Stored Procedures
Datensicherheit
Das RDBMS speichert die relationalen Daten auf einem Speichermedium. Neben den eigentlichen Daten werden ebenfalls Informationen über die Datenschemata und Zugriffsrechte von Benutzern gespeichert. Letztere sind wichtig, um die Datensicherheit zu garantieren. Dazu gehört sowohl Schutz gegen Datenverlust sowie Schutz gegen unerlaubten Zugriff. Die Metadaten eines DBMS werden auch als das Data Dictionary oder Katalog des Systems bezeichnet.
Ein weiterer wichtiger Aspekt von Datenbanken ist das Sichern des Datenbestandes durch Backups. In der Praxis ist dies oft ein nicht zu vernachlässigendes Performance-Problem, da während eines Backups Daten nur sehr eingeschränkt modifiziert werden dürfen.
Transaktionen
Ein weiterer wichtiger Teil der Datensicherheit sind das Transaktionskonzept, das Daten gegen Race Conditions durch den parallelen Zugriff mehrerer Benutzer schützt. Andernfalls könnten Daten von verschiedenen Benutzern gleichzeitig geändert werden. Das Ergebnis der Änderungen würde dann vom Zufall abhängen. Vereinfacht dargestellt sperren Transaktionen Daten vorübergehend für den Zugriff durch andere Benutzer, bis eine Transaktion durch einen Commit beendet wird. Danach werden die geänderten Daten wieder freigegeben.
Datenintegrität
Die Integrität der Daten kann durch Constraints sichergestellt werden. Dies sind Regeln im Managementsystem, die beschreiben, wie Daten verändert werden dürfen. Der wichtigste Vertreter bei relationalen Datenbanksystemen ist der Foreign Key Constraint. Dieser verhindert, daß Daten gelöscht werden können, die noch von einer anderen Tabelle benötigt werden. Das heißt Daten die über einen Foreign Key referenziert werden.
Anfrageoptimierung
Damit Daten abgefragt und manipuliert werden können stellt das DBMS eine Datenbanksprache zur Verfügung. Eine Anfrage an das Datenbanksystem wird dabei zunächst in die logischen Operationen der relationalen Algebra übersetzt. Danach werden sogenannte Datenbankoperatoren ausgewählt, die die logische Operation tatsächlich auf den Daten ausführt. Die Wahl der Operatoren und die Reihenfolge ihrer Ausführung nennt man das erstellen eines Ausführungsplans durch den Anfrageoptimierer. Der Optimierer ist ein besonders komplexer Teil der Datenbanksoftware und hat wesentlichen Einfluss auf die Effizienz des Gesamtsystems.
Bei der Anfrageoptimierung spielen Indizes eine wichtige Rolle. Sie dienen dazu, schnell einen bestimmten Datensatz zu finden. Welche Daten einen Index erhalten wird mit dem Datenbankschema festgelegt, kann aber später von einem Datenbankadministrator angepasst werden.
Anwendungsunterstützung
Zur Unterstützung von Datenbankapplikationen bieten Datenbanksysteme Trigger und Stored Procedures an. Ein Trigger löst eine Aktion in der Datenbank aus, wenn ein bestimmtes Ereignis eingetreten ist, häufig bei Einfüge- oder Änderungsoperationen. Stored Procedures dienen dem Ausführen von Scripten in der Datenbank. Da Stored Procedures innerhalb des Datenbanksystems ausgeführt werden sind sie oft der effizienteste Weg, Daten zu manipulieren.
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 Joins aus den einzelnen Relationen wiederhergestellt werden, was zu unübersichtlichen Abfragen führt.
- künstliche Schlüsselattribute
- Zur eindeutigen Identifizierung von Tupeln müssen in manchen Fällen 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 Anwendungsobjektes nichts zu tun haben, sondern "nur" Verwaltungsinformationen sind.
- externe Programmierschnittstelle
- Da in vielen relationalen Datenbanken nur Datenmanipulationssprachen eingeschränkter Mächtigkeit vorhanden sind, folgt daraus, dass Schnittstellen notwendig werden, um mächtigere Programmiersprachen einbinden zu können. Es gibt jedoch auch relationale Datenbanken mit mächtigen Programmiersprachen wie PL/SQL in Oracle. Die Verbindung von Datenbanksprachen mit externen, schon vorhandenen Programmiersprachen führt zu einer wenig programmiererfreundlichen Handhabung, z.B. beim Einbinden von SQL in C++-Programme: Beide Sprachen verfolgen hier ein unterschiedliches Verarbeitungsparadigma: SQL arbeitet mengenorientiert und C++ satzorientiert.
- fehlendes Verhalten
- 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.
Gegenüberstellung von Grundbegriffen
| Tabelle | Relationales Datenmodell | Entity-Relationship-Modell (ERM) | Unified Modeling Language (UML) |
| Wertebereich (Domäne, Domain) | Wertebereich (Domäne, Domain) | Wertebereich (Domäne, Domain) | Wertebereich (Domäne, Domain) |
| Kopfzeile | Relationstyp/Relationsformat | Entitätstyp | Klasse |
| Spaltenüberschrift | Attribut | Attribut | Attribut |
| Inhalt | Relation | Entitätsmenge(-set) | Objektmenge, Instanzmenge, Klasse |
| Inhalt | Fremdschlüssel | Beziehung (Relationship) | Assoziation |
| Zeile | Tupel | Entität | Objekt, Instanz |
| Zelle | Attributwert | Attributwert | Attributwert |
Siehe auch
- Relationale Entwurfstheorie
- Datenbankoperator
- Deduktive Datenbank
- Liste der Datenbankmanagementsysteme
Literatur
- ↑ Edgar F. Codd: A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, 6/13/Juni 1970, ACM Press, New York, S. 377-387, ISSN 0001-0782
- 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. Oldenbourg, München 2004, ISBN 3-486-27392-2
Weblinks
- ZenoServer 2.4.26
- Zenodot
- Digitale Bibliothek
- Downloadshop
- Retrodigitalisierung
- Nutzungsbedingungen
- Impressum