Datenbanken Schlüssel, Normalform

Schlüssel

Stets ist die Menge aller Attribute der Tabelle ein Schlüssel­kandidat.

In diesem Beispiel ist die Attributmenge {Inhaber, Kontonr} kein Schlüssel­kandidat. Zwar lässt sich in der aktuell vorliegenden Tabelle jede Zeile durch diese Attribute eindeutig identifizieren. Es ist jedoch nicht ausgeschlossen, dass das DRK unter der leicht zu merkenden Nummer 414141 auch noch ein Konto bei der Deutschen Bank einrichtet.

Die Eigenschaft "Schlüssel­kandidat" bezieht sich also nicht auf die aktuellen Einträge in der Tabelle, sondern auf sämtliche möglichen Einträge - unter Berück­sichtigung der Gegebenheiten der realen Welt.

In obigem Beispiel gehen wir etwa davon aus, dass zwei verschiedene Inhaber nicht dasselbe Konto haben können, sonst wäre die Attributmenge {Kontonr, Bank, Blz} kein Schlüssel­kandidat.

Schlüssel sind also minimale identifizierende Attributmengen. Eine Tabelle kann unter­schiedliche Schlüssel haben. Ein Schlüssel wird als Primär­schlüssel ausgezeichnet; die anderen möglichen Schlüssel heißen alternative Schlüssel.

Wiederum bezieht sich die Eigenschaft "Schlüssel" nicht auf die aktuellen Einträge in der Tabelle, sondern auf sämtliche möglichen Einträge. Hier gehen wir davon aus, dass durch Angabe von Kontonr und Blz ein Konto eindeutig identifizierbar ist.

Ist {Kontonr, Blz} als Primär­schlüssel ausgezeichnet, so sorgt das Datenbank­system dafür, dass keine neuen Zeilen eingetragen werden können, wenn die Primär­schlüssel­attribut­werte schon belegt sind. So würde das Datenbank­system etwa verhindern, dass die Zeile (Müller, 190032, Kieler Sparkasse, 210 501 70) aufgenommen wird.

Jede Tabelle hat einen Schlüssel, aber nicht unbedingt einen echten Schlüssel.

 

Beziehungen

Schlüssel, die aus mehreren Attributen bestehen, sind problematisch. So ist für die Darstellung der Beziehung VERWANDT untenstehende Tabelle erforderlich, in der die Schlüssel der beteiligten Personen als Fremdschlüssel (Attribute, die in einer anderen Tabelle Schlüssel sind) auftreten. Ändert sich der Name einer Person, etwa durch Heirat, so ist eine entsprechende Änderung nicht nur in der Tabelle PERSON, sondern auch in der Tabelle VERWANDT nötig.

Es ist daher sinnvoll, ein weiteres Attribut Nummer als künstlichen Schlüssel einzuführen. Nummer dient also quasi als Zeiger auf eine bestimmte Person. Die Person wird also durch diesen Zeiger eindeutig identifiziert und nicht durch ihre Eigenschaften wie Name, Vorname und Geburtsdatum, die sich möglicherweise ändern können oder die auch möglicherweise für zwei verschiedene Personen übereinstimmen können. Dies ist der Grund dafür, dass wir Personal­nummern, Matrikel­nummern, Sozial­versicherungs­nummern, Mitglieds­nummern, Kunden­nummern usw. haben, über die wir in den unter­schiedlichen Datenbanken identifiziert werden.

Die Beziehung VERWANDT reduziert sich dadurch auf folgende Tabelle:

 

Normalform

Tabellen können zunächst beliebig aufgebaut sein. Ein Ziel im Datenbank­konzept ist es jedoch, die Daten frei von Redundanz zu speichern. Dies ist gewährleistet, wenn sich die Tabellen in der sogenannten Boyce-Codd-Normalform befinden.

Die Boyce-Codd-Normalform lässt sich mithilfe der Begriffe Projektion und Schlüssel charakterisieren.

Zur Erinnerung: Durch Projektion können Spalten einer Tabelle ausgewählt werden. Das Ergebnis dieser Operation ist wieder eine Tabelle. Mehrfach auftretende Zeilen dieser Tabelle werden nur einmal aufgeführt, denn die Zeilen der Tabelle müssen eine Relation bilden. Eine Relation ist aber eine Menge, und eine Menge kann nur unter­schiedliche Elemente enthalten.

Zu beachten ist, dass es sich um einen echten Schlüssel handeln muss. Als eigenen Schlüssel einer Projektion bezeichnen wir eine Attributmenge, die nicht auch Schlüssel der ganzen Tabelle ist.

Als Beispiel betrachten wir die Tabelle KONTO.

Diese Tabelle ist nicht in Boyce-Codd-Normalform. Um dies zu zeigen, müssen wir also eine Projektion der Tabelle finden, die einen eigenen echten Schlüssel hat.

Folgende Tabelle ist die Projektion der Tabelle KONTO auf die Spalten {Bank, Blz}. Mehrfach auftretende Zeilen werden nur einmal aufgeführt.

Das Attribut {Blz} ist offenbar ein Schlüssel dieser Projektion, und sogar ein echter Schlüssel, denn er besteht nicht aus allen Attributen der Projektion. Das Attribut {Blz} ist aber kein Schlüssel der gesamten Tabelle KONTO, sondern ein eigener Schlüssel der Projektion. Damit ist die Tabelle nicht in Boyce-Codd-Normalform.

Immer wenn eine Projektion vorhanden ist, die einen eigenen echten Schlüssel hat, ist dies ein Indiz dafür, dass beim Datenbank­entwurf die Entities nicht klar identifiziert wurden. In dem Beispiel ist "Bank" eine eigene Entity.

Zerlegung

Um eine redundanzfreie Speicherung der Daten zu erzielen, wird die Tabelle KONTO wie folgt in zwei Tabellen zerlegt. Die ursprüngliche Tabelle kann dann durch einen Verbund der beiden Tabellen wieder zurückgewonnen werden.

KONTO  Inhaber Kontonr BankId Meyer 602201 1 DRK 414141 2 Meyer 190032 3 Schmidt 175060 3

BANK  Id Name Blz 1 Postbank Hamburg 200 100 20 2 Commerzbank Kiel 210 400 10 3 Sparkasse Kiel 210 501 70

Der Verbund dieser beiden Tabellen wird durch folgendes SQL-Kommando realisiert; Ergebnis ist die ursprüngliche Tabelle:

Durch SELECT Name AS Bank wird die Spalte Name ausgewählt und in der Ergebnis­tabelle mit der Bezeichnung Bank versehen (so wie es in der ursprünglichen Tabelle KONTO war).

 

 

Weiter mit:   [Literatur]   oder  

 

H.W. Lang   FH Flensburg   lang@fh-flensburg.de   Impressum   ©   Created: 08.11.1999   Updated: 10.01.2008