Relationale Datenbank

Eine relationale Datenbank ist eine Datenbank, die auf dem relationalen Datenbankmodell basiert, das von Edgar F. Codd 1970 erstmals vorgeschlagen wurde; darin ist Relation ein im streng mathematischen Sinn wohldefinierter Begriff (terminus technicus), der im Wesentlichen ein mathematisches Modell für eine Tabelle beschreibt (siehe dazu Relation (Datenbank)). Die Daten werden dabei in Form von zweidimensionalen Tabellen verwaltet, die über Schlüssel (Primärschlüssel, Fremdschlüssel) miteinander verknüpft werden können. Die meisten in der Praxis eingesetzten Datenbanksysteme sind für relationale Datenbanken konzipiert (relationale Datenbankmanagementsysteme, kurz RDBMS). Im allgemeinen Sprachgebrauch ist deshalb oft eine relationale Datenbank bzw. ein relationales Datenbanksystem gemeint, wenn von Datenbanken die Rede ist.

Für relationale Datenbanken gibt es mit SQL eine verbreitete und größtenteils standardisierte Abfragesprache.

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

Früher wurden in der betrieblichen Datenverarbeitung hierarchische Datenbanksysteme und Netzwerk-Datenbanksysteme verwendet. Sie kommen in Spezialfällen auch heute noch zum Einsatz.

Zum Teil werden die relationalen Datenbanken durch objektorientierte Datenbanken abgelöst. Relationale Datenbanken sind aber derzeit immer noch die am meisten verbreitete Datenbankform und es ist nicht klar, ob sich die objektorientierten Datenbanken durchsetzen werden. Die großen Datenbankhersteller fügen ihren relationalen Datenbanken objektorientierte Eigenschaften hinzu und haben so die objektrelationalen Datenbanken entwickelt.

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 Vorlage:Lit beschrieben. Theoretisch basieren alle Operationen auf der relationalen Algebra.

Die erste kommerziell erfolgreiche relationale Datenbank wurde jedoch erst Ende der 1970er von der Firma Oracle auf den Markt gebracht.

1986 hat Codd in der Computer World einen zweiteiligen Artikel mit 12 strengen Anforderungen veröffentlicht, welche ein RDBMS aus seiner Sicht erfüllen muss. Dabei sind die Regeln so streng, dass kein zur Zeit verfügbares Datenbanksystem alle erfüllt. Besondere Probleme bereiten die Regeln 6, 9, 10, 11 und 12. Da es aktuell (Februar 2004) noch keine eindeutigen, allgemeinverständlichen Übersetzungen gibt, sind hier die Originalüberschriften auf Englisch aufgeführt:

The Information Rule
Guaranteed Access Rule
Systematic Treatment of Null Values
Dynamic On-line Catalog Based on the Relational Model
Comprehensive Data Sublanguage Rule
View Update Rule
High-level Insert, Update and Delete
Physical Data Independence
Logical Data Independence
Integrity Independence
Distribution Independence
Nonsubversion Rule

Zusätzlich hat Codd noch die Regel 0 definiert, wonach jeder Zugriff nur durch relationale Fähigkeiten stattfinden darf.

Die Grundregeln für eine relationale Datenbank (nach Codd) lassen sich wie folgt beschreiben:

Jede Relation ist eine zweidimensionale Tabelle und entspricht einem Relationstyp
Jede Zeile dieser Relation (Tabelle) wird Tupel genannt und beschreibt ein konkretes Tupel des Relationstyps, den die Relation (Tabelle) darstellt
Jede Spalte der Relation (Tabelle) entspricht einem Attribut des Relationstyps. Die konkreten Tupel werden somit durch die entsprechenden Attributwerte beschrieben.
Der Grad einer Relation bezeichnet die Anzahl der Attribute
Die Kardinalität einer Relation entspricht der Anzahl der Tupel
Existiert für ein Attribut eine begrenzte Anzahl von Attributwerten, so wird die Zusammenfassung aller Attributwerte für dieses Attribut Domäne (Wertebereich) genannt
Es ist nicht relevant, in welcher Reihenfolge Zeilen bzw. Spalten der Tabelle angeordnet sind
Die Existenz zweier identischer Zeilen ist ungültig
Attributwerte sind atomar

Ende 1990 hat Codd in seinem Buch The Relational Model for Database Management - Version 2 Vorlage:Lit die bisherigen 12 Regeln auf 333 Regeln differenziert, die allgemeine Akzeptanz gefunden haben.

Wichtige Begriffe relationaler Datenbanken

Datei:Begriffe relationaler Datenbanken.png

Begriffe relationaler Datenbanken

Abhängigkeit

