Planung und Vorbereitung einer Datenbank
Planung und Vorbereitung einer Datenbank
Planung und Vorbereitung einer Datenbank
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Planung</strong> <strong>und</strong> <strong>Vorbereitung</strong> <strong>einer</strong> <strong>Datenbank</strong><br />
Ausgangssituation<br />
Der Bedarf bzw. das Angebot an Nachhilfeunterricht von Schülern für Schüler ist an unserer<br />
Schule gegeben. Leider ist es oft schwer Angebot <strong>und</strong> Nachfrage von Nachhilfeunterricht<br />
zu koordinieren. Einige Schüler wollen dieses Problem mit Hilfe <strong>einer</strong> <strong>Datenbank</strong> lösen.<br />
Gr<strong>und</strong>sätzlich soll gelten, dass der Ort, die Preise <strong>und</strong> die Zeiten für die Nachhilfe von den<br />
Betroffenen selbst festgelegt werden. Die Personendaten sollen über ein Formular erfasst<br />
<strong>und</strong> anschließend von der Schulsekretärin eingegeben werden. Die Abfrage der Daten<br />
wird unter Aufsicht <strong>einer</strong> weiteren Person durchgeführt.<br />
Für die Umsetzung der Problemstellung bleiben noch einige Fragen offen, die von der Arbeitsgruppe<br />
gelöst werden müssen.<br />
- Wie soll die <strong>Datenbank</strong> aufgebaut sein?<br />
- Welche Information soll die <strong>Datenbank</strong> liefern? (output)<br />
- Welche Informationen sollen in die <strong>Datenbank</strong> eingegeben werden? (input)<br />
Gr<strong>und</strong>legende Vorarbeiten<br />
Von der Problemstellung bis zur fertigen <strong>Datenbank</strong> sind es viele verschiedene Schritte.<br />
Ein <strong>Datenbank</strong>entwickler nutzt für die <strong>Datenbank</strong>konzeption das sogenannte Entity-<br />
Relationship-Modell (ER-Modell).<br />
Von der realen Welt zur <strong>Datenbank</strong><br />
Für die Entwicklung <strong>einer</strong> <strong>Datenbank</strong> ist es erforderlich, dass eine genaue Analyse der<br />
Objekte <strong>und</strong> Prozesse der Realwelt durchgeführt wird.<br />
Reale Welt Modellierung Datenmodell Abbildung Modellsicht<br />
Realität<br />
Maschine<br />
Bei der Analyse der Realität erkennt man, dass in den meisten Fällen die<br />
Mensch<br />
- Dinge der Realwelt als Objekte im Relationenmodell, auch Entities genannt, <strong>und</strong><br />
- Abhängigkeiten in einem Weltausschnitt durch Objektbeziehungen<br />
beschrieben werden können.<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 1 von 9
Auf unser Beispiel bezogen sind Fächer <strong>und</strong> Personen, die Nachhilfe in diesen Fächern<br />
erhalten oder geben wollen, Objekte. In einem Datenmodell fasst man gleichartige Objekte<br />
zu einem Objekttyp zusammen, also FACH bzw. PERSON.<br />
Der Vorgang der Nachhilfe bringt Objekte vom Typ FACH mit Objekten vom Typ PERSON<br />
in Beziehung. Man erkennt natürlich sofort, dass die Beziehungen zwischen Fächern <strong>und</strong><br />
Personen noch genauer beschrieben werden müssen. Es wird daher der Beziehungstyp<br />
NACHHILFE, der den konkreten Vorgang beschreibt, definiert. Welche Person gibt wem in<br />
welchem Fach Nachhilfe?<br />
- Objekttypen: FACH, PERSON<br />
- Beziehungstyp: NACHHILFE<br />
Jedem Objekttyp sind bestimmte Eigenschaften zugeordnet, die Attribute. Alle Objekte<br />
dieses Typs besitzen die gleichen Eigenschaften. Attribute für das Objekt vom Typ PER-<br />
SON können beispielsweise der Name, der Vorname, die Adresse oder das Geburtsdatum<br />
sein.<br />
Das Datenmodell Nachhilfeunterricht bildet folgende Prozesse ab: Eine Schule bietet verschiedenen<br />
Nachhilfeunterricht an (Entität FACH), der von verschiedenen Personen (Entität<br />
PERSON) durchgeführt wird. Dieser Prozess wird durch die Entität NACHHILFE beschrieben.<br />
Diese Art der Darstellung nennt man Entity-Relationship-Modell oder ER-<br />
Modell.<br />
Das Entity-Relationship-Modell<br />
Mit Hilfe des Entity-Relationship-Modells wird das <strong>Datenbank</strong>modell dem jeweiligen <strong>Datenbank</strong>system<br />
angepasst. Verwendet man ein relationales <strong>Datenbank</strong>system, müssen<br />
Tabellen auf der Gr<strong>und</strong>lage des ER-Modells definiert werden.<br />
Das ER-Modell ist ein Hilfsmittel für den Entwurf eines Datenmodells. Es beinhaltet grafische<br />
Formen zur Darstellung von Objekten (Entitäten) <strong>und</strong> deren Objektbeziehungen (Relationship).<br />
Element Bedeutung Symbol<br />
Entitytyp Objekttyp Rechteck<br />
Beziehung Objektbeziehung Raute<br />
Attribute Objekteigenschaften Ellipse<br />
Ein wichtiger Schritt der Modellierung ist die Festlegung der Entitäten. D. h., jeder Zustand,<br />
der in <strong>einer</strong> <strong>Datenbank</strong> abgebildet werden soll, muss zunächst analysiert <strong>und</strong> in<br />
kleinste Komponenten zerlegt werden.<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 2 von 9
Name<br />
Vorname<br />
Anrede<br />
(Tabellen unvollständig)<br />
PERSON<br />
ID-Person<br />
Telefon Klasse<br />
Nachhilfe<br />
Objekt Beziehung Objekt<br />
Nach dem Definieren der Entitäten legt man fest, in welcher Beziehung die Entitäten zueinander<br />
stehen.<br />
Prinzipiell unterscheidet man zwei Arten von Beziehungen: eindeutige <strong>und</strong> mehrdeutige<br />
Beziehungen. Bei eindeutigen Beziehungen gibt es immer genau eine Verbindung zwischen<br />
zwei Entitäten. Bei mehrdeutigen Beziehungen stehen eine oder mehrere Entitäten<br />
eines Entitätstyps mit <strong>einer</strong> oder mehreren Entitäten eines anderen Entitätstyps in Beziehung.<br />
Beziehungstyp Beschreibung Beispiel<br />
Eindeutig 1:1 Ein Objekt vom Typ A ist genau einem<br />
Objekt vom Typ B zugeordnet<br />
Funktional 1:n Jedes Objekt vom Typ A kann mit beliebig<br />
vielen Objekten des Typs B in<br />
Beziehung stehen; jedes Objekt vom<br />
Typ B steht genau mit einem Objekt<br />
vom Typ A in Beziehung<br />
Komplex n:m Jedes Objekt vom Typ A bzw. vom Typ<br />
B kann mit beliebig vielen Objekten<br />
des jeweilig anderen Typs in Beziehung<br />
stehen.<br />
FACH<br />
ID-Fach<br />
Fachname<br />
Die Person „Huber“ ist dem<br />
Fach „Deutsch“ zugeordnet.<br />
Der Person „Huber“ sind die<br />
Fächer „Deutsch, Englisch“<br />
zugeordnet.<br />
Die Fächer „Deutsch, Englisch“<br />
können nur der Person<br />
„Huber“ zugeordnet werden.<br />
Der Person „Huber“ sind die<br />
Fächer „Deutsch, Englisch“<br />
zugeordnet <strong>und</strong> der Person<br />
„Meier“ sind die Fächer<br />
„Deutsch, Englisch <strong>und</strong> Erdk<strong>und</strong>e“<br />
zugeordnet.<br />
Eindeutige Objektbeziehungen sind in der Realwelt eher selten anzutreffen. Häufiger tritt<br />
dagegen die 1:n- bzw. n:m-Beziehung auf.<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 3 von 9
Im Gegensatz zur 1:1- bzw. 1:n-Beziehung, die direkt in das relationale <strong>Datenbank</strong>system<br />
überführt werden kann, lässt sich die n:m-Beziehung nicht direkt im relationalen Datenmodell<br />
abbilden. In diesem Fall muss diese zuerst durch Definition <strong>einer</strong> neuen Entität in zwei<br />
1:n-Beziehungen überführt werden.<br />
In unserem Beispiel kann jede Person Nachhilfe in beliebig vielen Fächern wählen. Genauso<br />
können in jedem Fach beliebig viele Personen Nachhilfe bekommen.<br />
Relationales <strong>Datenbank</strong>modell<br />
Ein <strong>Datenbank</strong>modell beschreibt formale Regeln zur Verwaltung <strong>und</strong> Manipulation von<br />
Daten in einem <strong>Datenbank</strong>system.<br />
Begriffsklärung:<br />
Relation (Tabelle)<br />
Im relationalen Datenmodell werden Relationen durch Tabellen dargestellt, deren<br />
- Zeilen die Objekte <strong>einer</strong> Anwendungswelt repräsentieren, während die<br />
- Tabellenspalten die Attributeigenschaften dieser Objekte enthalten.<br />
Tabellenname (Entität)<br />
Der Tabellenname beschreibt einen Objekttyp, auch Entität oder Relation genannt. Im obigen<br />
Beispiel PERSON <strong>und</strong> FACH.<br />
Spaltenname (Attribut)<br />
Der Spaltenname beschreibt eine bestimmte Eigenschaft, wie beispielsweise Personenname<br />
oder Geburtsdatum. Jeder Spalte wird ein genau definierter Datentyp zugeordnet<br />
(z. B: Zahlen, Zeichenketten, Datum).<br />
Ist die Tabelle einmal definiert, können sowohl die Anzahl der Spalten als auch die Namen<br />
der Tabellenspalten nicht mehr verändert werden. Sollen später Änderungen erfolgen, so<br />
muss eine neue Tabelle definiert <strong>und</strong> der Inhalt der alten Tabelle übernommen werden.<br />
Tabellenzeile (Tupel)<br />
PERSON<br />
n<br />
Nachhilfe<br />
Die Zeilen <strong>einer</strong> Tabelle, auch Tupel oder Datensätze genannt, beinhalten die konkreten<br />
Daten für die einzelnen Objekte eines Objekttyps. Für den Objekttyp PERSON sind das<br />
beispielsweise konkrete Namen, Anschriften oder das Geburtsdatum.<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 4 von 9<br />
m<br />
FACH
Erstellen von Beziehungen zwischen Tabellen<br />
In <strong>einer</strong> <strong>Datenbank</strong> kommt es darauf an, dass zwischen den Tabellen Beziehungen hergestellt<br />
werden. Dazu werden Schlüsselattribute benötigt. Diese Schlüsselattribute sind die<br />
Voraussetzung für Tabellenverknüpfungen.<br />
Gr<strong>und</strong>sätzlich kann jedes Attribut <strong>einer</strong> Tabelle als Schlüsselattribut verwendet werden.<br />
Voraussetzung ist jedoch, dass die Werte dieses Attributs eindeutig sind, d. h., jeder Wert<br />
darf nur einmal vorkommen. Auf die Tabelle PERSON bezogen heißt das, dass wir eine<br />
Spalte benötigen, die eine laufende Nummerierung beinhaltet. Man nennt diese Spalte<br />
„ID-Person“. Diese Spalte wird als Primärschlüssel definiert.<br />
Um zwei Tabellen miteinander zu verknüpfen, muss eine Tabelle darüber hinaus einen<br />
Fremdschlüssel beinhalten. Ein Fremdschlüssel definiert ein Attribut, das in <strong>einer</strong> anderen<br />
Tabelle als Primärschlüssel vorkommt. Im Gegensatz zum Primärschlüssel, der nur einmal<br />
innerhalb <strong>einer</strong> Relation vergeben werden darf, ist es möglich, mehrere Fremdschlüssel in<br />
<strong>einer</strong> Relation zu definieren.<br />
Anwendung:<br />
In der <strong>Datenbank</strong> für die Nachhilfe gibt es bereits drei Relationen: FACH, PERSON,<br />
NACHHILFE.<br />
Relation FACH<br />
ID-Fach Name Klasse<br />
1 Deutsch 7<br />
2 Mathematik I 8<br />
Das Attribut ID-Fach wird als Primärschlüssel definiert. Durch den Primärschlüssel werden<br />
die Tupel <strong>einer</strong> Relation nicht einzeln, sondern als Menge betrachtet. Das hat den Vorteil,<br />
dass ein beliebiger Datensatz problemlos gelöscht oder eingefügt werden kann. Zur eindeutigen<br />
Darstellung wird der Primärschlüssel in unserer Tabelle unterstrichen.<br />
Relation PERSON (ist verkürzt dargestellt)<br />
ID-Person Name Adresse<br />
1 Willi Winzig München, Dachauer Straße 7<br />
2 H<strong>einer</strong> Winzig München, Dachauer Straße 3<br />
Nur eindeute Attribute können als Primärschlüssel verwendet werden. Da dies auf Name<br />
<strong>und</strong> Adresse nicht zutrifft, wurde die Spalte „ID-Person“ hinzugefügt.<br />
Relation NACHILFE<br />
ID-Nachhilfe ID-Fach ID-Person<br />
1 1 1<br />
2 2 1<br />
3 2 2<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 5 von 9
Die Relation NACHHILFE ist eine Beziehungsrelation. Sie besitzt zwei Attribute. Sie beinhaltet<br />
zwei Fremdschlüssel (ID-Fach <strong>und</strong> ID-Person). Beide sind bereits in den Tabellen<br />
FACH bzw. PERSON als Primärschlüssel enthalten.<br />
Auf diese Weise gelingt es uns, eindeutig festzustellen, welche Person in welchem Fach<br />
Nachhilfe erhält. Man erkennt auch, dass die Fremdschlüssel nicht eindeutig sein müssen.<br />
Durch die Definition der Fremdschlüssel erhalten wir eine 1:n-Beziehung zwischen der<br />
Relation Nachhilfe <strong>und</strong> Fach bzw. Nachhilfe <strong>und</strong> Person.<br />
FACH<br />
n 1 1 n<br />
NACHHILFE<br />
PERSON<br />
Das bedeutet konkret, dass in einem Fach mehrere Personen Nachhilfe erhalten können<br />
<strong>und</strong> dass eine Person in verschiedenen Fächern Nachhilfe bekommen kann. Auf diese<br />
Weise erhält man indirekt eine n:m-Beziehung zwischen den Tabellen FACH <strong>und</strong> PER-<br />
SON.<br />
Normalisierung<br />
Zur Gewährleistung <strong>einer</strong> widerspruchsfreien Datenverwaltung auf der Gr<strong>und</strong>lage des relationalen<br />
Datenmodells wurden von E. F. Codd eine Reihe von Regeln aufgestellt, die<br />
sogenannte Normalisierung. Von praktischer Bedeutung sind nur die ersten drei Normalformen,<br />
da sie weitgehend Dateninkonsistenzen <strong>und</strong> <strong>Datenbank</strong>anomalien ausschließen.<br />
Dateninkonsistenz:<br />
Unter Inkonsistenz versteht man einen Verweis <strong>einer</strong> Liste auf einen nicht vorhandenen<br />
Eintrag <strong>einer</strong> anderen Liste.<br />
<strong>Datenbank</strong>anomalie:<br />
Beim Arbeiten mit <strong>Datenbank</strong>-Tabellen können unter gewissen Umständen Zustände eintreten,<br />
die in dieser Form nicht gewollt sind (Inkonsistenz oder Datenverlust). Diese werden<br />
als Anomalien bezeichnet. Man unterscheidet Anomalien danach, wodurch sie zustande<br />
kommen: Änderungsanomalie, Updateanomalie, Einfügeanomalie, Löschanomalie,<br />
Mehrbenutzeranomalie. Anomalien können beseitigt werden, indem die Tabellen in eine<br />
entsprechende Normalform gebracht werden.<br />
Stufen des Normalisierungsprozesses:<br />
1. Normalform<br />
(1. NF)<br />
Atomisierung<br />
Alle Attribute <strong>einer</strong> Relation sollen in ihrer kleinsten Form vorliegen.<br />
Praktisch wirkt sich das so aus, dass in jeder Zeilen- oder Spaltenposition<br />
der Tabelle nur ein Wert vorkommt.<br />
Atomarer Wert: Ein Wert, der nicht in seine Bestandteile zerlegt werden kann<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 6 von 9
Diese Forderung lässt sich für unser Beispiel leicht erfüllen. Die Attribute „Name“ <strong>und</strong> „Adresse“<br />
müssen noch weiter zerlegt werden.<br />
Relation NACHHILFE<br />
ID-Nachhilfe ID-Person Name Adresse ID-Fach Fachname<br />
1 1 Willi Winzig München, Dachauer Straße 7 1 Deutsch<br />
2 2 H<strong>einer</strong> Winzig München, Dachauer Straße 3 2 Englisch<br />
Relation NACHHILFE (1. NF)<br />
ID-Nachhilfe ID-Person Name Vorname Ort Straße ID-Fach Fachname<br />
1 1 Winzig Willi München Dachauer Straße 7 1 Deutsch<br />
2 2 Winzig H<strong>einer</strong> München Dachauer Straße 3 2 Englisch<br />
2. Normalform<br />
(2. NF)<br />
Funktionale<br />
Abhängigkeit<br />
Eine Relation ist in der 2. NF, wenn sie sich in der 1. NF befindet<br />
<strong>und</strong> alle Nichtschlüsselfelder vom Gesamtschlüssel, aber nicht von<br />
Teilschlüsseln funktional abhängen.<br />
Wenn der Primärschlüssel nur aus einem Attribut besteht, ist jede<br />
Relation, die sich in der 1. NF befindet, zwangsläufig auch in der<br />
2. NF.<br />
Funktionale Abhängigkeit: Unter funktionaler Abhängigkeit versteht man, dass von einem<br />
Attributwert direkt auf einen anderen Attributwert geschlossen werden kann.<br />
Beispiel: Wenn Entität Y voll funktional von X abhängt, dann müssen in allen Tupeln, in denen sowohl X als<br />
auch Y vorkommt, die Werte der Attribute von X immer denselben Wert besitzen, ebenso wie die Werte von<br />
Y.<br />
Relation NACHILFE (1. NF)<br />
ID-Nachhilfe ID-Person Name Vorname Ort Straße ID-Fach Fachname<br />
1 1 Winzig Willi München Dachauer Straße 7 1 Deutsch<br />
2 2 Winzig H<strong>einer</strong> München Dachauer Straße 3 2 Englisch<br />
In unserem Fall ist das Attribut Fachname vom Attribut „ID-Nachhilfe“ abhängig <strong>und</strong> „ID-<br />
Nachhilfe“ ist ein Schlüsselattribut. Dagegen ist das Attribut „Ort“ vom Attribut „ID-Person“<br />
abhängig <strong>und</strong> „ID-Person“ ist kein Schlüsselattribut. Um diese Abhängigkeit zu beseitigen<br />
muss die Tabelle in zwei neue zerlegt werden.<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 7 von 9
Relation NACHHILFE (2. NF)<br />
ID-Nachhilfe ID-Person ID-Fach Fachname<br />
1 1 1 Deutsch<br />
2 2 2 Englisch<br />
Relation PERSON (2. NF)<br />
ID-Person Name Vorname Ort Straße<br />
1 Winzig Willi München Dachauer Straße 7<br />
2 Winzig H<strong>einer</strong> München Dachauer Straße 3<br />
3. Normalform<br />
(3. NF)<br />
Transitive<br />
Abhängigkeit<br />
Eine Relation befindet sich in der 3. NF, wenn sie sich in der 2. NF<br />
befindet <strong>und</strong> alle Datenfelder, die nicht Teil des Schlüssels sind,<br />
untereinander in k<strong>einer</strong> Abhängigkeit stehen.<br />
Alle Nichtschlüsselattribute müssen also voneinander unabhängig<br />
sein.<br />
transitive Abhängigkeit: Abhängigkeit zwischen nicht Schlüsselattributen<br />
In unserem Beispiel ist das Attribut „Fachname“ vom Attribut „ID-Fach“ funktional abhängig.<br />
Es wird deshalb nochmals aufgespalten.<br />
Relation NACHHILFE (3. NF)<br />
ID-Nachhilfe ID-Person ID-Fach<br />
1 1 1<br />
2 2 2<br />
Relation FACH (3. NF)<br />
ID-Fach Fachname<br />
1 Deutsch<br />
2 Englisch<br />
Relation PERSON (3. NF)<br />
ID-Person Name Vorname Ort Straße<br />
1 Winzig Willi München Dachauer Straße 7<br />
2 Winzig H<strong>einer</strong> München Dachauer Straße 3<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 8 von 9
Integritätsprüfung<br />
Entity-Integrität<br />
Dadurch wird sichergestellt, dass jedes Tupel <strong>einer</strong> Relation eindeutig identifiziert werden<br />
kann. Dazu muss der Primärschlüssel folgende Eigenschaften besitzen:<br />
- Der Primärschlüssel muss eindeutig sein.<br />
- Der Primärschlüssel darf keinen Null-Wert beinhalten.<br />
Referenzielle Integrität<br />
Die referenzielle Integrität stellt sicher, dass die Tabellenverknüpfungen problemlos ausgeführt<br />
werden können. Dies bedeutet, dass referenzierte Datensätze in <strong>einer</strong> anderen<br />
Relation tatsächlich vorhanden sind.<br />
Beispiel:<br />
FACH<br />
ID-Fach Name Klasse<br />
1 Deutsch 7<br />
2 Mathematik 5<br />
NACHILFE<br />
ID-Nachhilfe ID-Fach ID-Person<br />
1 1 1<br />
2 2 1<br />
3 2 2<br />
PERSON (ist verkürzt dargestellt)<br />
ID-Person Name Adresse<br />
1 Willi Winzig München<br />
2 H<strong>einer</strong> Winzig München<br />
Die referenzielle Integrität verlangt, dass alle Fächer in der Tabelle NACHHILFE auch in<br />
der Tabelle FACH vorhanden sind.<br />
Arbeitskreis am ISB <strong>Planung</strong> <strong>einer</strong> <strong>Datenbank</strong> Seite 9 von 9