An dieser Stelle bedanke ich mich bei den Menschen, die mich bei der Erstellung der vorliegenden Arbeit in vielfältiger Weise unterstützt haben: Bei Herrn Florian Stich von der Firma SYBASE. Er stellte mir im Namen seiner Firma eine Softwarelizenz des Programms Sybase PowerDesigner innovative (Version 9.5.) zur Verfügung und stand mir mit Rat und Tat zur Seite. Ebenfalls möchte ich mich bei der Firma Resolution Ltd. für die Lizenz der Software xCase bedanken. Ein Dankeschön geht auch an die Firma CHARONWARE, welche mir eine Lizenz der Software CaseStudio 2 2 angeboten hat und an Herrn Fux, der mich während der Testphase bei auftretenden Problemen unterstützt hat.

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

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

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

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

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ä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 ¹ 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.

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

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.

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

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:

1. Einführung in den Datenbankentwurf 15

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

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 physikalische 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 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 ² 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.

² 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 zusammengesetzt sein und ist stets eine minimale identifizierende Attributkombination. Jede echte Obermenge 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)

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.

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 aufzubauen. 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 ⁿ auch ein Objekt der Klasse E ist. Betrachten wir folgendes Beispiel:

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 Deu- tung zu (siehe Tabelle 1: Notation von Kardinalitäten).

1. Einführung in den Datenbankentwurf 20

Notationsarten

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

³ IE-Notation: Bezeichnung der Notation bei logischer Modellierung- DM-Notation bei physischer

⁴ manchmal auf Krähenfussnotation genannt

⁵ 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 Dokumentation von Softwaresystemen 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).

1. Einführung in den Datenbankentwurf 22

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)

1. Einführung in den Datenbankentwurf 23

Eine Flugstrecke <> mit einem bestimmten Flugzeugtyp. Ebenso <> 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)

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

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.

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:

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

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

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

⁶ http://www3.informatik.tu-muenchen.de/lehre/WS2001/HSEM-bayer/Ausarbeitung_codd.pdf