17.1 Definitionen

Formal beruht das relationale Datenmodell auf dem mathematischen Relationenbegriff, der Mengenlehre und dem Prädikatenkalkül. Ein relationales Modell besteht dabei aus einer (nicht-hierarchischen) Sammlung von n-stelligen Relationen. Alle Objekte und Beziehungen werden durch n-stellige Relationen repräsentiert. Eine Datenbank ist (aus dieser Sicht) wie folgt definiert:

Definition 17.1-1: Relationale Datenbank
Eine Relationale Datenbank ist eine endliche Menge von inhaltlich zusammenhängenden (denselben Weltausschnitt beschreibenden) endlichen Relationen.

Mit endlicher Relation ist gemeint, dass die Zahl aller Tupel (die Extension der Relation) endlich ist.

Der Begriff der "Relation" kommt aus der Mengenlehre. Seine Verwendung in der Datenbanktheorie und -praxis zur Modellierung von Realität für die maschinelle Informationsverarbeitung mutet oft überraschend an. Deshalb soll er hier, ausgehend von der mathematischen Definition bis zu seiner Ausprägung in der Datenbanktheorie, dargestellt werden. Vorab einige Definitionen, die in dieser formalen Fassung am Beginn dieses Kapitels nicht angegeben wurden:

Definition 17.1-2: Wertebereich
Ein Wertebereich (domain) D ist (im Datenbankkontext) eine endliche Menge von Begriffen, die zur Erfassung von Eigenschaften bzw. zur Benennung von Objekten dienen.

Wertebereich

Einige einfache Beispiele:

  • {Relationales Datenbanksystem, Objektorientiertes Datenbanksystem, Hierarchisches Datenbanksystem, Netzwerkdatenbanksystem, Information Retrieval System} zur Erfassung verschiedener Typen von Datenbanksystemen.
  • {10.000,-- DM, 1.500,-- DM, 2.800,-- Euro} zur Erfassung der konkreten Preise von Datenbanksystemen.
  • {COBOL, FORTRAN, C, PASCAL, SMALLTALK, PROLOG} zur Erfassung von Programmiersprachen.
  • {INGRES, INFORMIX, Visual dBase, Paradox, FoxPro, Access} zur Benennung von Datenbanksystemen.

Die zweite Definition klärt das kartesische Produkt zweier Wertebereiche.

Definition 17.1-3: Kartesisches Produkt von Wertebereichen
Das kartesische Produkt der Wertebereiche D1, ..., Dn wird mit
D1 * D2 ... * Dn bezeichnet und besteht aus der Menge aller Tupel
(x1, x2, ..., xn), so dass für jedes i (i=1, ...,n) gilt: (xi ist Element von Di)

Ein einfaches Beispiel: Seien D1={a,b,c}, D2={x,y}. Dann besteht das kartesische Produkt aus den Tupeln {(a,x), (a,y), (b,x), (b,y), (c,x), (c,y)}. Dieses kartesische Produkt zweier solcher Mengen lässt sich auch tabellarisch darstellen:

Tabelle mit kartesischem Produkt zweier Mengen

Spalte1

Spalte 2

a

x

a

y

b

x

b

y

c

x

c

y


In einem (beliebigen) mathematischen Begriffswörterbuch findet sich die folgende Definition einer Relation:

17.2 Relation – mathematisch

Definition 17.2-1: Relation - mathematisch
Es seien D1, D2, ...., Dn beliebige nichtleere Mengen und
D1 * D2 * .... * Dn deren kartesisches Produkt. Dann heißt jede Untermenge R desselben eine n-stellige Relation.
Gilt (x1, x2, ..., xn) aus R mit xt aus Dt (t=1, ..., n), dann stehen x1, x2, ..., xn in der Relation R zueinander.

Besonders häufig tritt der Fall auf, dass es sich um genau zwei Mengen A und B handelt. In diesem Fall schreibt man xRy (x aus A, y aus B).

Auf diese Weise werden also aus Wertebereichen Relationen. Bevor wir dies voll in den Datenbankbereich übertragen hier einige Beispiele.

17.2.1 Beispiel Datenbanksysteme / Produzenten

Das erste betrifft Datenbanksysteme und deren Produzenten. Es ist natürlich gegenüber der Realität stark vereinfacht. Seien

D1={Microsoft, Borland}

und

D2={Visual dBase, Paradox, Access, FoxPro}.

Dann besteht das kartesische Produkt aus der Menge der Tupel:

{(Microsoft, Visual dBase), (Microsoft, Paradox), (Microsoft, Access), (Microsoft, FoxPro), (Borland, Visual dBase), (Borland, Paradox), (Borland, Access), (Borland, FoxPro)}.

