Normalisierung in Datenbanken (1. bis 3. Normalform)
Patrick Boekhoven
https://www.youtube.com/watch?v=aCXKT4ycAbQ

Transkript (automatisch erstellt)

0:11 In diesem Video beschäftigen wir uns mit dem Thema Normalisierung aus dem Bereich der Datenbanken. Die Normalisierung ist notwendig, damit Anomalien in relationalen Datenbanken
0:19 vermieden werden können. Dazu habe ich bereits ein Video gemacht bzw. ab bereits aufgezeigt was Anomalien sind und zu welchen Problemen sie führen. Das Video verlinke ich oben.
0:31 Immer wieder führt dies zu Problemen bzw. zu Schwierigkeiten. Dabei reicht es aber einfach, dass man sich die Regeln einprägt und einfach nur anwendet. Diese Regeln werde ich euch
0:43 gleich Schritt für Schritt einmal erläutern. Und dazu sei gesagt, dass die Normalisierung ein Datenbankdesign ist und den Sinn hat, Anomalien
0:50 und Redundanzen zu verhindern. Wir starten dazu mit der nullten Normalform und zu diesem Zweck
0:57 gucken wir uns die Datenbank der Computer Firma hyperEDV an, die zwar eine Datenbank haben,
1:03 die allerdings noch umnormalisiert ist. Bei einer Datenbanken der nullten Normalform befinden sich alle Daten unnormalisiert in einer einzigen Tabelle. Und genau das ist hier der fall.
1:15 Unsere Datenbank besteht aus einer einzigen Tabelle mit Bestellnummer, Name Geburtsdatum etc. Und ihr seht direkt, das sieht nicht besonders gut aus und sollte auch nicht so
1:25 bleiben, weshalb wir die Tabellen gleich in die erste Normalform überführen. Ich hatte bereits gesagt, es gibt immer recht
1:32 starre regeln bei der Normalisierung die einhalten müssen und das Gleiche gilt auch hier. Die Regel um Tabellen in die erste Normalform zu überführen lautet: "Alle Attribute werte
1:41 müssen atomar sein". Unter einem Attribut selber verstehen wir eine spalte wie BestellNr oder den Namen. Und unter atomar
1:49 verstehen wir, dass wir diese Attribute nicht weiter aufgliedern können. Das ist hier im Moment noch nicht der fall, weil unsere Tabelle befindet sich ja noch in der nullten Normalform
1:59 und wir schauen uns jetzt beispielsweise mal den Namen an. Unsere Kunden haben einen Vor- und einen Nachnamen und das bedeutet, wir müssen diese spalten soweit aufgliedern,
2:09 wie es nur möglich ist. Wir machen aus der einen Spalte Name zwei neue Spalten und zwar Vor- und Nachname.
2:17 Denn nur so können wir am Ende nach Nachnamen sortieren und dort alle Kunden anzeigen lassen, die mit einem es mit einem S im Nachnamen beginnen. Denn unser Computer wüsste ja nicht,
2:28 wenn Ludger Sievert in einer Zelle steht, wie soll er das Ganze aufteilen. Wo beginnt
2:32 hier der Nachname beziehungsweise, was ist der Vor- oder was ist der Nachname. Gleiches gilt noch für die Adresse. Auch die Adresse müssten wir noch in die Attribute Straße,
2:42 Ort oder Postleitzahl aufteilen, denn auch hier weiß der Computer nicht, wie kann man
2:48 unterscheidet zwischen Straße, Ort und Postleitzahl. Wenn wir uns zum Beispiel alle Kunden aus Münster anzeigen lassen und die stehen in einem Feld, dann ist das nicht besonders günstig.
2:59 Bedeutet, wir müssen alles so weit aufteilen, dass alles in einer einzigen Spalte atomar aufgeteilt ist. Und dann würde ich sagen, machen wir das doch mal und schauen uns das
3:08 Ergebnis einmal an. Und ja die Aufmerksamen unter euch werden jetzt bemerken, die Hausnummer könnte man doch auch noch aufteilen. Natürlich könnte
3:16 man das und das wäre laut Regel absolut richtig. Aber wir wollen weder nach der Hausnummer sortieren noch irgendwas mit der Hausnummer großartig machen. Deswegen bringt uns das
3:25 jetzt keine großen Vorteil. Hier geht es natürlich immer abzuwägen ist es sinnvoll oder ist es nicht sinnvoll aber wenn wir die Regel so anwenden würden. Dann müssten wir
3:33 die Hausnummer natürlich auch in eine eigene Spalte überführen. So weit klar? Die Regel ist relativ einfach anzuwenden. Und wir haben, wenn wir es nicht ganz streng
3:43 sehen, eine Tabelle in der ersten Normalform vorliegen. Das machen wir weiter mit der zweiten Normalform und dazu schauen wir uns wie gewohnt erst
3:51 mal die Definition an, welche wir zur zweiten Normalform benötigen. Die Regel lautet folgendermaßen: Eine Tabelle befindet sich in der zweiten Normalform, wenn sie sich in der ersten Normalform
4:03 befindet und jedes Nichtschlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist. Das klingt jetzt erstmal ein bisschen komplizierter als es eigentlich ist.
4:12 Denn so kompliziert ist es gar nicht. Das werden wir jetzt merken. Als erste Information ist wichtig, dass jede Normalform die vorherige Normalform voraussetzt, wie auch bei der zweiten.
4:24 Bedeutet, wenn wir eine Tabelle in der zweiten Normalform haben möchten oder überführen wollen, muss ich die Tabelle erstmal in der ersten Normalform befinden. Und dann können
4:34 wir die Tabelle in die zweite Normalform bringen. Diese Regel gilt auch für die dritte Normalform. Bedeutet, dort muss die Tabelle erstmal in der zweiten Normalform vorhanden sein. Jetzt
4:44 schauen wir mal weiter, denn für die zweite Normalform machen wir ein kleiner Exkurs in relationalen Datenbanken. In relationalen Datenbanken arbeiten wir mit Primärschlüsseln.
4:52 Ein Schlüssel dient in einer relationalen Datenbank dazu, dass ein Datensatz zweifelsfrei identifiziert werden kann und dieser Wert darf daher auch nur einmal vorkommen. Unsere
5:03 Primärschlüssel erkennen wir daran, dass die Spalten oben wie bei Kundennummer und Bestellnummer unterstrichen sind. Dafür werden eine oder vielleicht auch mehrere Spalten
5:12 definiert, die diese Aufgabe übernehmen. Für eine Bestellung beispielsweise können wir uns die Bestellnummer dafür gut vorstellen. Eine Bestellung hat eine Nummer und diese
5:21 ist einzigartig. Die gibt es auch nicht mehrfach. Da gibt es nichts dran zu rütteln. Gleiches gilt für den Kunden und für alle Artikel. Auch hier ist die Kundennummer, beziehungsweise
5:30 die Artikelnummer einzigartig. Jeder Kunde hat eine eigene Nummer und jeder Artikel hat eine eigene Nummer. Und jetzt widmen wir uns einmal der Geschichte mit den voll funktionalen
5:40 Abhängigkeiten. Wir erhalten jetzt insgesamt vier Tabellen, wie ihr seht, die aus dieser einen Tabelle am Anfang entstanden sind. Diese sind
5:48 Bestellung, Kunde, Artikel und BestellungenArtikel. Wir schauen jetzt Schritt für Schritt an, warum diese Tabellen so in dieser Form entstanden sind und wie wir damit umgehen. Jede dieser
6:00 Tabellen hat in einer relationalen Datenbank einen Primärschlüssel und Nichtschlüsselattribute, die in der zweiten Normalform voll funktional von Primärschüssel abhängig sind. Wir schauen
6:11 uns das beispielsweise beim Kunden an. Da ist der Vorname voll funktional abhängig zur KundenID. Noch besser sehen wir das in der Tabelle BestellungArtikel. Hier nutzen
6:20 wir einen zusammengesetzten Primärschlüssel aus Bestellnummer und Artikelnummer. Also beide Spalten bilden hier den Primärschlüssel. Bestellung und Artikel dürfen zusammen so
6:30 in dieser Tabelle nicht noch einmal vorkommen. Dazu kommt die Spalte Anzahl, die und da kann man das relativ gut sehen, gleichermaßen von der Bestellnummer als auch von der Artikelnummer
6:42 abhängig ist. Wir benötigen also immer beide Informationen. Also die Bestellnummer und die Artikelnummer zusammen, damit die Anzahl aussagekräftig ist. Das bedeutet, die Anzahl
6:52 ist voll funktional abhängig zum gesamten Primärschlüssel. Wir haben also jede Spalte die von einem Schlüsselkanidaten nicht vollfunktional abgängig war, in der vorigen Tabelle in eine
7:06 Untertabelle ausgelagert. Wir erinnern uns, wir hatten eigene Schlüsselkandidaten, beziehungsweise die Artikelnummer, Kundennummer und Bestellnummer in einer Tabelle und die haben wir jetzt in
7:15 eigene Tabellen ausgelagert, was in der zweiten Normalform normal ist. Jetzt fragt ihr euch an einigen Stellen berechtigt, wie kommen wir auf die zweite Kundennummer und die zweite
7:26 Artikelnummer und die zweite Bestellnummer. Das gucken wir uns jetzt mal im Detail an. Schauen wir uns jetzt nochmal die Beziehung zwischen der Tabelle Kunde und
7:35 der Tabelle Bestellung und der Beziehung zwischen der Tabelle Bestellung, BestellungArtikel und Artikel und der Tabelle BestellungArtikel an. Beginnen wir erst mal mit der Bestellung
7:47 und dem Kunden und wir sehen, dass die Kundennummer in der Tabelle Bestellung auftaucht. Hier handelt es sich um eine Beziehung zwischen der Tabelle Kunde und der Tabelle Bestellung
7:57 und zwar um eine 1 zu n Beziehung. Die 1 bedeutet in diesem Fall, dass jede Bestellung einen oder keinen Kunden haben kann.
8:06 Und das n steht dafür, dass jeder Kunde keinen einen oder mehrere Bestellungen getätigt haben kann. Dies wird so aufgelöst in relationalen Datenbanken, dass der Primärschlüssel auf
8:18 der Kundenseite als Fremdschlüssel in der Tabelle Bestellung fungiert. So kann jede Bestellnummer nur einmal auftauchen, da die Spalte Bestellnummer der Primärschlüssel
8:29 ist und der Kunde kann so mehrfach auftauchen und kann mehrere Bestellungen haben. So lösen wir nur 1 zu n Beziehung in relationalen Datenbanken auf. Jetzt haben wir hier noch
8:38 eine zweite Beziehung und diese ist ein bisschen komplizierter. Hier handelt es sich um eine n zu m Beziehung. Wenn wir bei einer 1 zu n Beziehung,
8:47 wie wir gerade gesehen haben, den Primärschlüssel als Fremdschlüssel in der anderen Tabelle übernehmen können, brauchen wir bei einer
8:54 n zu n Beziehung in jedem Fall eine neue Tabelle. Die n zu n Beziehung sagt aus, dass ein Artikel mehrere Bestellungen haben kann und eine Bestellung
9:04 mehrere Artikel. Hier müssen wir, wie schon erwähnt eine neue Tabelle kreieren, indem wir auf einen zusammengesetzten Primärschlüssel aus Bestellung und Artikel zurückgreifen.
9:14 Die Bestellung und der Artikel dürfen somit nur ein einziges mal vorkommen, aber ein Artikel kann in mehreren Bestellungen vorkommen und eine Bestellung kann mehrere Artikel enthalten.
9:25 An dieser Stelle empfehle ich nochmal das Thema Beziehungen in relationalen Datenbanken, um sich noch einmal anzuschauen. Das soll nicht Thema dieses Videos sein. Es ist allerdings
9:36 Grundlage, um das Thema Normalisierung verstehen zu können. Und nun wieder zurück zu den Normalformen. Die Bedingung ist erfüllt, dass jedes Nichtschlüsselattribut voll funktional
9:47 von allen Schlüsselattributen abhängig ist und damit haben wir unser Ziel erreicht, dass sich alle unsere Tabellen in der zweiten Normalform befinden. Last but not least kommt nun die
9:58 dritte Normalform. Schauen wir uns zuerst einmal wieder die Regel an: Eine Tabelle befindet sich genau dann in der dritten Normalform, wenn sie sich in der zweiten Normalform befindet
10:07 und kein Nichtschlüsselattribut transitiv von einem Schlüsselkandidaten abhängt. Schauen wir
10:12 uns hier zuerst mal den Begriff transitiv an einem Beispiel an. Aus A folgt B und aus B folgt C. Beispielsweise, wenn die 3 kleiner als die 5 ist und die 5 kleiner als
10:26 die 8 ist, ergibt sich transitiv, dass 3 auch kleiner als die 8 ist. Das übertragen wir jetzt mal auf unsere Tabelle: Das Attribut Ort hängt von der Postleitzahl ab und erst
10:37 dann vom Primärschlüssel. Die nicht Schlüsselattribute sind somit nicht voneinander unabhängig und das verstößt gegen die dritte Normalform. Die transitivabhängige Spalte Ort wird also
10:50 in eine weitere Untertabelle ausgelagert, da sie ja nicht direkt vom Schlüsselkandidaten abhängt. Sondern nur indirekt. Also erstellen wir eine neue
10:58 Tabelle Postleitzahl mit Ort und zack wir sehen, wir haben jetzt ein Schema bzw. Tabellen die sich in der dritten Normalform befinden.