Vergleich verschiedener Case-Tools für den Einsatz im konzeptuellen Datenbankentwurf

Inhaltsverzeichnis

0. Motivation für den Einsatz von CASE-Tools

1. Einführung in den Datenbankentwurf
1.1 Phasen des Datenbankentwurfs
1.2 Datenmodellierung
1.2.1 Objekte
1.2.1 Abstraktionsmechanismen
1.2.2 Beziehungen
1.3. Datenmodelle
1.3.1 ER – Modell
1.3.2 UML-Diagramme
1.3.2.1. Anwendungsfalldiagramme
1.3.2.2. Klassendiagramm
1.3.3. Relationales Datenmodell
1.3.3.1. Aufbau des Relationenmodells
1.3.3.2. Begriffsdefinitionen

2. Fallbeispiel
2.1. Einzelheiten des Fallbeispiels
2.1.1. Sicht des Passagiers:
2.1.2 Sicht der Flughafenverwaltung
2.1.3 Sicht der Fluggesellschaft

3. Klassifizierung der CASE-Werkzeuge
3.1. Fundamentale Anforderungen
3.1.1 Diagramme
3.1.2. Funktionen
3.1.2.1.Korrektheit
3.1.2.2. Datenbankanbindung
3.1.2.3 Forward-Engineering
3.1.2.3.1 Transformation ER-Modell nach Relationenmodell
3.1.2.3.2 SQL-Code
3.1.3. Bedienungskomfort
3.2. Erweiterte Anforderungen
3.2.1. Import
3.2.2. Reverseengineering
3.2.3. Referentielle Integrität
3.2.4. Festlegen von Indizes
3.2.5. Flexibilität
3.3. Weitere Bewertungspunkte

4. Bewertung
4.1. Powerdesigner
4.1.1. Installation
4.1.1. Erscheinungsbild
4.1.2. Modellierungsarten
4.1.2.1 ER-Modell
4.1.2.2 Physisches Datenmodell
4.1.2.3 UML-Klassenmodell
4.1.3. Funktionen
4.1.3.1. Validierungsfunktion
4.1.3.2. Datenbankanbindung
4.1.3.3. Forward-Engineering
4.1.3.3.1 Umsetzung einer 1:1-Relationship
4.1.3.3.2 Umsetzung einer 1:n-Relationship
4.1.3.3.3 Umsetzung einer n:m-Relationship
4.1.3.4. Reverse-Engineering
4.1.3.5. Import / Export
4.1.3.6. Reportfunktion
4.1.3.7 Anlegen von Indizes
4.1.3.8 Zusatzfunktionen
4.1.3.8.1 Ausführen von SQL-Statements
4.1.3.8.2 Speicherverwaltung
4.1.3.8.3 Schätzen der Datenbankgröße
4.1.4. Hilfe / Support
4.1.5. Benutzerfreundlichkeit
4.1.7. Resümee
4.2. CaseStudio 2
4.2.1. Installation
4.2.2. Erscheinungsbild
4.2.3. Modellierung
4.2.3. Funktionen
4.2.3.1. Validierungsfunktion
4.2.3.2. Datenbankanbindung
4.2.3.3. Forward-Engineering
4.2.3.3.1 (1:1)-Relationship:
4.2.3.3.2 (1:n)-Relationship
4.2.3.3.3. (n:m)-Relationship
4.2.3.3.4 Umsetzung des Fallbeispiels
4.2.3.4. Reverseengineering
4.2.3.5. Import / Export
4.2.3.6 Anlegen von Indizes
4.2.3.7 Reportfunktion
4.2.4. Hilfe / Support
4.2.5. Benutzerfreundlichkeit
4.2.6. Resümee
4.3. ERwin
4.3.1. Installation
4.3.2. Erscheinungsbild
4.3.3. Diagramme
4.3.3.2. Physisches Modell
4.3.3.3. Logisch / Physisches Modell
4.3.3.3. Wechsel zwischen den Modelltypen
4.3.4. Funktionen
4.3.4.1. Validierungsfunktion
4.3.4.2. Datenbankanbindung
4.3.4.3. Forward-Engineering
4.3.4.3.1 Umsetzung 1:1-Relationship
4.3.4.3.2 Umsetzung 1:n-Relationship
4.3.4.3.3.Umsetzung einer n:m-Relationship
4.3.4.4 Reverse-Engineering
4.3.4.5. Import / Export
4.3.4.6. Anlegen von Indizes
4.3.4.7. Reportfunktion
4.3.5. Hilfe / Support
4.3.6. Benutzerfreundlichkeit
4.3.7. Resümee

