Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

6 Normalformen Normalisieren Schlüssel

Ähnliche Präsentationen


Präsentation zum Thema: "6 Normalformen Normalisieren Schlüssel"—  Präsentation transkript:

1 6 Normalformen Normalisieren Schlüssel
Unter Normalisieren versteht man das Aufteilen der Daten in Relationen. Diese Aufteilung soll einerseits den praktischen Anforderungen durch das Anwendungsprogramm gerecht werden, andererseits soll diese Aufteilung die Konsistenzerhaltung unterstützen und ermöglichen. Insbesondere sollen Redundanzen (also das mehrfach Speichern der gleichen Daten) vermieden werden. Die einzelnen Relationen können in einem späteren Entwicklungsschritt auf Tabellen abgebildet werden. Schlüssel sind eindeutige Kennzeichen einzelner Datensätze einer Tabelle.

2 Datenmodell Das Entwickeln einer Anwendung mit Hilfe einer relationalen Datenbank erfordert die Entwicklung eines Datenmodells, das möglichst exakt die zu bearbeitenden Daten der realen Welt widerspiegelt. Wenn Programme entwickelt werden, die eine relationale Datenbank als Datenbasis haben, ist es notwendig, die Datenstrukturen sehr sorgfältig zu entwickeln. Die Datenstrukturen bilden das Fundament für die nachfolgenden Programme und sollten so angelegt sein, daß die in Zukunft zu entwickelnden Programme die vorhandenen Daten in beliebiger Kombination nutzen können und neue Daten in die vorhandenen Strukturen eingepasst werden können. Datenbankstrukturen sind sehr langlebig und können durch aus 15 bis 20 Jahre alt werden. Das Alter einer Anwendungssoftware wird in der Regel mit ca. 5 Jahren angenommen.

3 Datensammlung Diese Datensammlung ist eintypisches Beispiel für eine mangelhafte Datenstruktur. Hans ist für den Studiengang Informatik und Information Management eingeschrieben. Die Abfrage nach allen Studenten, die Information Management studieren ist schwierig. Studiengang und Regelstudienzeit sind an einen Eintrag eines Studenten gebunden. Wenn z.B. der Eintrag von Else gelöscht wird, verschwindet die Information über die Regelstudienzeit von Information Management. Die Information, dass die Regelstudienzeit für Informatik 9 Semester beträgt, wird mehrfach wiederholt. Bei einer Änderung müssen alle Einträge geändert werden. Ebenso wird die Information, dass Jutta die Matrikel Nr hat, mehrfach wiederholt.

4 Gründe für das Normalisieren
Vermeidung unerwünschter Abhängigkeiten bei Datenmanipulationen Gundlage für ein leicht erweiterbares Datenmodell Verständliches Datenmodell Elimination von Redundanzen Systematisches Auseindersetzen mit den Daten Durch ungeschickte Zusammenfassung einzelner Datenelemente können Abhängigkeiten erzeugt werden, die bei der Bearbeitung der Daten hinderlich sind und im täglichen Umgang mit den darauf aufbauenden Programmen stören können. In dem oben angegebene Beispiel gibt es keinen Grund, die Regelstudienzeit und die Note eines einzelnen Studenten in die gleiche Tabelle zu schreiben. Ein gut entwickeltes Datenmodell bietet die Grundlage für neue Anwendungsprogramme, die zur Zeit der Entwicklung des Datenmodells noch nicht geplant waren. Diese neuen Programme benötigen in der Regel zusätzliche Daten, die sich in das bestehende Datenmodell einpassen müssen. Ein umfangreiches Datenmodell wird von vielen Anwendungsentwicklern genutzt um zum Teil ganz spezielle Programme für einzelne Fachabteilungen zu erstellen. Weiterhin kann es für Abfragen an die Datenbank benutzt werden. Für alle Nutzer des Datenmodells ist eine verständliche und leicht zu lernenede Präsentation des Datenmodells notwendig. Redundanzen sind mehrfache Aussagen des gleichen Sachverhaltes. Wenn ein Sachverhalt auch mehrfach in der Datenbank gespeichert ist, kann es bei Änderungen zu Unstimmigkeiten führen, die die Glaubwürdigkeit der Datenbank in Frage stellen. Die Unstimmigkeiten treten dann auf, wenn Redundanzen vorhanden sind und nicht bekannt sind oder bei der Anwendungsentwicklung nicht berücksichtigt werden. Der Datenbankentwickler bekommt in der Regel unvollständige und widersprüchliche Vorgaben von den einzelnen Fachabteilungen. Das Normalisieren ist eine Möglichkeit, sich systematisch mit Datenstrukturen auseinanderzusetzen um Widersprüche aufzudecken und zu klären.

