Normalisierung - Versionsgeschichte

Flbkwikiadmin am 17. April 2026 um 08:55 Uhr

2026-04-17T08:55:51Z

Flbkwikiadmin am 16. April 2026 um 12:30 Uhr

2026-04-16T12:30:03Z

← Nächstältere Version		Version vom 16. April 2026, 14:30 Uhr
Zeile 6:		Zeile 6:
	Es gibt verschiedene Grade der Normalisierung: Die so genannte erste, zweite, dritte usw. Normalform. Diese Normalformen sind durch formale Anforderungen definiert.		Es gibt verschiedene Grade der Normalisierung: Die so genannte erste, zweite, dritte usw. Normalform. Diese Normalformen sind durch formale Anforderungen definiert.

			Man bringt ein relationales Schema in eine Normalform, indem man für sie geltende [[funktionale Abhängigkeit]]en in einfachere Relationen zerlegt, bis keine weitere Zerlegung mehr möglich ist. Dabei dürfen jedoch keine Daten verloren gehen.

	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.		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.
Zeile 48:		Zeile 46:

	== 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 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#Volle_funktionale_Abhängigkeit\|vollständig 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.		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.

Flbkwikiadmin am 16. April 2026 um 12:28 Uhr

2026-04-16T12:28:12Z

← Nächstältere Version		Version vom 16. April 2026, 14:28 Uhr
Zeile 48:		Zeile 48:

	== 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]] ~~'''~~vollständig funktional abhängig~~'''~~ ist.		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.

	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.		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.

Flbkwikiadmin: Die Seite wurde neu angelegt: „== Einführung == Unter '''Normalisierung''' eines relationalen Datenbankmodells versteht man die Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln und deren Normalformen, sodass ein Schema entsteht, das keine vermeidbaren '''Redundanzen''' mehr enthält. Das Ziel ist die redundanzfreie Datenspeicherung. Ein Schema, das Redundanzen enthält, kann dazu führen, dass bei Änderungen die…“

2026-04-16T12:23:59Z

Die Seite wurde neu angelegt: „== Einführung == Unter '''Normalisierung''' eines relationalen Datenbankmodells versteht man die Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln und deren Normalformen, sodass ein Schema entsteht, das keine vermeidbaren '''Redundanzen''' mehr enthält. Das Ziel ist die redundanzfreie Datenspeicherung. Ein Schema, das Redundanzen enthält, kann dazu führen, dass bei Änderungen die…“

Neue Seite

== 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.

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.

Es gibt verschiedene Grade der Normalisierung: Die so genannte erste, zweite, dritte usw. Normalform. Diese Normalformen sind durch formale Anforderungen definiert.

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 ==
Folgendes Schema wird exemplarisch aus einem denormalisierten Zustand in die 3. Normalform überführt.

=== 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).
{| class="wikitable"
! 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) ==
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.

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.

'''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.

{| class="wikitable"
! 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
|}
''Nun befindet sich die Tabelle in der 1NF!''

---

== 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]] '''vollständig 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.

'''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.

{| class="wikitable"
! 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 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 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'''.

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.

'''Tabelle: Salon'''
{| class="wikitable"
! SNR !! Salonname
|-
| 1 || Hammer Haare
|-
| 2 || Friedrich List Frisuren
|}

'''Tabelle: Mitarbeiter'''
{| class="wikitable"
! MNR !! MVorname !! MNachname !! FK_SNR
|-
| 1 || Sabine || Krause || 1
|-
| 2 || Claudia || Schrotter || 2
|}

'''Tabelle: Kunde'''
{| class="wikitable"
! KNR !! KVorname !! KNachname
|-
| 1 || Klaus || Meyer
|-
| 2 || Paula || Meyer
|}

'''Tabelle: Termin'''
{| class="wikitable"
! 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 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.''

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