5. Resümee und Ausblick
5.1. Gesamtwertung
5.2. Vor- und Nachteile beim Einsatz von CASE-Werkzeugen

Anhang

Literaturverzeichnis

Abbildungsverzeichnis:

0. Motivation für den Einsatz von CASE-Tools

Eine immer größere Rolle spielen Informationssysteme in unserem Leben. Informationssysteme 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 Datenbanken 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 genannten Anforderungen möglichst vollständig und korrekt zu erfassen und in einem konzeptionellen 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 Informationssystems sein.

Für die Darstellung der Anforderungen sind in den vergangen Jahren eine Reihe von Methoden 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 eingesetzt, 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 Datenbankmodellierung ihren Einsatz. Entweder wurden neue Tools entwickelt oder Softwareentwicklungstools 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 vorhandener 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 angeboten 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ützung 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 Korrektheit zu überprüfen und automatisch SQL-Code zu generieren. Weitere Anforderungen wurden nicht gestellt, es fließt jedoch positiv in die Bewertung mit ein, wenn das Tool mehr Funktionen bietet.

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 zurü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.

Kapitel 1

1. Einführung in den Datenbankentwurf

Die nachfolgenden Abschnitte beschäftigen sich mit den verschiedenen Phasen des Datenbankentwurfs. Des Weiteren werden Datenmodelle eingeführt, welche zur Modellierung von Datenbanken verwendet werden können. Darunter ist das ER-Modell von Chen, das erweiterte ER-Modell, welches auf das von Chen aufbaut. Da UML nicht nur in der Softwareentwicklung 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Phasen des Datenbankentwurfs

Informationsbedarfsanalyse

Am Anfang steht die Informationsbedarfsanalyse - auch Anforderungsanalyse genannt.

Hier werden zunächst die Anforderungen an die zu entwerfende Datenbank ermittelt. Während 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 werden 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 formalisierten Beschreibung. Die Beschreibung soll in einem semantischen Datenmodell realisiert werden, welches vollständig, widerspruchsfrei, konsistent und redundanzfrei sein soll. Es gibt verschiedene Datenmodelle, welche in dieser Phase eingesetzt werden können. Diese werden ausführlich in Kapitel 1.3. Datenmodelle vorstellt.

Logischer Entwurf

Der logische Entwurf bildet das konzeptionelle Modell auf Datenmodelle des Datenbanksystems ab. Es werden mittels einer Datenbank-Definitions-Sprache (engl.: Data Definition Language) 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öglichst hohe Effizienz bei der Ausführung von Anfragen und Anwendungsprogrammen zu erreichen, muss dies vor dem Hintergrund des konzeptuellen Schemas und den zu erwartenden 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.2 Datenmodellierung

Im Folgenden werden Datenmodelle und Modellierungskonzepte vorgestellt, die im konzeptuellen 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 beispielsweise 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 Wertebereich 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 Datenbanksystem 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 Eigenschaften, so spricht man von Abstraktion. Es gibt drei verschiedene Arten von Abstraktion:

- 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 Mitglieder alle Menschen sind. Sie sind bei einer Firma angestellt und führen dort bestimmte Tätigkeiten 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 bekannt.

Generalisierung

Haben Entitätsmengen gemeinsame Attribute, können diese einer neuen übergeordneten Entitätsmenge zugeordnet werden. Die übergeordnete Entitätsmenge wird als Generalisierungstyp 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 Flugbegleiter die Attribute Name und Anschrift von Person geerbt. Pilot hat zusätzlich noch das Attribut Lizenz.

Abbildung in dieser Leseprobe nicht enthalten

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 unterschiedliche 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 beispielsweise unterschiedlich ausgeprägten Flügeln. Fasst man diese Mengen zu einer neuen Klasse Flugzeug zusammen, so spricht man von Aggregation.

1.2.2 Beziehungen

Klassifikation, Generalisierung und Aggregation haben Beziehungen zwischen Klassen gebildet. Die Objekte stehen in einem erkennbaren logischen Zusammenhang, ohne dass man das gesamte System kennen muss. Genauso gut kann aber auch zwischen zwei oder mehreren Objekten eine Assoziation erstellt werden, die keiner der Abstraktionsarten entspricht und deren Beziehung nur durch die Kenntnis des Sachverhalts erkennbar wird.

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 denen 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 Tatsache, 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.

