Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).
Normalisierung in Datenbanken (1. bis 3. Normalform)
Das Wichtigste aus dem Video
Tipp auf eine Zeit – das Video springt genau dorthin.
Transkriptautomatisch erstellt · 68 Zeilen
- 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
- 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.
- 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
- gleich Schritt für Schritt einmal erläutern. Und dazu sei gesagt, dass die Normalisierung ein Datenbankdesign ist und den Sinn hat, Anomalien
- und Redundanzen zu verhindern. Wir starten dazu mit der nullten Normalform und zu diesem Zweck
- gucken wir uns die Datenbank der Computer Firma hyperEDV an, die zwar eine Datenbank haben,
- 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.
- 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
- bleiben, weshalb wir die Tabellen gleich in die erste Normalform überführen. Ich hatte bereits gesagt, es gibt immer recht
- 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
- müssen atomar sein". Unter einem Attribut selber verstehen wir eine spalte wie BestellNr oder den Namen. Und unter atomar
- 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
- 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,
- wie es nur möglich ist. Wir machen aus der einen Spalte Name zwei neue Spalten und zwar Vor- und Nachname.
- 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,
- wenn Ludger Sievert in einer Zelle steht, wie soll er das Ganze aufteilen. Wo beginnt
- 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,
- Ort oder Postleitzahl aufteilen, denn auch hier weiß der Computer nicht, wie kann man
- 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.
- 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
- 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
- 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
- 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
- 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
- sehen, eine Tabelle in der ersten Normalform vorliegen. Das machen wir weiter mit der zweiten Normalform und dazu schauen wir uns wie gewohnt erst
- 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
- 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.
- 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.
- 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
- 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
- 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.
- 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
- 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
- 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
- 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
- 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
- Abhängigkeiten. Wir erhalten jetzt insgesamt vier Tabellen, wie ihr seht, die aus dieser einen Tabelle am Anfang entstanden sind. Diese sind
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- und zwar um eine 1 zu n Beziehung. Die 1 bedeutet in diesem Fall, dass jede Bestellung einen oder keinen Kunden haben kann.
- 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
- 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
- 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
- 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,
- wie wir gerade gesehen haben, den Primärschlüssel als Fremdschlüssel in der anderen Tabelle übernehmen können, brauchen wir bei einer
- 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
- 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.
- 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.
- 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
- 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
- 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
- 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
- und kein Nichtschlüsselattribut transitiv von einem Schlüsselkandidaten abhängt. Schauen wir
- 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
- 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
- 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
- in eine weitere Untertabelle ausgelagert, da sie ja nicht direkt vom Schlüsselkandidaten abhängt. Sondern nur indirekt. Also erstellen wir eine neue
- Tabelle Postleitzahl mit Ort und zack wir sehen, wir haben jetzt ein Schema bzw. Tabellen die sich in der dritten Normalform befinden.