Funktionale Abhängigkeit

Bei gegebenen Relation R ist das Attribut B genau dann vom Attribut A funktional Abhängig(A->B), wenn 2 Tupel einer aus R, die im Attribut A den gleichen Wert besitzen, auch im Attribut B den gleichen wert aufweisen. Das heißt, dass zu jedem Zeitpunkt jeder Wert von A genau zu einem Wert von B korrespondiert. FA ist eine Eigenschaft der [Semantik] von Attributen einer Relation.

Mehrwertige Abhängigkeit

Gegeben ist eine Relation R(A,B,C).Eine mehrwertige Abhängigkeit ("multi valued dependency"") A->->B existiert in R genau dann, wenn eine Menge von von B-Werten, die einem gegebenen Paar (A-Wert,C-Wert) in R entsprechen, nur von den A-Wert abhängig, vom C C-Wert jedoch unabhängig ist (A,B u. C können zusammengesetzt sein).

Volle Funktionale Abhängigkeit

Ein Attribut ist voll funktional abhängig, wenn es von einem zussammgesetzten Attribut und nicht von einem einzelnen Attribut funktional abhängig ist.

Attribut

Beschreibung einer bestimmmten Eigenschaft einer Entität bzw. Aussage, die über eine bestimmte Entität (Objekt) der Miniwelt gemacht werden.

Determinante

Ist ein Attribut oder eine Gruppe von Attributen, von der beliebige andere Attribute voll Funktional abhängig sind.

Globales Attribut

Ein Attribut heißt global, wenn es in mindestens einer Relation eines betrachteten Datenmodells als (Bestandteil des) Primärschlüssel(s) vorkommt.

Lokales Attribut

Ein Attribut heißt lokal, wenn es nur in einer Relation des betrachteten Datenmodells und nicht als (Bestandteil des) Primärschlüssels(s) vorkommt.

Multiples Attribut

Ein Attribut kann zu einem Zeitpunkt mehrere Werte annehmen. Es besitzt mehrere Ausprägungen (Instanzen, "multivalued").

Periodenfeld

Ist ein multiples Attribut, wobei jede Ausprägung eine vordefinierte Bedeutung hat.

Zusammengesetztes Attribut

Besteht aus mehreren einfachen, atomaren Attributen.

Datenmodell-Integration

Fein-Datenmodelle zu sichten und auf ein gemeinsames gültiges Datenmodell zu machen, das UwDM, zu machen.Strebt nach projektübergreifender Klärung und Vereinheitlichung von betriebswirtschaftlichen und technischen Daten. Die dabei gewonnen Erkenntnisse und Ergebnisse sind auch Voraussetzung für eine anwendungssystemübergreifende Datenbanknutzung.

Domäne

Eine durch den Domänentyp bezeichnete Menge von Werten, die als Attributwerte für die Entitäten eines Entitätstypes zulässig sind.

Entität

Individuelles Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt (Individuum der Miniwelt).

Entitätstyp

Zusammenfassung aller gleichartigen Entitäten, d.h. Objekte mit gleichen Attributen (aus der Miniwelt) unter einem gemeinsamen Oberbegriff. ====Beschreibungsentitätstyp Beschreibt bzw. charakterisiert andere Entitäten. Sie sind existenzabhänging von anderen Entitäten.

Beziehungsentitätstyp

Repräsentiert eine zwei oder mehrdimensionale Beziehung zwischen zwei oder mehr Entitätstypen.

Kategorie

Im Gegensatz zum Shared-Sub-ET ist eine Kategorie ein Sub-ET der Vereinigung von mehreren übergeordneten Super-ETs.

Kernentitätstyp

Kann unabhängig von anderen Entitätstypen existieren. Sie repräsentieren grundlegende Aussagen, die für das Verständnis der betrachteten Miniwelt von zentraler Bedeutung sind.

Owner-Entitätstyp

Shared Sub-Entitätstyp

Ist ein Sub-ET, der mehreren Super-ETs zugeordnet ist, so dass sich ein logisches Netzwerk ergibt(Untermenge des Durchschnittes der Super-ETs).

Sub-Entitätstyp

Ein Entitätstyp E1 ist ein Sub-Entitätstyp des Entitätstypes E2, wenn jede Entität von E2 immer mit einer Entität von E1 in Beziehung steht. Ein Sub-ET ist ohne übergeordneten Super-ET nicht existenzfähig und erbt alle Attribute des Super-ET, wo zusätzliche Attribute vorhanden sein können.

Super-Entitätstyp

Weak Entitätstyp

Besitzt keinen eigen Schlüssel, wird identifiziert durch eine Muss-Beziehung zu einen Owner-Entitätstyp.

Generalisierung

Als Inverser Prozess zur Spezialisierung stellt die Generalisierung die konzeptionelle, schrittweise Synthese von ETs zu einem Super-ET dar (Bottom-Up-Vorgehen).

Grad

Anzahl der Attribut einer Relation.

Kardinalität

Anzahl der Zeilen einer Relation.

Beziehungskardinalität

Anzahl der Beziehungs-Instanzen, an denen ein Entity teilnehmen kann. Ein Beziehungtyp kann als eindeutig (1:1), einseitig eindeutig (1:n) oder komplex (m:n) typisiert werden.

Beziehungsart

Bestimmt, ob auch 0 als Beziehungskardinalität erlaubt ist oder das ob das Minimum 1 gilt.

Rekursive Beziehung

Sind Beziehungen zwischen Entitäten des selben ETs(Eigenbeziehung).

Integrität

Die Erhaltung der Integrität umfasst die Ausrechterhaltung der Korrektheit und Konsistens von Daten.

Referentielle Integrität

Korrektheit der Beziehungen zwischen Relationen und durch Aufrechterhaltung der Konsitens zwischen den Tupel der beteiligten Relationen.

Menge

Ansammlung von Elementen. M=(l1,l2,l3) ist eine mathmatische Notation für eine Menge M, die aus 3 Elementen besteht.

Relationales DB-Schema

Zusammenfassung eine Menge von Relationen und zugeordneter Integritätsbedingungen.

Relationales Datenmodell

Repräsentation der Daten in einer Datenbank als Ansammlung von Relationen.

Relationship (Beziehung)

Drück als Begriff auf Elementarebene den funktionalen Zusammenhang zwischen 2 oder mehreren Entitäten in eine Richtung aus. Zwischen 2 Entitäten, die dem gleichen ET (rekursive Beziehung) oder unterschiedlichen ETs angehören können, existieren immer 2 Beziehungen entsprechend den beiden Verbindungsrichtungen.

Normalform

1. NF

Eine Relation liegt in 1.NF vor, wenn jeder Attributwert eine atomare, nicht weiter zerlegbare Dateneinheit ist. Multiple und zusammengesetzte Attribute sind verboten.

2. NF

Eine Relation liegt in der 2. NF vor, wenn sie in der 1.NF ist und jedes Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel ist.

3. NF

Eine Relation liegt in der 3.NF vor, wenn sie sich in der 2.NF befindet und jedes Nichtschlüsselattribut nicht transitiv abhängig vom Primärschlüssel ist.

4. NF

Eine Relation liegt in der 4.NF vor, wenn sie sich in der BCNF befindet und alle mehrwertigen Abhängigkeiten funktionale Abhängigkeiten sind.

5. NF

Boyce-Codd-NF

Eine Relation liegt in der BCNF vor, wenn jede Determinante ein Schlüsselkandidat ist.

Normalisierung

Regelwerke für die Analyse von Relationen basierend auf ihren Schlüsseln und den funktionalen Abhängigkeiten ihrer Attribute (Normalisierungsregeln). Erkennen nicht korrekter Relationen, sowie die Zerlegung (Dekomposition) in mehrere Relationen. Erkennen und Reduktion von [Redundanz]en.

Normalisierungsprozess

relationen, die nicht in 2. NF sind, müssen in mehrere Relationen zerlegt werden. Dabei werden jene Attribute, die von Teilschlüsseln funktional abhängig sind, zusammen mit diesen Teilschlüsseln in getrennten Relationen zusammengefasst.

Relationale Operation

Hat prinzipiell eine Menge von Tabellenzellen als Ziel, die vom Anwender durch ein qualifizierendes Prädikat (Suchausdruck) beschrieben wird. Das Ergebnis einer relationalen Datenmanipulation ist wiederum eine (temporäre) Relation, so dass die widerholte Anwendung bzw Verkettung relationaler Operationen (Relationsalgebra), möglich ist. Die RO wird durch Relationale Operanten ausgeführt.

Relationshiptype (Beziehungstyp)

Oberbegriff für die Menge gleichartiger,wechselseitiger Relationships (Beziehungen) zwischen zwei oder mehren ETs.Der RT ist als Begriff auf Mengenebene nur abstrakt vorhanden, also in der Miniwelt real nicht existent.

Grad eines Relationships

Gibt die Anzahl der ETs an, die miteinander in Beziehung stehen(Dimension einer Beziehung).

Spezialisierung

Stellt eine konzeptionelle, schrittweise Verfeinerung bei der Definition eines ETs-dar, wobei die Unterscheidung der Sub-ETs

Schlüssel

Es ist ein Attribut zur eindeutigen Identifikation von Entitäten einer oder mehrerer Relationen.

Fremdschlüssel

Ist ein Attribut oder eine Kombination von Attributen (zusammengesetzter Fremdschlüssel), der in einer oder mehreren Relationen Primärsachlüssel ist. Ein Fremdschlüssel kann selbst Teil einer Relation sein. In Kann-Beziehungen kann der FS den NULL-Wert annehmen.

Künstlicher Primärschlüssel

Wenn unter den bereits definierten Attributen für einen ET kein Schlüsselkandidat gefunden werden kann, muss ein eigenes Attribut "Künstlicher Primärschlüssel" eingeführt werden.

Primärschlüssel

Ein Attribut oder die minimale Kompination von Attributen, die eine Entität eindeutig Identifizieren.Die Attributkombination wird Zusammengesetzer Schlüssel (compounded Key) genannt.

Teilschlüssel

Alle einzelnen Attribute eines compouded Keys.

Surrogat

Ein vom DB-System automatisch vergebener Primärschlüssel.("Database Key",RAA(relative Randomadresse),..). Anwender braucht keinen PS definieren.

Tupel

Unternehmensweites Datenmodell

Integriertes Feindatenmodel aller betrachteten Relationen von Anwendungssystemfeindatenmodellen.

Unternehmens-Datenmodell

Verdichtetes Datenmodell, das für die strategische Applikationsplanung geeignet ist, als umfassende Feinmodelle. Ähnlich wie Europa- oder Weltkarten für bestimmte Aufgaben besser geeignet sind als Stadtpläne. Soll aus dem detaillierten Datenmodell herleitbar sein, um wieder den "Wald statt vieler Bäume" sichtbar zu machen.

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

Schwachpunkte der relationalen Modellierung

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.
keine transitive Hülle berechenbar
Mit dem reinen Relationenmodell lässt sich keine Transitive Hülle berechnen. Betrachten wir z.B. eine Relation Mitarbeiter mit Primärschlüsselattribut PersNr (jeder Mitarbeiter hat genau eine Personalnummer) und einem zweiten Attribut hat_Chef. Dieses enthält den Wert der PersNr des jeweiligen Chefs. Wir können nun zu jedem Mitarbeiter seinen direkten Vorgesetzten bestimmen. Möchten wir aber alle seine Vorgesetzten bestimmen, also die Chefs seines Chefs, dann ist uns das nicht möglich.

Empfehlungen (Best Practices)

Bezeichner für Tabellen, Felder, Views, Trigger sollten folgenden Regeln gehorchen:

Ein Bezeichner muss mit einem Buchstaben oder einem Unterstrich (_) beginnen und darf keine Leerzeichen enthalten.
Auf das erste Zeichen können Buchstaben, Ziffern und Unterstriche folgen.
Reservierte Wörter (z.B. FROM) dürfen nicht als Bezeichner verwendet werden.
Bezeichner sollten max. 64 Zeichen haben

Viele Datenbankmanagementsysteme sind wesentlich freizügiger bei der Vergabe von Bezeichnern. Man sollte diese Freiheiten aber nicht benutzen, denn dies erschwert das Portieren einer Datenbank auf ein anderes Datenbankmanagementsystem. Vor allem bei der Benutzung von reservierten Wörtern kann es zu Fehlern kommen, die sich nur schwer finden lassen.

Siehe auch

Literatur

Edgar F. Codd: A Relational Model of Data for Large Shared Data Banks. In: 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
Thomas Connolly, Carolyn Begg, Anne Strachan: Datenbanksysteme. Eine praktische Anleitung zu Design, Implementierung und Management. Addison-Wesley, München 2002, ISBN 3-8273-2013-5
Tobias Eggendorfer: Datenbanksysteme für Wirtschaftsinformatiker. Books on Demand, Norderstedt 2005, ISBN 3-8334-2493-1
Ramez Elmasri, Shamkant B. Navathe: Grundlagen von Datenbanksystemen, Pearson Studium, 15. September 2002, ISBN 3-8273-7021-3
Alfons Kemper, André Eickler: Datenbanksysteme. Eine Einführung. Oldenbourg, München 2004, ISBN 3-486-27392-2
Peter Stahlknecht, Ulrich Hasenkamp: Einführung in die Wirtschaftsinformatik. Springer, Berlin 2002, ISBN 3-540-41986-1
Helmut Dreßler: Datenstrukturentwurf (Vom Faktenchaos zur Anwenderdatenbank). R. Oldenbourg, München Wien 1995, ISBN 3-486-21808-5

Weblinks

Kriterien für relationale Datenbanksysteme mit ausführlicher Beschreibung der 12 Regeln