Abbildung in dieser Leseprobe nicht enthalten

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 Fluglizenzen auf unterschiedliche Flugzeugtypen besitzen kann, werden Beziehungen durch Angabe Ihrer Komplexität näher bestimmt.

Komplexität

Der Wert der Komplexität gibt an, wie viele Instanzen einer Klasse an der Beziehung teilnehmen können. Es stehen dazu für jede an der Relation teilhabende Klasse Werte zwischen 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:

Abbildung in dieser Leseprobe nicht enthalten

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 bestimmten 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 Beziehung 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.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 Verstä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 klassischer 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 entwickelt. 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 verbreitet sind oder auch in nur wenigen bzw. keinen CASE-Tools eingesetzt werden.

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 unterschiedliche Notation und teilweise neue Konzepte ergaben. In der vorliegenden Arbeit wird das erweiterte 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 Gegenstä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 Oberbegriff. Graphisch werden sie im ER-Diagramm als Rechtecke dargestellt.

Seien der Passagier “Elmasri“ und “Navathe“ jeweils Entitäten. Dann kann man eine Entitätsmenge “Passagier“ modellieren.

In der Praxis hat sich mittlerweile aber durchgesetzt, dass eine Entitätsmenge Entität genannt wird. Man spricht also von Entität, wenn man eine Klasse von Objekten meint. Im Folgenden 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 Eigenschaften der Entität festhalten, und identifizierende Attribute, welche Schlüssel zur eindeutigen Identifikation einer konstanten Entität innerhalb ihrer Entitätsmenge bilden.

Schlüssel

Ein Schlüssel K kann aus einem oder mehreren identifizierenden Attributen zusammengesetzt sein und ist stets eine minimale identifizierende Attributkombination. Jede echte Obermenge von K ist ein Schlüsselkandidat. Falls die Attributkombination K1 und K2 beide eine Entität identifizieren können, aber K1 in K2 enthalten ist, dann ist nur K1 der Schlüssel. K2 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)

Abbildung in dieser Leseprobe nicht enthalten

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 zwischen 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 Sachverhalt: 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.

Abbildung in dieser Leseprobe nicht enthalten

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)

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 aufzubauen. Die Generalisierung ist wie folgt definiert: Eine Entität E ist eine Generalisierung von einer Gruppe von Entitäten E1, E2, E3, …, En, wenn jedes Objekt der Klassen E1, …En auch ein Objekt der Klasse E ist. Betrachten wir folgendes Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

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 Angestellter 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 Angestellter.

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 klassifizieren. Neben „genau 1“ und „vielen“ unterstützt sie die den Wert 0 und die Angabe von Intervallen. 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 Deutung zu (siehe Tabelle 1: Notation von Kardinalitäten).

Notationsarten

Abbildung in dieser Leseprobe nicht enthalten

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:

Abbildung in dieser Leseprobe nicht enthalten

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 verwendet man eine kleine Raute.

Abbildung in dieser Leseprobe nicht enthalten

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])

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 Dokumentation von Software­systemen zu schaffen (vgl. [8]). Von der Object Management Group (OMG) wurde sie inzwischen als Industriestandard verabschiedet [3] und ihre zunehmende Verbreitung 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), Anwendungen, 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 unterscheiden 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 Funktion und Notation von Diagrammen erläutert, welche im Datenbankentwurf zum Einsatz kommen. UML-Diagramme lassen sich in Struktur-, Verhaltens- und Implementierungsdiagramme gruppieren. Für den Datenbankentwurf sind hauptsächlich Strukturdiagramme im Einsatz. Dazu zählen Aktivitätsdiagramm, Anwendungsfall- und Klassendiagramm. Das Aktivitätsdiagramm visualisiert Abläufe im System.

1.3.2.1. Anwendungsfalldiagramme

Mehrere Anwendungsfalldiagramme (engl.: Use-Case-Diagram) beschreiben die Anforderungen 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 qualifizierbaren 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 System. Anwendungsfälle werden im System als Ovale eingetragen und erhalten einen Namen. (Siehe Abbildung 8).

Abbildung in dieser Leseprobe nicht enthalten

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 Diagramme ä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 Datenbankmodellierung werden allerdings keine Methoden angegeben, sondern nur im Softwareentwurf.

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)

