Sie sind auf Seite 1von 0

PR : IT eU

DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 1 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Datenbanken entwickeln
Vorgehensweise
Die Entwicklung einer DB vollzieht sich in mehreren Schritten. Zunchst ist festzustellen, welche Informationen
die Anwender vom DBS erwarten. Aufgrund dieser Erhebung kann man sich dann berlegen, welche Tabellen
bentigt werden. Ferner mu festgelegt werden, welche Datentypen fr die einzelnen Tabellenspalten bentigt
werden. Diesen Proze bezeichnet man als Datenmodellierung. Erst wenn die Datenmodellierung abgeschlossen
ist, knnen die Tabellen angelegt werden.
Man sollte sich fr diesen Schritt ruhig ein wenig Zeit nehmen, weil es nachher hufig
unmglich ist, ohne groen Aufwand Fehler zu beheben.
Grundstze
Um sich einigen rger zu ersparen, empfiehlt es sich, ein paar Grundstze bei der Datenmodellierung zu
beachten:
Keine Redundanz
Unter Redundanz versteht man das doppelte Vorhandensein einzelner Daten. Am folgenden Beispiel wird dies
besonders deutlich:
In folgender Tabelle werden Adressen gespeichert:

Vor-/Nachname Vorname Strae
Hans Maier Hans Musterstr. 5
J rgen Mller J rgen In dem Muster 4
Christof Meier Christof Gibt es nicht 1

