Wir gehen ein komplettes Beispiel zur Normalisierung einer
relationalen Datenbank durch in der einhundertvierundvierzigsten
Episode des Anwendungsentwickler-Podcasts. TL;DR Ich gehe mit dir
an einem Beispiel mit Bestellungen und Artikeln durch, wie du eine
relationale Datenbank bis zur dritten Normalform aufbaust. Dabei
zerlegst du zusammengesetzte Werte, verteilst mehrfach enthaltene
Artikel auf einzelne Zeilen und trennst Daten anhand ihrer
Abhängigkeiten in eigene Tabellen. Primärschlüssel und
Fremdschlüssel halten die Beziehungen zusammen, während du
Redundanzen und daraus entstehende Anomalien vermeidest. Für deine
Prüfung als Fachinformatiker:in solltest du die Normalformen
definieren und jeden Schritt an einem vorbereiteten Beispiel
begründen können. Kapitelmarken [00:00:01] Hinweis zum Fachgespräch
[00:00:37] Normalisieren in der schriftlichen Prüfung und im
Fachgespräch [00:02:26] Ein passendes Beispiel für die Prüfung
vorbereiten [00:05:16] Redundanzen und Anomalien als Grund fürs
Normalisieren [00:06:53] Merkhilfe: The key, the whole key and
nothing but the key [00:07:52] Das Beispiel mit Kund:innen und
Bestellungen [00:12:20] Ausgangstabelle und Probleme beim Abfragen
[00:16:11] Erste Normalform und atomare Attribute [00:19:03]
Postleitzahlen: Kardinalität und Datentyp [00:20:34]
Wiederholungsgruppen auf einzelne Zeilen verteilen [00:24:56]
Datensätze über Schlüssel identifizieren [00:26:33] Redundanzen und
Änderungsanomalien [00:28:58] Zweite Normalform und vollständige
funktionale Abhängigkeit [00:32:18] Eigene Tabellen und
Fremdschlüssel einführen [00:33:52] Bestellpositionen als
m:n-Zwischentabelle [00:36:25] Menge und konkreten Kaufpreis
richtig zuordnen [00:39:53] 1:n-Beziehungen in der zweiten
Normalform [00:42:28] Dritte Normalform und redundante
Artikelgruppen [00:44:50] Transitive Abhängigkeiten verstehen
[00:47:47] Artikelgruppen auslagern und per Fremdschlüssel
verknüpfen [00:50:49] Das fertige Tabellenmodell und seine
Schlüssel [00:53:19] Anomalien vermeiden und Beziehungen erhalten
[00:56:15] Normalformen und Merkhilfe für die Prüfung wiederholen
[00:58:50] Begleitmaterial und Literatur [01:00:48] Feedback und
Abschluss Inhalt Theoretische Grundlagen Wir normalisieren
Datenbanken um Redundanzen zu vermeiden, die zu Anomalien führen
können. Mehr dazu in Podcast-Episode 18. Grundlagen wie Schlüssel,
Kardinalitäten usw. erkläre ich in Podcast-Episode 17. Merksatz:
"The key, the whole key, and nothing but the key." Beispieldaten
Wir verwenden ein "klassisches" Beispiel, das so oder ähnlich in
vielen IHK-Prüfungen genutzt wird. Umfeld: Kunden bestellen Artikel
aus verschiedenen Artikelgruppen. Ein Kunde kann mehrere
Bestellungen durchführen. Eine Bestellung wird immer von genau
einem Kunden getätigt. Zu den Kunden werden Name und Adresse
erfasst. Jede Bestellung hat ein Bestelldatum. In einer Bestellung
können mehrere Artikel enthalten sein. Ein Artikel kann auch in
mehreren Bestellungen auftauchen. Artikel haben eine Bezeichnung
und einen Preis. Ein Artikel kann zu genau einer Artikelgruppe
gehören. Eine Artikelgruppe kann mehrere Artikel enthalten.
Artikelgruppen haben eine Bezeichnung und einen Rabatt.
Ausgangssituation (nicht normalisiert) Alle Bestellungen stehen in
einer einzelnen Tabelle. Jede Bestellung steht komplett inkl.
mehrerer Artikel in einer Zeile. Die Adresse steht komplett in
einem einzigen Attribut. Beispiele für Probleme: Viele Redundanzen
(z.B. Adressen, Artikelbezeichnungen), Sortierung nach Ort ist
nicht möglich, Selektion aller gekaufter Fernseher ist nicht
möglich. 1. Normalform Definition: Es gibt 1) nur atomare Attribute
und 2) keine Wiederholungsgruppen. "the key": Alle Datensätze sind
eindeutig über einen Primärschlüssel identifizierbar. Durch 2)
werden Redundanzen zunächst eingeführt, da aus einer Zeile nun
mehrere Zeilen mit redundanten Inhalten werden. Vorgehen:
Nicht-atomare Attribute auf mehrere Spalten aufteilen.
Wiederholungsgruppen auf mehrere Zeilen aufteilen. Ein Datensatz
ist über einen zusammengesetzten Schlüssel aus drei Attributen
identifizierbar. Redundanzen: Kunden-, Bestell- und Artikeldaten
sind jeweils mehrfach vorhanden. Ursache: Tabelle enthält drei
Konzepte (Kunde, Bestellung, Artikel), die alle nur von Teilen des
Schlüssels abhängen und nicht vom gesamten. 2. Normalform
Definition: (1. Normalform erfüllt und) alle Attribute sind voll
funktional vom Primärschlüssel abhängig. "the whole key": Alle
Attribute hängen vom gesamten Schlüssel ab (und nicht nur von
seinen Teilen). Vorgehen: Alle drei Konzepte auf einzelne Tabellen
aufteilen. Fremdschlüssel für Referenzen einführen.
Zuordnungstabelle Position mit zusammengesetztem Schlüssel aus
Fremdschlüsseln einführen. m:n-Beziehungen werden aufgelöst. Menge
gehört an die Kombination aus Bestellung und Artikel und weder an
das eine noch das andere allein. Redundanzen: Artikelgruppe und
Rabatt gehören zusammen und sind mehrfach vorhanden. Ursache:
Rabatt hängt von Artikelgruppe ab und nicht von der Artikelnummer
(=transitive Abhängigkeit). 3. Normalform Definition: (2.
Normalform erfüllt und) es gibt keine transitiven Abhängigkeiten.
"and nothing but the key": Kein Nicht-Schlüssel-Attribut hängt von
einem anderen Nicht-Schlüssel-Attribut ab. Vorgehen: Artikelgruppe
in eigene Tabelle extrahieren und Fremdschlüssel für Referenz
einführen. 1:n-Beziehungen werden aufgelöst. Ergebnis Jede Tabelle
enthält genau ein Konzept. Keine Daten sind mehr redundant. In
jeder Tabelle gibt es einen eindeutigen Primärschlüssel.
Fremdschlüssel werden für Referenzen auf Datensätze in anderen
Tabellen verwendet. Literaturempfehlungen Zum Einstieg ins Thema
Datenbanken inkl. Modellierung, Normalisierung und SQL empfehle ich
Einstieg in SQL* von Michael Laube. * Links Permalink zu dieser
Podcast-Episode RSS-Feed des Podcasts Relationale Datenbanken -
Häufige Fragen im Fachgespräch Normalisierung - Häufige Fragen im
Fachgespräch Normalisierung (Datenbank) Zusammenfassung
Normalformen in deiner IT-Prüfung An einem Beispiel mit
Bestellungen und Artikeln gehe ich mit dir bis zur dritten
Normalform. Als IT-Azubi zum/zur Fachinformatiker:in
Anwendungsentwicklung brauchst du dieses Wissen beim Entwerfen
relationaler Tabellenmodelle und im Fachgespräch. Dort gehören auch
die Definitionen der Normalformen und die Gründe für jeden Schritt
zu den möglichen Fragen. Bereite dir dafür ein konkretes Beispiel
vor, dessen Beziehungen du nachvollziehen kannst. Das hier
beschriebene Bestellmodell kommt häufig in IHK-Aufgaben vor. Auch
ein anderes vertrautes Beispiel eignet sich, wenn du die
Abhängigkeiten darin erklären kannst. Warum Daten normalisieren?
Wenn du dieselben Daten mehrfach speicherst, entstehen Redundanzen.
Daraus können Anomalien folgen: Ändert sich etwa eine Adresse,
musst du jeden betroffenen Datensatz anpassen. Bleibt eine alte
Adresse stehen, enthält die Datenbank widersprüchliche Angaben.
Durch die einzelnen Normalformen verteilst du zusammengehörige
Daten auf eigene Tabellen. So lassen sich Angaben getrennt abfragen
und an einer Stelle ändern. Der zusätzliche Speicherbedarf mehrfach
gespeicherter Werte spielt dabei eine untergeordnete Rolle. Das
Beispiel und seine Beziehungen In meinem Beispiel bestellen
Kund:innen Artikel, die jeweils zu einer Artikelgruppe gehören. Für
das Modell gelten diese Regeln: Kund:in und Bestellung, 1:n: Ein:e
Kund:in kann mehrere Bestellungen aufgeben. Jede Bestellung gehört
genau einer Person. Bestellung und Artikel, m:n: Eine Bestellung
kann mehrere Artikel enthalten. Derselbe Artikel kann in mehreren
Bestellungen vorkommen. Artikelgruppe und Artikel, 1:n: Jeder
Artikel gehört im Beispiel zu genau einer Gruppe, die mehrere
Artikel enthalten kann. Zu einer Kund:in gehören Name und Adresse.
Eine Bestellung hat ein Bestelldatum; beim Artikel sind Bezeichnung
und Preis hinterlegt. Die Artikelgruppe hat eine eigene Bezeichnung
und einen Rabatt, etwa zehn Prozent für Elektronik. Am Anfang
stehen alle Angaben in einer Excel-Tabelle mit einer Zeile pro
Bestellung. Die komplette Adresse ist in einer Zelle gespeichert,
ebenso die Liste der bestellten Artikel. Dadurch lassen sich
einzelne Orte oder Artikel schwer gezielt abfragen. Sobald eine
Person erneut bestellt, werden ihre Angaben nochmals erfasst. Erste
Normalform: atomare Attribute und aufgelöste Wiederholungsgruppen
Für die erste Normalform müssen die Attribute atomar sein und
Wiederholungsgruppen aufgelöst werden. Zusammengesetzte Werte
aufteilen Atomar bedeutet, dass ein Wert für die Anforderungen
deines Datenmodells als einzelne Einheit behandelt wird. Die
Adresse zerlege ich im Beispiel in eine Spalte für die Straße
einschließlich Hausnummer sowie separate Spalten für Postleitzahl
und Ort. Wie weit du solche Angaben aufteilst, hängt von deinen
Anforderungen ab. Wenn du die Hausnummer oder ihren Zusatz einzeln
verarbeiten musst, bekommen diese Bestandteile eigene Spalten. Im
Beispiel bleibt die Straßenangabe einschließlich Hausnummer
zusammen. Zwei Details sind dabei zu beachten: Zwischen
Postleitzahl und Ort besteht in Deutschland eine m:n-Beziehung. Ein
Ort kann mehrere Postleitzahlen haben; eine Postleitzahl kann für
mehrere Orte gelten. Speichere Postleitzahlen als Text, damit
führende Nullen erhalten bleiben. Dieser Datentyp erlaubt auch
Buchstaben, die in internationalen Postleitzahlen vorkommen.
Mehrfach enthaltene Artikel auf einzelne Zeilen verteilen Enthält
eine Bestellung mehrere Artikel in einer Zelle, liegt eine
Wiederholungsgruppe vor. Dafür erhält jeder bestellte Artikel eine
eigene Zeile. Die übrigen Angaben zur Bestellung und zur
bestellenden Person werden zunächst in jede dieser Zeilen
übernommen. Bei einer Bestellung mit mehreren Artikeln stehen die
Kundendaten dadurch mehrfach in der Tabelle. Diese zusätzlichen
Redundanzen entstehen beim ersten Schritt und werden in den
folgenden Normalformen entfernt. Jede Zeile muss eindeutig
identifizierbar sein....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.