BESTELLUNG - Wirtschaftsinformatik HTW Berlin

HTW Berlin Prof. Dr. Zschockelt Datenmodellierung/Datenbanken (03)RDM-Normalisierung.ppt Folie 1 

Die Güte von 

Datenmodellen 

etwas genauer 

betrachtet 

(Normalformen des RDM)


Güte von Datenmodellen 

Die Güte oder auch Qualität von Datenmodellen kann unterschiedlich sein und wird 

neben der richtigen Darstellung des Inhalts (Semantik) auch an bestimmten formalen 

Kriterien gemessen, wie z. B. an 

• dem Grad der Redundanzfreiheit, 

• dem Schutz vor potentiellen Inkonsistenzen (Anomalien), 

• der Übersichtlichkeit und leichten Handhabbarkeit des Datenmodells, 

• der Effizienz potentieller Datenzugriffe usw. 

Zwei mögliche Wege führen zu "guten“ Datenmodellen 

Normalisierung von Relationen 

Ein vorgegebener Entwurf niedriger 

Güte soll verbessert werden. 

Ausgangspunkte sind 

funktionale Abhängigkeiten zwischen 

Attributen und 

gegebene ggf. "schlechte" Relationen 

Synthese von Relationen 

Es soll von vornherein ein "optimales" 

Modell konstruiert werden. 

Erst im 

Kapitel 4 

Semantische Beziehungen zwischen 

Datenobjekten (Entitys) und 

ermittelte Attribute der Entitys.


Was ist nun genau die Normalisierung 

Physische relationale Datenmodelle in 1NF können von schlechter Qualität 

sein, d. h. zu Doppelarbeiten und Fehlern im Umgang mit der modellierten 

Datenbank führen. 

Ursache dafür sind mögliche Redundanzen und Anomalien. 

Der Prozess der Qualitätsverbesserung eines physischen relationalen 

Datenmodells durch Beseitigung/Verminderung der Redundanzen und 

Anomalien wird Normalisierung genannt. 

Von besonderer Bedeutung für die Modellierung von relationalen 

Datenbanken (RDB) ist die dritte Normalform (3NF). 

Die Theorie der Normalisierung fußt auf funktionalen Abhängigkeiten 

zwischen den Attributen einer Relation. 

Neben dem theoretischen Ansatz der Normalisierung gibt es aus praktischer 

Sicht häufig auftretende semantische Beziehungstypen, die immer zum 

gleichen Resultat des Normalisierungsprozesses führen.


Redundanzen und Anomalien der Datenmanipulation im RDM 

Redundanz: Weitschweifigkeit, Überfluss (Überladung einer Information mit 

überflüssigen Informationselementen) 

Bestellung Lieferant Name Datum Artikel Bezeichnung Anzahl 

023 00102 Adler GmbH 02. 01. 2003 140 Topfix 200 

118 10033 Bussard AG 05. 03. 2003 237 Primus 30 

437 00102 Adler GmbH 28. 03. 2003 555 Leckerle 500 

540 20987 Zobel & Co. 02. 04. 2003 140 Topfix 120 

540 20987 Zobel & Co. 02. 04. 2003 555 Leckerle 180 

543 20987 Zobel & Co. 07. 04. 2003 237 Primus 20 

BESTELLUNG (Bestellung, Lieferant, Name, Datum, Artikel, Bezeichnung, Anzahl) 

Die Tabelle befindet sich in 1NF, ist also formal zulässig, aber qualitativ 

nicht hinreichend gut !



Redundanz: Weitschweifigkeit, Überfluss (Überladung einer Information mit 

überflüssigen Informationselementen) 









Alle grün gekennzeichneten Informationen sind aus 

unterschiedlichen Gründen redundant !



Anomalie: Unregelmäßigkeit, Regelwidrigkeit - (1) Einfügeanomalie 









Fehlende Attribute bei Einfügung von Tupeln. 

679 Mopsfidel



Anomalie: Unregelmäßigkeit, Regelwidrigkeit - (2) Änderungsanomalie 








BESTELLUNG (Bestellung, Lieferant, Name, Datum, Artikel, Bezeichnung, Anzahl)







437 00102 Adler GmbH 28. 03. 2003 555 Nimmmich 500 











437 00102 Adler GmbH 28. 03. 2003 555 Nimmmich 500 


540 20987 Zobel & Co. 02. 04. 2003 555 Nimmmich 180 



Mehrfach gespeicherte Attribute zwingen zur mehrfachen Änderung des 

Sachverhaltes.



Anomalie: Unregelmäßigkeit, Regelwidrigkeit - (3) Löschanomalie 











Anomalie: Unregelmäßigkeit, Regelwidrigkeit - (3) Löschanomalie 









Unzweckmäßiges Löschen von Attributen bei Löschung eines Tupels als 

