Das Relationenmodell
Beziehungen
zwischen Entitätsmengen
Der Normalisierungsprozess
1. Normalform
2. Normalform
3. Normalform
Elimination
von Attributen
Schlussbemerkung
Glossar
Anhang
Das Relationenmodell ist einfach und leicht verständlich, da es auf 'nahe liegenden' Konzepten basiert.
Das Relationenmodell ermöglicht eine systematische Analyse der Daten, es bietet sinnvolle Hilfen bei der Gruppierung der Merkmale.
Es ist nicht nur ein Modell für ein logisches Datensystem, sondern ist auch aus eine redundanzfreie, physische Speicherung ausgerichtet, ohne dass damit das vorgesehene physische Datenmodell oder gar die künftige Verwendung der Daten durch die Entwurfsarbeit präjudiziert würde.
Das auf Relationenbasis entworfene Datensystem lässt sich gut darstellen und ist mit vernünftigem Aufwand auf heute vorhandene DB-Systeme übertragbar.
Assoziationstyp (EM1, EM2) | Entitäten aus EM2, die jeder Entität
aus der Menge EM1 zugeordnen sind |
1: (einfache Assoziation)
c: (konditionelle Assoziation) m: (multiple Assoziation) mc: (multipel-konditionelle Ass.) |
genau eine
keine oder eine (c=0/1) mindestens eine (m >=1) keine, oder mehrere (mc >=0) |
Entitätsmenge 1 | Entitätsmenge 2 | Beziehungstyp | Beziehung |
rechte Schuhe
Abteilungen Personal Kinder Frauen Personen Projekte Standorte Vorlesungen Personen |
linke Schuhe
Personal Abteilungen Ehepaare Männer Parteien Projekte Standorte Studenten Personen |
1-1
c-1 m-1 mc-1 c-c m-c mc-c m-m mc-m mc - mc |
Paare
Abteilungsleiter Abteilungszugeh. Familienzugeh. Heirat Parteizugeh. ist Unterprojekt Distanz Einschreibung Freundschaften |
Die Aufgabe des Normalisierungsprozesses besteht darin, Redundanzen zu erkennen und zu eliminieren. Redundanz ist in einem Datenbestand genau dann vorhanden, wenn ein Teil davon ohne Informationsverlust weggelassen werden kann. Dieser weglassbare Teil heisst entsprechend 'redundante Information'. Datenbank. Überlegungen beabsichtigen in vielen Fällen die Elimination unnötiger Redundanz, insbesondere wegen des Speicheraufwandes und weil sog. Mutationsanomalien auftreten können, wenn redundant gespeicherte Daten nicht mutiert werden.
Mit der Erkennung von Abhängigkeiten wird ersichtlich, welche Attributswerte aus anderen Attributswerten abgeleitet werden können. Dadurch werden allfällige Redundanzen und Mutationsanomalien sichtbar.
Ziel der Normalisierung ist es, die Attribute so zu Entitätsmengen (und damit zu Relationen) zuzuordnen, dass innerhalb einer Relation keine Redundanzen auftreten. Dabei ist zu beachten, dass Redundanzfreiheit der Relationen nicht für alle Zwecke der Arbeit mit Daten zweckmässig ist.
Die Normalisierung andererseits ist aber Voraussetzung für eine
saubere Datenanalyse.
Beispiel: | Eine Firma besteht aus Abteilungen mit je einem Abteilungsnamen (Abt-Nm) und einer Abteilungsnummer (Abt#). Jedes Projekt in der Firma wird im allgemeinen von mehreren Angestellten (P-Nm) bearbeitet und hat einen Projektnamen (Pjt-Nm) und eine Projektnummer (Pjt#). Alle Angestellten (P-Nm) haben eine Personalnummer (P#) und sie arbeiten teilweise an mehreren Projekten (P-Pjt), wobei jeweils bekannt ist, wie viel Arbeitszeit die einzelnen Angestellten für die einzelnen Projekte aufwenden (P-Pjt-Zeit). |
Hinweis: Das Zeichen # ist immer als 'Nummer' zu lesen.
(P# | P-Nm | Abt# | Abt-Nm | Pjt# | Pjt-Nm | P-Pjt-Zeit) |
101 | Hans | 1 | Physik | 11, 12 | A, B | 60, 40 |
102 | Rolf | 2 | Chemie | 13 | C | 100 |
103 | Urs | 2 | Chemie | 11, 12, 13 | A, B, C | 20, 50, 30 |
104 | Paul | 1 | Physik | 11, 13 | A, C | 80, 20 |
Eine Relation befindet sich in der 1. Normalform, wenn ihre Attribute nur einfache Attributswerte aufweisen.
Die obige Tabelle PERSONAL ist keine Relation in erster Normalform, da Pjt#, Pjt-Nm und Pjt-Zeit keine einfachen Attribute sind.
Diese Tabelle muss deshalb umgeschrieben werden, wobei sich die Bedeutung der Tupel ändern kann (Figur 2-7: Tupel = Person, Figur 2-8: Tupel = Person-Projekt-Beziehung). Der Informationsgehalt im Gesamten bleibt aber erhalten.
Fig. 2-8 zeigt jetzt eine definitionsgerechte Relation in der 1. Normalform.
Die Attributskombination (P#, Pjt#) ist ein Schlüssel dieser Relation.
(P# | P-Nm | Abt# | Abt-Nm | Pjt# | Pjt-Nm | P-Pjt-Zeit) |
101 | Hans | 1 | Physik | 11 | A | 60 |
101 | Hans | 1 | Physik | 12 | B | 40 |
102 | Rolf | 2 | Chemie | 13 | C | 100 |
103 | Urs | 2 | Chemie | 11 | A | 20 |
103 | Urs | 2 | Chemie | 12 | B | 50 |
103 | Urs | 2 | Chemie | 13 | C | 30 |
104 | Paul | 1 | Physik | 11 | A | 80 |
104 | Paul | 1 | Physik | 13 | C | 20 |
Man sieht sofort, dass die Relation in Fig. 2-8 Redundanzen enthält: Der Personenname ist aus der Personalnummer bestimmbar (=abhängig) und müsste eigentlich nicht für jedes Projekt wiederholt werden. Das kostet platz und/oder Arbeitsaufwand. Bei dieser Relation kann aber auch eine sog. Mutationsanomalie auftreten: Ändert der Name (Hans zu John) der Person mit P# = 101, so wird die Relation widersprüchlich, wenn die Namensänderung nur bei einem Tupel (z.B. beim ersten) ausgeführt würde. Das Problem liegt offensichtlich darin, dass die eine Relation in Fig. 2-8 verschiedene Sachverhalte (Personalien, Abteilungszugehörigkeit und Projektzuordnung der Personen) beschreibt, die jedoch unabhängig voneinander und zu unterschiedlichen Zeitpunkten ändern können. Es muss deshalb eine Aufspaltung in mehrere Relationen angestrebt werden.
Eine Relation ist in der 2. Normalform, wenn sie in der 1. Normalform ist und jedes nicht zum Identifikationsschlüssel gehörige Attribut voll von diesem abhängig ist.
Die 2. Normalform erzwingt damit eine erste Gruppierung der Attribute in einer Relation nach Sachgebieten und eliminiert dadurch Redundanzen.
Beispiel: Die Relation aus Fig. 2-8
PERSONEN-PROJEKT(P#, P-Nm, Abt#, Abt-Nm, Pjt#, Pjt-Nm,P-Pjt-Zeit)Für den 2. Normalisierungsschritt ist die Relation deshalb aufzuspalten in die folgenden drei Relationen (Schlüssel unterstrichen):mit dem Schlüssel (P#, Pjt#) ist nicht in der 2. Normalform, weil die Attribute P-Nm, Abt#, Abt-Nm, Pjt-Nm nicht voll abhängig sind von diesem Schlüssel. Pjt-Nm ist nur vom Schlüssel Pjt# und P-Nm nur vom Schlüssel P# abhängig.
PROJEKT(Pjt#, Pjt-Nm)
11 | A |
12 | B |
13 | C |
PERSONAL(P#, P-NM, Abt#, Abt-Nm)
101 | Hans | 1 | Physik |
102 | Rolf | 2 | Chemie |
103 | Urs | 2 | Chemie |
104 | Paul | 1 | Physik |
PROJEKTZUGEHOERIGKEIT(P#, Pjt#,P-Pjt-Zeit)
101 | 11 | 60 |
101 | 12 | 40 |
102 | 13 | 100 |
103 | 11 | 20 |
103 | 12 | 50 |
103 | 13 | 30 |
104 | 11 | 80 |
104 | 13 | 20 |
Die Relationen PROJEKT und PROJEKTZUGEHÖRIGKEIT enthalten nun keine Redundanzen mehr. in der Relation PERSONAL dagegen ist für jeden Angestellten der Abteilungsname gespeichert, obwohl sich dieser Name bereits aus der Abteilungsnummer ergibt. Ändert der Abteilungsname (oder irgendeine andere Eigenschaft der Abteilung), könnten somit noch immer Mutationsanomalien auftreten. um dies zu verhindern, ist ein 3. Normalisierungsschritt notwendig.
Eine Relation ist in der 3. Normalform, wenn sie in der 2. Normalform ist, und kein Attribut, das nicht zum Identifikationsschlüssel gehört, transitiv von diesem abhängt.
Die 3. Normalform bringt ein weiteres Kriterium zum Auftrennen von Relationen und eliminiert die beim 2. Normalisierungsschritt verbliebenen Redundanzen von Attributen.
Beispiel: Die Relation
PERSONEN-PROJEKT(P#, P-Nm, Abt#, Abt-Nm)Eine Aufspaltung von personal in Fig. 2-9 liefert zwei Relationen in 3. Normalform in Fig. 2-10.ist zwar in der 2., nicht aber in der 3. Normalform, weil das Attribut Abt-Nm über Abt# transitiv vom Schlüssel P# abhängt (oder umgekehrt auch Abt# über Abt-Nm).
PERSONAL(P#, P-Nm, Abt#)
101 | Hans | 1 |
102 | Rolf | 2 |
103 | Urs | 2 |
104 | Paul | 1 |
ABTEILUNG(Abt#,Abt-Nm)
1 | Physik |
2 | Chemie |
Relationen in der 3. Normalform (3. NF, englisch TNF) heissen oft auch 'normalisiert'.
Wenn wir eine Relation in 3. Normalform betrachten, so lässt sich daraus direkt keine weitere Umformung begründen. Dennoch können mehrere Relationen gemeinsam noch weitere Redundanzen aufweisen. Um diese erkennen zu können, führen wir die Begriffe der globalen bzw. lokalen Attribute ein.
Die Datenbasis muss aus Relationen in dritter Normalform bestehen, welche nur Global- und Lokal-Attribute enthalten.
Ein Attribut heisst global, wenn es mindestens in einer Relation im Identifikationsschlüssel vorkommt.
Ein Attribut heisst lokal, wenn es nur in einer Relation und dort nicht im Identifikationsschlüssel vorkommt.
In einer Datenbasis kann es nun aber Attribute geben, die weder global
noch lokal sind. Das ist dann der Fall, wenn die gleiche Eigenschaft einer
entität in zwei verschiedenen Relationen beschreiben wird. Diese Situation
tritt bei überlappenden Entitätsmengen auf. in einer solchen
datenbasis treten Redundanzen und Schwierigkeiten bei den Mutationen auf,
obwohl alle Relationen je in 3. Normalform sind (z.B. wenn Name und Adresse
gewisser 'Hochschulangehöriger', sowohl bei den 'Studenten', als auch
bei den 'Mitarbeitern' geführt werden, führt das zu Redundanz).
Man löst dieses Problem durch Einführung einer übergeordneten
Entitätsmenge, so dass man die gemeinsamen Merkmale der überlappenden
Entitätsmengen (hier also von Name und Adresse) einer einzigen Relation
zuordnen kann. Diese Massnahme ist gleichwertig mit der 'Elimination von
Attribitten, die weder global noch lokal sind'.
Beispiel: Die beiden Relationen
STUDENT(S#, Nm, Adr, Abt, Dozent)
MITARBEITER(M#, Nm, Adr, Lohnklasse)werden in folgende Relationen überführt:
HOCHSCHULANGEHOERIGER(P#, Nm, Adr)
STUDENTEN(P#, S#, Abt, Dozent)
MITARBEITER(P#, M#, Lohnklasse)
Mit den Normalisierungsschritten werden die häufigsten Fälle
von Redundanz durch das Verbot lokaler transitiver Abhängigkeit beseitigt,
und durch das Konzept der Global- und Lokal-Attribute kann man auch auf
globaler Ebene Redundanzlosigkeit erzwingen.
Attribute | Die Beschreibung einer Relation geschieht durch Attribute (Name, Adresse,
Personalnummer, Automarke)
z.B. PERSON (P#, P-Nm, Abt#, Abt-Nm) |
Entitäten | Eine Entität (entity) ist ein individuelles Exemplar von Elementen
der realen oder der Vorstellungswelt. Sofern eine Beziehung zwischen Entitäten
eine Bedeutung in der realen oder in der Vorstellungswelt hat, kann auch
ein individuelles Exemplar einer solchen Beziehung als Entität aufgefasst
werden.
z.B. K. Meier, die Ehe A-B, ein Jahrgang der Zeitschrift 'Feld und Wald' |
Entitätsmenge | Zusammenfassung von Entitäten.
z.B. Entität: 1 Student, 1 Doktor Entitätsmenge: Studenten, Doktoren |
Relation | Tabelle |
Transitiv Abhängig | Abhängig auch über schlüsselfremde Umwege
z.B. In der Relation PERSON (P#, P-Nm, Abt#, Abt-Nm) ist Abt-Nm transitiv abhängig von P#, da Abt# funktional von P# und Abt-Nm funktional von Abt# abhängt, während P# nicht funktional von Abt# abhängt. |
Tupel | Datenzeile einer Relation |
[1] Aus dem Buch 'Informationssysteme und Datenbanken'
von C. A. Zehnder
[2] Erstellt von T. Isler