Normalformen - Versionsgeschichte

Admin: Textersetzung - „mussswiki.idv.edu“ durch „mussswiki.idb.edu“

2018-10-01T13:09:55Z

Textersetzung - „mussswiki.idv.edu“ durch „mussswiki.idb.edu“

← Nächstältere Version		Version vom 1. Oktober 2018, 15:09 Uhr
Zeile 81:		Zeile 81:

	== Zitiervorschlag ==		== Zitiervorschlag ==
	''Mittendorfer'' in ''Höller'', Informationsverarbeitung I, Normalformen (mussswiki.~~idv~~.edu/iv1)		''Mittendorfer'' in ''Höller'', Informationsverarbeitung I, Normalformen (mussswiki.idb.edu/iv1)

Cstitz: /* Zitiervorschlag */

2015-09-17T13:12:33Z

Zitiervorschlag

← Nächstältere Version		Version vom 17. September 2015, 15:12 Uhr
Zeile 81:		Zeile 81:

	== Zitiervorschlag ==		== Zitiervorschlag ==
	''Mittendorfer'' in ''Höller'', Informationsverarbeitung I ~~(24. 2. 2014)~~, Normalformen (mussswiki.idv.edu/iv1)		''Mittendorfer'' in ''Höller'', Informationsverarbeitung I, Normalformen (mussswiki.idv.edu/iv1)

Mstabauer am 15. September 2015 um 06:56 Uhr

2015-09-15T06:56:20Z

← Nächstältere Version		Version vom 15. September 2015, 08:56 Uhr
Zeile 1:		Zeile 1:
	<yambe:breadcrumb>Datenbanken\|Datenbanken</yambe:breadcrumb>		<div class='noprint'><yambe:breadcrumb>Datenbanken\|Datenbanken</yambe:breadcrumb></div>
	{{Kurzform\|Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes.}}		{{Kurzform\|Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes.}}

Khager: /* Zitiervorschlag */

2014-09-23T12:58:47Z

Zitiervorschlag

← Nächstältere Version		Version vom 23. September 2014, 14:58 Uhr
Zeile 81:		Zeile 81:

	== Zitiervorschlag ==		== Zitiervorschlag ==
	''Mittendorfer'' in ''~~Pils~~'', Informationsverarbeitung I (24. 2. ~~2013~~), Normalformen (mussswiki.idv.edu/iv1)		''Mittendorfer'' in ''Höller'', Informationsverarbeitung I (24. 2. 2014), Normalformen (mussswiki.idv.edu/iv1)

Elisaka am 5. März 2013 um 16:33 Uhr

2013-03-05T16:33:11Z

← Nächstältere Version		Version vom 5. März 2013, 18:33 Uhr
Zeile 1:		Zeile 1:
	~~<!--~~<yambe:breadcrumb>Datenbanken\|Datenbanken</yambe:breadcrumb~~>--~~>		<yambe:breadcrumb>Datenbanken\|Datenbanken</yambe:breadcrumb>
	{{Kurzform\|Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes.}}		{{Kurzform\|Der Aufbau relationaler Datenbanken, ersichtlich in den Inhalten ihrer Tabellen und deren Beziehungen untereinander, zielt in erster Linie auf die Vermeidung von Redundanzen ab. Sogenannte Normalformen können als Gesetze zur Konstruktion von Tabellen betrachtet werden, deren Einhaltung zur weitgehenden Vermeidung von Redundanzen führen. Die Normalformen sind Gegenstand des folgenden Lernschrittes.}}

Hans4mido: /* Dritte Normalform: Vermeidung von transitiven Abhängigkeiten */

2013-02-25T21:16:41Z

Dritte Normalform: Vermeidung von transitiven Abhängigkeiten

← Nächstältere Version		Version vom 25. Februar 2013, 23:16 Uhr
Zeile 58:		Zeile 58:

	Berücksichtigt man die Zustellbezirke der Post, so kann festgestellt werden, dass jeder Postleitzahl eindeutig ein Zustellbezirk (zur zeitweiligen Verwirrung auch "Ort" genannt) zugeordnet werden kann. Das Feld ''Ort'' hängt demnach vom Feld ''Plz'' ab und muss ausgelagert werden.		Berücksichtigt man die Zustellbezirke der Post, so kann festgestellt werden, dass jeder Postleitzahl eindeutig ein Zustellbezirk (zur zeitweiligen Verwirrung auch "Ort" genannt) zugeordnet werden kann. Das Feld ''Ort'' hängt demnach vom Feld ''Plz'' ab und muss ausgelagert werden.
	Die ohne Berücksichtigung der 3. Normalform also falsch ~~abgeleitete~~ Tabellen wären:		Die ohne Berücksichtigung der 3. Normalform also falsch konstruierte Tabellen wären:

	* ''Verlag'' (Kurzbezeichnung, Name, Kundennummer, Strasse, Plz, Ort)		* ''Verlag'' (Kurzbezeichnung, Name, Kundennummer, Strasse, Plz, Ort)
	* ''Kunde'' (Nr, Vorname, Nachname, Strasse, Plz, Ort)		* ''Kunde'' (Nr, Vorname, Nachname, Strasse, Plz, Ort)

	Adressen werden des Feldes ''Ort'' entledigt und es entsteht eine neue Tabelle mit der Bezeichnung ''PLZ'' ~~mit~~ den Spalten ~~PLZ~~, Ort und Region.		Adressen werden des Feldes ''Ort'' entledigt und es entsteht eine neue Tabelle mit der Bezeichnung ''PLZ'' und den Spalten Plz, Ort und Region.

	Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:		Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:

