Normalisierung: Unterschied zwischen den Versionen

Aus FLBK-Wiki
Zur Navigation springen Zur Suche springen
← Zum vorherigen Versionsunterschied
Flbkwikiadmin (Diskussion | Beiträge)
Bürokraten, Oberflächenadministratoren, Administratoren
2.195 Bearbeitungen
VisuellWikitext
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
== Einführung ==
== Einführung ==
Unter '''Normalisierung''' eines relationalen Datenbankmodells versteht man die Aufteilung von Attributen in mehrere [[Relation (Datenbanken)|Relationen]] (Tabellen) mithilfe der Normalisierungsregeln und deren Normalformen, sodass ein Schema entsteht, das keine vermeidbaren '''Redundanzen''' mehr enthält.
Die '''Normalisierung''' eines relationalen Datenbankmodells bezeichnet den strukturierten Prozess, [[Attribut|Attribute]] anhand fester Regeln (Normalformen) auf mehrere [[Relation (Datenbanken)|Relationen]] (Tabellen) aufzuteilen. Das primäre Ziel dieses Vorgangs ist es, ein Datenbankschema zu erstellen, das frei von vermeidbaren '''Redundanzen''' (Datenverdopplungen) ist.


Das Ziel ist die redundanzfreie Datenspeicherung. Ein Schema, das Redundanzen enthält, kann dazu führen, dass bei Änderungen die mehrfach enthaltenen Daten nicht konsistent, sondern nur teilweise und unvollständig geändert werden. Hierdurch können die Datenänderungen überflüssig oder widersprüchlich werden. Außerdem können [[Anomalie|Anomalien]] auftreten. Zudem belegt das mehrfache Speichern derselben Daten unnötig Speicherplatz.
Eine redundanzarme Datenspeicherung ist essenziell für die Datenintegrität. Enthält ein Schema Redundanzen, führt dies bei Aktualisierungen häufig zu [[Anomalie|Anomalien]] (Einfüge-, Änderungs- oder Löschanomalien). Mehrfach gespeicherte Daten könnten beispielsweise nur teilweise geändert werden, was zu widersprüchlichen und inkonsistenten Datenbeständen führt. Zudem belegt redundante Speicherung unnötigen Speicherplatz.


Es gibt verschiedene Grade der Normalisierung: Die so genannte erste, zweite, dritte usw. Normalform. Diese Normalformen sind durch formale Anforderungen definiert.  
Es gibt verschiedene formale Grade der Normalisierung (Erste, Zweite, Dritte Normalform etc.). Ein relationales Schema wird normalisiert, indem es anhand seiner [[Funktionale Abhängigkeit|funktionalen Abhängigkeiten]] schrittweise in kleinere Relationen zerlegt (dekomponiert) wird. Diese Zerlegung muss zwingend verlustfrei erfolgen – es dürfen keine Informationen verloren gehen.


 
In der Praxis wird vor allem in der Entwurfsphase einer [[Relationale Datenbank|relationalen Datenbank]] normalisiert. Ein sauberer logischer Modellentwurf, beispielsweise durch ein [[Entity-Relationship-Modell]] (ERM), erfüllt oft bereits von vornherein die wichtigsten Normalformen. Dennoch dient die formale Normalisierung als wichtiges Prüfinstrument, um verbliebene Redundanzen aufzudecken.
 
Man bringt ein relationales Schema in eine Normalform, indem man für sie geltende funktionale Abhängigkeiten in einfachere Relationen zerlegt, bis keine weitere Zerlegung mehr möglich ist. Dabei dürfen jedoch keine Daten verloren gehen.
 
Normalisiert wird vor allem in der Phase des Entwurfs einer [[Relationale Datenbank|relationalen Datenbank]]. Ein exakter Modellentwurf, wie das [[Entity-Relationship-Modell]] (ERM), macht eine Normalisierung eigentlich überflüssig, kann aber eingesetzt werden, um Anomalien zu beseitigen oder Redundanzen nachträglich zu minimieren.


== Beispiel der Normalisierungsschritte ==
== Beispiel der Normalisierungsschritte ==
Folgendes Schema wird exemplarisch aus einem denormalisierten Zustand in die 3. Normalform überführt.
Folgendes Schema wird exemplarisch aus einem denormalisierten Ausgangszustand schrittweise in die 3. Normalform überführt.