Abbildung in dieser Leseprobe nicht enthalten

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 in dieser Leseprobe nicht enthalten

Abbildung 10: Ternäre Beziehung

Klassifikation

In UML wird der Klassifikation keine gesonderte Notation zugeordnet. Die spezifischen Eigenschaften einer klassifizierenden Relation werden durch das Angeben von Beziehungsstelligkeit 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 Terminals. Es handelt sich dabei also um eine existenzgebundene Form der Aggregation.

Sie wird wie in Abbildung 11: Aggregation abgebildet umgesetzt. Die nicht-existenzgebundene ist mit einer nicht ausgefüllten Raute definiert.

Abbildung in dieser Leseprobe nicht enthalten

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 Halbkreis auf diese Verbindungslinie gesetzt. Die gerundete Linie ist dann in Richtung Elternobjekt gerichtet.

Abbildung in dieser Leseprobe nicht enthalten

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: Notation von Kardinalität sind alle möglichen Werte zur Angabe der Kardinalität aufgelistet:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Notation von Kardinalität in UML

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 Attributtyp.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Relation mit Attributen

Will man einer Beziehung ein Attribut zuordnen, geschieht das mittels eines Rechtecks vergleichbar mit der Darstellung eines Klassenattributes. Allerdings wird das Rechteck mit einer gestrichelten Linie mit der Beziehung verbunden, der das Attribut zugewiesen werden soll.

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 folgendermaßen vorstellen:

Abbildung in dieser Leseprobe nicht enthalten

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 Anlegen 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 Relationenmodells sind Instanzen einer konkreten Entität eines ER-Diagramms. Man bezeichnet die Einträge als Tupel oder Datensätze. Manchmal auch als Records. Der Wertebereich eines Atttributs (Domain) muss festgelegt werden, damit bei Änderungen der Attributwerte Syntaxprüfungen durchgeführt.

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üsselarten: Primärschlüssel, Sekundärschlüssel und Fremdschlüssel^[6].

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 betriebswirtschaftliche Aspekte wie Vermietung von Ladenflächen. Die Perspektive der Fluggesellschaft bietet einen Einblick in Durchführung von Flugabschnitten, Wartung von Flugzeugen, 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 in dieser Leseprobe nicht enthalten

Abbildung 15: Szenario Flugbuchung

Eine Person kann im Reisebüro ein oder mehrere Flugabschnitte buchen. Diese finden zu einem bestimmten Datum und zu einer festgelegten Uhrzeit statt. Sie starten auf einem Flughafen, welcher eindeutig durch ein internationales Flughafenkürzel gekennzeichnet ist. Ebenso ist der Zielflughafen bestimmt. Tickets können nur ausgestellt werden, wenn die Anfrage an die Flugdatenbank einen Flug mit freiem Platzkontingent in der gewünschten Klasse (Economy, Business oder First Class) liefert. Die Preise sind in der jeweiligen Landswährung des Startflughafens angegeben. Der Umrechnungskurs ist bekannt

Ist der Zahlungsvorgang erfolgt, wird dem Kunden ein Ticket mit einer eindeutigen Ticket-ID ausgestellt. Auf dem Ticket werden Name, Anschrift, Start- und Zielflughafen, Termin des Fluges, Preis, Sitzplatz, Fluggesellschaft und Personalausweisnummer vermerkt.

Will der Passagier den Flug antreten, spielt sich folgendes Szenario ab (vgl.: Abbildung 16: Passagier tritt Flug an.)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Passagier tritt Flug an.

Folgende Einzelheiten zum Flug spielen eine Rolle:

Ein Flug kann auf mehrere Flugabschnitte aufgeteilt sein. Dann muss der Passagier diesen Kreislauf mehrmals durchlaufen, bis er am Zielflughafen angekommen ist. Sein Flugticket ist genau für einen Flugabschnitt gültig. Will der Passagier beispielsweise von München nach Kenia fliegen, so besitzt er zwei Flugtickets. Eines hat den Startflughafen München und Zielflughafen Amsterdam. Das zweite den Startflughafen Amsterdam und den Zielflughafen Kenia. Logischerweise ist bei solchen Tickets allgemein formuliert der Termin des n-ten Flugtermins vor dem (n-1)-ten. Und der Startflughafen des n-ten Tickets der des (n-1)-ten Tickets.