Hans4mido: /* Dritte Normalform: Vermeidung von transitiven Abhängigkeiten */

2013-02-25T21:13:38Z

Dritte Normalform: Vermeidung von transitiven Abhängigkeiten

← Nächstältere Version		Version vom 25. Februar 2013, 23:13 Uhr
Zeile 63:		Zeile 63:
	* ''Kunde'' (Nr, Vorname, Nachname, Strasse, Plz, Ort)		* ''Kunde'' (Nr, Vorname, Nachname, Strasse, Plz, Ort)

	~~Sie~~ werden des Feldes ''Ort'' entledigt und es entsteht eine neue Tabelle mit der Bezeichnung ''PLZ'', ~~die – wie soll es anders sein – über das Schlüsselfeld ''Plz'' mit ihrer ursprünglichen Heimat verbunden werden~~.		Adressen werden des Feldes ''Ort'' entledigt und es entsteht eine neue Tabelle mit der Bezeichnung ''PLZ'' mit den Spalten PLZ, Ort und Region.

	Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:		Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur:

Hans4mido: /* Zitiervorschlag */

2013-02-24T15:51:41Z

Zitiervorschlag

← Nächstältere Version		Version vom 24. Februar 2013, 17:51 Uhr
Zeile 81:		Zeile 81:

	== Zitiervorschlag ==		== Zitiervorschlag ==
	''Mittendorfer'' in ''Pils'', Informationsverarbeitung I (27. 2. ~~2012~~), Normalformen (mussswiki.idv.edu/iv1)		''Mittendorfer'' in ''Pils'', Informationsverarbeitung I (24. 2. 2013), Normalformen (mussswiki.idv.edu/iv1)

Hans4mido: /* Erste Normalform: Entfernen von Wiederholgruppen */

2013-02-24T15:49:06Z

Erste Normalform: Entfernen von Wiederholgruppen

← Nächstältere Version		Version vom 24. Februar 2013, 17:49 Uhr
Zeile 21:		Zeile 21:
	== Erste Normalform: Entfernen von Wiederholgruppen ==		== Erste Normalform: Entfernen von Wiederholgruppen ==

	Jedes Feld darf im Datensatz '''nur einmal''' vorkommen. Gibt es mehrere Felder vom '''gleichen Typ''', so müssen diese in einer '''eigenen ~~Relation~~''' gespeichert werden.		Jedes Feld darf im Datensatz '''nur einmal''' vorkommen. Gibt es mehrere Felder vom '''gleichen Typ''', so müssen diese in einer '''eigenen Tabelle''' gespeichert werden.

	Die Überführung der Objektklasse ''Auftrag'' in eine Tabelle ~~(Relation)~~ könnte der verbalen Beschreibung des Geschäftsmodells entsprechend „Jeder Auftrag kann mehrere Bücher enthalten, die jeweils in beliebiger Menge geordert werden können“ bzw. in Anlehnung an das ER-Diagramm folgende Struktur aufweisen:		Die Überführung der Objektklasse ''Auftrag'' in eine Tabelle könnte der verbalen Beschreibung des Geschäftsmodells entsprechend „Jeder Auftrag kann mehrere Bücher enthalten, die jeweils in beliebiger Menge geordert werden können“ bzw. in Anlehnung an das ER-Diagramm folgende Struktur aufweisen:

	* ''Auftrag'' (Nr, Kundennummer, Datum, Positionsnummer, Buchnummer, Menge, Positionsnummer, Buchnummer, Menge, ...)		* ''Auftrag'' (Nr, Kundennummer, Datum, Positionsnummer, Buchnummer, Menge, Positionsnummer, Buchnummer, Menge, ...)