=== Ausgangssituation (Nicht normalisiert) ===
=== Ausgangssituation (Nicht normalisiert) ===
In diesem Zustand gibt es Attribute mit mehreren Werten (Wiederholungsgruppen bei Termindatum) und nicht atomare Werte (Vor- und Nachname in einem Feld).
In diesem Zustand weist die Tabelle zwei massive Strukturfehler auf: Es existieren Attribute mit mehreren Werten (Wiederholungsgruppen beim ''Termindatum'') und nicht atomare Werte (Vor- und Nachname stehen gemeinsam in einem Feld).
 
{| class="wikitable"
{| class="wikitable"
! Kundenname !! Mitarbeitername !! Salon !! Termindatum
! Kundenname !! Mitarbeitername !! Salon !! Termindatum
Zeile 28: Zeile 25:


== Die 1. Normalform (1NF) ==
== Die 1. Normalform (1NF) ==
Die 1. Normalform (kurz '''1NF''') ist erfüllt, wenn jedes Attribut einer Relation einen '''atomaren Wertebereich''' aufweist. Eine Relation befindet sich in der ersten Normalform, wenn alle Attribute nur einfache Attributwerte aufweisen. (Beispiel: Die Adresse darf nicht als ein Attribut verwendet werden, sondern muss in PLZ, Ort, Straße und Hausnummer aufgeteilt werden). Zudem darf es keine Wiederholungsgruppen geben.  
Ein Relationenschema befindet sich in der 1. Normalform (kurz '''1NF'''), wenn die Wertebereiche aller Attribute '''atomar''' sind. Das bedeutet, dass jeder Attributwert eine unteilbare Informationseinheit darstellen muss (z. B. muss eine Adresse in Straße, Hausnummer, PLZ und Ort aufgeteilt werden). Zudem sind Wiederholungsgruppen (Listen oder Arrays in einem Feld) unzulässig.


Zur Bildung der ersten Normalform müssen die nicht atomaren Attribute umgewandelt werden. Dies kann durch Einfügen zusätzlicher Zeilen, Spalten oder neuer Relationen erfolgen.  
Um ein Schema in die 1NF zu überführen, müssen zusammengesetzte Attribute aufgespalten und Wiederholungsgruppen durch das Anlegen neuer Datensätze (Zeilen) aufgelöst werden.


'''Umsetzung:''' Um die 1NF zu erfüllen, müssen für Werte der Spalte ''Termindatum'' zusätzliche Zeilen eingefügt werden und die Inhalte der Spalten ''Mitarbeitername'' und ''Kundennamen'' müssen in jeweils zwei Spalten (MVorname und MNachname bzw. KVorname und KNachname) ausgelagert werden.
'''Umsetzung:''' Die Spalten ''Mitarbeitername'' und ''Kundenname'' werden jeweils in Vor- und Nachname (KVorname, KNachname, MVorname, MNachname) zerlegt. Für die beiden Termindaten von Klaus Meyer wird die Zeile dupliziert, sodass pro Zelle nur noch ein Datum steht.


{| class="wikitable"
{| class="wikitable"
Zeile 43: Zeile 40:
| Paula || Meyer || Claudia || Schrotter || Friedrich List Frisuren || 09.11.2012
| Paula || Meyer || Claudia || Schrotter || Friedrich List Frisuren || 09.11.2012
|}
|}
''Nun befindet sich die Tabelle in der 1NF!''
''Die Relation erfüllt nun die Kriterien der 1. Normalform.''


---
---


== Die 2. Normalform (2NF) ==
== Die 2. Normalform (2NF) ==
Ein Relationenschema ist in der 2. Normalform (kurz '''2NF'''), wenn es in der 1. Normalform ist und jedes Nicht-Schlüsselattribut von einem [[Primärschlüssel]] [[Funktionale_Abhängigkeit|vollständig funktional abhängig]] ist.
Ein Relationenschema befindet sich in der 2. Normalform (kurz '''2NF'''), wenn es sich in der 1NF befindet und jedes Nicht-Schlüsselattribut von jedem Schlüsselkandidaten [[Funktionale Abhängigkeit#Volle funktionale Abhängigkeit|voll funktional abhängig]] ist.


Zunächst muss also ein Primärschlüssel definiert werden. In diesem Beispiel lässt sich aber keine Attributkombination finden, für die sich immer jeder Datensatz identifizieren lässt. Denn es ist denkbar, dass ein Kunde beim gleichen Mitarbeiter am gleichen Datum zwei Friseurtermine wahrnimmt.
Um diese Bedingung zu prüfen, muss zunächst ein [[Primärschlüssel]] identifiziert werden. Im obigen Beispiel aus der 1NF gibt es keine natürliche Attributkombination, die einen Termin eindeutig identifiziert (ein Kunde könnte am selben Tag beim selben Mitarbeiter mehrere Termine haben).


'''Umsetzung:''' Wird ein künstlicher Primärschlüssel für die Relation definiert, ist die Anforderung automatisch erfüllt. Man erweitert die Tabelle um eine Spalte `IdTermin`. Der künstliche Primärschlüssel generiert einen Autowert, anhand dessen sich jede Spalte eindeutig identifizieren lässt.
'''Umsetzung:''' Die praktikabelste Lösung ist die Einführung eines künstlichen Primärschlüssels (Surrogatschlüssel). Die Tabelle wird um die Spalte `IdTermin` erweitert, die fortlaufend durchnummeriert wird.


{| class="wikitable"
{| class="wikitable"
Zeile 63: Zeile 60:
| 3 || Paula || Meyer || Claudia || Schrotter || Friedrich List Frisuren || 09.11.2012
| 3 || Paula || Meyer || Claudia || Schrotter || Friedrich List Frisuren || 09.11.2012
|}
|}
''Die Relation erfüllt nun die Anforderungen der 2NF. Sie befindet sich in der 1NF und es gibt kein Attribut in der Tabelle, das sich nicht eindeutig und voll funktional durch den Primärschlüssel IdTermin bestimmen lässt.''
''Die Relation befindet sich nun in der 2NF: Jedes Attribut in der Tabelle wird eindeutig und voll funktional durch den Primärschlüssel IdTermin bestimmt.''


---
---


== Die 3. Normalform (3NF) ==
== Die 3. Normalform (3NF) ==
Ein Relationenschema befindet sich in der 3. Normalform (kurz '''3NF'''), wenn es in der 2NF ist und kein Attribut, das nicht zum Primärschlüssel gehört, von diesem '''transitiv abhängt'''.  
Ein Relationenschema befindet sich in der 3. Normalform (kurz '''3NF'''), wenn es in der 2NF vorliegt und '''kein Nicht-Schlüsselattribut transitiv vom Primärschlüssel abhängt'''. Ein Nicht-Schlüsselattribut darf also nicht durch ein anderes Nicht-Schlüsselattribut bestimmt werden.
 
Betrachten wir die Relation aus der 2NF: Mit Hilfe des Primärschlüssels `IdTermin` lässt sich eindeutig der Vorname eines Mitarbeiters, eines Kunden oder eines Salons bestimmen. Allerdings hängt der Salonname von der Salonnummer (SNR) ab und nur ''transitiv'' von `IdTermin`. Gleiches gilt für Kunden (KNR -> KVorname, KNachname) und Mitarbeiter (MNR -> MVorname, MNachname).
 
'''Umsetzung:''' Um das Schema in die 3NF zu überführen, müssen Kunden-, Mitarbeiter- und Saloninformationen in eine eigene Relation ausgelagert werden.


Betrachten wir die Relation aus der 2NF: Der Primärschlüssel `IdTermin` bestimmt eindeutig den Mitarbeiter und den Salon. Allerdings hängt der ''Salonname'' fachlich von der Identität des Salons ab und somit nur indirekt (transitiv) vom Termin. Gleiches gilt für die Kunden (Kunden-ID bestimmt KVorname und KNachname) und Mitarbeiter.


'''Umsetzung:''' Um transitive Abhängigkeiten aufzulösen, werden die zusammengehörigen Kunden-, Mitarbeiter- und Saloninformationen in eigene Relationen ausgelagert und über [[Fremdschlüssel]] verknüpft.


'''Tabelle: Salon'''
'''Tabelle: Salon'''
Zeile 114: Zeile 109:
|}
|}


''Das Schema befindet sich nun in der 3NF. Es herrschen nur direkte vollfunktionale Abhängigkeiten. Durch [[Fremdschlüssel|Fremdschlüsselbeziehungen]] bleibt der Bezug der Daten untereinander erhalten. Das Ziel der redundanzfreien Datenhaltung ist erreicht.''
''Das Schema befindet sich nun vollständig in der 3NF. Es existieren ausschließlich direkte, voll funktionale Abhängigkeiten vom jeweiligen Primärschlüssel der Tabelle. Die Verknüpfung der Daten bleibt durch die Fremdschlüssel erhalten, während das Ziel der redundanzfreien Datenhaltung erreicht wurde.''


[[Kategorie:Datenbanken]]
[[Kategorie:Datenbanken]]
[[Kategorie:AHR_I_Informatik LK]]
[[Kategorie:AHR_I_Informatik LK]]
[[Kategorie:FI_I_SDM]]
[[Kategorie:FI_I_SDM]]

Aktuelle Version vom 17. April 2026, 10:55 Uhr

Einführung

Die Normalisierung eines relationalen Datenbankmodells bezeichnet den strukturierten Prozess, Attribute anhand fester Regeln (Normalformen) auf mehrere Relationen (Tabellen) aufzuteilen. Das primäre Ziel dieses Vorgangs ist es, ein Datenbankschema zu erstellen, das frei von vermeidbaren Redundanzen (Datenverdopplungen) ist.

Eine redundanzarme Datenspeicherung ist essenziell für die Datenintegrität. Enthält ein Schema Redundanzen, führt dies bei Aktualisierungen häufig zu Anomalien (Einfüge-, Änderungs- oder Löschanomalien). Mehrfach gespeicherte Daten könnten beispielsweise nur teilweise geändert werden, was zu widersprüchlichen und inkonsistenten Datenbeständen führt. Zudem belegt redundante Speicherung unnötigen Speicherplatz.

Es gibt verschiedene formale Grade der Normalisierung (Erste, Zweite, Dritte Normalform etc.). Ein relationales Schema wird normalisiert, indem es anhand seiner funktionalen Abhängigkeiten schrittweise in kleinere Relationen zerlegt (dekomponiert) wird. Diese Zerlegung muss zwingend verlustfrei erfolgen – es dürfen keine Informationen verloren gehen.

In der Praxis wird vor allem in der Entwurfsphase einer relationalen Datenbank normalisiert. Ein sauberer logischer Modellentwurf, beispielsweise durch ein Entity-Relationship-Modell (ERM), erfüllt oft bereits von vornherein die wichtigsten Normalformen. Dennoch dient die formale Normalisierung als wichtiges Prüfinstrument, um verbliebene Redundanzen aufzudecken.

Beispiel der Normalisierungsschritte

Folgendes Schema wird exemplarisch aus einem denormalisierten Ausgangszustand schrittweise in die 3. Normalform überführt.

Ausgangssituation (Nicht normalisiert)

In diesem Zustand weist die Tabelle zwei massive Strukturfehler auf: Es existieren Attribute mit mehreren Werten (Wiederholungsgruppen beim Termindatum) und nicht atomare Werte (Vor- und Nachname stehen gemeinsam in einem Feld).

Kundenname Mitarbeitername Salon Termindatum
Klaus Meyer Sabine Krause Hammer Haare 11.10.2012, 14.10.2012
Paula Meyer Claudia Schrotter Friedrich List Frisuren 09.11.2012

---

Die 1. Normalform (1NF)

Ein Relationenschema befindet sich in der 1. Normalform (kurz 1NF), wenn die Wertebereiche aller Attribute atomar sind. Das bedeutet, dass jeder Attributwert eine unteilbare Informationseinheit darstellen muss (z. B. muss eine Adresse in Straße, Hausnummer, PLZ und Ort aufgeteilt werden). Zudem sind Wiederholungsgruppen (Listen oder Arrays in einem Feld) unzulässig.

Um ein Schema in die 1NF zu überführen, müssen zusammengesetzte Attribute aufgespalten und Wiederholungsgruppen durch das Anlegen neuer Datensätze (Zeilen) aufgelöst werden.

Umsetzung: Die Spalten Mitarbeitername und Kundenname werden jeweils in Vor- und Nachname (KVorname, KNachname, MVorname, MNachname) zerlegt. Für die beiden Termindaten von Klaus Meyer wird die Zeile dupliziert, sodass pro Zelle nur noch ein Datum steht.

KVorname KNachname MVorname MNachname Salon Termindatum
Klaus Meyer Sabine Krause Hammer Haare 11.10.2012
Klaus Meyer Sabine Krause Hammer Haare 14.10.2012
Paula Meyer Claudia Schrotter Friedrich List Frisuren 09.11.2012

Die Relation erfüllt nun die Kriterien der 1. Normalform.

---

Die 2. Normalform (2NF)

Ein Relationenschema befindet sich in der 2. Normalform (kurz 2NF), wenn es sich in der 1NF befindet und jedes Nicht-Schlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist.

Um diese Bedingung zu prüfen, muss zunächst ein Primärschlüssel identifiziert werden. Im obigen Beispiel aus der 1NF gibt es keine natürliche Attributkombination, die einen Termin eindeutig identifiziert (ein Kunde könnte am selben Tag beim selben Mitarbeiter mehrere Termine haben).

Umsetzung: Die praktikabelste Lösung ist die Einführung eines künstlichen Primärschlüssels (Surrogatschlüssel). Die Tabelle wird um die Spalte `IdTermin` erweitert, die fortlaufend durchnummeriert wird.

IdTermin KVorname KNachname MVorname MNachname Salon Termindatum
1 Klaus Meyer Sabine Krause Hammer Haare 11.10.2012
2 Klaus Meyer Sabine Krause Hammer Haare 14.10.2012
3 Paula Meyer Claudia Schrotter Friedrich List Frisuren 09.11.2012

Die Relation befindet sich nun in der 2NF: Jedes Attribut in der Tabelle wird eindeutig und voll funktional durch den Primärschlüssel IdTermin bestimmt.

---

Die 3. Normalform (3NF)

Ein Relationenschema befindet sich in der 3. Normalform (kurz 3NF), wenn es in der 2NF vorliegt und kein Nicht-Schlüsselattribut transitiv vom Primärschlüssel abhängt. Ein Nicht-Schlüsselattribut darf also nicht durch ein anderes Nicht-Schlüsselattribut bestimmt werden.

Betrachten wir die Relation aus der 2NF: Der Primärschlüssel `IdTermin` bestimmt eindeutig den Mitarbeiter und den Salon. Allerdings hängt der Salonname fachlich von der Identität des Salons ab und somit nur indirekt (transitiv) vom Termin. Gleiches gilt für die Kunden (Kunden-ID bestimmt KVorname und KNachname) und Mitarbeiter.

Umsetzung: Um transitive Abhängigkeiten aufzulösen, werden die zusammengehörigen Kunden-, Mitarbeiter- und Saloninformationen in eigene Relationen ausgelagert und über Fremdschlüssel verknüpft.

Tabelle: Salon

SNR Salonname
1 Hammer Haare
2 Friedrich List Frisuren

Tabelle: Mitarbeiter

MNR MVorname MNachname FK_SNR
1 Sabine Krause 1
2 Claudia Schrotter 2

Tabelle: Kunde

KNR KVorname KNachname
1 Klaus Meyer
2 Paula Meyer

Tabelle: Termin

IdTermin FK_KNR FK_MNR Termindatum
1 1 1 11.10.2012
2 1 1 14.10.2012
3 2 2 09.11.2012

Das Schema befindet sich nun vollständig in der 3NF. Es existieren ausschließlich direkte, voll funktionale Abhängigkeiten vom jeweiligen Primärschlüssel der Tabelle. Die Verknüpfung der Daten bleibt durch die Fremdschlüssel erhalten, während das Ziel der redundanzfreien Datenhaltung erreicht wurde.

Abgerufen von „https://wiki.flbk-hamm.de/index.php?title=Normalisierung&oldid=2803“