SPOC-Web Icon, semantic Knowledge Management

Relational Tables

Relationale Tabellen

Relationale Tabellen und Datenbanken wurden Anfang der 70er Jahre erfunden. Sie haben eine mächtige mathematische Basis und eine hohe Reife. Dadurch werden sie in jedem Bereich der Informationstechnologie eingesetzt: vom Mainframe bis hin zum Mobiltelefon.

Die Grundlagen der relationalen Theorie sind schnell erfassbar. Ihre Beherrschung trägt wesentlich bei zum Verständnis jedes Software-Systems.

In Spoc-Web werden diese Ansätze nahtlos mit den neuen Ideen des semantischen Web verknüpft. Aus dieser Kombination von bewährten und neuen Technologien entsteht ein System, das gleichzeitig äußerst flexibel und hochperformant arbeiten kann.

Der Aufbau von relationalen Tabellen

Tabellen sind 2-dimensionale Datenspeicher, bestehend aus Zeilen und Spalten.

Jede Zeile stellt ein Objekt/Ding mit eigener Identität dar.

In den Spalten stehen jeweils Daten/Werte des gleichen Typs und mit gleicher Bedeutung.

Erlaubte Daten-Typen sind:

  • Text
  • Datum und Uhrzeit
  • Zahlen: ganze Zahlen oder Fließkomma-Zahlen
  • Verweise auf Zeilen in relationalen Tabellen: meist in Form von ganzen Zahlen

Insbesondere die Verweise erlauben die Flexibilität und Leistung des relationalen Modells und damit seinen großen Erfolg.

Die Zeilen und Spalten bilden an ihren Kreuzungen die sogenannten "Zellen", deren Inhalt möglichst "atomar" sein sollte, denn die Datenbank kann den "Inhalt" von Zellen nur mit großem Aufwand bearbeiten. Das bedeutet, dass man z.B. separate Spalten/Zellen für Vor- und Nachname schafft, wenn man diese getrennt benutzen möchte.

 

Tabellen: Schema und Beispiel

Schmatische Tabelle mit Zeilen und Spalten
(inkl. ID Spalte mit technischem eindeutigen Wert)
ID Spalte 2 ... Spalte N
 1  Zeile 1 ... ...
  ...   ...
m Zeile m ... ...
Beispiel-Tabelle: Personendaten einer Familie
ID Vorname Nachname Addresse Stadt Staat ZIP

3

John

Doe

569 Peach St.

Martin

TN

38237

6

Jane

Doe

569 Peach St.

Martin

TN

38237

8

Jack

Doe

569 Peach St.

Martin

TN

38237

9

Jill

Doe

569 Peach St.

Martin

TN 38237

Eindeutige Tabellen-Schlüssel

Bei der Beschreibung von Objekten wird erklärt, wie wichtig ein eindeutiger Name ist. Dasselbe gilt auch für Tabellen: dort heißen eindeutige Namen "Schlüssel". Tabellen besitzen meist sogar zwei Schlüssel: eine technische ID (meist eine hochgezählte ganze Zahl) und eine fachlich begründete, eindeutige Kombination von Spalten.

ID: Technischer Schlüssel

Jede Zeile sollte einen eindeutigen Namen besitzen, an dem man sie von allen anderen unterscheiden kann. Dafür wird in der Regel eine besondere Spalte angelegt: die sogenannte "ID" oder "Identität" Spalte. In der Praxis wird hierfür meist eine ganze Zahl verwendet und für jede neue Zeile hochgezählt. Wichtig dabei ist, dass diese ID NIE wieder geändert wird. Sie wird auch nicht wiederverwendet, wenn eine Zeile mal gelöscht wird. Deshalb ist eine Zahl auch gut geeignet, weil sie keine Bedeutung trägt. Diese IDs werden in der Regel auch nicht veröffentlicht und so besteht kaum eine Veranlassung, sie ändern zu wollen.

Wenn sie veröffentlich werden, wie z.B. Kontonummern, dann beginnen viele Systeme bereits mit sechsstelligen Zahlen, damit Kunden nicht auf die Idee kommen, die Nummer ändern zu wollen.