5 Funktionale Abhängigkeit
In der Relation R(A,B) ist das Attribut B von dem Attribut A funktional abhängig, falls zu jedem Wert von A genau ein Wert von B gehört. A wird Determinante von B genannt. Beispiel: Zu jedem Studiengang (A) gehört genau eine Regelstudienzeit (B). Eine weitere funktionale Abhängigkeit besteht zwischen dem Namen und der Matrikelnummer einer Studentin. Nicht funktional abhängig voneinander sind der Name und die Vorlesung. Es gibt nicht zu jedem Namen genau eine Vorlesung, die die Studentin besucht.

6 Volle funktionale Abhängigkeit
In der Relation R(S1, S2, A) ist das Attribut A von den Attributen S1, S2 voll funktional abhängig, wenn A von den zusammengesetzten Attributen (S1, S2) abhängig ist, nicht aber von je einem einzelnen Attribut S1 oder S2. Beispiel: Die Note (A) ist von den beiden Attributen Name (S1) und Vorlesung (S2) abhängig. Keines der beiden Attribute Name (S1) oder Studiengang (S2) bestimmt allein die Note (A).

7 Transitive Abhängigkeit
In der Relation R(S, A, B) ist das Attribut B transitiv von S abhängig, wenn A von S funktional abhängig ist, aber S nicht von A; und B ist funktional von A abhängig ist. Beispiel: Der Studiengang (A) ist vom Namen (S) des Studenten abhängig; jedem Studenten ist also ein Studiengang zugeordnet. Der Name ist aber nicht von Studiengang abhängig. Die Regelstudienzeit (B) ist vom Studiengang (A) abhängig, aber nicht vom Studenten (S).

8 Berechnete Attribute Beispiel:
Ein weiteres Beispiel für eine transitive Abhängigkeit ist die Berechnung eines Attributes aus einem oder mehreren Attributen. Das berechnete Attribut kann entweder in der Datenbank gespeichert werden oder jeweils bei der Abfrage berechnet werden. Die Entscheidung für eine der beiden Lösungen hängt unter Anderem von folgenden Faktoren ab: Aufwand und Kosten für die Berechnung: Statistische Berechnungen aus großen Datenmengen können sehr aufwendig sein und entweder bei der Eingabe eines neuen wertes oder bei der Abfrage des berechneten Wertes den Rechner erheblich belasten. Häufigkeit der Eingabe von Werten und Häufigkeit der Abfrage der berechneten Werte: Wenn häufig neue Werte eingegeben weden, aber die berechneten Werte selten abgefragt werden, kann eine Berechnung bei der Abfrage sinnvoll sein. Wenn die Eingaben selten geändert werden, die berechneten Werte aber häufig abgefragt werden, kann ein redundantes Speichern der berechneten Werte die bessere Lösung sein. Reproduzierbarkeit der Berechnung: Die Kosten in der eigenen und einer fremden Währung sind abhängig vom Tageskurs und können unter Umständen zu einem späteren Zeitpunkt nicht mehr reproduziert werden. Aktualität des berechneten Attributs: Wenn sich die Eingangsgrößen häufig ändern und die Berechnung der Ausgangsgröße sehr aufwendig ist, kann essinnvoll sein, diese Berechnung in Zeiten minimaler Rechnerauslastung mit den dann aktuellen Eingagnsgrößen durchzuführen. Dadurch können Inkonsistenzen auftreten, die gegen den Performancegewinn abgewogen werden müssen.

9 Schlüssel Sei X = {A1, ..., An} die Menge aller Attribute einer Relation R(A1,..., An). Eine Teilmenge SÍX von Attributen ist ein Schlüsselkandidat, wenn gilt: X ist funktional von S abhängig Die funktionale Abhängigkeit gilt nicht für eine echte Teilmenge von S Mit einem Schlüssel, der sich aus einem oder mehreren Attributen zusammensetzen kann, kann jedes Tupel der Relation eindeutig definiert werden. In älteren, hierarchischen Datenbanksystemen (z.B. IMS) ist der Zugriff über einen Schlüssel die einzige Möglichkeit, ein bestimmtes Tupel aus der Datenbank zu lesen. Der Schlüssel wird dabei intern in den Speicherplatz auf der Platte umgerechnet. Der Datenzugriff über den Schlüssel ist häufig von einem prozeduralen Programmierstil geprägt und es besteht die Gefahr, dass dieser Programmierstil auch auf Bereiche angewendet wird, in denen das deklarative, mengenorientierte Programmieren sinnvoller ist. Die hier betrachteten Schlüssel dienen der Identifikation von Datensätzen. Sie haben nichts mit den Schlüsseln gemeinsam, die zur Verschlüsselung von Informationen eingesetzt werden!