Ein Flugabschnitt findet ohne Zwischenlandung statt. Er hat eine ID, über welche er eindeutig identifizierbar ist. Er wird von einer bestimmten Fluggesellschaft angeboten. Der Flugabschnitt hat einen Startflughafen und einen Zielflughafen. Er wird zu einem bestimmten Tag und zu einer bestimmten Uhrzeit angeboten. Beispeilsweise Mo-Fr 8.12h München – Berlin.

2.1.2 Sicht der Flughafenverwaltung

Weltweit gibt es eine bestimmte Anzahl von Flughäfen, die mit einem eindeutigen internationalen Kürzel (z.B.: MUC für München) gekennzeichnet sind. Des Weiteren liegen Informationen über den Namen des Flughafens und des Landes und der Stadt, in welchen der Flughafen sich befindet, vor. [i1] (siehe Tabelle 3: Flughäfen) Auf diesem Flughafen gibt es Angestellte, die sich um den Check-In und die Landebahnverwaltung kümmern. Sie werden von der Flughafenverwaltung angestellt, ihrem Einsatzbereich zugewiesen und bezahlt.

Ein Flughafen hat ein oder mehrere Landebahnen, die an bestimmten Zeiten für ein Flugzeug freigegeben werden. Von dort aus startet bzw. dort landet dann das Flugzeug, welches die Erlaubnis hierfür hat.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Flughäfen

Die Flughafenverwaltung hat einen Tower. Dieser vergibt Start- bzw. Landeerlaubnisse für Flugzeuge und teilt ihnen eine zu dem gewünschten Zeitpunkt freie Rollbahn mit. Für jede Rollbahn ist mindestens ein Flugloste zuständig. Auf einer Rollbahn darf innerhalb von fünf Minuten jeweils nur ein Flugzeug landen bzw. starten. So soll sichergestellt werden, dass es zu keiner Kollision kommt. Eine Rollbahn ist durch ein Gate mit dem Flughafengebäude verbunden. So haben die Passagiere Zutritt zu ihrer Abflugrollbahn.

Die Flughafenverwaltung vermietet Ladenflächen auf ihrem Flughafen. Der Mitpreis wird in Landeswährung pro Quadratmeter festgesetzt. Vom Mieter sind Name, Anschrift, Ort und der Name des Ladens bekannt.

2.1.3 Sicht der Fluggesellschaft

Eine Fluggesellschaft hat einen Namen und eine Anschrift Ihres Sitzes. Durch ihren Namen ist sie eindeutig gekennzeichnet. Beispiel siehe Tabelle 4: Fluggesellschaften. Eine Fluggesellschaft hat in einer Stadt ihren Hauptsitz. In einer Stadt darf höchstens eine Fluggesellschaft ihren Sitz haben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Fluggesellschaften

Eine Fluggesellschaft hat Angestellte (Piloten, Flugbegleiter und Wartungspersonal). Diese werden auf Flugabschnitten je nach Qualifikation zu bestimmten Arbeiten eingeteilt.

Der Fluggesellschaft gehört eine Anzahl von Flugzeugen. Ein Flugzeug gehört zu einem Flugzeugtyp. Es hat bestimmte Eigenschaften wie Sitzplatzanzahl in den verschiedenen Klassen, Anzahl der benötigten Flugbegleiter und benötigte Pilotenlizenz. Ein Flugzeugtyp ist beispielsweise Boeing 747, Airbus A330, Tupolew 154). Ein Flugzeugtyp kann je nach Tankfassungsvermögen eine bestimmt Reichweite (Flugkilometer pro Strecke) leisten. Auf allen Flugabschnitten, die kleiner gleich dieser Reichweite sind, darf ein Flugzeug dieses Flugzeugtyps dann eingesetzt werden.

Eine Fluggesellschaft bietet Flugabschnitte an, die gebucht werden können. Die Flugabschnitte werden mit einem Flugzeug geflogen. Ein oder mehrere Piloten und ein oder mehrere Flugbegleiter werden für eine bestimmte Flugstrecke eingesetzt.

Die Fluggesellschaft führt für ihre angebotenen Flüge mit ihren Mitarbeitern den Check-In und die Sicherheitskontrolle am Flughafen durch. Beim Check-In wird überprüft, ob der Name auf dem Personalausweis mit dem auf dem ausgestellten Ticket identisch ist. Außerdem wird das Gepäck der Person in Empfang genommen, wenn es nicht mehr als 25kg an Gewicht hat. Das Gepäck wird dann mit Fahrzeugen auf die Rollbahn gebracht, auf welcher das Flugzeug starten wird und anschließend in das Flugzeug verladen.