Fachlicher Schlüssel

Neben dem technischen Schlüssel gibt es auch einen fachlichen eindeutigen Schlüssel, anhand dessen man die Zeilen eindeutig voneinander unterscheiden kann. Da der technische Schlüssel oft nicht veröffentlicht wird, ist so ein fachlicher Schlüssel notwendig, um die Zeilen auch ohne ID, nur anhand ihrer Eigenschaften auseinander halten zu können. Bei Personen wird z.B. oft folgende Kombination verwendet: Vorname, Nachname, sowie Geburtsort und Geburtsdatum.

Die Art des fachlichen Schlüssels wird wesentlich durch das fachliche Umfeld bestimmt, vor allem dadurch, welche Felder überhaupt verfügbar sind.

Tabellen = Klassen

Es zeigt sich nun, dass die Entsprechung von Tabellen zu den hier beschriebenen Klassen vollständig und keineswegs zufällig ist. Nachfolgend ist der Vergleich zwischen Tabellen-Struktur und den semantischen Konzepten von Individuen und Mengen nochmals tabellarisch aufgeführt.

Tabelle Zeile Zelle Spalte Verweis Verweis-Spalte Schlüssel ID
Semantik  Ding  Eigenschaft Prädikat Beziehung Relation Name ID

Normalisierung für Leistung und Eindeutigkeit:

Relationale Datenbanken verwenden im Unterschied zu einfachen Listen und Tabellen-Kalkulations-Anwendungen stets mehrere Tabellen, um ihre Daten zu speichern. Verweise auf andere Tabellen entsprechen Verbindungen zwischen Objekten. Das eröffnet die Möglichkeit, wiederholte Daten zu vermeiden, was einerseits die Menge reduziert, aber noch wichtiger: die Realität besser abbildet.

Im obigen Beispiel wiederholt sich nicht nur die Adresse, sondern auch der Familienname.

Durch die Einführung einer neuen Tabelle namens "Familie" kann man diese Wiederholung vermeiden und außerdem der Tatsache Rechnung tragen, dass Familien in der Regel zusammen wohnen:

Normalisierte-Tabelle:

ID Vorname FamilienId

3

John

4

6

Jane

4

8

Jack

4

9

Jill

4

Links wird die obige Tabelle nochmals wiederholt, aber in normalisierter Form: Familie und Anschrift sind durch den Verweis der FamilienId auf Familie#4 gegeben. 

Dort sind diese Daten neben denen anderer Familien nur ein einziges mal gespeichert.

Zugehörige Familien-Tabelle:

ID Nachname Addresse Stadt Staat ZIP

...

...

...

...

...

...

4

Doe

569 Peach St.

Martin

TN

38237

... ... ... ... ... ...

Wie man sieht, gibt es Anschrift und Familienname nur noch einmal. Dadurch ergeben sich mehrere Vorteile:

  • Die Datenbank wird kleiner und schneller
  • Fehler in der Anschrift oder dem Familiennamen können nur einmal auftreten und zentral behoben werden (SPoC)
  • Sollte die Familie umziehen, muss nur ein einziger Eintrag geändert werden. Inkonsistenzen z.B. durch Vergessen eines Familienmitglieds können nicht auftreten.

Es mag erscheinen als ob dies eher menschliche Probleme sind, die bei Software nicht auftreten sollten, aber genau das passiert, wenn die Datenbank-Strukturen die reale Situation nicht (mehr) korrekt abbilden. Die Liste der Beispiele in denen Software-Benutzer durch fehlerhafte oder veraltete Strukturen gezwungen werden, Daten wiederholt einzugeben oder umständlich zu pflegen, ist endlos.

Beziehungs-Kardinalitäten: 1:1, 1:N, N:1 und N:M

Kardinalitäten beschreiben die Flexibilität der Relation: Sie beschränken, wie viele Zeilen der einen Tabelle mit wie vielen von der anderen Tabelle verknüpft werden können.

