Tabellen als Relationen mit Attributen

• » Home
• »Sql-Tutorial
• » Verknüpfung von Tabellen

Eine denormalisierte Tabelle enthält pro Geschäftsvorfall eine Zeile und ist insofern mit einer freien schriftlichen Aufzeichnung vergleichbar. Wird diese Zeile auf einzelne Zellen aufgeteilt und werden den Spalten Namen zugewiesen, so spricht man davon, daß der Tabelle Attribute zugeordnet sind. Stimmen zwei Zeilen in allen Attributen überein, so kann eine Zeile entfernt werden, da in der Menge der Zeilen kein Element (= Zeile) doppelt vorkommen kann: Entweder handelt es sich um einen Eingabefehler oder es gibt bsp. tatsächlich zwei verschiedene Personen mit demselben Vor- und Nachnamen, dann muß ein zusätzliches Attribut eingeführt werden, welches die Eindeutigkeit jeder Zeile sicherstellt. Statt Tabelle wird in der eher mathematisch orientierten Literatur auch von Relation gesprochen: Ein Geschäftsvorfall stellt eine individuelle Relation zwischen verschiedenen Attribut-Werten dar.

Ein Schlüssel ist eine Menge von Attributen, mit dem eine Datenzeile eindeutig identifiziert werden kann. Ein Schlüssel-Kandidat ist ein Schlüssel mit minimaler Attribut-Anzahl. Eine Tabelle / Relation kann mehrere Schlüssel-Kandidaten haben. Ein Primär-Schlüssel ist ein beliebig ausgewählter Schlüsselkandidat. Besteht dieser aus mehreren Attributen, so wird er als zusammengesetzter Primärschlüssel bezeichnet. Ein Schlüssel-Attribut ist schließlich ein Attribut, das zu mindestens einem Schlüssel gehört, ansonsten handelt es sich um ein Nicht-Schlüssel-Attribut.

Ein Attribut B heißt funktional abhängig vom Attribut A, falls zu einem Wert von Attribut A höchstens ein Wert von B gehört. So sind Name (B) und Vorname (C) einer Person funktional abhängig von der Personalnummer dieser Person. Ein Attribut B heißt voll funktional abhängig vom Schlüssel A, falls B funktional abhängig ist von A, jedoch nicht schon funktional abhängig von einer Teilmenge von A ist. Besteht der Schlüssel A nur aus einem Attribut und ist B funktional abhängig von A, so ist B bereits voll funktional abhängig. Das Attribut C heißt transitiv abhängig von A, falls es ein Nicht-Schlüssel-Attribut B gibt, das funktional abhängig ist von A und von dem C funktional abhängt. Ein Attribut B kann, im Gegensatz zur funktionalen Abhängigkeit von A, auch mehrwertig abhängig von A sein. In diesem Fall gibt es mehrere Attribut-Werte B, die A zugeordnet sein können (Bsp.: mehrere Mailadressen einer Person).

Ziel der Normalisierung über die fünf Normalformen ist es, zunächst atomare Attribute einzuführen und anschließend die Mengen von Schlüsseln und Nichtschlüssel-Attributen so der Reihe nach zu identifizieren, daß alle redundanten Beziehungen herausgezogen und in einzelne Tabellen ausgelagert werden. Die oben definierten Begriffe der 'vollen funktionalen Abhängigkeit' sowie der Transitivität dienen dazu, Abhängigkeiten zwischen den Attributen aufzuspüren und solche Wiederholungen zwischen verschiedenen Attributen in neue Tabellen auszulagern. Das Ergebnis ist nicht mehr eine große, redundante Tabelle, sondern viele kleine und schmale Tabellen, die durch verschiedenste Beziehungen miteinander verknüpft sind. Für diese Beziehungen wird - leider - oftmals ebenfalls der Begriff Relation verwendet, so daß dieser Begriff sowohl für Tabellen als auch für Beziehungen zwischen Tabellen genutzt wird. Jede dieser Einzel-Tabellen kann um einen eigenen zusätzlichen Primärschlüssel ergänzt werden, der als ganze Zahl implementiert, dessen Wert vom Datenbanksystem festgelegt und beim Einfügen neuer Datensätze automatisch hochgezählt wird. Wird in einer anderen Tabelle auf diese Tabelle bezug genommen, so genügt es, eine zusätzliche Spalte einzufügen und diese als Fremdschlüssel (foreign key) zu deklarieren.

