8 Primärschlüssel, Fremdschlüssel und Index

Betrachten wir im Folgenden Ihre Situation in der Berufsschule und in Ihrem Lehrbetrieb. Wir konzentrieren uns dabei auf die Datenhaltung in unserer Schule.

Achtung: Die folgenden Inhalte beziehen sich ausschliesslich auf relationale Datenbanken (MySQL / MSSQL / Oracle usw.)!

8.1 Lernziele

Jede/r Lernende:

  • …kann in eigenen Worten beschreiben was ein Primärschlüssel ist
  • …kann in eigenen Worten beschreiben was ein Fremdschlüssel ist
  • …kann Primärschlüsselkandidaten aus einem Datensatz bestimmen
  • …kann 1 x mc-Relationen in einem ERM-Diagramm abbilden
  • …kann mc x mc-Relationen in einem ERM-Diagramm abbilden

8.2 Ausgangssituation

Sie sind als Lernende in unserer Schule angemeldet. Dabei wurden die Daten Namen, Adresse, Telefonnummer von Ihnen gespeichert. Zusätzlich wurden Sie mit einem Kürzel ausgestattet. Ihre Lehrmeister, mit Namen, Telefonnummer und Email, befinden sich ebenfalls in dieser Datenbank. Natürlich wurde auch die Verbindung von Ihnen mit Ihrem Lehrmeister gespeichert.

Daneben werden in der Datenbank Klassen administriert. Von Klassen wird grundsätzlich nur der Kürzel gespeichert. Ebenfalls werden Sie als Lernender einer Klasse zugeordnet.

8.3 ER-Diagramm

Die Ausgangslage führt zu folgendem ER-Diagramm:

Ausgangslage

Figure 8.1: Ausgangslage

8.4 Primärschlüssel

PrimaryKey (PK):
Der Primärschlüssel ist eine Spalte in der Tabelle, durch die eindeutig jede Zeile identifiziert wird (gerne mit dem Namen ID). Es kann auch eine Kombination von Spalten als eindeutig festgelegt werden; das ist aber selten sinnvoll. In der Regel sollte diese Spalte auch keine andere “inhaltliche” Bedeutung haben als die ID.

Das Relationenmodell fordert, dass jede Tabelle ein Attribut oder eine Attributkombination enthält, über die jeder Datensatz eindeutig identifiziert werden kann. In der Praxis kommen Attribute, die in jedem Fall eindeutig sind, selten vor. Beispiele wären Autonummern oder eine Kombination aus Bankleitzahl und Kontonummer. Oft werden daher zusätzliche Attribute definiert, welche die Datensätze fortlaufend oder nach einem Nummernkreis durchnummerieren. Sie können vor dem Benutzer verborgen bleiben und nur der internen Datenbankverwaltung dienen oder sichtbar sein, wie zum Beispiel Artikel- oder Kundennummer.

Solche eindeutigen Felder werden auch auf der physikalischen Ebene benötigt und dienen unter anderem dem schnellen Auffinden von Datensätzen in grossen Tabellen. Sie werden Primärschlüssel genannt. Eine Tabelle kann nur einen Primärschlüssel haben. Die Tabelle erscheint nach diesem Schlüssel sortiert. Ein Primärschlüssel ändert während der gesamten Existenz eines Datensatzes seinen Wert nicht.

Der Primärschlüssel wird speziell gekennzeichnet, z. B.fett, eine spez.Farbe (meist rot) oder doppelt unterstrichen. Es kann auch vorteilhaft sein bei der Benennung ein p voran zu stellen.

Beispiel: pKundenNR

Um jetzt also in unserem Klassenbeispiel die Primärschüssel zu finden, gehen wir wie folgt vor:

Der Primärschlüssel muss den Datensatz eindeutig identifizieren

Folgende Primärschlüssel machen Sinn:

  • Klasse -> Attribut Klassenkuerzel
  • Lerndender -> Attribut Kuerzel
  • Lehrmeister -> Attribut Name

8.5 Fremd-Schlüssel

ForeignKey (FK):
Über Fremdschlüssel werden die Tabellen miteinander verknüpft. Einem Feld in der einen Tabelle wird ein Datensatz in einer anderen Tabelle zugeordnet; dieser wird über den Primärschlüssel bereitgestellt. Es kann auch eine Kombination von Spalten verwendet werden; da sich der Fremdschlüssel aber auf einen Primärschlüssel der anderen Tabelle beziehen muss, ist dies ebenso selten sinnvoll. Die “Datenbank-Theorie” geht sogar soweit, dass die Schlüsselfelder dem Anwender gar nicht bekannt sein müssen.