Zeile 31:		Zeile 31:
	[[Bild:Datenmodell_3.gif]]		[[Bild:Datenmodell_3.gif]]

	Das Feld ''Nr'' in der Tabelle ''Auftrag'' (''Auftrag.Nr'') ist das Schlüsselfeld der Tabelle ''Auftrag'' und wird daher mit dem Feld ''~~Auftragspos.~~Auftragsnummer'' verbunden. Die Namen der beiden Felder unterscheiden sich zwar, aber der Inhalt ist in beiden Fällen ident. Hier zeigt sich eine unvermeidbare Redundanz in relationalen Datenbanken, weshalb man auch von '''kontrollierter Redundanz''' und nicht von redundanzfrei spricht.		Das Feld ''Nr'' in der Tabelle ''Auftrag'' (''Auftrag.Nr'') ist das Schlüsselfeld der Tabelle ''Auftrag'' und wird daher mit dem Feld ''Auftragsnummer'' der Tabelle Auftragsposition verbunden. Die Namen der beiden Felder unterscheiden sich zwar, aber der Inhalt ist in beiden Fällen ident. Hier zeigt sich eine unvermeidbare Redundanz in relationalen Datenbanken, weshalb man auch von '''kontrollierter Redundanz''' und nicht von redundanzfrei spricht.

	Für die Erfüllung der im ~~(detaillierten)~~ Geschäftsmodell beschriebenen Aufgaben (z. B. Rechnungslegung) sind detaillierte Daten über die Bücher (z. B. der Preis) erforderlich. Wie auch aus dem ER-Diagramm ersichtlich ist, gibt es eine Verbindung zwischen der Tabelle ''Auftrag'' und der Tabelle ''Buch'' über die neu gebildete Tabelle ''Auftragspos''. Die Notwendigkeit zur Neubildung einer Tabelle zwischen ''Auftrag'' und ''Buch'' ist auch aus ihrer m:n-Beziehung ableitbar.		Für die Erfüllung der im Geschäftsmodell beschriebenen Aufgaben (z. B. Rechnungslegung) sind detaillierte Daten über die Bücher (z. B. der Preis) erforderlich. Wie auch aus dem ER-Diagramm ersichtlich ist, gibt es eine Verbindung zwischen der Tabelle ''Auftrag'' und der Tabelle ''Buch'' über die neu gebildete Tabelle ''Auftragspos''. Die Notwendigkeit zur Neubildung einer Tabelle zwischen ''Auftrag'' und ''Buch'' ist auch aus ihrer m:n-Beziehung ableitbar.

	[[Bild:Datenmodell_4.gif]]		[[Bild:Datenmodell_4.gif]]

Hans4mido: /* Der Sinn der Normalisierung */

2013-02-24T15:37:34Z

Der Sinn der Normalisierung

← Nächstältere Version		Version vom 24. Februar 2013, 17:37 Uhr
Zeile 13:		Zeile 13:
	* Wie viele Spalten sollen in welcher Tabelle angelegt werden?		* Wie viele Spalten sollen in welcher Tabelle angelegt werden?

	Die Antwort auf diese Fragen gibt mitunter die sogenannte '''Normalisierung'''. Mit Hilfe der Regeln der Normalisierung wird es möglich, die Datenbank ideal zu strukturieren. Dadurch werden '''Redundanzen''' vermieden: Diese erfordern nämlich nicht nur einen größeren Speicherbedarf, sondern führen auch zu einer erhöhten Fehleranfälligkeit, beispielsweise bei Wartungstätigkeiten. Sollen Daten, die an mehr als einem Speicherort vorhanden sind, geändert werden, müssen diese Änderungen an allen Speicherorten auf exakt die gleiche Art und Weise vorgenommen werden. So ist beispielsweise die Änderung einer Kundenandresse wesentlich einfacher, wenn die betreffenden Daten nur in der Tabelle ''~~Kuonde~~'' gespeichert sind und nicht auch noch an anderen Orten innerhalb der Datenbank.		Die Antwort auf diese Fragen gibt mitunter die sogenannte '''Normalisierung'''. Mit Hilfe der Regeln der Normalisierung wird es möglich, die Datenbank ideal zu strukturieren. Dadurch werden '''Redundanzen''' vermieden: Diese erfordern nämlich nicht nur einen größeren Speicherbedarf, sondern führen auch zu einer erhöhten Fehleranfälligkeit, beispielsweise bei Wartungstätigkeiten. Sollen Daten, die an mehr als einem Speicherort vorhanden sind, geändert werden, müssen diese Änderungen an allen Speicherorten auf exakt die gleiche Art und Weise vorgenommen werden. So ist beispielsweise die Änderung einer Kundenandresse wesentlich einfacher, wenn die betreffenden Daten nur in der Tabelle ''Kunde'' gespeichert sind und nicht auch noch an anderen Orten innerhalb der Datenbank.

	== Normalisieren der Tabellen ==		== Normalisieren der Tabellen ==