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.
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:
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.
ID | Spalte 2 | ... | Spalte N |
---|---|---|---|
1 | Zeile 1 | ... | ... |
... | ... | ||
m | Zeile m | ... | ... |
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 |
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.
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.
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.
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 |
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:
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.
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.
Eigentlich sind alle Beziehungen auf 1:N Beziehungen zurückzuführen. Folgende Spezialfälle sollten aber nochmals im Detail betrachtet werden:
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.
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.
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.
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:
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-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 |
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 |
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: