Warenkorb
0 Artikel | US$ 0,00
ID 6878
Sandra Auerhammer
Vergleich und Beurteilung
verschiedener CASE-Tools für den
Einsatz im konzeptionellen
Datenbankentwurf
BA-Thesis / Bachelor
an der Technischen Universität München
Fachbereich Informatik
4 Monate Bearbeitungsdauer
März 2003 Abgabe
ID 6878
Auerhammer, Sandra: Vergleich und Beurteilung verschiedener CASE-Tools für den
Einsatz im konzeptionellen Datenbankentwurf
Hamburg: Diplomica GmbH, 2003
Zugl.: München, Technische Universität, BA-Thesis / Bachelor, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
5
Inhaltsverzeichnis
0. Motivation für den Einsatz von CASE-Tools ...8
1. Einführung in den Datenbankentwurf ...10
1.1 Phasen des Datenbankentwurfs...10
1.2 Datenmodellierung ...12
1.2.1 Objekte ...12
1.2.1 Abstraktionsmechanismen ...12
1.2.2 Beziehungen...13
1.3. Datenmodelle ...16
1.3.1 ER Modell ...17
1.3.2 UML-Diagramme ...20
1.3.2.1. Anwendungsfalldiagramme ...20
1.3.2.2. Klassendiagramm...20
1.3.3. Relationales Datenmodell...20
1.3.3.1. Aufbau des Relationenmodells...20
1.3.3.2. Begriffsdefinitionen ...20
2. Fallbeispiel ...20
2.1. Einzelheiten des Fallbeispiels ...20
2.1.1. Sicht des Passagiers: ...20
2.1.2 Sicht der Flughafenverwaltung ...20
2.1.3 Sicht der Fluggesellschaft ...20
3. Klassifizierung der CASE-Werkzeuge...20
3.1. Fundamentale Anforderungen...20
3.1.1 Diagramme ...20
3.1.2. Funktionen...20
3.1.2.1.Korrektheit ...20
3.1.2.2. Datenbankanbindung ...20
3.1.2.3 Forward-Engineering ...20
3.1.2.3.1 Transformation ER-Modell nach Relationenmodell ...20
3.1.2.3.2 SQL-Code...20
3.1.3. Bedienungskomfort...20
3.2. Erweiterte Anforderungen ...20
3.2.1. Import ...20
3.2.2. Reverseengineering ...20
3.2.3. Referentielle Integrität ...20
3.2.4. Festlegen von Indizes...20
3.2.5. Flexibilität...20
3.3. Weitere Bewertungspunkte ...20
6
4. Bewertung ...20
4.1. Powerdesigner ...20
4.1.1. Installation ...20
4.1.1. Erscheinungsbild ...20
4.1.2. Modellierungsarten ...20
4.1.2.1 ER-Modell...20
4.1.2.2 Physisches Datenmodell ...20
4.1.2.3 UML-Klassenmodell ...20
4.1.3. Funktionen...20
4.1.3.1. Validierungsfunktion ...20
4.1.3.2. Datenbankanbindung ...20
4.1.3.3. Forward-Engineering ...20
4.1.3.3.1 Umsetzung einer 1:1-Relationship ...20
4.1.3.3.2 Umsetzung einer 1:n-Relationship ...20
4.1.3.3.3 Umsetzung einer n:m-Relationship ...20
4.1.3.4. Reverse-Engineering...20
4.1.3.5. Import / Export ...20
4.1.3.6. Reportfunktion ...20
4.1.3.7 Anlegen von Indizes ...20
4.1.3.8 Zusatzfunktionen ...20
4.1.3.8.1 Ausführen von SQL-Statements...20
4.1.3.8.2 Speicherverwaltung ...20
4.1.3.8.3 Schätzen der Datenbankgröße...20
4.1.4. Hilfe / Support...20
4.1.5. Benutzerfreundlichkeit ...20
4.1.7. Resümee ...20
4.2. CaseStudio 2...20
4.2.1. Installation ...20
4.2.2. Erscheinungsbild ...20
4.2.3. Modellierung ...20
4.2.3. Funktionen...20
4.2.3.1. Validierungsfunktion ...20
4.2.3.2. Datenbankanbindung ...20
4.2.3.3. Forward-Engineering ...20
4.2.3.3.1 (1:1)-Relationship: ...20
4.2.3.3.2 (1:n)-Relationship ...20
4.2.3.3.3. (n:m)-Relationship ...20
4.2.3.3.4 Umsetzung des Fallbeispiels...20
4.2.3.4. Reverseengineering ...20
4.2.3.5. Import / Export ...20
4.2.3.6 Anlegen von Indizes ...20
4.2.3.7 Reportfunktion ...20
4.2.4. Hilfe / Support...20
4.2.5. Benutzerfreundlichkeit ...20
4.2.6. Resümee ...20
7
4.3. ERwin ...20
4.3.1. Installation ...20
4.3.2. Erscheinungsbild ...20
4.3.3. Diagramme ...20
4.3.3.2. Physisches Modell...20
4.3.3.3. Logisch / Physisches Modell ...20
4.3.3.3. Wechsel zwischen den Modelltypen...20
4.3.4. Funktionen...20
4.3.4.1. Validierungsfunktion ...20
4.3.4.2. Datenbankanbindung ...20
4.3.4.3. Forward-Engineering ...20
4.3.4.3.1 Umsetzung 1:1-Relationship...20
4.3.4.3.2 Umsetzung 1:n-Relationship...20
4.3.4.3.3.Umsetzung einer n:m-Relationship...20
4.3.4.4 Reverse-Engineering...20
4.3.4.5. Import / Export ...20
4.3.4.6. Anlegen von Indizes ...20
4.3.4.7. Reportfunktion ...20
4.3.5. Hilfe / Support...20
4.3.6. Benutzerfreundlichkeit ...20
4.3.7. Resümee ...20
5. Resümee und Ausblick...20
5.1. Gesamtwertung ...20
5.2. Vor- und Nachteile beim Einsatz von CASE-Werkzeugen ...20
Anhang ...20
Literaturverzeichnis ...20
Abbildungsverzeichnis:...20
8
0. Motivation für den Einsatz von CASE-Tools
Eine immer größere Rolle spielen Informationssysteme in unserem Leben. Informationssys-
teme basierend auf Hochleistungsrechnern werden zur wissenschaftlichen Auswertung von
mehreren terrabyte-großen Datenmengen benötigt. Reisende wollen per Laptop via Satellit
auf relevante Datenbanken zugreifen, um Daten von anderen verteilten oder mobilen Daten-
banken abzufragen oder Daten bereitzustellen. Multimediale Datenbanken werden immer
öfter in Schule, Studium, Aus- und Weiterbildung eingesetzt.
Literaturdatenbanken in Bibliotheken sind genauso wenig wegzudenken, wie Datenbanken
zur Ticketreservierung, Buchung von Unterkünften, Fahrten und Flügen.
Egal, um welche der genannten Datenbanken es geht, sie haben alle eines gemeinsam:
Komplexität. So führt die anwachsende Zahl an Informationssystemen, ihre Größe und die
Komplexität dazu, dass es immer schwieriger wird, fehlerfreie Systeme zu entwerfen.
Bei der Entwicklung von Informationssystemen spielt die Anforderungsanalyse eine sehr
wichtige Rolle. Fehler, die in dieser Phase begangen werden, sind im weiteren Verlauf der
Entwicklung sehr kostspielig. Umso wichtiger ist es, die von den zukünftigen Anwendern ge-
nannten Anforderungen möglichst vollständig und korrekt zu erfassen und in einem konzep-
tionellen Modell darzustellen. Die Darstellung soll zum einen für den Anwender verständlich
sein und zum anderen soll sie dem Entwickler als Grundlage des zu entwickelnden Informa-
tionssystems sein.
Für die Darstellung der Anforderungen sind in den vergangen Jahren eine Reihe von Metho-
den und Verfahren entwickelt worden. In der Praxis haben sich im Bereich Datenbankentwurf
zwei Datenmodelle durchgesetzt: (E)ER-Modell, basierend auf dem ER-Modell von Chen mit
einigen Erweiterungen, und das UML-Klassenmodell.
Im Bereich der Softwareentwicklung wurden immer mehr rechnergestützte Werkzeuge ein-
gesetzt, die eine fehlerlose Entwicklung von Softwaresystemen unterstützen sollten. Diese
Werkzeuge werden unter dem Begriff CASE-Tools (computer aided software engineering)
zusammengefasst. In den 80er Jahren fanden diese Tools erstmals auch im Bereich Daten-
bankmodellierung ihren Einsatz. Entweder wurden neue Tools entwickelt oder Softwareent-
wicklungstools wurden für den Einsatz der Datenbankentwicklung angepasst.
An der TU-München werden derartige Tools derzeit noch nicht verwendet; es wird allerdings
über ihren Einsatz nachgedacht. Vorliegende Arbeit soll einen Einblick in eine Auswahl vor-
handener Tools bieten, und die Wahl eines passenden Werkzeuges für den Einsatz am
Lehrstuhl Datenbanken und Informationssysteme unterstützen. Die Werkzeuge sollen später
Studenten im Datenbankpraktikum, welches für Studenten im Hauptstudium Informatik an-
geboten wird, zur Verfügung gestellt werden. Bei der Bewertung der Softwarewerkzeuge
spielen allgemeine Aspekte wie z.B. Diagrammtypen und Funktionalität ebenso eine Rolle
wie Anforderungen, welche speziell in diesem Praktikum an die Software gestellt werden. Ein
spezifischer Aspekt im Hinblick auf den Einsatz im Praktikum ist zum Beispielt die Unterstüt-
zung der IBM Datenbank DB2 in der Version 7.1 bzw. 8.
Getestet wurde eine Auswahl von drei Softwarewerkzeugen. Bei dieser Auswahl wurde Wert
gelegt, dass jedes Tool mindestens eine Modellierungsart unterstützt: Entweder UML- oder
ER-Diagramme. Ein weiterer Gesichtspunk war die Möglichkeit, das Diagramm auf Korrekt-
heit zu überprüfen und automatisch SQL-Code zu generieren. Weitere Anforderungen wur-
den nicht gestellt, es fließt jedoch positiv in die Bewertung mit ein, wenn das Tool mehr
Funktionen bietet.
0. Motivation für den Einsatz von CASE-Tools
9
Unter den getesteten CASE-Tools sind:
- PowerDesigner von der Firma Sybase
- CaseStudio 2 von der Firma CHARONWARE
- ERwin von der Firma Computer Associates International
Kapitel 1 bietet einen Einblick in die verschiedenen Datenbankentwurfsphasen und stellt
Konzepte und Eigenschaften der Datenmodelle Entity-Relationship-Diagramm und UML-
Klassendiagramm vor.
Kapitel 2 stellt ein Beispielszenario vor. Es handelt sich dabei um eine Flughafen-
Datenbank. Es werden die zu modellierenden Vorgänge ausgearbeitet und ein ER-
Diagramm entwickelt. Auf dieses Fallbeispiel wird immer wieder im Bereich Softwaretest zu-
rückgegriffen.
In Kapitel 3 werden neben den minimalen Anforderungen, welche an ein CASE-Tool in der
Datenbankentwicklung gestellt werden, auch wünschenswerte zusätzliche Eigenschaften,
welche das Tool haben soll, diskutiert.
Im vierten Kapitel findet die Bewertung der Softwaretools nach den in Kapitel 3 genannten
Aspekten statt.
1. Einführung in den Datenbankentwurf
10
Kapitel 1
1. Einführung in den Datenbankentwurf
Die nachfolgenden Abschnitte beschäftigen sich mit den verschiedenen Phasen des Daten-
bankentwurfs. Des Weiteren werden Datenmodelle eingeführt, welche zur Modellierung von
Datenbanken verwendet werden können. Darunter ist das ER-Modell von Chen, das erwei-
terte ER-Modell, welches auf das von Chen aufbaut. Da UML nicht nur in der Softwareent-
wicklung immer mehr an Bedeutung gewinnt, sondern auch im Datenbankbereich, wird das
UML-Klassendiagramm vorgestellt. Sowohl im ER-Diagramm als auch im UML-
Klassendiagramm existieren Abstraktionsmechanismen. Es wird erklärt, welche Bedeutung
diese Konzepte haben und wie sie in den einzelnen Datenmodellen umgesetzt werden. Im
Laufe der Zeit sind immer mehr Varianten in der Notation von Diagrammen aufgetaucht.
Deshalb widmet sich einer der folgenden Abschnitte der Notationsarten und stellt sie gegen-
über.
1.1 Phasen des Datenbankentwurfs
Der Datenbankentwurf lässt sich in vier Phasen aufteilen, welche sukzessive durchlaufen
werden. Vgl. Abbildung Nr. 1.
Informationsbedarfsanalyse
"Miniwelt"
semantisches
Modell
Tabellenstruktur
DDL
Speicher- und
Indexstrukturen
Konzeptioneller Entwurf
Logischer Entwurf
Physischer Entwurf
Informationsbedarfsanalyse
"Miniwelt"
semantisches
Modell
Tabellenstruktur
DDL
Speicher- und
Indexstrukturen
Konzeptioneller Entwurf
Logischer Entwurf
Physischer Entwurf
Abbildung 1: Phasen des Datenbankentwurfs
1. Einführung in den Datenbankentwurf
11
Informationsbedarfsanalyse
Am Anfang steht die Informationsbedarfsanalyse - auch Anforderungsanalyse genannt.
Hier werden zunächst die Anforderungen an die zu entwerfende Datenbank ermittelt. Wäh-
rend dieser Phase werden folgende Fragestellungen beantwortet: Welche Objekte aus der
realen Welt sollen in die Datenbank eingebunden werden? In welchem Verhältnis stehen
diese zueinander? Welche Anfragen sollen später in der Datenbank zu Verfügung stehen?
Welche Anforderungen haben die Nutzer an die Datenbank?
Dabei spielt es noch keine Rolle, auf welchem Datenbanksystem das Projekt realisiert wer-
den soll, oder welche Anwendungen auf die Datenbank später zugreifen werden. Stehen die
zur Modellierung der Datenbank relevanten Informationen nach der ersten Entwurfsphase
zur Verfügung, geht man zum konzeptionellen Entwurf über.
Konzeptioneller Entwurf
Ziel dieses Entwurfschrittes ist die Erarbeitung einer vom DBMS unabhängigen formalisier-
ten Beschreibung. Die Beschreibung soll in einem semantischen Datenmodell realisiert wer-
den, welches vollständig, widerspruchsfrei, konsistent und redundanzfrei sein soll. Es gibt
verschiedene Datenmodelle, welche in dieser Phase eingesetzt werden können. Diese wer-
den ausführlich in Kapitel 1.3. Datenmodelle vorstellt.
Logischer Entwurf
Der logische Entwurf bildet das konzeptionelle Modell auf Datenmodelle des Datenbanksys-
tems ab. Es werden mittels einer Datenbank-Definitions-Sprache (engl.: Data Definition Lan-
guage) Tabellen angelegt. Auf diese Tabellen greift später eine Anfragesprache wie z.B.:
SQL zu und liefert ein Ergebnis.
Physischer Entwurf
Im physischen Entwurf werden Speicherstruktur und Indexstruktur
1
festgelegt. Um eine mög-
lichst hohe Effizienz bei der Ausführung von Anfragen und Anwendungsprogrammen zu er-
reichen, muss dies vor dem Hintergrund des konzeptuellen Schemas und den zu erwarten-
den Anfragen geschehen. Es fließen dabei aber auch Aspekte wie vorliegende Anzahl, Art
und Größe der Platten, zu erwartende Daten- und Anfragemenge mit ein.
Sollten die Ergebnisse eines oder mehrerer Phasendurchläufe nicht zufrieden stellend sein,
kann man in die vorige Phase zurückkehren und Änderungen vornehmen.
Diese Arbeit beschäftigt sich hauptsächlich mit der konzeptuellen Entwurfsphase und dem
Einsatz von Software, welche in dieser Phase eingesetzt werden kann.
1
Ein Index zu einer Datei ist eine Hilfsstruktur, um Operationen zu beschleunigen, die aufgrund der Organisati-
onsform der Datei nicht effizient ausgeführt werden können.
1. Einführung in den Datenbankentwurf
12
1.2 Datenmodellierung
Im Folgenden werden Datenmodelle und Modellierungskonzepte vorgestellt, die im konzep-
tuellen Entwurf eingesetzt werden. In dieser Modellierungsphase wird das reale System
durch Reduktion auf die relevanten Zusammenhänge vereinfacht. Die Modellierung stützt
sich auf drei Säulen.
- Objekte
- Abstraktionsmechanismen
- Beziehungen
1.2.1 Objekte
Als Objekte werden alle im System verwendeten Einheiten bezeichnet. Hierzu können bei-
spielsweise ein Mensch, ein Gebäude, ein Fahrzeug, ein Flug, ein Datum und vieles mehr
zählen. Objekte besitzen Eigenschaften, auch Attribute genannt. Ein Attribut beschreibt eine
fachliche Eigenschaft eines Objektes. Es wird durch seinen Attributsnamen und seinen Wer-
tebereich definiert. Der Wertebereich, manchmal auch Domäne genannt, gibt die Menge aller
möglichen bzw. zugelassenen Werte für ein Attribut an. Zur Auswahl stehen je nach Daten-
banksystem Integer, Character, Double usw. In dem man den Wertebereich einschränkt,
kann man Sachverhalte sinnvoll modellieren. So ist es z.B. sinnvoll für das Attribut Gehalt
nur positive Werte zuzulassen.
1.2.1 Abstraktionsmechanismen
Vernachlässigt man einige nicht relevante Eigenschaften eines Objekts oder einer Menge
von Objekten, und konzentriert man sich nur auf eine Teilmenge der charakteristischen Ei-
genschaften, so spricht man von Abstraktion. Es gibt drei verschiedene Arten von Abstrakti-
on:
· Klassifikation
· Generalisierung
· Aggregation
Klassifikation
Die Klassifikation wird dazu verwendet, eine Klasse von Objekten zu definieren, welche die
gleichen Eigenschaften besitzt. So ist z.B. das Konzept Personal eine Klasse, deren Mitglie-
der alle Menschen sind. Sie sind bei einer Firma angestellt und führen dort bestimmte Tätig-
keiten aus. Darunter sind z.B. Mitarbeiter Herr Wolfgang Meier, der Pilot bei der Lufthansa
ist, Frau Lisa Fritz, angestellt bei den New York Flight Services Inc., zuständig für den
Check-in wie auch Frau Sabine Vogel, Stewardess bei der Swiss Air. Die Klassenobjekte
haben gemeinsame Eigenschaften aber unter Umständen in einer anderen Ausprägung.
Darunter sind Name, Vorname, Arbeitgeberfirma und ein Tätigkeitsbereich. Sie beziehen alle
ein Gehalt und dem Arbeitgeber ist die Anschrift und ihre Ausbildung bzw. Qualifikation be-
kannt.
1. Einführung in den Datenbankentwurf
13
Generalisierung
Haben Entitätsmengen gemeinsame Attribute, können diese einer neuen übergeordneten
Entitätsmenge zugeordnet werden. Die übergeordnete Entitätsmenge wird als Generalisie-
rungstyp und die untergeordneten als Spezialisierungstypen bezeichnet. Die entstehende
Generalisierungshierarchie verknüpft die Entitätsmengen durch ein Dreieck (IS-A-
Beziehung), wobei der Generalisierungstyp alle Attribute an den Spezialisierungstyp vererbt.
Die identifizierenden Attribute (Schlüsselattribute) müssen gleich sein. Die untergeordneten
Entitätsmengen können eigene Attribute besitzen. In Abbildung 2 haben Pilot und Flugbeglei-
ter die Attribute Name und Anschrift von Person geerbt. Pilot hat zusätzlich noch das Attribut
Lizenz.
Person
Name
Anschrift
is
a
is
a
Pilot
Flugbegleiter
Spezialisierungstypen
Lizenz
Generalisierungstyp
Person
Name
Anschrift
is
a
is
a
Pilot
Flugbegleiter
Spezialisierungstypen
Lizenz
Generalisierungstyp
Abbildung 2: Generalisierung
Aggregation
Unter Aggregation versteht man das Bilden einer neuen Klasse, in dem man Mengen von
anderen Klassen zusammenfasst. Die zusammengefassten Mengen haben dabei unter-
schiedliche Eigenschaften, sind aber alle Komponenten der neu gebildeten Klasse.
Betrachten wir die für den Flugzeugbau relevanten Teile: Dazu zählen unter anderem Flü-
gel, Steuerungsheck, Räder, Flugzeugkörper, technische Fluginstrumente und Sitze. Es soll
sich dabei aber nie um ein bestimmtes Teil handeln, sondern um eine Menge von beispiels-
weise unterschiedlich ausgeprägten Flügeln. Fasst man diese Mengen zu einer neuen Klas-
se Flugzeug zusammen, so spricht man von Aggregation.
1.2.2 Beziehungen
Klassifikation, Generalisierung und Aggregation haben Beziehungen zwischen Klassen ge-
bildet. Die Objekte stehen in einem erkennbaren logischen Zusammenhang, ohne dass man
das gesamte System kennen muss. Genauso gut kann aber auch zwischen zwei oder meh-
reren Objekten eine Assoziation erstellt werden, die keiner der Abstraktionsarten entspricht
und deren Beziehung nur durch die Kenntnis des Sachverhalts erkennbar wird.
1. Einführung in den Datenbankentwurf
14
In der Praxis kann man Relationen in zwei verschiedene Gruppen einteilen. Dabei gruppiert
man Relationen nach dem Aspekt, wie viele Klassen daran beteiligt sind. Relationen, an de-
nen zwei Klassen teilnehmen, werden binär genannt. Nehmen mehr als zwei Objekte daran
teil, spricht man von n-ären Beziehungen.
Binäre Beziehungen
Von binären Beziehungen zwischen Klassen spricht man, wenn genau zwei Klassen in der
Beziehung involviert sind. Als Beispiel betrachte man die Klasse Flugzeug und Pilot. Hier
kann man eine Beziehung bilden. Interpretieren kann man die Beziehung mittels der Tatsa-
che, dass ein Pilot ein Flugzeug fliegt. Genau so gut kann man eine Relation zwischen den
Klassen Person und Flug erzeugen. Sie steht in dem Zusammenhang, dass eine Person
einen Flug buchen kann.
n-näre Beziehungen
Bei n-nären Beziehungen sind immer mehr als zwei Klassen beteiligt.
Flugabschnitt
Flug
Buchung
Passagier
Flugabschnitt
Flug
Buchung
Passagier
Abbildung 3: Ternäre Beziehung
Oft kann man derartige Relationen aber in mehrere binäre Relationen auflösen. Dies hat den
Vorteil, dass bei zweistelligen Relationen zum einen die Kardinalität mehr Aussagekraft hat,
und zum anderen die Relation meist verständlicher ist. Um darstellen zu können, dass ein
Pilot nicht nur eine Fluglizenz auf einen bestimmten Flugzeugtyp hat, sondern mehrere Flug-
lizenzen auf unterschiedliche Flugzeugtypen besitzen kann, werden Beziehungen durch An-
gabe Ihrer Komplexität näher bestimmt.
Komplexität
Der Wert der Komplexität gibt an, wie viele Instanzen einer Klasse an der Beziehung teil-
nehmen können. Es stehen dazu für jede an der Relation teilhabende Klasse Werte zwi-
schen 0 und n zur Verfügung. Stellen wir uns die Klasse als Rechteck vor. Die Beziehung
werden wir durch eine Verbindungslinie zwischen den teilhabenden Klassen kennzeichnen.
Hat ein Pilot Lizenzen auf mehreren Flugzeugtypen erworben, so ergibt sich aus diesem
Sachverhalt die in Abbildung 2 dargestellte Relation:
1. Einführung in den Datenbankentwurf
15
Pilot
Flugzeugtyp
n
n
hat Lizenz
Pilot
Flugzeugtyp
n
n
hat Lizenz
Abbildung 4: Komplexität einer Relation
Liest man von Links nach Rechts, so ergibt sich das n, welches bei der Klasse Flugzeugtyp
steht. Ein Pilot kann eine Lizenz auf einem oder mehreren Flugzeugtypen haben. Liest man
von Rechts nach Links, so ist der Sachverhalt dargestellt, dass die Lizenz auf einem be-
stimmten Flugzeugtyp von mehreren Piloten besessen werden kann.
Kardinalität
Mittels der Kardinalität kann man die Werte der Komplexität genauer spezifizieren.
Kardinalitätsbeschränkungen legen fest, wie viele Instanzen minimal und maximal in die Be-
ziehung eingehen.
Attribute von
Beziehungen
Attribute können nicht nur an Objekten, sondern auch an Beziehungen zugewiesen werden.
So könnte man der Beziehung zwischen Pilot und Flugzeug ein Attribut Datum zuordnen.
1. Einführung in den Datenbankentwurf
16
1.3.
Datenmodelle
Um diese in Beziehung stehenden Objekte darstellen zu können, existieren verschiedene
Datenmodelle. Es handelt sich dabei um graphische und/oder sprachliche Beschreibungen,
in der die schon kennen gelernten Konzepte umgesetzt werden.
Zitat:
A map is not the territory it represents,
but, if correct, it has a similar structure
to the territory, which accounts for its usefulness.
[A. Korzybski, Science & Sanity, 4th Ed. 1958, pp. 58-60]
Datenmodelle sollen die Realität möglichst korrekt abbilden. So tragen sie sehr viel zum Ver-
ständnis des Sachverhaltes bei. Sind die Modelle allerdings fehlerhaft oder bilden wichtige
Details nicht ab, so sind sie unbrauchbar.
Man unterscheidet konzeptionelle und logische Datenmodelle. Bei einem konzeptionellen
Modell handelt es ich um eine Darstellung der Realität in stark abstrahierter Form. Als klassi-
scher Vertreter sei hier das Entity-Relationship-Modell von Chen genannt.
Logische Datenmodelle hingegen unterstützen eine Form von Datenbeschreibungen, welche
durch Computer bearbeitet werden können. Diese Modelle können leicht auf die physika-
lische Struktur einer Datenbank übertragen werden. Das Relationale Modell ist im Bereich
der Datenbankentwicklung das bekannteste. Es wurde 1970 von E. F. Codd bei IBM entwi-
ckelt. In diesem Datenbankmodell werden die Daten in Tabellen (Relationen) gespeichert.
Eine Tabelle besteht aus Reihen (records, tupels), die den Datensatz enthalten und aus
Spalten (fields, columns), welche die Attribute enthalten. Tabellen können durch Spalten mit
gleichen Attributen miteinander verknüpft sein. Jede Tabelle einer Datenbank ist jederzeit
auffindbar, weil sie durch einen eindeutigen Namen identifiziert werden kann. Der Anwender
muss lediglich die Namen kennen, um eine Abfrage zu starten. Auch wird jedes Einzelobjekt
durch eine Eigenschaft gekennzeichnet, deren Wert für dieses Objekt eindeutig ist (vgl. [21]).
Allen Modellen ist dabei gemeinsam, dass keines der Modelle eine Datenbankbeschreibung
liefert, auf der man Datenbankoperationen ausführen könnte. Die Modelle sind lediglich ein
Zwischenschritt. Aus ihnen lassen sich dann einfach Datenbanken definieren (vgl. 3.1.2.3
Forward-Engineering).
Im nachfolgenden Abschnitt werden zwei Datenmodelltypen eingeführt. Es wird zum einen
das ER-Modell, welches seit 1960 im Datenbankentwurf erfolgreich verwendet wird, und zum
anderen UML-Diagramme, welche ursprünglich aus dem Bereich der Softwareentwicklung
kommen, eingeführt. Neben den genannten Modellen existieren noch eine Reihe weiterer
Modelle. Diese werden hier aber außer Acht gelassen, weil sie entweder nicht so weit ver-
breitet sind oder auch in nur wenigen bzw. keinen CASE-Tools eingesetzt werden.
1. Einführung in den Datenbankentwurf
17
1.3.1 ER Modell
Das ER-Modell entstand bereits Ende der 70-er Jahre und gehört zu dem populärsten
Modellen, welche bei einem konzeptionellen Entwurf eingesetzt werden. Es wurde von Dr.
P.Chen
2
entwickelt und erlebte im Laufe der Jahre viele Erweiterungen, die oft unterschiedli-
che Notation und teilweise neue Konzepte ergaben. In der vorliegenden Arbeit wird das er-
weiterte ER-Diagramm erklärt. Dieses unterscheidet sich vom ,,ersten" Modell in so fern,
dass es Abstraktionskonzepte und die Angabe von Kardinalitäten unterstützt.
Das ER-Modell (deutsch: Gegenstand-Beziehungs-Modell) dient zur Abbildung von Gegens-
tänden (engl.: entities) und ihrer Beziehung (engl.: relationship) zueinander.
Als Entity werden die für ein zu entwickelndes System relevanten Objekte dargestellt und
durch Eigenschaften (engl.: attributes, properties) beschrieben. Ein Objekt bzw. eine Entität
ist ein individuelles und identifizierbares Exemplar von Dingen, Personen oder Begriffen der
realen oder der Vorstellungswelt entwickelt.
Entität
Im Deutschen hat sich der Begriff Entität durchgesetzt.
Beispiele für Entitäten sind:
· Der Flugzeugtyp Boeing 747
· Der Passagier Hans Dampf
· Der Flughafen New York.
· Passagiere
Eine Entitätsmenge (engl.: entity set), auch Entitätstyp genannt, ist die Zusammenfassung
von Entitäten mit gleichen Eigenschaften unter einem eindeutigen, gemeinsamen Oberbeg-
riff. Graphisch werden sie im ER-Diagramm als Rechtecke dargestellt.
Seien der Passagier "Elmasri" und "Navathe" jeweils Entitäten. Dann kann man eine Enti-
tätsmenge "Passagier" modellieren.
In der Praxis hat sich mittlerweile aber durchgesetzt, dass eine Entitätsmenge Entität ge-
nannt wird. Man spricht also von Entität, wenn man eine Klasse von Objekten meint. Im Fol-
genden wird der Begriff Entität auch nach dieser Konvention verwendet.
Attribut
Die Beschreibung der Eigenschaften einer Entität erfolgt durch Zuordnung von Attributen.
Sie wird durch den Attributsnamen und dessen Wertebereich definiert. Mögliche Attribute der
Entität "Passagier" wären "Name", "Anschrift" oder "Alter". Der Wertebereich für Name und
Anschrift wären Zeichenfolgen bestehend aus Buchstaben und Zahlen. Dagegen ist beim
Attribut Alter nur ein Wertebereich der natürlichen Zahlen zulässig.
Man unterscheidet beschreibende Attribute, welche die anwendungsrelevanten Eigenschaf-
ten der Entität festhalten, und identifizierende Attribute, welche Schlüssel zur eindeutigen
Identifikation einer konstanten Entität innerhalb ihrer Entitätsmenge bilden.
2
Dr. P. Chen: Professor of Computer Science since 1983. He is the originator of the Entity-Relationship Model
(Weitere Informationen unter:
http://www.csc.lsu.edu/~chen/chen.html
)
1. Einführung in den Datenbankentwurf
18
Schlüssel
Ein Schlüssel K kann aus einem oder mehreren identifizierenden Attributen zusammenge-
setzt sein und ist stets eine minimale identifizierende Attributkombination. Jede echte Ober-
menge von K ist ein Schlüsselkandidat. Falls die Attributkombination K
1
und K
2
beide eine
Entität identifizieren können, aber K
1
in K
2
enthalten ist, dann ist nur K
1
der Schlüssel. K
2
ist
ein Schlüsselkandidat.
Attribute
Attribute werden in ER-Diagrammen als Ovale dargestellt und durch ungerichtete Kanten mit
der entsprechenden Entitätsmenge verbunden. Der Primärschlüssel wird unterstrichen. (vgl.
Abbildung 5: Entität mit Attributen)
Passagier
PassportNr
Name
Anschrift
Passagier
PassportNr
Name
Anschrift
Abbildung 5: Entität mit Attributen
Beziehungen
Abhängigkeiten zwischen Entitäten bzw. Entitätsmengen werden durch Beziehungen (engl.
relationships / relations) dargestellt. Eine Beziehung wird durch eine ungerichtete Linie zwi-
schen den beteiligten Entitäten dargestellt. In der Mitte der Verbindungslinie wird eine Raute
gesetzt, in der der Name der Beziehung eingetragen wird. Betrachten wir folgenden Sach-
verhalt: Der Passagier bucht einen Flug. Und andererseits kann ein Flug von einer Person
gebucht werden. Will man einer Beziehung ein Attribut zuordnen, dann verbindet man die
Ovale direkt mit der Raute.
Flug
Buchung
Datum
Person
Flug
Buchung
Datum
Person
Abbildung 6: Beziehung mit Attribut
Bei dem vorliegenden Beispiel könnte man das Attribut ,,Datum der Flugbuchung" einfügen.
(Siehe
Abbildung 6: Beziehung
mit Attribut
)
1. Einführung in den Datenbankentwurf
19
Klassifikation / Aggregation
Zur Darstellung dieser beiden Abstraktionsmechanismen gibt es im ER-Diagramm keine
Möglichkeit. Der Sachverhalt muss über eine einfache Relationship realisiert werden.
Generalisierung
In einem ER-Modell ist es möglich, eine Generalisierungshierarchie zwischen Entitäten auf-
zubauen. Die Generalisierung ist wie folgt definiert: Eine Entität E ist eine Generalisierung
von einer Gruppe von Entitäten E
1
, E
2
, E
3
, ..., E
n
, wenn jedes Objekt der Klassen E
1
, ...E
n
auch ein Objekt der Klasse E ist. Betrachten wir folgendes Beispiel:
Abbildung 7: Generalisierung im ER-Modell
Dabei spielt es keine Rolle, dass Angestellte auch in Männer und Frauen eingeteilt werden
können. Das sollte hier nicht modelliert werden. Aber es ist deutlich, dass jedes Objekt aus
der Klasse Pilot auch in der Klasse der Angestellten enthalten ist. Das bedeutet, dass Ange-
stellter eine Generalisierung von Pilot ist. Das Selbe gilt für die Entität Flugbegleiter. In den
Ebenen oberhalb ist die Person eine Generalisierung von sowohl Mann, Frau und Angestell-
ter.
Kardinalität
Die Kardinalität wird jeweils bei der Entität in der Nähe der Beziehungskante vermerkt.
Zum einen gibt es die CHEN-Notation. Sie kennt nur die Kardinalitätswerte 1 und n. Die aus
UML-Klassendiagrammen übernommene Notation bietet mehr Möglichkeiten zu klassifizie-
ren. Neben ,,genau 1" und ,,vielen" unterstützt sie die den Wert 0 und die Angabe von Inter-
vallen. In einer Variante dieser Notation werden die Sterne durch das aus der Chen-Notation
bekannte ,,n" ersetzt. Die Krähenfussnotation verwendet kleine Symbole an den Enden der
Beziehungskanten. Die ausgehenden Kanten aus den Symbolen lassen eine intuitive Deu-
tung zu (siehe Tabelle 1: Notation von Kardinalitäten).
1. Einführung in den Datenbankentwurf
20
Notationsarten
CHEN UML
IE
3
/ DM-
Notation
4
(IDEF1X)
5
Bedeutung
n
*
Beliebig viele
0..1
Z
Null oder 1
0..*
0, 1, oder mehr
1
1..1
1
Mindestens 1 und maxi-
mal 1
1..*
P
1 oder mehr
Tabelle 1: Notation von Kardinalitäten
Man beachte, dass es sich bei der IDEF1X-Notation immer um die Darstellung der ,,rechten"
Seite handelt. Seien folgende Beispiele gegeben:
Eine Fluggesellschaft hat ein oder mehrere Flugzeuge
:
Die rechte Seite ist wie in Tabelle 1: Notation von Kardinalitäten beschrieben. Die linke Seite
der Relationship wird festgelegt durch die passende Wahl von Beziehungstypen wie 1: n
oder n:m. Will man auf der linken Seite mit der IDEF1X-Notation eine Null darstellen, so ver-
wendet man eine kleine Raute.
Die IDEF1X Notation regelt allerdings nicht nur die Darstellung von Kardinalitäten, sondern
auch die von Entitäten, schwachen Entitäten und Relationship-Linien. (vgl. [16])
3
IE-Notation: Bezeichnung der Notation bei logischer Modellierung- DM-Notation bei physischer
4
manchmal auf Krähenfussnotation genannt
5
http://www.idef.com/Downloads/pdf/Idef1x.pdf
1. Einführung in den Datenbankentwurf
21
1.3.2 UML-Diagramme
UML (Unified Modeling Language) wurde mit dem Ziel entwickelt, eine einheitliche, allgemein
einsetzbare und objektorientierte Modellierungssprache für die Entwicklung und Dokumenta-
tion von Softwaresystemen zu schaffen (vgl. [8]). Von der Object Management Group (OMG)
wurde sie inzwischen als Industriestandard verabschiedet [3] und ihre zunehmende Verbrei-
tung deutet auf eine wachsende Akzeptanz bei Softwareentwicklern hin. Ein weit verbreitetes
Missverständnis ist, dass UML eine Sprache allein für objektorientierte Entwicklungen sei.
Ein Missverständnis deshalb, weil UML als eine sehr flexibel und anpassungsfähige Sprache
entwickelt wurde. Dies ebnet den Weg für den Einsatz von UML in vielen verschiedenen
Modellierungstypen, wie Modelle für Geschäftsprozesse (business process), Arbeitsabläufe
in Unternehmen (Business Workflow), Folge von Anfragen (sequence of query), Anwendun-
gen, Datenbanken, Strukturen (wie z.B. Rechnerstrukturen) und vieles mehr (vgl. [8]).
Beim Einsatz von UML zur Datenbankentwicklung bietet sich ein großer Vorteil:
Das Team, welches in der Anwendungsprogammierung schon mit UML arbeitet, kann mittels
dieser Sprache mit dem Team der Datenbankentwicklung kommunizieren. Das war beim
Einsatz von ER-Diagrammen nur bedingt möglich. Es sind zwar in ER- und UML-Modellen
ähnliche Modellierungsansätze (vgl. Kapitel...) und Notationen (vgl.) vorhanden, jedoch un-
terscheiden sie sich in der Darstellung sowohl von Objekten als auch von Kardinalität der
Beziehungen.
UML stellt eine Reihe von Diagrammen zur Verfügung. Im folgenden Abschnitt werden Funk-
tion und Notation von Diagrammen erläutert, welche im Datenbankentwurf zum Einsatz
kommen. UML-Diagramme lassen sich in Struktur-, Verhaltens- und Implementierungsdia-
gramme gruppieren. Für den Datenbankentwurf sind hauptsächlich Strukturdiagramme im
Einsatz. Dazu zählen Aktivitätsdiagramm, Anwendungsfall- und Klassendiagramm. Das Akti-
vitätsdiagramm visualisiert Abläufe im System.
1.3.2.1. Anwendungsfalldiagramme
Mehrere Anwendungsfalldiagramme (engl.: Use-Case-Diagram) beschreiben die Anforde-
rungen an das System. Damit werden das Verhalten und der Funktionsumfang des zu
realisierenden Systems festgelegt.
Definition: Use-Case:
Eine Sequenz von zusammengehörenden Transaktionen, die von einem Akteur im Dialog
mit einem System ausgeführt werden, um einen sichtbaren, quantifizierbaren oder qualifi-
zierbaren Einfluss auf die Systemumgebung zu erzeugen. Ein Use-Case-Diagramm besteht
aus einem Akteur und einem System, welches als Rechteck dargestellt wird. Der Akteur
kann eine Aktion im System auslösen. Eine Aktion bewirkt eine Zustandsänderung im Sys-
tem. Anwendungsfälle werden im System als Ovale eingetragen und erhalten einen Namen.
(Siehe Abbildung 8).
1. Einführung in den Datenbankentwurf
22
Abbildung 8: Elemente eines Use-Case-Diagramms
Aus der Use-Case Beschreibung lassen sich fachliche Begriffe (Objekte), ihre Aufgaben,
Eigenschaften und Zusammenhänge ermitteln. Dies kann durch eine geeignete Methode wie
zum Beispiel OMT (deutsch: object oriented modeling technique) geschehen. Die Objekte
bzw. ihre zugehörigen Klassen werden in Form von Diagrammen dargestellt. Diese Dia-
gramme ähneln sehr den Entity-Relationship-Diagrammen.
1.3.2.2. Klassendiagramm
Das UML-Klassendiagramm fand seinen Ursprung im ER-Modell von P.Chen. Es übernahm
die Konzepte Entität (Objekte) und Relationen.
Klassen
Was die Objekte im ER-Modell, sind die Klassen im UML-Klassendiagramm. Sie werden in
UML-Notation folgendermaßen abgebildet: Eine einfache Klassenansicht wird durch ein
Rechteck abgebildet. Im oberen Abschnitt steht der Klassenname. Im zweiten Drittel werden
Attribute der Klasse und im dritten Drittel können Methoden angegeben werden. In der Da-
tenbankmodellierung werden allerdings keine Methoden angegeben, sondern nur im Soft-
wareentwurf.
binäre Relationen
Eine binäre Relation wird durch eine Verbindungslinie zwischen zwei Klassen dargestellt.
Der Name der Relation wird oberhalb bzw. unterhalb der Verbindungslinie angegeben. Ein
Pfeil dazu kennzeichnet die Richtung, in welcher die Relation besteht. (siehe
Abbildung 9: Beziehung zwischen zwei
UML-Klassen
)
1. Einführung in den Datenbankentwurf
23
Abbildung 9: Beziehung zwischen zwei UML-Klassen
Eine Flugstrecke <<wird geflogen>> mit einem bestimmten Flugzeugtyp. Ebenso gibt
ein Flugzeugtyp eine Sitzverteilung für eine Flugstrecke, auf dem der Flugzeugtyp
eingesetzt wird, vor.
n-näre Beziehungen
Relationen, an denen mehr als zwei Klassen beteiligt sind, werden ähnlich denen im ER-
Diagramm dargestellt. Zwischen die beteiligten Klassen wird eine Raute eingefügt. Von den
Klassen führt jeweils eine Linie zu der Raute, so dass sich folgendes Bild ergibt
(Siehe Abbildung 10: Ternäre Beziehung)
Abbildung 10: Ternäre Beziehung
Klassifikation
In UML wird der Klassifikation keine gesonderte Notation zugeordnet. Die spezifischen Ei-
genschaften einer klassifizierenden Relation werden durch das Angeben von Bezie-
hungsstelligkeit und Kardinalität beschrieben.
Aggregation
Bei der Aggregation handelt es sich um einen Spezialfall der Relation. Man unterscheidet
zwei Arten. Zum einen die existenzgebundene und zum anderen die nicht-
existenzgebundene Aggregation. Betrachten wir folgenden Fall:
Ein Flughafen hat mehrere Terminals. Existiert kein Flughafen, existieren auch keine Termi-
nals. Es handelt sich dabei also um eine existenzgebundene Form der Aggregation.
1. Einführung in den Datenbankentwurf
24
Sie wird wie in Abbildung 11: Aggregation abgebildet umgesetzt. Die nicht-
existenzgebundene ist mit einer nicht ausgefüllten Raute definiert.
Abbildung 11: Aggregation
Generalisierung:
Die Generalisierung kann folgendermaßen dargestellt werden:
Durch Pfeile, die von den Kindern zum Elternobjekt führen. Manchmal wird auch ein Halb-
kreis auf diese Verbindungslinie gesetzt. Die gerundete Linie ist dann in Richtung Elternob-
jekt gerichtet.
Eltern
Kind 1
Kind 2
Eltern
Kind 1
Kind 2
Eltern
Kind 1
Kind 2
Eltern
Kind 1
Kind 2
Abbildung 12: Notationsvarianten
Kardinalität
In Abbildung 11: Aggregation wurde schon die Kardinalität der abgebildeten Aggregation
eingezeichnet. Von Links nach Rechts gelesen ist es folgendermaßen zu interpretieren. Ein
Flughafen besteht aus mindestem einem oder mehreren (1 ..* ) Terminals. Von Rechts nach
Links entsprechend: Ein Terminal gehört zu genau einem (1) Flughafen. In Tabelle 2: Nota-
tion von Kardinalität sind alle möglichen Werte zur Angabe der Kardinalität aufgelistet:
UML-Notation
Bedeutung
*
Beliebig viele
0..1
Null oder 1
0..*
0, 1, oder mehr
1..1
Mindestens 1 und maximal 1
1..*
1 oder mehr
Tabelle 2: Notation von Kardinalität in UML
1. Einführung in den Datenbankentwurf
25
Attribute
Attribute werden in der Box unterhalb des Klassennamens aufgeführt. Entweder vermerkt
man nur den Attributnamen oder für eine ausführliche Modellierung auch gleich den Attribut-
typ.
Abbildung 13: Relation mit Attributen
Will man einer Beziehung ein Attribut zuordnen, geschieht das mittels eines Rechtecks ver-
gleichbar mit der Darstellung eines Klassenattributes. Allerdings wird das Rechteck mit einer
gestrichelten Linie mit der Beziehung verbunden, der das Attribut zugewiesen werden soll.
1. Einführung in den Datenbankentwurf
26
1.3.3. Relationales Datenmodell
Das Relationale Datenmodell, kurz auch Relationenmodell genannt, wurde 1970 von E.F.
Codd entwickelt. Es soll Datenmodelle wie z.B. das ER-Modell in ein Datenformat abbilden,
welches von relationalen DBMS verarbeitet werden kann. Man kann sich das Modell folgen-
dermaßen vorstellen:
Tabellenname
Spalten-
name
Spalten-
Name 2
Spalten-
Name 3
Tabellen-
eintrag
Tabellen-
eintrag
Tabellen-
eintrag
...
...
...
Tabellenname
Spalten-
name
Spalten-
Name 2
Spalten-
Name 3
Tabellen-
eintrag
Tabellen-
eintrag
Tabellen-
eintrag
...
...
...
Abbildung 14: Relationenmodell
1.3.3.1. Aufbau des Relationenmodells
Das relationale Modell besteht aus Objekten, Operationen und Regeln. Zu den Objekten
zählen Relationen, Tupel, Attribute, Domänen und Schlüssel. Unter Operationen versteht
man neben Abfrage- bzw. Updateoperationen auf Relationen auch Operationen zum Anle-
gen und Löschen von Relationen. Regeln werden definiert, um die Konsistenz der Daten zu
gewährleisten.
1.3.3.2. Begriffsdefinitionen
Als Relation bezeichnet man eine logisch zusammenhängende Einheit von Informationen.
Eine Relation ist durch ihren Namen und die Namen der Attribute eindeutig beschrieben.
Sie entspricht einer Entität im Entity-Relationship-Diagramm. Dargestellt wird eine Relation
als zweidimensionale Tabelle mit einer festen Anzahl von Spalten und einer variablen Anzahl
von Zeilen dar. Die Spalte einer Relationentabelle stellt ein Attribut der Relation dar. Diese
ist entsprechend zu dem Attribut einer Entität. Die Einträge in den Zeilen des Relationenmo-
dells sind Instanzen einer konkreten Entität eines ER-Diagramms. Man bezeichnet die Ein-
träge als Tupel oder Datensätze. Manchmal auch als Records. Der Wertebereich eines
Atttributs (Domain) muss festgelegt werden, damit bei Änderungen der Attributwerte Syn-
taxprüfungen durchgeführt.
1. Einführung in den Datenbankentwurf
27
Für eine Relation müssen folgende Eigenschaften gelten:
- es gibt keine zwei Tupel, die in ihren Attributwerten übereinstimmen.
- Die Reihenfolge, in der die Tupel bzw. Attribute einer Relation gespeichert werden, ist
nicht definiert, spielt also keine Rolle
Schlüssel erlauben den Zugriff auf Tupels. Im Relationalen Modell gibt es folgende Schlüs-
selarten: Primärschlüssel, Sekundärschlüssel und Fremdschlüssel
6
.
6
http://www3.informatik.tu-muenchen.de/lehre/WS2001/HSEM-bayer/Ausarbeitung_codd.pdf
2. Fallbeispiel
28
Kapitel 2
2. Fallbeispiel
Im Folgenden wird ein Fallbeispiel eingeführt. Es handelt sich dabei um Szenarien aus dem
thematischen Gebiet Flughafen, Reise, Buchung, Sicherheit, Angestellte und vieles mehr.
Dieses Beispiel wird Grundlage der Modellierung in Kapitel 2 und 4 sein.
2.1. Einzelheiten des Fallbeispiels
Das Fallbeispiel wird nun aus verschiedenen Perspektiven durchleuchtet: Zum einen aus der
Sicht eines Passagiers. Hier beginnt es bei der Flugbuchung, geht weiter über Check-In,
Flugantritt bis hin zur Landung am Zielflughafen.
Die Sicht der Flughafenverwaltung gibt einen Einblick in Check-In, Flugabfertigung und be-
triebswirtschaftliche Aspekte wie Vermietung von Ladenflächen. Die Perspektive der Flugge-
sellschaft bietet einen Einblick in Durchführung von Flugabschnitten, Wartung von Flugzeu-
gen, usw. Für die Modellierung des gesamten Fallbeispiels müssen die einzelnen Sichten
integriert werden.
2.1.1. Sicht des Passagiers:
Abbildung 15: Szenario Flugbuchung gibt eine kleine Einführung in die Flugbuchung.
Abbildung 15: Szenario Flugbuchung
Kunde will in Reisebüro Flug
strecke buchen
Festlegung von
Reiseroute (Start-,
Zielflughafen)
Termin (Datum. Uhrzeit)
Anfrage an Flugdatenbank
Ergebnis: Freie Plätze zu
gesuchter Flugroute und
Preise für diverse Sitzkate-
gorien
Buchung der Flugstrecke in
bestimmter Sitzkategorie.
Bezahlung
Ticketausstellung (Name,
Personalausweisnummer)
Kunde hat
Flugbuchung
erfolgreich
abgeschlossen
Ende der Leseprobe aus 131 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2003, Vergleich und Beurteilung verschiedener CASE-Tools für den Einsatz im konzeptionellen Datenbankentwurf, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/222221
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare