In der achzehnten Episode meines Anwendungsentwickler-Podcasts
setze ich die Reihe der häufigen Fragen im Fachgespräch zum Thema
Datenbanken mit dem Themenbereich der Normalisierung fort. TL;DR
Ich gehe mit dir typische Fragen zur Normalisierung relationaler
Datenbanken im Fachgespräch durch. Dabei erfährst du, wie mehrfach
gespeicherte Daten zu Anomalien führen und wie du die ersten drei
Normalformen anhand einer CD-Datenbank erklärst. Außerdem geht es
um referenzielle Integrität und darum, wie eine Datenbank mit
bestehenden Fremdschlüsselbeziehungen beim Löschen von Datensätzen
umgeht. Für deine Prüfung empfehle ich dir ein vertrautes Beispiel
aus deinem Abschlussprojekt oder deinem Betrieb. Kapitelmarken
[00:00:01] Einstieg ins Fachgespräch [00:00:37] Datenbanken als
Thema im Fachgespräch [00:01:34] Warum relationale Datenbanken
normalisiert werden [00:02:20] Redundante Daten und Denormalisieren
im Data-Warehouse [00:04:31] Einfügeanomalie [00:05:38]
Änderungsanomalie [00:06:28] Löschanomalie [00:07:11] Antworten zu
Normalformen im Fachgespräch strukturieren [00:08:40] Definitionen
der ersten drei Normalformen [00:09:32] Ein eigenes Beispiel für
die Prüfung wählen [00:10:46] Erste Normalform und atomare Werte
[00:12:57] Zusammengesetzte Werte und Listen aufteilen [00:15:49]
Zweite Normalform und vollständige Schlüsselabhängigkeit [00:19:58]
m:n-Beziehungen und Zuordnungstabellen [00:21:50] Dritte Normalform
und transitive Abhängigkeiten [00:23:49] Daten zu Interpret:innen
in eine eigene Tabelle auslagern [00:25:25] 1:n-Beziehung zwischen
Interpret:innen und CDs [00:26:38] Prüfungsrelevanz weiterer
Normalformen [00:27:34] Referenzielle Integrität [00:29:04] Umgang
mit Fremdschlüsselbeziehungen [00:29:26] Ungesicherte Referenzen
unter der Bezeichnung No Action [00:30:25] Restrict: Löschen bei
bestehenden Referenzen sperren [00:31:40] Cascade: abhängige
Datensätze automatisch löschen [00:32:34] Set Null: Fremdschlüssel
auf NULL setzen [00:33:41] Ausblick auf Datenbankmodellierung und
SQL [00:34:30] Kontakt, Shownotes und Newsletter Inhalt
Normalisierung Warum werden Datenbanken normalisiert? Vermeidung
von Redundanzen, die zu Anomalien führen können. Welche Anomalien
gibt es und was sind Beispiele dafür? Einfüge-, Änderungs- und
Löschanomalie Normalformen Normalform: nur atomare Werte
Normalform: 1. Normalform und alle Attribute sind voll funktional
vom Primärschlüssel abhängig (hier werden die m:n-Beziehungen
aufgelöst) Normalform: 2. Normalform und keine transitiven
Abhängigkeiten (hier werden die 1:n-Beziehungen aufgelöst) Was
bedeutet referentielle Integrität? Alle Fremdschlüssel zeigen auf
gültige Datensätze. Welche technischen Maßnahmen zur Wahrung der
referentiellen Integrität gibt es? No Action, Restrict, Cascade,
Set Null Literaturempfehlungen *(direkt beim Rheinwerk-Verlag
bestellen*) Das passende Kapitel im OpenBook: 12 Datenbanken -
Rheinwerk Computing :: IT-Handbuch für Fachinformatiker Links
Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts
Normalisierung (Datenbank) – Wikipedia mysql - Setting up table
relations what do "Cascade", "Set Null" and "Restrict" do? - Stack
Overflow Advanced MySQL - Referentielle Integrität - Fremdschlüssel
- Referenzaktionen Weitere Infos zum FachgesprächDu suchst noch
mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese
Artikel- und Podcast-Kategorie: Alle Artikel rund um das
Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf
das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie
herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im
Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich
für meinen Newsletter einträgst, bekommst du immer direkt alle
Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt
anmelden! Zusammenfassung Warum Datenbanken normalisiert werden
Wenn ich Kundendaten zusammen mit gekauften Artikeln in einer
Tabelle speichere, stehen dieselben Kundeninformationen bei jedem
Kauf erneut in einem Datensatz. Solche mehrfach abgelegten Daten
heißen Redundanzen. Daraus können Anomalien entstehen, die durch
das Normalisieren vermieden werden sollen: Einfügeanomalie: Du
möchtest eine:n Kund:in anlegen, bevor eine Bestellung vorliegt.
Sind die Artikeldaten in derselben Tabelle als Pflichtfelder
definiert, lässt sich der Datensatz erst mit diesen Angaben
speichern. Änderungsanomalie: Ändert sich der Nachname einer
Person, müssen sämtliche Datensätze mit diesem Namen angepasst
werden. Wird dabei ein Datensatz übersehen, enthält die Datenbank
widersprüchliche Angaben. Löschanomalie: Beim Löschen eines
Artikeldatensatzes verschwinden zugleich die darin gespeicherten
Kundendaten. Hat die betreffende Person nur diesen Artikel gekauft,
gehen ihre Daten vollständig verloren. Bewusst redundant
gespeicherte Daten im Data-Warehouse Für ein Data-Warehouse kann
ich Daten bewusst redundant ablegen, damit große Datenmengen
schnell abgefragt werden können. Enthält eine Tabelle bereits die
Kundendaten zusammen mit den Bestellungsdaten und den zugehörigen
Artikeln, entfallen zusätzliche Joins für diese Informationen. Ein
klassisches Data-Warehouse enthält häufig einen zeitlichen
Ausschnitt aus der Produktionsdatenbank. Dieser sogenannte
dispositive Datenstand dient dazu, Auswertungen durchzuführen. Wenn
dadurch Abfragen schneller werden, kommt auch das gezielte
Denormalisieren einer Datenbank infrage. Deine Antwort im
Fachgespräch vorbereiten Bei einer offenen Frage zu Normalformen
empfehle ich dir, zunächst die allgemeinen Definitionen zu nennen
und anschließend ein Beispiel schrittweise durchzugehen. Daran
kannst du auch Fremdschlüssel und Beziehungen zwischen Tabellen
erläutern. Wähle möglichst eine Datenbank aus deinem
Abschlussprojekt oder deinem Betrieb, mit der du vertraut bist. So
kannst du gegenüber den Prüfer:innen begründen, warum bestimmte
Daten auf diese Weise abgebildet wurden. Für die folgenden Schritte
verwende ich eine CD-Datenbank aus dem Wikipedia-Artikel zum
Normalisieren. Erste Normalform: atomare Werte Die erste Normalform
verlangt, dass eine Tabelle ausschließlich atomare Werte enthält.
Jeder Wert steht dabei für eine einzelne Information. Eine
vollständig in einem Feld gespeicherte Adresse wird dafür auf
passende Spalten verteilt, etwa eine eigene Spalte für die
Postleitzahl und eine für den Ort. Dadurch lässt sich gezielt nach
diesen Angaben suchen, ohne den gesamten Adresstext zerlegen zu
müssen. Auch eine Liste gekaufter CD-IDs in einem einzelnen Feld
enthält mehrere Werte. Im beschriebenen Beispiel entsteht deshalb
für jede gekaufte CD eine eigene Zeile, die zunächst auch die
Kundendaten erneut enthält. Jede Zelle enthält nun einen einzelnen
Wert. Die wiederholten Kundendaten führen allerdings zu
Redundanzen, die in weiteren Schritten bearbeitet werden.
Zusätzliche Spalten wie CD1 oder CD2 würden bei weiteren Käufen
Änderungen an der Tabellenstruktur erfordern. Bei Personen mit
wenigen Käufen blieben außerdem viele dieser Felder leer. Zweite
Normalform: abhängig vom gesamten Schlüssel Damit die zweite
Normalform vorliegt, muss die erste erfüllt sein. Alle
Nichtschlüsselattribute müssen vollständig funktional vom gesamten
Primärschlüssel abhängen. In meinem CD-Beispiel enthält die
Ausgangstabelle pro Zeile einen Track samt Albumdaten. Ein
Datensatz wird durch die Kombination aus CD-ID und Track-ID
eindeutig bestimmt. Der Albumtitel hängt dabei bereits von der
CD-ID allein ab. Damit besteht eine Abhängigkeit von einem Teil des
zusammengesetzten Schlüssels. Die Albumdaten werden deshalb in eine
eigene Tabelle ausgelagert: Die Tabelle CD enthält die CD-ID und
den Albumtitel sowie zunächst Angaben zur interpretierenden Person.
Die Tabelle Track enthält die CD-ID als Fremdschlüssel, die
Track-ID als weiteren Teil des Primärschlüssels und den Titel des
Tracks. In der CD-Tabelle hängt der Albumtitel von der CD-ID ab.
Der Track wird in der Track-Tabelle über die vollständige
Kombination aus CD-ID und Track-ID bestimmt. Eine CD kann mehrere
Titel enthalten, während derselbe Titel auf mehreren CDs erscheinen
kann, etwa auf einem Best-of-Album. Diese m:n-Beziehung wird im
Podcast im Zusammenhang mit der zweiten Normalform besprochen. Eine
Zuordnungstabelle enthält die Schlüssel der beteiligten Datensätze.
Dritte Normalform: transitive Abhängigkeiten auflösen Die dritte
Normalform setzt die zweite voraus. Transitive Abhängigkeiten
entstehen, wenn ein Nichtschlüsselattribut über ein weiteres
Nichtschlüsselattribut vom Primärschlüssel abhängt. In der
CD-Tabelle steht zunächst neben der interpretierenden Person auch
deren Gründungsjahr. Dieses Jahr gehört zur Person beziehungsweise
zur Band. Über diese Angabe hängt es mittelbar von der CD-ID ab.
Ich lagere die entsprechenden Daten in eine eigene Tabelle aus.
Daraus ergibt sich folgendes Modell: CD: CD-ID, Albumtitel und
Interpret:innen-ID. Interpret:innen: Interpret:innen-ID, Name und
Gründungsjahr. Track: CD-ID, Track-ID und Titel des Tracks. Das
Gründungsjahr hängt damit direkt vom Schlüssel der
Interpret:innen-Tabelle ab. Zwischen dieser Tabelle und der
CD-Tabelle besteht im Beispiel eine 1:n-Beziehung: Eine
interpretierende Person kann mehrere CDs veröffentlichen. Dabei
gilt die Annahme, dass jede CD genau einer Person beziehungsweise
Band zugeordnet ist. Alben mit mehreren beteiligten Künstler:innen
sind in diesem Modell ausgeklammert. Für deine Prüfung empfehle ich
dir, die ersten drei Normalformen anhand eines Beispiels erklären
zu können. Weitere Formen wie die Boyce-Codd-Normalform werden
erwähnt; in meinen bisherigen schriftlichen und mündlichen
Prüfungen habe ich dazu keine Fragen erlebt. Referenzielle
Integrität Wenn die Interpret:innen-ID einer CD auf einen
vorhandenen Datensatz in der Interpret:innen-Tabelle verweist,
lässt sich diese Beziehung korrekt auflösen. Referenzielle
Integrität bedeutet, dass Fremdschlüssel auf gültige Datensätze
zeigen. ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.