Wie man leicht erkennen kann, kommt der jeweilige Vorname in zwei Spalten vor. Dies
bringt zwei Nachteile mit sich: Zum einen kostet es mehr Speicherplatz, was bei einigen 1000
Datenstzen schon etwas ausmacht; zum anderen werden nderungen schwieriger, anflliger
fr Fehler und auch aufwendiger, da ja zwei Attribute gendert werden mssen. Wenn dies
nicht erfolgt, treten Inkonsistenzen auf.
Wenn zum Beispiel Christof Meier feststellt, da ein Christoph, mit `f` geschrieben, einfach
nicht so gut aussieht und er es gerne in Christoph gendert haben wrde, dabei aber nur das
Attribut Vorname gendert wird, knnten zum Beispiel die Briefe weiter an Christof Meier
geschickt werden, weil hier das Attribut Vor-/Nachname verwendet wird. An einer anderen
Stelle im Programm wrde aber wieder der korrigierte Christoph auftauchen.
Eindeutigkeit
Eine DB enthlt Angaben zu den Eigenschaften einer Person oder Sache. Mittels dieser Angaben mu eindeutig
ein bestimmtes Tupel identifizierbar sein.
Das DBMS verfgt nicht ber einen definierten Zugriffsweg auf einen bestimmten Datensatz.
Deshalb mu in jeder Zeile einer Tabelle ein Wert enthalten sein, der diesen Eintrag eindeutig
kennzeichnet bzw. identifiziert. Um die Eindeutigkeit der Tabellenzeilen zu gewhrleisten,
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 2 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
erweitert man den Datensatz um ein Identifikationsmerkmal, z.B. wird einem Artikeldatensatz
eine Artikelnummer zugeordnet. Dieses Merkmal nennt man Schlssel.
Beim Festlegen des Schlssels kann man einen Schlssel selbst definieren oder einen
fremddefinierten bernehmen. Bei einem Buch wrde sich da die ISBN-Nummer anbieten.
Um nicht Gefahr zu laufen, da durch eine nderung solcher fremddefinierten Schlssel im
DBS Inkonsistenzen auftreten, zum Beispiel, weil der Schlssel nicht mehr eindeutig ist,
empfiehlt es sich hufig, einen eigenen zu nehmen.
Keine Prozedaten
Prozedaten sind Daten, die durch einen Rechenproze aus gespeicherten Attributen gewonnen werden.
Folgendes einfaches Beispiel: Neben dem Geburtsdatum wird auch noch das Alter gespeichert. Sptestens nach
einem J ahr ist dieser Eintrag falsch. Deshalb sollten diese Prozedaten bei jeder Abfrage neu errechnet werden.
Datenmodelle entwickeln
Es gibt mehrere Vorgehensweisen. Eine Mglichkeit ist, erst einmal darber nachzudenken, was man eigentlich
machen will, dann die entsprechenden Prozeduren entwickeln und dabei sehen, welche Art von Daten man
braucht. Diese Vorgehensweise kennen diejenigen, die schon einmal programmiert haben.
Andererseits kann man sich auch zuerst berlegen, welche Daten berhaupt anfallen und wie
diese am besten organisiert werden. Anschlieend kann man sich dazu die entsprechenden
Funktionen ausdenken. Da Datenbanken in der Regel zum Speichern von Daten gedacht sind,
empfiehlt sich letztere Vorgehensweise; man sollte aber trotzdem die bentigten Funktionen
nicht aus dem Auge verlieren. Also zusammenfassend:
Als erstes mu man feststellen, welche Daten gebraucht werden bzw. anfallen und wie diese
organisiert werden sollen. Im nchsten Schritt ist zu berlegen, ob alle Anforderungen
realisierbar sind.
Bei der objekt-orientierten Programmierung geht man noch einmal anders vor. Hier berlegt
man sich, welche Objekte bentigt werden, welche Daten sie speichern mssen und welche
Methoden sie bentigen. Dazu spter mehr in einem eigenen Kapitel.
Tabellen erstellen
Um die bentigten Tabellen zu entwickeln, gibt es fr einfache DBs im Prinzip zwei Mglichkeiten: Entweder
stur nach Schema-F ber die fnf Normalformen oder etwas intuitiver ber das ER-Modell, evtl. anschlieend
mit Kontrolle durch die fnf Normalformen.
Erst wenn man grere DBs entwickelt, mu man mit beiden Mglichkeiten gleichzeitig
arbeiten. Das heit, erst mit dem ER-Modell eine Grundstruktur festlegen und diese dann mit
den fnf Normalformen berprfen.
Die fnf Normalformen
Die 1. Normalform
Definition:
Ein Relationstyp ist in der 1. Normalform, wenn alle Attribute maximal einen Wert haben. Am
Kreuzungspunkt einer Spalte mit einer Reihe darf also maximal ein Datenwert stehen. Das Nichtvorhandensein
von Daten ist zulssig.
Mit anderen Worten: Wiederholungsgruppen sind nicht erlaubt.


PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 3 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Andere Definition:
Die Attribute der Relation mssen atomar sein (ist eine schon vorausgesetze Eigenschaft von Relationen).
Strukturierte Attribute (wie Adresse) mssen aufgeteilt werden in ihre Teilattribute (z.B. in PLZ, Ort, Strae und
Hausnummer). Relationen in erster Normalform werden auch oft als flache Relationen bezeichnet. Aufgrund von
funktionalen Abhngigkeiten (PLZ bestimmt Ort) ergeben sich in 1NF-Relationen Redundanzen.
Ein kleines Beispiel:
Es sollen alle Bestellformulare eines Versandhandels in einer Datenbank gespeichert werden.
Eine einzelne Bestellung enthlt die Kundennummer, das Datum, die Auftragsnummer und
natrlich die bestellten Artikel sowie deren Anzahl. Siehe dazu auch folgende Tabelle `
Auftrag`.

Auftrag
AuftragNr Datum KundenNr AritkelNr Anzahl
4711 3.10.1999 12345 4692 5
4711 3.10.1999 12345 0567 2
4711 3.10.1999 12345 5671 3
4711 3.10.1999 12345 0579 1
0815 1.3.1998 54321 8971 2
0815 1.3.1998 54321 5324 5
0815 1.3.1998 54321 0579 9