Bevor der Passagier das Flugzeug betreten kann, wird die Sicherheitskontrolle durchgeführt. Dabei wird sowohl er selbst, als auch sein Handgepäck auf gefährliche Gegenstände kontrolliert.

Landet das Flugzeug, so wird das Gepäck zum Ausgang gebracht. Dort kann der Passagier es abholen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Flugdurchführung durch Fluggesellschaft

Die Fluggesellschaft selbst ist verantwortlich für die Instandhaltung und Einhaltung der Sicherheitsvorschriften. Deshalb beschäftigt sie Wartungspersonal, die auf bestimmte Flugzeugtypen geschult sind. Über Wartungen, Reparaturen, Fehler und andere flugzeugtechnischen Vorfälle wird für jedes Flugzeug Buch geführt. Ebenfalls wird für die Piloten und Flugbegleiter ein Buch über Arbeitszeit und Einsatzort angelegt.

Kapitel 3

3. Klassifizierung der CASE-Werkzeuge

Moderne Softwareentwicklung ist heute ohne Werkzeugunterstützung nicht mehr denkbar.

Erst der Einsatz von CASE-Umgebungen (Computer Aided Software Engineering) gewährleistet die Einhaltung der Spezifikation und liefert korrekte Systeme. Der Begriff CASE-Umgebung wird in der Literatur unscharf verwendet. Aus diesem Grund haben sich eine Vielzahl von Synonymen (software engineering environment, programming support environment) eingebürgert. Einige Autoren unterscheiden zwischen CASE-Werkzeugen und CASE Plattformen, die zusammen eine CASE-Umgebung bilden (vgl. [22]).

Unter CASE-Werkzeugen versteht Balzert (siehe [5] und [6]) alle Softwarewerkzeuge, die zumindest einzelne Softwareentwicklungstätigkeiten (z.B. Analyse, Entwurf, Implementierung) unterstützen. Im Bereich des Datenbankentwurfs müsste mindestens eine der folgenden Tätigkeiten unterstützt werden:

- Analyse
- Diagramme (ER, EER, UML, …)
- Implementierung ( SQL-Codegenerierung)

CASE-Plattformen stellen Basisdienstleistungen (z.B. Datenverwaltung, Automatisierungsschnittstelle, Kommunikationsdienste) für die Integration von CASE-Werkzeugen zur Verfügung. Eine CASE-Umgebung besteht demnach aus einer CASE-Plattform und mehreren integrierten CASE-Werkzeugen.

Die Entwicklung von CASE-Tools begann in den 80er Jahren. Seitdem sind viele hundert verschieden Werkzeuge (siehe [23]) dieser Art auf dem Markt. In den Anfangsjahren fanden sie aber hauptsächlich im Bereich Softwareentwicklung ihren Einsatz.

Vom Einsatz im Bereich Datenbankentwicklung erhoffte man sich dabei mehr als nur schöner gezeichnete ER-Diagramme. Man wollte darüber hinaus Korrektheitsüberprüfung der Modelle, und die Möglichkeit der automatischen Codegenerierung, wie sie schon bei der Softwareentwicklung gegeben war.

Um CASE-Werkzeuge klassifizieren zu können, muss man sich über die konkreten Anforderungen der Benutzergruppe und über den Einsatzbereich im Klaren sein. Die folgenden Abschnitte sollen CASE-Werkzeuge dahingehend klassifizieren, in wie weit sie für den Einsatz an der technischen Universität München im Datenbankpraktikum eingesetzt werden können und welche Vorteile ihr Einsatz bringt.

Oben genanntes Praktikum wird jedes Semester im Bereich Datenbanksysteme angeboten. Im Sommersemester 2003 geht es um die Modellierung einer „Flughafen“-Datenbank, ähnlich derer, wie sie im Kapitel „2. Fallbeispiel“ vorgestellt wurde.

In den folgenden Abschnitten soll eine Art Kriterienkatalog erstellt werden, in welchem alle Anforderungen, die an die Softwaretools gestellt werden, enthalten sind. Die Tools sollen vor allem in der konzeptuellen Entwurfphase eingesetzt werden und die Arbeit des Datenbankmodellierers unterstützen. In der abschließenden Bewertung wird auf die Eignung der Software im Praktikum eingegangen.

