silvesterlangen.de

Seite

Datenbank planen

Entity Relationship Model (ERM) oder Entity Relationship Diagram (ERD)

Bevor wir darüber nachdenken mit Datenbanken zu arbeiten, müssen wir erst einmal lernen eine Datenbank zu planen. Wo werden welche Daten gespeichert und wieso ist das so? Warum speichere ich nicht die Kundendaten zusammen mit den Passwörtern in der gleichen Tabelle und was ist ein Primärschlüssel? Diese Fragen klären wir jetzt und bauen uns die erste kleine Datenbank zur Speicherung von Kontaktdaten.

Wie speichere ich Daten?

Wer hat es denn schon nicht mal gemacht... Die Kontaktdaten seiner Freunde etc in einer Exceldatei gespeichert. Vermutlich sah das dann so oder so ähnlich aus wie hier.

Name, Vorname | Adresse | TelNr | Mail | Geburtstag ...

Solange die Liste klein ist, ist alles gut. Eine Aktualisierung der Liste sollte kein Problem sein. Was aber, wenn die Liste mehrere tausend Kontakte beinhaltet? Wie groß ist die Gefahr, dass der beste Kumpel oder die Oma mehrfach in der Liste vorkommt. Schlimmer noch: Einige Kontakte sind nicht nur mehrfach drin, die Einträge widersprechen sich sogar. Mal wohnt die Oma in der Weingartenstraße 15, ein paar Einträge weiter wohnt sie in der Münchener Straße 542a. Die Einträge des besten Kumpels sind mehrfach vorhanden und jedes mal eine andere Telefonnummer. Die Daten sind redundant. Das bedeutet, dass sie mehrfach vorhanden sind. Zwar ist in der IT Redundanz etwas Gutes, allerdings in Datenbanken eher ein Problem, was man verhindern muss.

Man muss zugeben, dass eine solche Liste wie oben beschrieben, schneller außer Kontrolle geraten kann als einem lieb ist. Diese Liste denn noch korrekt zu pflegen ist mit einem hohen Aufwand verbunden und macht mehr Arbeit als sie Nutzen bringt.

Daten korrekt speichern

Das bedeutet die Daten in kleinstmögliche Einheiten zu zerlegen und dafür Sorge zu tragen, dass sie "atomar" sind. Also jede Einzelinformation für sich und diese Information muss je Spalte immer gleicher Art sein.

Um beim Beispiel Kontaktdaten zu bleiben stellen wir uns folgende zwei Tabellen vor.

Tabelle: Person

Kontakt_id	Vorname	Nachname
1	Bert	Meyer
2	Tatinka	Schmidt

Tabelle: Telefon

Kontakt_id	Telefon	E-Mail
1	123456	meyer@t-offline.de
2	98745	t-schmidt@waeb.de
2	8566661	tati@r-byte.job

Bei Tabelle Person haben wir den Namen in Vorname und Nachname zerlegt und eine Kontakt_id vergeben mit der die Person eindeutig identifiziert wird. Diese ID lässt sich nun in weiteren Tabellen verwenden.

Bei der Tabelle Telefon speichern wir die Telefonnummer(n) und ggf. auch weitere Kontaktdaten. Mit der ID sorgen wir für die Zuordnung zur richtigen Person. Nun haben wir den Vorteil, dass wir alle Kontaktdaten in einer eigenen Tabelle haben und dort nur ein mal pflegen müssen. Bekommt Tatinka eine weitere Telefonnummer oder ändert sie sich bzw. die Mailadresse, dann ist muss man die Daten nur an einer einzigen Stelle ändern. Heiratet Tatinka und nimmt den Namen des Mannes an, dann ändern wir nur in einer Tabelle den Nachnamen. Die Zugehörigkeit ihrer weiteren Daten ändert sich desshalb nicht.

Es wäre denkbar die Datenbank um eine weitere Tabelle zu erweitern, um so noch mehr Informationen zu speichern.

Die Vorbereitung der Daten

Bevor wir also anfangen unsere Daten in Tabellen zu packen, müssen wir uns überlegen welche Daten überhaupt vorhanden sind, wohin wir sie speichern werden und wie wir überhaupt erst mal sie zerlegen.

Beginnen wir mit der Zerlegung an und zwar in die kleinstmögliche Einheit. Die Adresse zerlegen wir in Straße, Hausnummer, PLZ und Ort. Den Namen in Anrede, Titel, Vorname und Nachname. Die Telefonnummer in Landesvorwahl, Vorwahl und Hauptnummer. Jede Einzelinformation (Attribut) muss in eine eigene Spalte. Um herauszufinden, ob die Daten nun bereit sind in eine Datenbank gesteckt zu werden, müssen wir sie erst einmal prüfen, ob sie a) redundanzfrei und b) konsistent sind. Redundanzfrei bedeutet, dass die Daten nur ein mal vorkommen dürfen. Konsistent bedeutet, dass sie sich gegenseitig nicht widersprechen und obsolet (veraltet) sind. Wir prüfen auf die Normalisierungsformen, um herauszufinden, ob die Daten für die Datenbank zu gebrauchen sind.

Die Normalisierungsformen (NF)

Es gibt insgesamt 5 Normalisierungsformen. Im Normalfall hat man nur mit den ersten drei zu tun. Jede Form ist eigentlich eher wie eine Stufe anzusehen. Die ersten drei Stufen müssen erreicht werden.

Die erste Normalform (1NF)

Eine Tabelle ist in erster Normalform, wenn in jeder Zelle nur ein Wert steht.
Die Werte je Spalte müssen gleicher Art sein.

Die zweite Normalform (2NF)

Die 1NF muss erfüllt sein.
Der Primärschlüssel muss nun gesetzt werden.Es können auch zwei Attribute (oder mehr) zusammen einen Primärschlüssel bilden!
Zudem müssen die Nichtschlüsselattribute auf Abhängigkeit zum Teil-schlüsselattribut geprüft werden. Besteht eine Abhängigkeit zu einem Teilschlüsselattribut (also nur ein Teil des Primärschlüssels, falls er aus mehreren Attributen besteht), so sind beide Attribute zu entfernen und eine neue Tabelle zu bilden.
Sind keine Nichtschlüsselattribute vorhanden, ist die 2NF erfüllt.

Die dritte Normalform (3NF)

Die 2NF muss erfüllt sein.
Die Nichtschlüsselattribute müssen gegeneinander auf Abhängigkeit geprüft werden. Sind sie voneinander abhängig, dann muss damit eine neue Tabelle gebildet werden. Ist dem nicht so und die NSA sind unabhängig untereinander, so ist die 3NF erfült.

Beziehungen (Kardinalitäten)

Auch gerne mal Multiplizitäten genannt, aber in der Datenbanksprache eigentlich der falsche Begriff. Kardinalitäten sind die Beziehungen zwischen den Entitäten (Objekte, die wiedergespiegelt werden) wie sie miteinander verbunden sind. Die Aufzählung hier drunter sollte es eigentlich ziemlich verdeutlichen.

1:1 - Ein Auto gehört einem Eigentümer

1:n - Ein Eigentümer hat viele Häuser

m:n - Viele Eigentübmer haben viele Häuser

1:c - Ein Auto hat ein Tempomat oder keins

1:mc - Ein Eigentümer hat Null oder viele Autos

Es spielt keine Rolle, ob man m oder n schreibt. Es dient nur zur Symbolisierung von "viele".

Bei einer m:n Beziehung gehen die "n" zur Assoziation rüber.