Um die Wiederholungsgruppen zu vermeiden, werden fr diese gesonderte Tabellen erstellt.
Dadurch wrden sich die folgenden beiden Tabellen ergeben:
best. Artikel
AritkelNr Anzahl
4692 5
0567 2
5671 3
0579 1
8971 2
5324 5
0579 9
Auftrag
AuftragNr Datum KundenNr
4711 3.10.1999 12345
0815 1.3.1998 54321
J etzt ist aber die Zuordnung verloren gegangen. Wer hat welche(n) Artikel bestellt?
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 4 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Dieses Problem ist einfach zu lsen. Wir mssen nur festhalten, welche Artikel zu welcher
Bestellung gehren. Da die AuftragNr eindeutig ist, nehmen wir diese als Primrschlssel fr
`Auftrag`. Nun fgen wir noch diese Spalte entsprechend ihrer Werte der Relation `best.
Artikel` hinzu, und schon haben wir wieder unsere Zuordnung.
In dieser Konstellation wird die Spalte `AuftragNr` in `best. Artikel` als Fremdschlssel
bezeichnet.
Weiterhin wurde schon oben gefordert, da jede Zeile eindeutig ansprechbar sein mu. Wie
aber ist das in unserem Fall der bestellten Artikel zu erreichen?
Nun, die AuftragNr und die ArtikelNr kommen zwar mehrfach vor, trotzdem ist die Lsung
aber ganz einfach: Die Kombination aus AuftragNr und ArtikelNr mu eindeutig sein. Wenn
wir also diese Kombination whlen, ist die o.g. Forderung erfllt. Diese Kombination wird
brigens als ,zusammengesetzter Primrschlssel` bezeichnet.
Damit ergeben sich fr unser Beispiel die folgenden beiden Relationen:

best. Artikel
AufragNr AritkelNr Anzahl
4711 4692 5
4711 0567 2
4711 5671 3
4711 0579 1
0815 8971 2
0815 5324 5
0815 0579 9
Auftrag
AuftragNr Datum KundenNr
4711 3.10.1999 12345
0815 1.3.1998 54321

Die 2. Normalform
Definition:
Ein Relationstyp ist in der 2. Normalform, wenn er in der 1. Normalform ist und jedes Attribut vom gesamten
Primrschlssel abhngt.
Relationstypen, die in der 1. Normalform sind, sind automatisch in der 2. Normalform, wenn ihr Primrschlssel
nicht zusammengesetzt ist.

Andere Definition:
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 5 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Die zweite Normalform vermeidet partielle funktionale Abhngigkeiten (diese bewirken
Redundanzen). Eine partielle funktionale Abhngigkeit besteht, wenn Attribute (die nicht
Schlsselkandidaten sind) funktional schon von einem Teil des Schlssels abhngen. Die
zweite Normalform kann durch Elimination der abhngigen Attribute und Auslagerung in
eine eigene Relation erreicht werden.

Figure: 2. Normalform

Ein kleines Beispiel:
Neben der AuftragNr, der ArtikelNr und der Menge soll auch der Hersteller des Artikels
gespeichert werden. Damit wrde sich die folgende Artikel-Tabelle ergeben.
AuftragNr und ArtikelNr sind der zusammengesetzte Primrschlssel.

best. Artikel
AuftragNr ArtikelNr Menge Hersteller
4711 4692 5 Blech-AG
4711 0567 2 Keramik GmbH
4711 5671 3 Baustoff KG
4711 0579 1 Keramik GmbH
0815 8971 2 Keramik GmbH
0815 5324 5 Baustoff KG
0815 0579 9 Keramik GmbH

In diesem Beispiel ist das Attribut `Hersteller` nur vom Teilschlssel `ArtikelNr` und nicht
auch von `AuftragNr` abghngig. Damit die Relation der 2. NF gengt, mu das Attribut
`Hersteller` aus der Relation herausgenommen und der (neuen) Relation Artikel zugeordnet
werden.
Daraus wrden dann folgende beiden Relationen entstehen:

PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 6 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
best. Artikel
AufragNr AritkelNr Anzahl
4711 4692 5
4711 0567 2
4711 5671 3
4711 0579 1
0815 8971 2
0815 5324 5
0815 0579 9
Artikel
ArtikelNr Hersteller
4692 Blech-AG
0537 Keramik GmbH
5671 Baustoff KG
0579 Keramik GmbH
8971 Keramik GmbH
5324 Keramik GmbH

Die 3. Normalform
Definition:
Die 3. Normalform ist erfllt, wenn die 2. Normalform erfllt ist und die Nicht-Schlssel-Attribute funktional
unabhngig voneinander sind.
Sind A und B Attribute eines Relationstyps, so ist B funktional abhngig von A, wenn fr jedes Vorkommen ein
und desselben Wertes von A immer derselbe Wert von B auftreten mu.
Eine funktionale Abhngigkeit kann auch von einer Gruppe von Attributen bestehen.

Andere Definition:
Die dritte Normalform lst transitive Abhngigkeiten auf. Geht man von einem Schlssel aus,
der eine Attributmenge bestimmt, die wiederum ein abhngiges Attribut bestimmt, so liegt
eine transitive Abhngigkeit vor. Zur Beseitigung kann man das transitiv abhngige Attribut
in eine neue Relation kopieren (gemeinsam mit der bestimmenden Attributmenge) und aus
der ursprnglichen Relation entfernen.
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 7 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at

Figure: 3. Normalform

Ein kleines Beispiel:
Zu den einzelnen Artikeln sollen die ArtikelNr, die Bezeichnung, der Hersteller und die
HerstellerNr gespeichert werden. Als Primrschlssel wird die ArtikelNr verwendet. Wrde
man die zustzliche Spalte einfach in die vorhandene Tabelle Artikel einfgen, ergbe sich
damit folgende Tabelle:

Artikel
ArtikelNr Bezeichnung HerstellerNr Hersteller
4692 Putzeimer 5410 Blech-AG
0567 Waschbecken 5647 Keramik GmbH
5671 Gummi 6740 Baustoff KG
0579 Teller 5647 Keramik GmbH
8971 Tasse 5647 Keramik GmbH
5324 Badewanne 5647 Keramik GmbH

Wie man unschwer erkennen kann, ist der Herstellername funktional abhngig von der
HerstellerNr und nicht von der ArtikelNr.
Was jetzt kommt, ist nicht schwer zu erraten: Die Tabelle `Artikel` wird in die beiden
Tabellen `Artikel` und `Hersteller` aufgespalten. Das heit, es ergeben sich folgende
Tabellen:




PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 8 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Artikel
ArtikelNr Bezeichnung HerstellerNr
4692 Putzeimer 5410
0567 Waschbecken 5647
5671 Gummi 6740
0579 Teller 5647
8971 Tasse 5647
5324 Badewanne 5647
Hersteller
HerstellerNr Hersteller
5410 Blech-AG
5647 Keramik GmbH
6740 Baustoff KG

Die 4. Normalform
Definition:
Die 4. Normalform ist erfllt, wenn die 3. Normalform erfllt ist und wenn keine paarweise auftretenden
mehrwertigen Abhngigkeiten vorhanden sind.
Sind A, B und C Attribute eines Relationstypes, so ist C mehrwertig abhngig von A, falls fr jeden Wert von A
fr alle Werte von B, die zusammen mit diesem Wert von A auftreten, jeweils die gleiche Wertemenge von C
auftreten mu. Fr verschiedene Werte von A knnen unterschiedliche Wertemengen von C auftreten.
Bei Versto gegen die 4. Normalform knnen ,,Gruppeninkonsistenzen`` auftreten.
Kurzes Beispiel:
Disposition
ArtikelNr Lager AuftragNr
04532 SFO-4 2063
04532 NYC-4 2063
04532 SFO-4 2267
04532 NYC-4 2267
53944 ORD-1 2088
53944 SFO-1 2088
53944 LAX-1 2088
53944 ORD-1 2070
53944 SFO-1 2070
53944 LAX-1 2070

PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 9 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
In der Relation Disposition sind folgende Informationen festgehalten:
der Lagerort fr jeden Artikel
Auftrge, in denen ein Artikel vorkommt
Es soll nicht ausgesagt werden, aus welchem Lager der Artikel fr einen Auftrag kommt.
Folgende mehrwertige Abhngigkeiten liegen vor:
`Lager` ist mehrwertig abhngig von `ArtikelNr :
Fr jeden Artikel mu fr alle Auftrge, fr die der Artikel bestellt ist, jeweils die
gleiche Gruppe von Lagern auftreten.
`AuftragNr` ist mehrwertig von `ArtikelNr` :
Fr jeden Artikel mu fr alle Lager, in denen der Artikel aufbewahrt wird, jeweils die
gleiche Gruppe von Auftrgen auftreten.
Damit die Relation der 4. NF gengt, mu sie in zwei neue Relationen (Artikel-Lager und
Artikel-Auftrag) aufgespalten werden. Die erste Relation beschreibt, in welchem
Zusammenhang Artikel und Lager stehen; die zweite den Zusammenhang zwischen Artikel
und Auftrag.
Die 5. Normalform
Definition:
Ein Relationstyp ist in der 5. Normalform, wenn er in der 4. Normalform ist und er sich unter keinen
Umstnden durch Kombination einfacherer Relationstypen mit unterschiedlichen Schlsseln bilden lt.
Denormalisierung der Tabellen
Im Prinzip kann man die Tabellen, die man nach den fnf Normalisierungen erhalten hat, 1:1 in der DB
verwenden. Es ist jedoch zu prfen, ob man in der Normalisierungswut die Tabellen nicht zu sehr
auseinandergerissen hat. Tabellen, die denselben Primrschlssel haben, knnen ohne weiteres zusammengelegt
werden, ohne gegen eine Normalisierungsform zu verstoen.
Bei umfangreichen Datenbestnden mit hohen Zugriffszahlen empfiehlt sich jedoch, aus
Performancegrnden wieder eine gewisse Denormalisierung herzustellen. Da wir aber keine
so hohen Zugriffszahlen und Datenbestnde haben, da der Server berlasten werden knnte,
knnen wir diesen Schritt getrost bergehen.
Hierbei kann man sagen, da es weniger problematisch ist, mit sich nicht ndernden Daten
gegen die Normalformen zu verstoen. Bei diesen entfllt nmlich das Problem, da beim
ndern nicht alle Daten verndert werden und dadurch Widersprche entstehen. Trotzdem
sollte man sich immer im klaren darber sein, wann man gegen die Normalformen verstoen
hat!
Als nchstes ist anhand des Streifendiagramms zu berprfen, ob die Tabellen den
Anforderungen der Vorgnge entsprechen.
Streifendiagramm
Um die Tabellen grafisch dazustellen gibt es verschiedene Methoden. Eine Methode, mit der man relativ schnell
einen berblick ber die vorhandenen Relationen einschlielich deren Attribute und Beziehungen bekommt, ist
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 10 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
das Streifendiagramm. Damit ist es dann mglich, anhand des Vorgangskatalogs zu berprfen, ob alle
Vorgnge mglich sind und die Relationen stimmen.
Als Beispiel habe ich die Relationen `Auftrag`, `best. Artikel`, ` Artikel`und `Hersteller` aus
dem obigen Beispiel in der Abbildung 3.1 dargestellt.
Abbildung 3.1: Streifendiagramm
Das ER-Modell
Bei greren Projekten unumgnglich, bei kleineren fr manche schner: das Entity Relationship-Modell. Wer
ein wenig Erfahrung mit Datenbanken hat und gut nachdenkt, kann auch mit Hilfe des ER-Modells
Datenmodelle entwickeln, die allen Normalformen entsprechen.
Es gibt verschiedene Formen, das ER-Modell zu zeichnen. Ich benutze hier das sogenannte
Krhenfu-Diagramm.
Was bedeutet eigentlich Entity-Relationship ?
Fr Entitt gibt es verschiedene gebruchliche Definitionen:
Entitt [mlat.]die, -/-en, Philosophie: die bestimmte Seinsverfassung (Wesen) des einzelnen Seienden, auch
diese selbst.
Entitt [lat.-mlat.] die, -, -en: 1. Dasein im Unterschied zum Wesen eines Dinges (Philos.). 2. [gegebene] Gre
Wer jetzt wei, was Entity bedeutet, kann diesen Absatz berspringen; fr alle anderen versuche ich es anders zu
erklren: ,,Entity`` kann man mit ,,Objekt`` oder ,,Ding``ins Deutsche bersetzen, letztlich sind es konkrete
Objekte der Realitt. Beim ER-Modell sind Entities Objekte, die ber Attribute weiter beschrieben werden
knnen.
Nachdem wir jetzt hoffentlich wissen, was Entity bedeutet, sind wir beim zweiten Begriff
angelangt: Relationship bedeutet so viel wie ,,Beziehung`` oder ,, Relation``.
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 11 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Abbildung 3.2: ER-Beispiel 1
Ein kleines Beispiel:
Fr ein Unternehmen soll eine Datenbank entwickelt werden. Es sollen alle Mitarbeiter der
Firma gespeichert werden. Ferner soll man einer einer Abteilung zugehrig sein knnen.
J eder Mitarbeiter hat einen Vorgesetzten. Auerdem verfgt jede Abteilung ber einige oder
keine PKWs aus dem Fuhrpark fr die Mitarbeiter. Des weiteren soll es mglich sein zu
sagen, wer wann mit welchem Wagen gefahren ist.
Diese Realtittsbeschreibung legt drei Entitten nahe: Mitarbeiter, Abteilung, PKW. Die
Zeichnung 3.2 stellt die Beziehung der drei Entitten und deren Attribute dar.
Wie man unschwer erkennen kann, stellen die Rechtecke die Entitten da. Sowohl die
Entitten als auch nachher die Tabellen werden grundstzlich in der Einzahl bezeichnet.
Die Striche zwischen den Entitten stellen deren Beziehung da. Der durchgezogener Strich
bedeutet genau einer, der gestrichelte einer oder keiner. Der Krhenfu auf der anderen
Seite bedeutet oder mehrere. Die Wrter an den Strichen zeigen, was die Beziehung aussagt.
Also z.B.: Ein Mitarbeiter gehrt zu genau einer Abteilung. Eine Abteilung kann aus keinem,
einem oder mehreren Mitarbeiter bestehen. Da eine Abteilung keinen Mitarbeiter haben
kann, mag auf den ersten Blick merkwrdig erscheinen. Was ist aber, wenn die Abteilung
gerade erst eingerichtet wurde?
In den Rechtecken stehen die wichtigsten Attribute. Primrschlssel werden durch ein #
gekennzeichnet, Primrschlsselkanditaten dagegen durch (#) markiert. Attribute, bei denen
ein Wert eingetragen werden mu, werden mit einem * versehen; bei den optionalen wird ein
o verwendet.
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 12 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Wenn man sich dieses ER-Modell einmal genauer ansieht, stellt man fest, da es gegen die 1.
NF verstt. Die Beziehung zwischen `Mitarbeiter` und `PKW` ist eine n:m Beziehung. Um
dieses Problem zu lsen, wird eine sog. Link-Relation erstellt. Wie das dann genau aussieht,
ist in Abbildung 3.3 dargestellt.
Abbildung 3.3: ER-Beispiel 2
Relationen erstellen
Last but not least mssen aus dem ER-Modell noch die Tabellen erstellt werden. Das ist allerdings kein groes
Problem mehr - jede Entitt wird einfach zu einer Tabelle. Als nchstes sucht man sich alle Primrschlssel. In
unserem Beispiel ergbe sich folgendes:

Tabelle Primrschlssel
Mitarbeiter MNr
Abteilung AbtNr
Fahrbuch MNr, PKWNr, Datum
PKW PKWNr

Die Relation `Fahrbuch` hat einen zusammengesetzten Primrschlssel. Die ` MNr` oder auch
das Datum fr sich alleine wren nicht eindeutig, da ein Mitarbeiter ja nicht nur einmal Auto
fhrt und zu einem Zeitpunkt ja auch ggf. mehrere Leute gleichzeitig Autos fahren. In der
Kombination jedoch sind die drei Attribute eindeutig.
PR : IT eU
DI Panzirsch Robert
Information Technology

Bankverbindung: Bank Austria, Kontonummer 710 362 948, BLZ 12000, "PRIT eU, DI Panzirsch Robert",
IBAN: AT40 1200 0007 1036 2948, BIC: BKAUATWW Page 13 of 13
W www.prit.at
M office@prit.at, pr@prit.at
FN 289775s, HG Wien
UID ATU42032607
P Herklotzgasse 7, 1150 Wien
T +43 664 3000 250
F +43 664 77 3000 250
S +436643000250@text.mobilkom.at
Bei `PKW` wurde nicht das Kennzeichen als Primrschlssel genommen, obwohl es sich
dafr eignen wrde (mit Sicherheit eindeutig). Allerdings kann es passieren, da ein PKW ein
neues Kennzeichen bekommt. Um auch dann noch die Datenintigritt sicherstellen zu knnen,
habe ich einen neues Attribut eingefhrt.
Nachdem man die Primrschlssel herausgesucht hat, mssen auch die Fremdschlssel
gesucht werden, damit man die Beziehung zwischen den Relationen herstellen kann. Das ist
mit dem Krhenfudiagramm relativ einfach. Alle Relationen, die einen Krhenfu haben,
bekommen den Primrschlssel der anderen Relation. D.h. es mu z.B. die
Abteilungsnummer in die Relation `Mitarbeiter` eingefgt werden. Das ist auch logisch, denn
eine Abteilung kann natrlich auch mehrere Mitarbeiter haben. Wrde man dagegen die
Mitarbeiter-Nummer in `Abteilung` einfgen, htte man einen Versto gegen die 1. NF.
Aus unserem Beispiel ergben sich also folgende Relationen (mit Angabe der zu den
Fremdschlsseln gehrigen Primrschlssel):
Tabelle Primrschlssel Fremdschlssel
Mitarbeiter MNr AbtNr [Abteilung(AbtNr)]
VNr [Mitarbeiter(MNr)]
Abteilung AbtNr
Fahrbuch MNr, PKWNr, Datum MNr [Mitarbeiter(MNr)]
PKWNr [PKW(PKWNr)]
PKW PKWNr AbtNr [Abteilung(AbtNr)]
Als letztes mssen noch die bentigten Attribute den Relationen hinzugefgt und fr alle
Attribute die entsprechenden Datentypen festgelegt werden.
Datentypen
Nachdem jetzt die Datenstruktur feststeht, mu noch festgelegt werden, welche Datentypen fr die einzelnen
Attribute verwendet werden sollen. Im Prinzip gibt es drei verschiedene Datentypen: Zahlen, Text und groe
Objekte. In den verschiedenen Datenbanken gibt es dazu dann entsprechend verschiedene Gren.
Bei der berlegung, welchen Datentyp man verwendet, sollte man nicht vom Normalfall
ausgehen, sondern immer alle mglichen Ausnahmen betrachten. So ist es z.B. notwendig, fr
`Hausnummer` einen Text-Typ zu whlen, da z.B. ,,5a`` auch eine gltige Hausnummer ist.