Ein Fremdschlüssel ist ein Feld in einer Relation, welches eine Beziehung zu einem Schlüsselfeld einer anderen Relation herstellt. Beispielsweise befindet sich in einer Relation Aufträge in jedem Datensatz eine Kundennummer des Kunden, der den Auftrag ausgelöst hat.

Diese Kundennummer identifiziert einen Kunden in der Kundenrelation eindeutig. Die Kundennummer in der Auftragsrelation stellt somit einen Fremdschlüssel (“fremder” Schlüssel einer anderen Relation, wo er Primärschlüssel ist) dar.

Fremdschlüssel werden einfach unterstrichen gekennzeichnet, auch kursiv ist gebräuchlich! Empfehlenswert ist auch hier ein Präfix zu verwenden.

Fremdschlüssel dienen also dazu, “fremde” Primärschlüssel als Verbindung einzutragen.

Beispiel: fKundenNr

Ziel ist:

Die Relationen gemäss den Kardinalitäten abzubilden.

8.6 Relation -> 1 x mc abbilden (Lernender - Lehrmeister)

Die Interpretation dieser Relation bedeutet:

Es gibt offenbar eine Reihe von Lehrmeister, die mehrere oder keine Lernenden betreuen können. Jeder Lernende besitzt genau einen Lehrmeister.

Um dieses Beispiel jetzt im Datenmodell abzubilden, wird auf der Entität “Lernenden” ein zusätzliches Attribut erfasst:

FK_lehrmeister

Der Typ des Attributs entspricht dem Primärschlüssel der Entität “Lehrmeister”. Wurde also bei uns der Lehrmeister über den Namen identifiziert (was eigentlich nicht so clever ist), wird der Name als auch auf dem Lernenden als Fremdschlüsselbeziehung zum Lehrmeister eingetragen.

Folgendes Bild zeigt die Erweiterung mit dem Attribut FK_lehrmeister:

Lernender - Lehrmeister

Figure 8.2: Lernender - Lehrmeister

Damit wird jetzt also jedem Lernenden-Tupel noch zusätzlich mitgespeichert, wie der Name des Lehrmeisters lautet. Und da das für alle Lernenden möglich ist, können auch mehrere Lernenden den selben Lehrmeister besitzen.

Praktisch sieht das so aus:

Lernender - Lehrmeister mit Daten

Figure 8.3: Lernender - Lehrmeister mit Daten

Fragen:

  • Welche Lernende gehören zu welchem Lehrmeister?
  • Welcher Lehrmeister besitzt keine Lernenden?

8.6.1 Relation -> 1 x 1 abbilden

Die 1 x 1 Relation bildet hier nur ein Spezialfall der 1 x n Relation. Bei der 1 x 1 -Relation werden einfach auf beiden Entitäten ein FK-Attribut eingeführt.

8.7 Relation -> mc x mc abbilden (Klasse - Lernender)

Die 1 x mc-Beziehung war noch relativ einfach - jetzt wirds ein bisschen komplizierter. Wenn wir jetzt die Relation zwischen Lernenden und Klassen abbilden wollen, müssen wir beachten, dass Lernende grundsätzlich in mehreren Klassen sein können. Und eine Klasse besteht aus mehreren Lernenden.

Damit wird diese Relation abbilden können, müssen wir eine Zwischentabelle RelationKlasse einführen. In ihr werden jetzt alle Relationen als Kombination zwischen Primärschlüsseln der Entitäten abgebildet.

Aber langsam : zuerst das Bild.

Klassen - Lernender

Figure 8.4: Klassen - Lernender

Auch das kann jetzt noch ein bisschen “hirnverknotend” sein…darum unser Beispiel:

Lernender - Lehrmeister mit Daten

Figure 8.5: Lernender - Lehrmeister mit Daten

Fragen:

  • Welche Lernende sind in zwei, oder mehr Klassen?
  • Welche Lernende sind nur in einer Klasse?
  • An wie viele Klassenevents muss der Lehrmeister “NameLM2” gehen? Welche?

8.8 Abschluss und Feststellungen

Folgende Dinge gilt es festzuhalten:

Die anderen Kardinalitäten sind als Spezialformen der genannten 1 x mc-Relationen und mc x mc-Relationen zu sehen.

Sind in einem ER-Diagramm (Entitäten und Attribute) alle Zwischentabellen vorhanden und aufgelöst, spricht man von einem ERM-Diagramm (Entity Relationship Modell)

Die Überführung aus mc x mc-Relationen mittels Zwischentabellen, ist nur für relationale DBMS nötig.