HFWI8512 :: Datenstrukturen_Datenbanken

Bei einem Primärschlüssel handelt es sich um die Spalte (oder Spalten) einer Tabelle, mit der oder denen sich die Zeilen dieser Tabelle eindeutig identifizieren lassen.

KUNDEN

Kundennr.    Vorname      Nachname

1                   Sally            Thompson

2                   Sally           Henderson

3                  Harry           Henderson

4                  Sandra         Wellington

In dieser Tabelle ist beispielsweise „Kundennr.“ der Primärschlüssel.

Die Werte in den Spalten für Primärschlüssel müssen für jede Zeile eindeutig sein – Duplikate sind nicht zulässig. Außerdem dürfen sich in den Spalten für Primärschlüssel  keine Nullen befinden.

Bei „Fremdschlüsseln“ handelt es sich um Spalten, die auf Spalten mit Primärschlüsseln verweisen. So ist beispielsweise „Auftragsnr.“ der Primärschlüssel für die Tabelle AUFTRÄGE unten. Bei „Kundennr.“ handelt es sich damit um einen Fremdschlüssel, der auf den Primärschlüssel in der Tabelle KUNDEN verweist.

Falls man es ganz genau nimmt, müssen Fremdschlüssel nicht unbedingt auf einen Primärschlüssel verweisen. Die einzig echte Anforderung für eine Spalte, auf die ein Fremdschlüssel verweist, ist: Sie muss eindeutige Werte enthalten. 

1:n Beziehungen 

z.B. in einer Buchhandlung wird in der Datenbank verwaltet, dass ein Buch von einer Person ausgeliehen wird. Natürlich sind auch andere Beziehungen möglich. 

Jetzt wird es vorkommen, dass wir an eine Person mehr als ein Buch verleihen. Wir müssen also in unserer Tabelle eine 1:n Beziehung abbilden können.

Schon ist es bei den Tabellen und Datenbanken vorbei mit der Monogamie. Eine Person kann viele Bücher haben, aber jedes Buch kann sich gerade nur bei einer Person befinden – also 1 zu n.

_____________________

n:m Beziehungen

Komplexer wird es, wenn wir Beziehungen haben, die einen Mehrfachtatbestand erfüllen. Ich kann den Adressen nun z.B. besuchte Kurse (Unterrichtsfächer, Studienkurse, ...) zuordnen. Jede Person kann mehrere Kurse besuchen. Und jeder Kurs kann verschiedene Personen als Teilnehmer beinhalten. Das ergibt eine n:m Beziehung.

mathematisch gesehen:
1 Person kann 0,1 oder n Kurse besuchen
1 Kurs kann 0,1 oder m Teilnehmer haben

Normalisierung – logische Regeln zur Minimierung von Redundanz

Durch die Normalisierung und die strengen Regeln soll eine korrekte, relationale Datenbank aufgebaut werden bzw. diese erhalten bleiben. Dabei ist wichtig, dass Redundanzen vermieden werden, da diese sonst schnell bei Änderungen von Inhalten zu Inkonsistenzen führen.

Dabei bedeutet Redundanz (lateinisch redundare „im Überfluss vorhanden sein“) auf Deutsch Doppelung bzw. Überschneidungen.

Inkonsistenzen bedeutet: Widersprüchlichkeit oder Unbeständigkeit der eingegebenen Daten.

Erste Normalform (1 NF)

Jedes Datenfeld darf nur gleichartigen Inhalt enthalten (Beispiel: aus einem Datenfeld „Name“ entstehen zwei Datenfelder: eines für den Vornamen und eines für den Nachnamen). Dies wurde im Kapitel „Daten strukturieren – Vorüberlegungen zur Datenbankerstellung“ als Inhalte trennen (atomisieren) bezeichnet.

Beispiel:

Aus dem Feld „name“ mit dem Inhalt „Erika Schmidt“ werden die 2 Datenbankfelder „vorname“ und „nachname“. Das Feld „vorname“ bekommt als Inhalt „Erika“ und das Feld „nachname“ den Inhalt „Schmidt“.