In der Tabellendarstellung lassen sich diese Tupel wie folgt anordnen:

Tabelle mit kartesischem Produkt

Spalte 1

Spalte 2

Microsoft

Visual dBase

Microsoft

Paradox

Microsoft

Access

Microsoft

FoxPro

Borland

Visual dBase

Borland

Paradox

Borland

Access

Borland

Foxpro


Relationen im mathematischen Sinn bestehen nun aus Teilmengen dieser „Tupelmenge“. Im weniger abstrakten Datenbankkonzept fragen wir uns nun, welche Teilmengen (=Relationen) dieser Tupel einen Sinn ergeben. Welche erfasst z.B. die Relation Firma besitzt und verkauft Datenbanksystem (Zeitpunkt Frühjahr 2004). Welche Teilmenge könnte die Relation erfassen Firma würde gerne besitzen? Eine andere Relation könnte lauten: datenkompatible Datenbanksysteme. In dieser würden die Tupel erfasst, bei denen die beiden Datenbanksysteme datenkompatibel sind.

Semantisch sinnvolle Teilmengen

Damit dürfte klar sein, wohin der mathematische Relationenbegriff zielt und woher seine Tauglichkeit für die Datenbanktheorie kommt. Bestimmte Teilmengen - Relationen - ergeben semantisch einen Sinn und genau die sind es, die zur Datenmodellierung benutzt werden.

Sinn

Ein weiteres Beispiel soll Datenbanksysteme und deren Datentypen betreffen: Seien

Beispiel

D1={BLOBS, MEMO, TEXT}

und

D2={INGRES, Visual dBase, INFORMIX}.

D1 gibt also ausgewählte Datentypen an, D2 Datenbanksysteme. Das kartesische Produkt ist:

{(BLOBS, INGRES), (BLOBS, Visual dBase), (BLOBS, INFORMIX), (MEMO, INGRES), (MEMO, Visual dBase), (MEMO, INFORMIX), (TEXT, INGRES), (TEXT, Visual dBase), (TEXT, INFORMIX)}

Einen Sinn ergibt natürlich nur die Teilmenge, die tatsächlich festhält, welches Datenbanksystem welche Datentypen hat.

17.2.2 Beispiel Online-Datenbanken

Das folgende Beispiel begtrifft wiederum Online-Datenbanken. Gegeben seien zwei Mengen. Die erste besteht aus Anbietern von Online-Datenbanken:

{DIALOG, WEFA, STN},

die zweite aus Online-Datenbanken

{COMPENDEX, CRONOS-FRIC, CRONOS-ICG, CAS}.

Beides ist natürlich wiederum stark vereinfacht. Folgende Beziehung sei gegeben: DIALOG bietet nur COMPENDEX und CAS an, WEFA nur CRONOS-FRIC und CRONOS-ICG, STN nur CAS. Dann gilt also:

D1 = {Menge der Hosts} = (DIALOG, WEFA, STN)

D2 = {Menge der Online-Datenbanken) = (COMPENDEX, CRONOS-FRIC, CRONOS-ICG, CAS}

Das kartesische Produkt ergibt sich mit (D1 * D2):

(DIALOG, COMPENDEX), (DIALOG, CRONOS-FRIC), (DIALOG, CRONOS-ICG), (DIALOG, CAS), (WEFA, COMPENDEX), (WEFA, CRONOS-FRIC), (WEFA, CRONOS-ICG), (WEFA, CAS), (STN, COMPENDEX), (STN, CRONOS-FRIC), (STN, CRONOS-FRIC), (STN, CAS).

Eine Untermenge davon ist:

R = (DIALOG, COMPENDEX), (DIALOG, CAS), (WEFA, CRONOS-FRIC), (WEFA, CRONOS-ICG), (STN, CAS).

Diese Untermenge hat die Bedeutung Host A bietet Datenbank B an, weil sie mit der Semantik des fiktiven Weltausschnitts übereinstimmt. Andere Untermengen könnten die Tupel herausgreifen mit der Beziehung Host würde gerne anbieten oder besteht Vertrag bzgl. Datenbank bei Host.

Nicht alle Teilmengen besitzen Bedeutung für die Modellierung. Aber alle sinnvollen sind Untermengen des kartesischen Produkts und somit Relationen. Relationen drücken somit Beziehungen zwischen Begriffen aus. Hinter den Begriffen stehen Objekte, Eigenschaften, usw.