Der Kriterienkatalog ist aufgeteilt in folgende Bereiche:

1. fundamentale Anforderungen
2. erweiterte Anforderungen an die Funktionalität
3. Sonstiges

Der Bereich der Fundamentalen Anforderungen deckt die Thematik Modellierung (Diagrammart und Realisierung der Modellierung) und alle Aspekte der Benutzerfreundlichkeit ab.

Unter erweiterte Anforderungen an die Funktionalität werden Funktionen zusammengefasst, welche nicht unbedingt nötig sind, aber eine hilfreiche Unterstützung für den Datenbankentwickler bieten. Eine automatische Überprüfung des Systems auf Korrektheit zählt ebenso dazu wie die Möglichkeit SQL-Code zu generieren. Dieser kann entweder in einer Textdatei gespeichert oder durch eine direkte Datenbankanbindung in das DBMS eingebunden werden. Auch Import- und Exportfunktionen für Diagramme spielen hier eine Rolle.

Will man sich für den Einsatz eines bestimmten Softwaretools entscheiden, so spielen neben den schon genannten Anforderungen auch die Datenbanksysteme, welche von der Software unterstützt werden, genauso eine Rolle, wie das Betriebssystem, auf dem die Software betrieben werden kann. Eine nicht zu vernachlässigende Rolle spielt vor allem im universitären Bereich auch der Preis. Während Unternehmen beim Einsatz einer Software gerne auch höhere Investitionen tätigen, die unter Umständen eine Produktivitätssteigerung und somit auch Kosteneinsparungen mit sich bringen, ist dies im Umfeld einer Universität nicht der Fall. Deshalb wird oft auf eine kostengünstigere Variante ausgewichen, auch wenn deshalb in der Funktionalität Abstriche gemacht werden müssen.

3.1. Fundamentale Anforderungen

Unter dem Stichwort „fundamentale Anforderungen ist in erster Linie die Funktionalität zu verstehen. Die Software soll korrekt und stabil laufen und die Anforderungen der Entwickler gerecht werden. Dazu zählen die Unterstützung von wenigstens einem Datenmodell, Codegenerierung im Textformat oder durch direkte Datenanbindung und Korrektheitsüberprüfung. Die Fähigkeiten, referentielle Integritätsbedingungen umzusetzen ist unbedingt erforderlich.

Ein anderer Aspekt der fundamentalen Anforderungen ist der Bedienungskomfort, welcher die Übersichtlichkeit und Verständlichkeit der Anwendungsoberfläche ebenso beinhaltet wie eine umfassende Hilfefunktion.

3.1.1 Diagramme

Jedes der Softwaretools soll mindestens ein Modellierungsmodell unterstützen. Entweder ER-Diagramm oder das UML-Klassendiagramm. Wert gelegt wird auf eine korrekte Umsetzung der Diagramme mit Einhaltung der Notationskonventionen.

Zu den Anforderungen zählen auch, dass Schlüssel, Fremdschlüssel und zusammengesetzte Schlüssel umgesetzt werden können. Die Möglichkeit, Modellierungskonzepte wie Generalisierung, Klassifikation und Aggregation umzusetzen, soll von den Softwaretools auf jeden Fall unterstützt werden. Ein weiterer Gesichtspunkt ist die Modellierung von Check-Bedingungen. Dies sind einfache Überprüfungen, die z.B. den Wertebereich eines Attributs überprüfen.

Es soll die Möglichkeit bestehen, entwickelte Diagramme zu drucken und / oder zu exportieren. Bei der Exportfunktion wäre neben diversen Bild-Dateitypen auch der Export nach XML denkbar.

3.1.2. Funktionen

In den folgenden Abschnitten soll die Funktionalität betrachtet werden, welche sich Benutzern von den Softwaretools erwarten. Darunter sind Validierungsfunktionen, Datenbankanbindung, Forward- und Reverseengineering so wie Import und Export von verschiedenen Dateitypen.

3.1.2.1.Korrektheit