semantische Einheit. 

(Die Firmeninformation "Lieferant Name" (10033 Bussard AG) geht beim 

Löschen der Bestellung verloren, obwohl möglicherweise bei diesem 

Lieferanten erneut bestellt wird.)


Funktionale Abhängigkeiten 

Definition 

Ein Attribut A2 einer Relation R(A1,A2,...) heißt funktional abhängig vom 

Attribut A1 der Relation R, wenn zu jedem Wert a i (a i Є A1) höchstens ein Wert 

a k (a k Є A2) möglich ist. 

Beispiel: 

Artikelcode Bezeichnung Besteller 

0105 Zucker Meyer 

0105 Zucker Schulze 

0237 Mehl Meyer 

0105 Zucker Müller 

2356 Salz Moppel 

2356 Salz Meyer 

0105 Zucker Meyer 

Darstellung: Artikelcode Bezeichnung


Volle funktionale Abhängigkeit 

Definition 

Ein Attribut A2 einer Relation R(A1.1,A1.2,...A2,...) heißt voll funktional abhängig 

von einer zusammengesetzten Gruppe von Attributen A1.n der Relation R, 

wenn A2 funktional abhängig von der Gruppe A1.n, nicht aber funktional abhängig 

von einem beliebigen Teilattribut A1.j ist. 

Beispiel: 

Artikelcode Bezeichnung Lieferer Datum kg 

0105 Zucker Meyer 12.04.2003 100 

0105 Zucker Schulze 12.04.2003 150 

0237 Mehl Meyer 18.04.2003 200 

0105 Zucker Müller 22.04.2003 50 

2356 Salz Moppel 29.04.2003 30 

2356 Salz Meyer 04.05.2003 50 

0105 Zucker Meyer 04.05.2003 75 

Darstellung:(Artikelcode, Lieferer, Datum) ⇒ kg


Der Prozess der Normalisierung 

Das Normalisieren einer Relation (Tabelle) wird immer durch Aufteilung 

der Relation auf mehrere Relationen realisiert. Es wird so 

lange normalisiert, bis die nach der Aufteilung neu entstandenen 

Relationen der erwünschten Normalform entsprechen. 

Beispiel: 

Diese Relation 

befindet sich 

in 1NF 

Artikelcode Bezeichnung Lieferer Datum kg 

0105 Zucker Meyer 12.04.2003 100 

0105 Zucker Schulze 12.04.2003 150 

0237 Mehl Meyer 18.04.2003 200 

Diese Relationen befinden sich in 3NF 

Artikelcode Lieferer Datum kg 

0105 Meyer 12.04.2003 100 

0105 Schulze 12.04.2003 150 

0237 Meyer 18.04.2003 200 

Artikelcode Bezeichnung 

0105 Zucker 

0105 Zucker 

0237 Mehl


1. Normalform (1NF) nochmals zur Wiederholung 

Alle Attribute müssen elementar ( auch: atomar) sein. 

Konsequenz: Es darf kein Attribute geben, die aus Listen oder ähnlichen 

zusammen gesetzen Werten bestehen. 

Negativbeispiel: 

BEWERTUNG(Matrikelnummer, Name, Vorname, SG, Notenliste) 

ist nicht in 1NF, wenn in Notenliste z. B. "1,3;2,0;2,3;1,3" steht.


2. Normalform (2NF) 

Volle funktionale Abhängigkeit der Nichtschlüsselattribute von 

allen aus mehreren Attributen zusammengesetzten Schlüsseln. 

Konsequenz: Es darf kein Attribut des zusammengesetzten Primärschlüssels 

entfernt werden, ohne dass dabei die funktionale Abhängigkeit 

jedes Nichtschlüsselattributs vom Primärschlüssel verloren geht. 


BESTELUNG(Lieferantencode, ArtikelNr, Datum, Lieferer, Ort, Menge, Preis) 

Abhängigkeit Lieferantencode ,ArtikelNr, Datum ⇒ gilt nicht für alle Attribute. 

Aus Vereinfachungsgründen wir hier vorausgesetzt, dass ein Artikel bei dem 

gleichen Lieferanten nur einmal täglich bestellt werden kann.


3. Normalform 

Was sind transitive Abhängigkeiten? 

Definition: Wenn A B und B C, 

Beispiel: 

dann ist A C 

eine transitive Abhängigkeit 

A N R 

P re is 

L a g e r 

B e z 

O rt 

B e st 

.


3. Normalform (3NF) 

Ausschaltung transitiver funktionale Abhängigkeit zwischen 

einem Nichtschlüsselattribut und einem Schlüsselattribut. 

Konsequenz: Ein Nichtschlüsselattribut darf funktional nur vom Primärschlüssel 

und nicht von einem weiteren Nichtschlüsselattribut 