Verändern wir nun etwas den Blickwinkel, indem wir die Tupel spaltenweise untereinander anordnen und über die Spalten Benennungen der Begriffe schreiben, ergibt sich folgende Darstellung:

Hosts und Datenbanken

Host

Datenbank

DIALOG

COMPENDEX

DIALOG

CAS

WEFA

CRONOS-FRIC

WEFA

CRONOS-ICG

STN

CAS


Die Objekte von D1 sind jetzt Ausprägungen des Attributs Host, die von D2 Ausprägungen des Attributs Datenbanken.

Diese Darstellung einer Relation ist der Grund dafür, dass in der populären Literatur und in den Handbüchern der Datenbanksysteme meist von Tabellen die Rede ist, wenn Relationen gemeint sind. Dies ist nicht sehr glücklich, weil hinter einer Tabelle im relationentheoretischen Sinne mehr steht, als nur eine tabellarische Anordnung von Werten.

Die zu Beginn angeführten Eigenschaften einer Relation sind nun unschwer nachvollziehbar:

  • In einer Spalte stehen nur die Objekte einer Menge, bzw. die Ausprägungen eines Attributs. Im Spaltenkopf steht die Benennung der Menge bzw. der Attributsname.
  • Im Kreuzungspunkt einer Spalte und Zeile kann nur jeweils ein Objekt, bzw. eine Merkmalsausprägung stehen.
  • Jeder Begriff einer Spalte bezeichnet ein bestimmtes Objekt (und nur dieses), bzw. ist Ausprägung eines Attributs (mit allen Konsequenzen).
  • Alle Zeilen der Tabelle sind paarweise verschieden
  • Jede Zeile (Tupel) beschreibt ein Objekt (dies ist nur teilweise richtig, wie oben gezeigt wurde. Nach der Normalisierung ist es oft so, dass ein Tupel einer Relation nur Teilaspekte eines Objekts beschreibt).
  • Die Reihenfolge der Zeilen ist ohne Bedeutung

Die Identifizierung der Zeilen der Tabelle mit den Tupeln ist Ursache von Definitionen, die Relationen als eine Menge von Tupeln beschreiben. Mit obigem können dann Attribute wie folgt definiert werden:

Definition 17.2-2: Attribute
Die Spalten einer Relation enthalten Attribute. Im Spaltenkopf steht der Attributsname, darunter die Attributsausprägungen.

Die Attribute einer Relation sind normalerweise verschieden (nicht aber die Wertebereiche). Aus obigen Definitionen ergibt sich: Die Ausprägungen des Attributs der Spalte i einer Relation stammen aus dem Wertebereich Di.

17.3 Klasse (type)

Jetzt können auch die Begriffe Objekt- und Beziehungsklasse (entity type, relationship type) genauer gefasst werden. Aus den einzelnen Objekten bzw. Beziehungen bilden wir zum Zwecke der Datenmodellierung Objektklassen. Dabei werden genau die Objekte zu einer Klasse zusammengefasst, die als Tupel in einer Relation stehen (oben wurde formuliert: die durch dieselben Attribute beschrieben werden). Genau dasselbe gilt für Beziehungen und Beziehungsklassen.

Das einzelne Tupel einer Relation beschreibt (mit Einschränkungen) ein Objekt oder eine Beziehung. Die Menge der Tupel einer Relation beschreibt die zugehörige Objektklasse bzw. Beziehungsklasse.

Durch die Verwendung des Relationenbegriffs können die in der Relationentheorie entwickelten Instrumente für die Entwicklung von und die Arbeit mit Datenbanken Verwendung finden. Dies betrifft vor allem die Standardabfrage- und -auswertungssprache für Relationale Datenbanken SQL.

Relationen im oben beschriebenen Sinn sind das einzige im relationalen Datenmodell zur Modellierung des Realitätsausschnitts zur Verfügung stehende Werkzeug.

Abschließend nun noch die datenbanktheoretische Formulierung der Relationendefinition. Diese ist mehr oder weniger stark am mathematischen Relationenbegriff orientiert. Der Ausgangspunkt der Formulierung sind aber die auf den Objekten definierten Attribute und Merkmale:

Definition 17.3-1: Relation (datenbanktheoretisch)
Seien A1, A2, ...,An Attribute mit den Wertebereichen W1, W2, ... , Wn. Eine Teilmenge R von W1 x W2 x ... x Wn heißt n-stellige Relation über den Bereichen W1, W2,..., Wn. Die Elemente r aus R werden wie folgt bezeichnet:
r = (a1, a2, ...,an) mit (ai aus Wi, i=1,...,n).
n ist der Grad der Relation; r heißt n-Tupel aus R.