10 Schlüssel Eigenschaften eines Schlüssels eindeutig
unmittelbar zuteilbar kurz schreibbar Ein Schlüssel sollte Eindeutig sein: Für jedes Tupel gibt es genau einen Schlüssel, das es definiert und dieser Schlüssel definiert auch nur ein Tupel. Der Schlüssel wird im Leben des Tupels nicht geändert. Unmittelbar zuteilbar sein: Beim Anlegen eines neuen Tupels soll der Schlüssel sofort vergeben werden können. Dies muß auch möglich sein, wenn ein zentraler Rechner nicht verfügbar ist. Kurz sein: Aber bitte nie Speicherplatz auf Kosten der Lesbarkeit sparen!! Schreibbar sein: Da der Schlüssel das dazugehörende Tupel definiert, ist es wahrscheinlich, daß er zur Auswahl dieses Tupels eingegeben werden muß.

11 Sprechende Schlüssel Der Schlüssel enthält einen Hinweis auf das Tupel, das er identifiziert Vorteil: leicht zu merken für eine manuelle Bearbeitung der Tupel Nachteil: Bei der Änderung eines Attributs des Tupels kann sich der Schlüssel ändern

12 Sprechende Schlüssel Beispiel
Identifikation eines Personaldatensatzes über den Personennamen Vorteil: leicht zu merken Nachteil: Zwei Personen gleichen Namens Namensänderung komplizierte Namen Sprechende Schlüssel sind sinnvoll, wenn der Schlüssel oder Teile davon außerhalb der EDV benötigt oder reproduziert werden, um auf konventionelle Archive zuzugreifen. Die Patientenakten in der Medizinischen Hochschule Hannover werden durch eine patientenidentifikation gekennzeichnet, die folgende Form hat: tt.mm.jj-nngzp mit: tt.mm.jj Geburtsdatum nn Namenskürzel: die ersten zwei Buchstaben des Geburtsnamen werden in die Zahlen 00 bis 99 abgebildet. g Geschlechtskennzeichen z Mehrfachzähler: sind alle Ziffern bis hier identisch, wird hier eine Unterschiedung herbeigeführt. p Prüfziffer

13 Verdeckter Schlüssel Beispiel
Der Schlüssel wird nur für datenbankinterne Kennzeichnung benutzt und bleibt dem Anwender verborgen Beispiel: mehrsprachiger Katalog Fehlermeldungen Stücklisten sind Kataloge, in denen beschrieben aus welchen Einzelteilen ein Produkt aufgebaut ist. Sie sind ein Kommunikationsmittel zwischen der Entwicklungsabteilung und der Fertigungsabteilung. Bei großen Firmen ist es möglich, dass Entwicklungsabteilung und Fertigungsabteilung in unterschiedlichen Ländern sind. Die Einzelteile müssen dann automatisch in der jeweiligen Landessprache angezeigt werden.Sie werden dann durch einen internen sprachabhängigen Schlüssel gekennzeichnet, der dem Anwender verborgen ist. Eine Datenbankanwendung erzeugt bei Fehleingaben Hinweistexte und Fehlermeldungen. Diese Texte können entweder in das Programm integriert sein oder entsprechend dem Fehlercode aus einer Datenbanktabelle gelesen und angezeigt werden. Die zweite Möglichkeit ist empfehlenswert, wenn die Anwendung mehrsprachig ist. Dann können die Texte in den verschiedenen Sprachen gespeichert werden und entsprechend der gewünschten Sprache angezeigt werden.

14 Künstlicher Schlüssel Beispiel
Der Schlüssel wird bei Bedarf vom Rechner generiert. Der Anwender hat keinen Einfluß auf den Wert des Schlüssels. Beispiel: fortlaufend generierte Martikel Nummer Ein vom Rechner generierter künstlicher Schlüsel setzt voraus, dass der Rechner verfügbar ist, wenn der Schlüssel benötigt wird. Falls eine Identifizierung unverzüglich erforderlich sein sollte und die Gefahr eines Rechnerausfalles gegeben ist, müssen Alternativen für die Identifizierung vorhanden sein.

15 Schlüsselkandidaten Zu einer gegebenen Relation kann es mehr als eine Attributkombination geben, die die Kriterien für einen Schlüssel erfüllt. Die Attributkombination (Matr, Vorlesung) erfüllt die Kriterien, denn alle Tupel der Relation sind funktional von (Matr, Vorlesung) abhängig und keine Teilmenge von (Matr, Vorlesung) erfüllt die Kriterien. Das gleiche gilt für die Kombination (Name, Vorlesung). Die Kombination (Matr, Name, Vorlesung) erfüllt zwar die Bedingung der funktionalen Abhängigkeit, die Teilmengen (Matr, Vorlesung) und (Name, Vorlesung) sind aber auch Schlusselkandidaten. Damit scheidet (Matr, Name, Vorlesung) aus. Das Attribut (Note) ist auch ein Schlüsselkandidat für diese Relation, denn die Tupel sind funktional davon abhängig und keine Teilmenge von (Note) erfüllt die gleiche Bedingung. Das gleiche gilt für die Kombination (Vorlesung , Studiengang). Diese Beispiele zeigen, dass nicht jeder syntaktisch mögliche Schlüsselkandidat auch ein sinnvoller Schlüssel ist.