Korrektheit kann auf zwei Wegen erreicht werden. Der erste Weg ist das Abfangen von Fehlern bei der Eingabe. Dies kann durch automatisches Eintragen bestimmter Optionen (Bsp.: Kennzeichnen eines Attributes als „mandatory“ wenn der User es als Primärschlüssel auswählt). Die zweite Möglichkeit ist, eine Überprüfung aller Eingaben des Benutzers. Solle eine Eingabe fehlerhaft oder zweideutig sein, soll eine Fehlermeldung oder eine Anmerkung ausgegeben werden. Die Überprüfung der Korrektheit kann entweder gleichzeitig mit der Eingabe des Benutzers erfolgen, oder durch einen vom Benutzer ausgelösten Funktionsaufruf. Beide Möglichkeiten sind vorstellbar.

Sind nach Überprüfung ein oder mehrere Fehler oder Warnungen aufgetreten, soll die Software ein einfaches und schnelles Nachbearbeiten des Modells bzw. des Codes ermöglichen.

3.1.2.2. Datenbankanbindung

Um von einer Software auf eine Datenbank zugreifen zu können, wird eine Schnittstelle benötigt, die den Zugriff ermöglicht. Dies kann eine ODBC-Schnittstelle sein, oder durch ADO realisiert werden.

ODBC

Of ist diese Schnittstelle über ODBC (open database connectivity) realisiert. Dies ist eine von Microsoft definierte Programmierschnittstelle für den Zugriff von Programmen auf Datenbanken mittels SQL. Abbildung 18: ODBC-Architektur zeigt die Architektur einer ODBC-Schnittstelle.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: ODBC-Architektur

Bei der Anwendung handelt es sich beispielsweise um ein CASE-Tool. Dieses Tool schickt über ODBC-Aufrufe SQL-Anweisungen an die Datenbank. Der Treiber-Manager lädt den entsprechenden Datenbanktreiber. Im dargestellten Beispiel ist der Treiber 1 für die Datenquelle 1 zuständig. Die anderen Treiber sind den Datenquellen entsprechend zugeordnet. Der Datenbanktreiber übernimmt folgende Aufgabe: Er verarbeitet die ODBC-Aufrufe, schickt die SQL-Anweisungen im entsprechenden Datenbankdialekt an die Datenbank und liefert die Ergebnisse der Anfrage an die Anwendung zurück. Eine Datenquelle entspricht hier einer Datenbank.

Um die Inoperabilität zu gewährleisten, definiert ODBC zwei Konformitätsstufen: eine für Funktionsaufrufe (API-Konformität) und eine für die SQL-Ebene. Jeder Konformitätstyp hat drei Stufen.

Die Grundmenge der ODBC-Funktionen umfasst:

- Aufbau einer Verbindung zur Datenbank
- Vorbereiten und Ausführen von SQL-Anweisungen
- direktes Ausführen von SQL-Anweisungen
- Verwalten von Transaktionen (commit, rollback)

Weitere Funktionen werden dann in Level 1 API bzw. Level 2 API eingeteilt.

Darunter sind beispielsweise Funktionen wie:

- Aufbau einer Verbindung mit treiberspezifischen Dialogboxen
- Schrittweises Senden von Parameterwerten (für lange Daten)
- Schrittweises Empfangen von Ergebnissen
- Cursor zum datensatzweisen Auslesen der Ergebnismenge
- Abfragen der datenbankspezifischen Form der SQL-Anweisung

Für die Klasse der unterschiedlichen ODBC-Treiber wurde eine Standard-SQL-Grammatik entwickelt. Diese basiert auf der X/Open SQL CAE Spezifikation. Die spezifizierte Standardgrammatik ist in eine Grund-Grammatik aufgeteilt, welche von allen OCBC-Treibern unterstützt wird. Es gibt jedoch Konzepte, die nur von einer Teilmenge der vorhandenen Treiber umgesetzt wird. Verwendet eine Anfrage ein Element der ODBC-Grammatik, welche vom DBMS nicht unterstützt wird, konvertiert der Treiber das Statement und sendet es erst anschließend an die Datenbank. Diese Fälle treten aber selten auf, da die meisten Datenbankmanagementsysteme bereits die Standard-SQL-Grammatik verwenden.

[...]

---

^[1] Ein Index zu einer Datei ist eine Hilfsstruktur, um Operationen zu beschleunigen, die aufgrund der Organisationsform der Datei nicht effizient ausgeführt werden können.

^[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 )

^[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

^[6] http://www3.informatik.tu-muenchen.de/lehre/WS2001/HSEM-bayer/Ausarbeitung_codd.pdf