Mit gleichartig ist hier gemeint, dass im Feld „vorname“ dann durchaus auch 2 Vornamen auftauchen: „Karl Heinz“. 

Für die Tabelle muss ein Primärschlüssel vorhanden sein, damit jeder Datensatz eindeutig angesprochen werden kann.

Zweite Normalform (2 NF)

Die erste Normalform muss erfüllt sein! Erst wenn die erste Normalform erfüllt ist, kann man an die Anwendung der zweiten Normalform gehen.

Die 2. Normalform besagt: Jeder Datensatz bildet nur einen Sachverhalt ab. Liegen in einer Tabelle Daten vor, die nicht nur 1 Sachverhalt abbilden, werden diese Daten in einzelne thematische Tabellen unterteilt.

Dritte Normalform (3 NF)

Die erste und zweite Normalform muss erfüllt sein! Erst wenn die 1. und 2. Normalform erfüllt ist, kann man an die Anwendung der 3. Normalform gehen.

Bei der dritten Normalform geht es den indirekten (transitiven) Abhängigkeiten an den Kragen. In der Fachliteratur wird von transitiven Abhängigkeiten gesprochen.

Zum Beispiel haben wir in einer Tabelle neben Namen auch PLZ und Ort. Zu jedem Namen gehört eine PLZ und zu jeder PLZ gehört ein Ort. Der Ort ist also indirekt vom Namen abhängig.

Mathematisch ausgedrückt sieht das so aus:

„wenn NAME -> PLZ“ und „PLZ -> ORT“ dann „Name -> ORT“.

„Name -> ORT“ ist also eine transitive Abhängigkeit

Wir wollen aber in der Tabelle nur direkte Abhängigkeiten (also intransitive), weswegen das ganze auseinandergepflückt werden darf. 

Entity Relationship Modell (ERM)

Um die Strukturen von Daten und den Datenbankaufbau abzubilden, gibt es das Entity Relationship Modell (ERM). Durch das Modell kann die Struktur einfach anderen aufgezeigt werden (und gegebenenfalls in Arbeitsgruppen diskutiert werden). Es ist also ein konzeptionelles Arbeitsmittel.

Aber selbst wenn man alleine eine Datenbankanwendung erstellen, kann dieses Modell hilfreich sein, wenn man später sich nochmals schnell den Aufbau vor Augen führen möchten.

Grundbegriffe: Entity, Relationship und Attribute

Folgende Begriffe finden in der ERM Anwendung:

Entity:

Entität ist ein Objekt der modellierten Welt, das i.d.R. ein Gegenstand der realen Welt abbildet, wie beispielweise ein Buch (für eine Bücherverwaltung), eine Person (für die Adressverwaltung), eine Zeugnis-Note (für die Notenverwaltung).

Relationship:

Stellt die Beziehung zwischen Entitäten her, beispielweise das Buch wurde von dem Autor Schmidts geschrieben.

Attribut:

Jede Entität hat verschiedene Attribute, z. B. ein Buch hat ein Erscheinungsdatum, einen Verlag, eine Auflage.

Grafische Darstellung vom Entity Relationship Modell (ERM)

Um die Zusammenhänge zwischen Entitäten, Beziehungen und Attribute darzustellen, werden folgende Symbole verwendet:

Entity: ein Rechteck
Attribute: werden unter dem Rechteck in Rechtecken mit gerundeten Ecken angezeigt
Relationship: Die Beziehungen werden anhand von Rauten zwischen den Entitäten angezeigt.

1. Nur Beziehungen vom Typ 1 -c, 1-n, 1-mc
2. Jede Entitätsmenge im ERD (Entity Relationship Diagramm) braucht einen Attributskatalog (wie z.B. Kunde, Auftrag, Artikel usw.)
3. Jede Entitiätsmenge braucht einen eindeutigen Primärschlüssel
4. Jede Beziehung (pro Beziehung) braucht einen Fremdschüssel (entspricht dem Primärschlüssel einer anderen Tabelle/Entitätsmenge -> immer auf der Gegenseite! 1-mc usw.)
5. Jedes DB Modell ist in 3.Normalform!