Einschränkungen auf der Ebene von Spalten

Für eine einzelne Spalte können - unabhängig voneinander - zwei Einschränkungen deklariert werden:

• Nicht Null / Not Null: Ein solches Feld darf nicht leer sein, es muß auf jeden Fall einen Wert erhalten.
• Eindeutigkeit / UNIQUE: Jeder Wert in dieser Spalte muß innerhalb der Spalte eindeutig sein.

In beiden Fällen genügt es, das Feld bei der Erstellung mit diesen Eigenschaften zu deklarieren bzw. bei einer bereits definierten Tabelle die Felddefinition zu ändern. Ab dann überprüft das DBMS bei jedem Einfügungs- und Aktualisierungsversuch, ob die gesetzten Bedingungen durch den neu einzufügenden oder zu ändernden Datensatz mißachtet werden und verhindert die auslösende Operation gegebenenfalls.

Ist die Spalte als Primärschlüssel deklariert, so sind implizit beide Sondereigenschaften gesetzt: Ein Primärschlüssel darf nicht leer sein und er muß eindeutig sein. Denn der Wert einer Primärschlüssel-Zelle ist für diese Zeile eindeutig, damit sind mehrere leere oder doppelte Werte ausgeschlossen.

Beziehungen zwischen Tabellen

Stehen mehrere Tabellen zueinander in Beziehung, so sind verschiedene Szenarien denkbar:

• Basis- und Detail-Tabelle in einer 1:n-Beziehung: Zu einem Datensatz in der Basistabelle kann es keinen, einen oder mehrere Datensätze in der Detailtabelle geben. Die Detailtabelle enthält mehrwertige Attribute zur Basistabelle.

  So sollen zu Mitarbeitern Mailadressen hinzugefügt werden. Die Tabelle der Mitarbeiter verwendet einen eigenen, zahlbasierten Primärschlüssel, da weder Nachname noch Nachname + Vorname eindeutig sind. Es soll jedoch möglich sein, einem Mitarbeiter keine, eine oder mehrere Mailadressen zuzuweisen. Würde für jeden Mitarbeiter höchstens eine Mailadresse erfaßt, so würde es genügen, der Tabelle 'Mitarbeiter' eine weitere Spalte hinzuzufügen. Da jedoch beliebig viele Adressen zulässig sein sollen, wird eine Detailtabelle benötigt.

  Basistabelle tbl_Mitarbeiter:

  Mitarbeiter-ID	Name	Vorname
  15	Maier	Horst
  16	Schmidt	Susanne
  18	Schmidt	Frank

  Detailtabelle tbl_MailAdressen mit Fremdschlüssel von Mitarbeiter-Id auf die gleichnamige Primärschlüsselspalte in tbl_Mitarbeiter:

  ID	Mitarbeiter-Id	eMail
  2	15	horst.maier@mustermann-ag.de
  3	15	abt-1@mustermann-ag.de
  4	15	maier@privatadressen-erdbewohner.de
  5	18	frank.schmidt@mustermann-ag.de

  Damit wurden Horst Maier drei und Frank Schmidt eine Mailadresse zugewiesen, für Susanne Schmidt wurde keine Mailadresse aufgenommen.

• Zwei Basis-Tabellen werden in einer Detail-Tabelle durch eine n:m-Beziehung verknüpft: Es gibt zwei voneinander unabhängige Basis-Tabellen und es gibt Geschäftsvorfälle, bei welchen genau einem Datensatz der ersten Tabelle genau ein Datensatz der zweiten Tabelle zugewiesen wird. Jeder Datensatz aus jeder Basistabelle kann beliebig oft an Geschäftsvorfällen teilnehmen. Die n:m - Beziehung wird also aufgelöst in eine 1:m sowie in eine n:1 - Beziehung.

  Die Mitarbeiter der obigen Tabelle pflegen Kundenkontakte, jeder Kundenkontakt soll mit Datum und Notiz aufgezeichnet werden. Ein Mitarbeiter kann viele Kunden beraten, ein Kunde kann mit vielen Mitarbeitern Kontakt haben.

  Basistabelle tbl_Kunden:

  Kunden-ID	Name	Vorname
  30	Müller	Silvia
  35	Becker	Karl

  Detailtabelle tbl_Kundenkontakte mit Fremdschlüssel-Einschränkungen von Mitarbeiter-Id auf tbl_Mitarbeiter sowie von Kunden-Id auf tbl_Kunden:

  ID	Mitarbeiter-Id	Kunden-Id	Datum	Notiz
  2	16	35	20.04.2004	Erstgespräch
  3	15	35	22.04.2004	Tel. Verschiebung
  4	16	30	25.04.2004	Besichtigung
  5	16	35	28.04.2004	Vertragsunterzeichnung

  Hier hat der Kunde Karl Becker drei Kontakte, zwei mit der Mitarbeiterin Susanne Schmidt sowie ein Telefonat mit Horst Mayer. Mitarbeiterin Susanne Schmidt führt ferner eine Besichtigung mit Kundin Silvia Müller durch.