Wie unter Normalisierung gezeigt, entsteht eine Beziehung von Tabelle A zu Tabelle B, indem zu A eine Spalte (z.B. "B_ID") hinzugefügt wird, welche die eindeutigen Werte der Spalte B.ID enthält. Da jeder Wert aus B.ID in beliebig vielen Zeilen von A verwendet werden kann, entsteht eine von A nach B eine N(many A) zu 1(one B) Beziehung.

Umgekehrt besteht eine sog. "inverse" 1:N Beziehung von Tabelle B nach Tabelle A, die aber in Spoc-Web nicht separat verwaltet wird. Dieser Wechsel der Richtung/Perspektive entspricht in der Sprache dem Wechsel zwischen aktiver und passiver Satzform: Subjekt und Objekt wechseln in diesem Fall ihre Positionen und Rollen, das Verb wechselt zwischen aktiver und passiver Konjugation.

 

Sonderfälle: 1:0/1 und N:M Beziehungen

Eigentlich sind alle Beziehungen auf 1:N Beziehungen zurückzuführen. Folgende Spezialfälle sollten aber nochmals im Detail betrachtet werden:

  • A 1: B 0/1 Beziehungen entstehen wenn Tabelle B die Werte aus A.ID verwendet und zusätzlich eine Beschränkung für dessen Eindeutigkeit besitzt. Für jede Zeile von B muss es deshalb genau eine Zeile von A geben. Umgekehrt kann es aber Zeilen in A geben, auf die keine Zeile aus B zeigt. Jetzt können noch folgende Fälle unterschieden werden:
    • B.A_ID erlaubt 'null' Werte oder
    • B.A_ID muss immer befüllt sein. Dann kann man A_ID auch gleich als Primärschlüssel für B wählen. Diese Art der Beziehung wird oft für die Modellierung von Polymorphie in der objekt-orientierten Programmierung verwendet.
  • N:M Beziehungen sind nur Paare von zwei Beziehungen zu einer schmalen Tabelle in ihrer Mitte. Zwischen Tabelle A und B gibt es eine Tabelle P mit Paaren von Werten: A.ID und B.ID die jeweils auf die IDs von Tabelle A und B verweisen. Weil die Tabelle P nur zwei Spalten hat, wird sie bei High-Level Modellierungen oft übersprungen und die zwei 1:N und M:1 Beziehungen als eine M:N Beziehung dargestellt.
    Weil es beliebig viele Paare geben kann, können beliebige Kombinationen von Zeilen aus A und B entstehen.
    Beispiele sind u.a. die Teilnahme von Studenten an Kursen:
    • jeder Student kann mehreren Kursen teilnehmen
    • in jedem Kurs kann es mehrere Studenten geben.

Reine N:M Beziehungen sind ein eher seltener Sonderfall, denn meist ergeben sich im Laufe der Entwicklung weitere Daten, die für die Beziehung gespeichert werden müssen, wie z.B. die Dauer der Teilnahme am Kurs o.ä. und diese Werte können nur in der Tabelle P gespeichert werden. Sobald diese Zusatz-Daten auch Beziehungen enthalten, müssen auch Verweise auf die Tabelle P ermöglicht werden. Also erhält P eine technische ID, wodurch es seine eigene Identität erhält und zu einer vollständigen Tabelle/Klasse wird.

Die Rolle von Spalten-Einschränkungen

Spalten haben eine Menge von Eigenschaften. Neben dem Datentyp bestimmen vor allem die Einschränkungen (engl. "Constraints") ihre Bedeutung. Diese Einschränkungen werden nachfolgend beschrieben.

Null-Werte erlauben?

Relationale Datenbanken besitzen einen speziellen Wert "NULL", der gesetzt werden kann, um anzuzeigen, dass eine Zelle nicht befüllt, bzw. der Wert unbekannt ist. NULL kann jedem Datentyp zugeordnet werden, aber es ist ungleich jedem anderen Wert, selbst zu sich selbst, d.h. NULL <> NULL, anders als z.B. bei Programmiersprachen. Der Vergleich mit NULL liefert immer "falsch", weil man bei unbekannten Werten keine Aussagen treffen kann. Eigentlich erfordert dies auch eine ternäre Logik, die neben true und false auch NULL liefert, aber SQL bietet statt dessen besondere Operatoren: IS NULL und IS NOT NULL bzw. die Funktion isNull().