abhängig sein. 


ARTIKEL(ArtikelNr, Bezeichnung, VK_Preis, Bestand, LagerNr, LagerOrt) 

Transitive funktionale Abhängigkeit: ArtikelNr ⇒ LagerNr ⇒ LagerOrt 

(allerdings nur unter der Voraussetzung, dass zu jeder Lagernummer 

immer nur genau ein Lagerort gehört).


Fazit zur Normalisierungstheorie 

Nach den (theoretischen) Regeln der Normalisierung lässt sich 

eindeutig die Normalform einer Relation bestimmen. 

Relationen lassen sich folglich immer in 3NF normalisieren. Es 

gibt für spezielle Fälle jedoch noch weitere Normalformen (4NF, 

5NF) und Normalisierungsverfahren (z. B. Boyce Codd Normalform 

– BCNF). 

siehe dazu Elmasri/Navathe: "Grundlagen von Datenbanksystemen", 

Addison-Wesley 2002 oder Kudraß: “Taschenbuch 

Datenbanken“, Hanser 2007, S.92f. 

Aus betriebswirtschaftlicher (semantischer) Sicht führen typische 

Beziehungskonstellationen zu vorhersehbaren Normalisierungsproblemen. 

Bei Erkennen der typischen Beziehungskonstellation 

kann das daraus resultierende Normalisierungsproblem auch 

durch praktische Erfahrung gelöst werden siehe Folien 26, 27!


Damit alles 

o. K. ? 

Leider nein !


Ausgewählte Probleme der Normalisierung 

Obwohl die Normalisierung die grundlegende Methode zur Erzielung guter 

physischer Datenmodelle ist, ist sie nicht problemlos. 

Folgende 4 Probleme sollen näher beleuchtet werden: 

(1) Pseudo-Primärschlüssel täuschen 2NF vor bzw. erschweren das 

Erkennen transitiver Abhängigkeiten. 

(2) Ungeeignete Datentypen für Primärschlüssel führen zu 

Effektivitätsverlusten. 

(3) "Übernormalisierte" Relationen führen zu 

Effizienzverlusten und können unechte Tupel beim späteren 

Joining verursachen. 

(4) Nicht für jede Anwendung sind normalisierte Relationen die beste 

Lösung.



(1) Pseudo-Primärschlüssel täuschen 2NF vor. 

Durch das Hinzufügen einer laufenden Nummer kann ein künstlicher Primärschlüssel 

erzeugt werden. Formal befindet sich damit die Relation in 2NF, aber 

gut ist sie damit nicht. 

Beispiel: BESTELUNG(LiefererNr, ArtikelNr, Lieferer, Ort, Datum, Menge, Preis) 

wird durch Hinzufügen einer laufenden Nummer (LNR) zu 

BESTELUNG(Lnr, LiefererNr, ArtikelNr, Lieferer, Ort, Datum, Menge, Preis) 

Semantisch bedingte funktionale Abhängigkeiten werden dadurch möglicherweise 

erschwert wahrgenommen (nicht volle funktionale Abhängigkeit wandelt sich zur 

transitiven Abhängigkeit). 

LNR (laufende Nummerierung) hat bei richtiger Normalisierung häufig keinen 

Informationsgehalt mehr und kann gelöscht werden (Ausnahme: Reihenfolge der 

Tupel soll dokumentiert werden). 

Hier "greift" die BCNF (Boyce/Codd-Normalform) jede minimale Determinate 

muss ein Schlüsselkandidat sein.



(2) Ungeeignete Datentypen für Primärschlüssel führen zu Effektivitätsverlusten. 

Jeder Primärschlüssel führt bei der Implementierung des physischen 

Datenmodells auf ein Datenbank Manangement System (DBMS) zu einem 

Index (primary key und/oder foreign key), um Zugriffszeiten zu minimieren. 

Dieser soll speicheroptimal (kurz, einfacher Datentyp) sein. 

Beispiel: Student (Name, Vorname, GebDat, Studiengang, …) 

Der Primärschlüssel Name, Vorname, GebDat) ist nach der Normalisierungstheorie 

durchaus gültig, aber zu kompliziert zusammengesetzt und bei 

Datentypen wie z. B. Varchar(60) und Datetime entstehen daraus völlig 

ineffiziente Indizes. 

Besser ist hier das zusätzliche Hinzufügen eines prägnanten Kurzschlüssels, wie 

z. B. einer Immatrikulationsnummer mit Datentyp char(6) oder integer.



(3) "Übernormalisierte" Relationen führen zu Effizienzverlusten und können 

unechte Tupel beim späteren Joining verursachen. 

In der Präsentation der normalisierten Daten mittels Joining (siehe relationale 

Algebra) können sogenannte "unechte Tupel" entstehen, die falsche 