16 Erste Normalform Eine Relation ist in der ersten Normalform (1NF), wenn alle Attribute nur atomare Werte enthalten. Beispiel für eine Relation, die nicht in der ersten Normalform ist: Relationen in einem Datenmodell, das den oben angegebnen Kriterien genügt, sollten bestimmte formale Eigenschaften besitzen. Diese Eigenschaften werden durch die Normalformen definiert. In diesem Fall besteht der Attributwert für Studiengang aus zwei Angaben. Die Definition eines atomaren Wertes ist nicht immer ganz einfach. Ein Datum wird gewöhnlich als atomarer Wert aufgefasst, obwohl es sich als eine Struktur mit mehreren einzelnen Werten präsentiert. Ähnlich kann ein in ein Textfeld eingegebener Satz als eine Folge von Worten angesehen werden.

17 Zweite Normalform Eine Relation ist in der zweiten Normalform (2NF), wenn sie in der 1NF ist und jedes Nicht-Schlüssel-Attribut voll funktional abhängig ist vom Gesamtschlüssel. In dem Eingangsbeispiel ist (Matr, Vorlesung) ein möglicher Schlüssel. Die Note ist voll funktional davon abhängig, da sie nur der Kombination dieser beiden Schlüssel zugeordnet werden kann. Der Studiengang hingegen ist von der Matr abhängig. Also ist das Beispiel nicht in der dritten Normalform.

18 Beispiel nicht zweite Normalform
Die Note ist abhängig von der Matrikel Nr und der Vorlesung Der Studiengang ist vom Teilschlüssel, der Matrikel Nr abhängig.

19 Dritte Normalform Eine Relation ist in der dritten Normalform (3NF), wenn sie in der 1NF und der 2NF ist und keine transitiven Abhängigkeiten enthält. In dem Eingangsbeispiel ist die Regelstudienzeit abhängig vom Studiengang und dieser ist abhängig von der Matrikel Nr.

20 Beispiel nicht dritte Normalform
Die Note ist abhängig von der MatrikelNr und der Vorlesung Die verbale Beschreibung der Note ist nur abhängig von der Note, also transitiv abhängig von dem Schlüssel.

21 Normalisieren Datensammlung:
Für Hans existieren in einem Tupel mehrfache Einträge. Das widerspricht der ersten Normalform, nach der nur atomare Werte erlaubt sind.

22 Normalisieren Nicht-atomare Einträge auflösen:
Der eine Eintrag für Hans wird durch zwei Einträge für unterschiedliche Studiengänge ersetzt.

23 Normalisieren Schlüsel suchen :
Es werden zwei Tabellen gebildet, deren Tupel jeweils von einem Schlüssel voll funktional abhängig sind. Die erste Tabelle enthält die Studentendaten und jede Zeile wird durch die Matrikel Nr definiert. Die zweite Tabelle enthält die Noten und wird durch den Studenten und die Vorlesung definiert.

24 Normalisieren Transitive Abhängigkeiten auflösen :
Die jetzt enthaltenen Tabellen sind in der dritten Normalform und geeignet für ein übersichtliches Datenmodell.

25 Normalize until it hurts
Normalisieren Normalize until it hurts Denormalize until it works Eine Datensammlung sollte solange normalisiert werden, bis alle beteiligten Relationen in der dritten Normalform vorliegen. Dann liegen in der Regel sehr viele kleine Tabellen vor. Danach können gezielt durch die Anwendung bedingte Anormalien konstruiert werden. Diese Anormalien werden gewöhnlich erzeugt, um ein schnelleres Antwortzeitverhalten zu erreichen, da Abfragen über sehr viele Tabellen unter Umständen sehr langsam sein können. Sie sollten sorgfältig dokumentiert und begründet werden um nachfolgenden Programmierern die Arbeit zu erleichtern.

26 Zusammenfassung Normalisieren ist eine Bottom-Up Methode zum strukturieren der Daten Die 3NF hat keine funktionalen und transitiven Abhängigkeiten


Herunterladen ppt "6 Normalformen Normalisieren Schlüssel"

Ähnliche Präsentationen


Google-Anzeigen