Nicht Null-Einschränkungen stellen sicher, dass in einer Spalte immer ein Wert eingetragen wird. Dies ist v.a. für Schlüssel-Spalten notwendig.

Eindeutigkeit / Uniqueness

Eindeutigkeits-Einschränkungen (engl. "Unique Constraints") stellen sicher, dass dieselben Werte nicht mehrmals in die angegebenen Spalten eingetragen werden.

Eindeutigkeit sollte für jeden Schlüssel eingestellt werden:

  • Für den technischen Schlüssel stellen sie sicher, dass Verweise eindeutig sind.
  • Für die fachlichen Schlüssel verhindert dies die Entstehung von  Dubletten

Gemäß SQL Standard kann man Unique Constraints auch mit Nullable Spalten definieren. Zeilen mit null-Werten sind dann von der Uniqueness ausgenommen, denn der Vergleich mit NULL liefert ja immer false (s.o.). SQL Server (Microsoft) erlaubt allerdings nur eine Zeile mit NULL, außer man aktiviert SET ANSI_NULL ON. Alternativ kann man dort auch einen "filtered Unique Index" setzen, der Zeilen mit NULL ignoriert.

Fremdschlüssel / Foreign Key (FK)

Fremdschlüssel-Einschränkungen stellen sicher, dass ein Verweis immer existiert. Sie erlauben in der Fremdschlüssel-Spalte nur NULL oder Werte, die in der referenzierten ID- Spalte erlaubt sind.

Umgekehrt verhindern Fremdschlüssel auch das Löschen von Zeilen oder Ändern von IDs, so lange Zellen auf sie zeigen. Statt das Löschen oder Ändern zu verhindern kann man allerdings auch folgende Optionen wählen:

Option Auswirkung
CASCADE löscht auch die Zeilen, welche auf die gelöschte verweisen. Allerdings sind Zyklen in den Verweisen meist nicht erlaubt. Diese Option ist auch riskant, weil ggf. große Mengen von Daten gelöscht werden. 
SET DEFAULT setzt die referenzierenden Zellen auf den Default-Wert für die jeweilige Spalte
SET NULL setzt die referenzierenden Zellen auf NULL
 --- verhindert das Ändern oder Löschen

Einschränkungen auf Fremdschlüssel-Spalten

Besonders wichtig sind Einschränkungen auf Fremdschlüssel-Spalten. Sie formen wesentlich die Kardinalitäten der erlaubten Beziehungen.

Die nebenstehende Tabelle zeigt die verschiedenen Kombinationen von Constraints für eine Fremdschlüssel-Spalte und die daraus entstehenden Beziehungen.

FK Unique Nullable Beziehung
X  X  X 0/1 : 0/1
X X  O 1 : 0/1
X O X 0/1 : N
X  O O 1 : N

Vorteile von Tabellen

Relationale Tabellen sind die Basis für die meisten Software Anwendungen. Sie sind sehr schnell und flexibel und können mit wesentlich größeren Datenmengen umgehen als semantische Speicher, sogenannte Triple- oder Quad-Stores, die Eigenschaften und Beziehungen verwalten. Sie sind auch in der Handhabung übersichtlicher:

  • Sie stellen Eigenschaften und Beziehungen in Spalten dar, so dass Sie Einträge schnell und nach wechselnden Kriterien vergleichen können.
  • Sie erlauben die Suche/Filterung und Sortierung der Einträge nach ihren Eigenschaften und Beziehungen
  • Tabellen unterstützen Sie und andere bei der Erfassung von Daten, indem sie ein Schema mit einem Kernbestand an Eigenschaften und Beziehungen vorgeben, das nur noch ausgefüllt werden muss.
  • Sie können Einschränkungen angeben, die während der Eingabe oder Datenpflege geprüft werden und die Qualität der Daten wesentlich erhöhen.
  • Tabellen-Spalten und die Verknüpfungen untereinander liefern einen sehr schnellen Überblick über das jeweilige Themengebiet, das sie beschreiben! Diese Modellierung ist in semantischen Speichern auch möglich, aber nicht intuitiv.