• Eine Basis-Tabelle muß um diverse Spalten ergänzt werden, die Zellen bleiben jedoch für viele Zeilen leer. In diesem Fall ist es besser, eine zweite Tabelle zu definieren und diese durch eine 1:1-Beziehung mit der ersten Tabelle zu verknüpfen. Nun werden in der Randtabelle nur zu jenen Zeilen der Basis-Tabelle neue Zeilen eingefügt, falls zu dem Basis-Datensatz jene speziellen Informationen aufzuzeichnen sind:

  Es gibt die Tabelle tbl_Mitarbeiter mit sämtlichen Mitarbeitern (festangestellte und freie) und ihren Grunddaten. Zu den festangestellten Mitarbeitern sollen zusätzlich das Eintrittsdatum sowie Gehaltsinformationen abgelegt werden.

  Randtabelle tbl_MitarbeiterInfos:

  Mitarbeiter-ID	Eintritt	Stufe
  15	01.01.2000	XI-2
  16	01.05.2001	X-3

  Hier wird die Spalte Mitarbeiter-Id zusätzlich (1) als Primärschlüssel sowie (2) als Fremdschlüssel auf die Tabelle tbl_Mitarbeiter deklariert, es existiert keine Spalte vom Typ Auto-Wert. Durch die Auszeichnung als Primärschlüssel ist gewährleistet, daß zu jedem Mitarbeiter höchstens ein Eintrag in tbl_MitarbeiterInfos existiert. Die Definition als Fremdschlüssel stellt sicher, daß nur gültige Mitarbeiter-Id's verwendet werden.

  Mitarbeiter Nr. 18 / Frank Schmidt ist freier Mitarbeiter, für ihn existiert kein Eintrag in tbl_MitarbeiterInfos.

Konsequenzen bei der Nutzung von Fremdschlüssel-Einschränkungen

Werden bei der Definition einer Tabelle Fremdschlüssel-Einschränkungen verwendet, so gelten zusätzlich die folgenden Regeln:

• Das Ziel der Fremdschlüsseleinschränkung muß eine Spalte sein, die in der Basis-Tabelle Primärschlüssel ist. Denn ein Fremdschlüssel bedeutet, daß zur aktuellen Zeile genau eine Zeile der Basistabelle zugeordnet wird, folglich muß diese eindeutig identifizierbar sein.
• Das DBMS stellt sicher, daß in die mit einem Fremdschlüssel definierte Spalte der Detailtabelle nur Werte eingetragen werden können, welche bereits in der Basistabelle existieren.
• Ein Datensatz in der Basistabelle, dessen ID bereits in der Detailtabelle genutzt wird, kann nicht mehr gelöscht werden. Um ein Löschen zu ermöglichen, müssen zunächst alle auf dieser ID basierenden Detail-Datensätze gelöscht werden. Ausnahme: Das DBMS unterstützt kaskadierendes Löschen und diese Option wurde beim Erstellen des Fremdschlüssels aktiviert. In diesem Fall führt ein Löschen einer Zeile in der Basistabelle zum automatischen Löschen aller Detail-Zeilen.
• Im Regelfall können Spalten, die zu Fremdschlüssel-Bezügen gehören, nicht umbenannt oder gelöscht werden. Zunächst muß der Fremdschlüssel gelöscht und nach der Umbenennung wieder neu deklariert werden.
• Da über Fremdschlüssel-Spalten bei späteren Abfragen Tabellen wieder mit dem JOIN-Operator verknüpft werden, sind Fremdschlüssel-Spalten gute Kandidaten für Indizes zur Verbesserung der Leistung.