Informationen vortäuschen siehe dazu Elmasri/Navathe: "Grundlagen von 

Datenbanksystemen", Addison-Wesley 2002, Abschnitt 14.1 

Beispiel:Projekt (PersNr, Projektnr, Name, Stunden, Projektort) 

Diese Relation befindet sich nicht in 2NF, da Name nur von PersNr funktional 

abhängig ist. Das Projekt könnte aber an mehreren Standorten (Projektort) 

realisiert werden und ein Mitarbeiter kann an mehreren Standorten tätig sein. 

Eine Normalisierung 

PersProjekt (Persnr, Projektnr, Stunden, Projektort) und 

PersOrte (Name, Projektort) 

liefert Relationen in 3NF, wäre aber fatal fehlende Verbundtreue!



(4) Nicht für jede Anwendung sind normalisierte Relationen die beste Lösung. 

Die Normalisierung ist eindeutig auf eine optimierte Datenspeicherung gerichtet 

(Vermeidung von Redundanzen und Anomalien, Sicherung der Integrität), nicht 

auf anwendungsabhängige Kriterien der Datennutzung. 

Bei DB-Anwendungen, wo die Optimierung der Datenspeicherung keine oder 

nur eine sehr untergeordnete Rolle spielt, kann bewusst auf die 3NF und 

höhere NFverzichtet werden. 

Man bezeichnet dies auch als denormalisierte Relation. 

Beispiel: Zeit (Zeitkey, Bezeichnung, Monat, Quartal, Jahr, Wochentag) 

Derartige Relationen werden häufig als "Dimensionstabellen" in Data Warehouse 

Modellen verwendet. Hier ist der schnelle Zugriff auf nur eine Datenbanktabelle 

wichtiger als ein Update, welches bei einmal richtigen Daten ohnehin nie mehr 

erforderlich ist.


Anhang zur Normalisierungstheorie 

zwei typische semantische Beziehungstypen (1) 

Ein- und mehrwertige Attribute in einer Relation, die ein Objekt 

beschreibt, führen immer zur Verletzung der 2NF. 

Sie müssen als Master-Detail-Beziehung immer mit zwei oder 

mehr Relationen beschrieben werden. 

Beispiel: 

BESTELLUNG (Bestellung, Lieferant, Name, Datum, Artikel, Anzahl, Nettopreis) 

Die bestellten Artikel, ihre Bezeichnung und Anzahl sind ein Detail des 

Masters BESTELLUNG, das in einer Bestellung mehrfach vorkommen 

kann. 

Die Lösung: BESTELLUNG (Bestellung, Lieferant, Name, Datum) 

POSTEN (Bestellung, Artikel, Anzahl, Nettopreis)


Anhang zur Normalisierungstheorie 

zwei typische semantische Beziehungstypen (2) 

Dynamische Domänen dienen zur Verwaltung eines sehr großen 

und/oder stark veränderlichen Wertevorrats für ein Attribut, dessen 

Konsistenz über die referentielle Integrität geprüft wird. 

Dynamische Domänen müssen deshalb immer in einer eigenen 

Relation verwaltet werden. 

Beispiel: 

BESTELLUNG (Bestellung, Artikel, Anzahl, Nettopreis) 

ARTIKELKATALOG (Artikel, Artikelbezeichnung) 

Artikel in der Tabelle BESTELLUNG ist ein Fremdschlüssel, der die 

referentielle Abhängigkeit von der Tabelle ARTIKELKATALOG widerspiegelt. 

Generell gilt aber: 

Semantische Beziehungen zwischen Objekten werden vorrangig in 

semantischen Datenmodellen (z. B. ERM) wirksam.


Zusammenfassung zur Normalisierungstheorie 

Die Normalisierung von Relationen dient der optimalen Speicherung von 

Daten, unabhängig vom Verwendungszweck. 

Es gibt in der Theorie 5 Normalformen (5NF) sowie die zwischen der 

3NF und 4NF definierte Boyce-Codd-Normalform (BCNF). 

Für praktische Anwendungen der Wirtschaftsinformatik dominiert die 

3NF als Mindestanforderung. 

Der Verwendungszweck von Daten kann mit dem Ziel eines besonders 

schnellen Datenzugriffs zu häufig benutzen Zugriffsmustern führen. 

Sofern dieses Ziel eine höhere Priorität als die Datenmanipulation hat, 

kann eine Denormalisierung einzelner Relationen sinnvoll sein. 

Es gibt unterschiedliche theoretische Ansatzpunkte zur Methodik der 

Normalisierung. Ein in der Wirtschaftsinformatik häufig auftretender 

praktikabler Ansatz besteht im Erkennen von Master-Detail-Beziehungen 

und in der Verwendung dynamischer Domänen.

BESTELLUNG - Wirtschaftsinformatik HTW Berlin

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?