1. Einleitung - Institut für Parallele und Verteilte Systeme

Einleitung: Zweck des Dokuments
1.
1
Einleitung
Heutzutage benutzen viele Anwendungen Datenbanken. Immer, wenn irgendwo Daten erfaßt und
gespeichert werden sollen, werden Datenbanken eingesetzt. Durch effiziente Datenbanksystemehat man einen leichten und schnellen Zugriff auf die gewünschten Daten.
Eine gutes Konzept erhöht die Effizienz der Datenbank. Daher ist die Modellierung der Datenbank und des Schemas sehr wichtig. Es macht deswegen Sinn, für diese Modellierung ein
geeignetes Tool einzusetzen.
Das hat die Abteilung Anwendersoftware des IPVR der Fakultät Informatik der Universität Stuttgart richtig erkannt. Um ein geeignetes Tool für alle Mitarbeiter zu finden, fehlte es ihnen allerdings an Personal. Doch da die Studenten im Rahmen des Studiums praxisorientierte Arbeiten
durchführen müssen, kam die Abteilung auf die Idee, die Auswahl eines geeigneten Tools im
Rahmen einer Fachstudie von Studenten durchführen zulassen. Diese Fachstudie wurde ausgeschrieben und im Sommersemester 2001 von Christian Scheibel, Ralf Terdic und Michael Wenig
durchgeführt und durch Kerstin Schneider betreut.
1.1
Zweck des Dokuments
Dieses Dokument wurde im Rahmen einer Fachstudie erstellt. Dieses Dokument ist eine Entscheidungshilfe bei der Auswahl eines Datenbankmodellierungstools für die Abteilung Anwendersoftware des IPVR der Fakultät Informatik der Universität Stuttgart. Es gibt einen Überblick
über zur Debatte stehende Tools, zeigt deren Stärken und Schwächen und gibt schliesslich eine
Empfehlung welche(s) Tool(s) in Frage kommen.
1.2
Überblick über den weiteren Inhalt
Im Kapitel 2 wird ein Überblick über das gesamte Projekt gegeben. Es werden die Zeitplanung
und die Vorgehensweise vorgestellt. In Kapitel 3 werden die Grundlagen der Datenbankmodellierung kurz erläutert und einzelne Aspekte näher betrachtet. Das Kapitel 4 stellt die Anforderungen an die Tools dar, die aus einer Befragung der Mitarbeiter des Instituts hervorgegangen sind.
Die Fragen, die bei dieser Befragung gestellt wurden, kann man im Anhang A nachlesen. Die
Antworten der Mitarbeiter wurden bewertet und anhand dieser wurden dann die Tools getestet.
Welche Tools dabei berücksichtigt wurden sowie einige Infos dazu, kann man im Kapitel 5 nachlesen und wie sie bei dem Test abgeschnitten haben, steht in Kapitel 6. Die Ergebnisse werden in
Kapitel 7 noch einmal zusammengefasst und die Empfehung findet sich dann in Kapitel 8.
IPVR, Universität Stuttgart
1. October 2002
Fachstudie
2
2.
Projektüberblick: Aufgabenstellung
Projektüberblick
Dieses Kapitel dokumentiert die Anforderungen und das Vorgehen bei der Auswahl eines DBMTools. Zunächst wird die ursprüngliche Aufgabenstellung präsentiert. Anschließend wird auf
Aspekte bei der Vorgehensweise und der Zeitplanung eingegangen
2.1
Aufgabenstellung
2.2
Vorgehensweise
Zu Beginn eines jeden Projektes muss zunächst die Vorgehensweise festgelegt werden.
Die Auswahl eines Datenbank-Modellierungs-Tool gliedert sich grob in drei Phasen:
• Analysephase
• Testphase
• Entscheidungsphase.
2.2.1
Analysephase
Da das Tool von praktisch allen Mitarbeitern der Abteilung eingesetzt werden soll, gleichzeitig
aber auch zu erwarten ist, dass höchst unterschiedliche Einsatzbereiche vorhanden sind, müssen
die Anforderungen jedes einzelnen Mitarbeiters ermittelt werden
Zu diesem Zweck wird ein Fragebogen erstellt, welcher dann im Rahmen von Interviews mit den
späteren Anwendern zusammen ausgefüllt wird. Die Interviews werden jeweils vom gesamtem
Projektteam durchgeführt, so dass Anforderungen und Einschätzungen, welche nicht im Fragebogen dokumentiert werden können, allen Projektmitgliedern bekannt sind.
Die Fragebögen werden anschließend ausgewertet und ein Kriterienkatalog erstellt. Das genaue
Verfahren für die Auswertung der Fragebögen wird erst nach den Interviews festgelegt..
Der Kriterienkatalog wird im Rahmen einer Präsentation vor den Mitarbeitern der Abteilung
vorgestellt. Dies bietet eine einfache Möglichkeit, die ermittelten Kriterien nochmals zu validieren und eventuell noch vorhandene Missverständnisse aufzudecken.
Anschließend wird die Dokumentation der betroffenen Kapitel fertiggestellt und parallel dazu die
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
Projektüberblick: Zeitplanung
3
in Frage kommenden Tools ermittelt.
2.2.2
Testphase
Basierend auf dem Kriterienkatalog wird eine Analyse-Vorlage erstellt, welche für jedes einzelne
Tool entsprechend bearbeitet wird.
Dadurch soll ein Vergleich der, vermutlich sehr unterschiedlichen, Tools ermöglicht werden.
Die Analyse der einzelnen Tools wird auf die Projektmitglieder aufgeteilt. Dies birgt den Nachteil, dass unterschiedliche subjektive Einschätzungen auftreten können. Um deren Auswirkungen
zu minimieren, wird jedes analysierte Tool jeweils den beiden anderen Projektmitgliedern vorgestellt, so dass die Bewertung jeweils nicht auf eine einzelne Person beschränkt ist.
2.2.3
Entscheidungsphase
Die Ergebnisse der einzelnen Toolanalysen werden nun auf eine geeignete Weise verglichen und
daraus eine Empfehlung abgeleitet. Dabei werden insbesondere die Schwachstellen des Tools
erneut untersucht, um einer falschen Empfehlung vorzubeugen.
Die Dokumentation wird vervollständigt und in ein Gesamtdokument überführt.
Das Projekt endet schließlich mit einer Präsentation der Ergebnisse vor den Mitarbeitern der
Abteilung.
2.3
Zeitplanung
Für die Zeitplanung wurden die durchzuführenden Arbeitspakete inklusive ihrer Abhängigkeiten
identifiziert und deren Zeitbedarf geschätzt.
Die folgende Tabelle zeigt diese Ergebnisse auf. Bei Planungen, welche später modifiziert wurden, ist der ursprüngliche Wert in Klammern angegeben.
IPVR, Universität Stuttgart
1. October 2002
Fachstudie
4
Projektüberblick: Zeitplanung
Arbeitspaket
Dauer
Kurzbeschreibung
abhängig
von
Start
A1
1 Tag
Meeting mit Betreuer
8.5.2001
A2
1 Woche
Erstellen Fragebogen
9.5.2001
A3
1 Woche
Ermittlung Interviewpartner
9.5.2001
A4
1 Woche
Durchführung
views
A5
3 Wochen
Auswertung
Fragebögen
A6
3 Wochen
Ermittlung der Tools
und Lizenzbedingungen
A7
3 Wochen
Anfordern von Tools
A6
28.5.2001
A8
3 Wochen
Erstellen einer Toolanalyse-ErgebnisVorlage
A9
28.5.2001
A9
6 Wochen
Erstellen Kriterienkatalog
A5
9.5.2001
D1
5 Wochen
Vorauswahl Tools
A9
25.6.2001
Interder
A2, A3
21.5.2001
A4
28.5.2001
28.5.2001
(18.6.2001)
D2
5 Wochen
Testen Tools
D1
(parallel)
25.6.2001
(18.6.2001)
D3
1 Woche
Auswertung der Testergebnisse
D2
23.7.2001
D4
1 Woche
Abschlussdokumentation
D5
30.7.2001
D5
12 Wochen
parallele Dokumentation
D6
9.5.2001
D6
2 Wochen
Erstellen einer Dokumentstruktur
P1
1 Tag
Präsentation Analyseergebnisse
Fachstudie
1. October 2002
9.5.2001
A9
IPVR, Universität Stuttgart
Projektüberblick: Zeitplanung
Arbeitspaket
P2
2.3.4
5
Dauer
Kurzbeschreibung
1 Tag
Abschlusspräsentation
abhängig
von
Start
D4
Anmerkungen zur Zeitplanung
Die zeitliche Planung eines Projektes ist praktisch immer Modifikationen unterworfen. Diese
haben verschiedene Ursachen. Insbesondere in einem universtären, studentischem Projekt sind
Zeitplanungen höchst instabil, da bei Studenten im Gegensatz zu Mitarbeitern einer Firma keine
planbaren Zeitabschnitte existieren. Viele projektfremde Einflüsse müssen berücksichtigt werden,
teilweise ohne dass diese Vorhergesehen oder eingeschätzt werden können. Beispiele hierfür sind
Prüfungen, Vorträge in Seminaren und Studienprojekte.
2.3.4.1 Gründe für Verzögerungen
Dieser Abschnitt erläutert die im Rahmen dieser Fachstudie eingetretenen Ursachen für die vorgenommenen Modifikationen des Terminplanes:
1. Es hat sich herausgestellt, dass der Zeitbedarf für die Analysephase zu kurz gewählt wurde.
Dies ist weniger in einer Unterschätzung des Aufwandes begründet, sondern wurde durch
fachstudenfremde Aufgaben, wie beispielsweise ein Studienprojekt in einer kritischen Phase,
verursacht.
2. Die Präsentation der Analyseergebnisse musste aufgrund von Terminschwierigkeiten in der
Abteilung verschoben werden, so dass eine Validierung der herausgearbeiteten Anforderungen
nicht zum geplanten Zeitpunkt erfolgen konnte.
IPVR, Universität Stuttgart
1. October 2002
Fachstudie
6
3.
Grundlagen der Datenbankmodellierung: Phasen des Datenbankentwurfs
Grundlagen der Datenbankmodellierung
Dieses Kapitel versucht, einen Einblick in die Grundlagen der Datenbankmodellierung zu
gewähren, wobei auf die einzelnen Phasen der Modellierung eingegangen wird. Dabei werden
auch die Notationen beschrieben, die bei der Modellierung häufig verwendet werden.
3.1
Phasen des Datenbankentwurfs
Der Datenbankentwurf besteht grundsätzlich aus vier Phasen: Anforderungsanalyse, konzeptioneller, logischer und physischer Entwurf.
In der Anforderungsanalyse werden zunächst die Anforderungen der Nutzer der zu entwerfenden Datenbank ermittelt. Beispielsweise werden Informationen darüber gesammelt, welche
Daten erfaßt werden müssen, welche Datenquellen vorhanden sind usw. Die Ergebnisse der
Anforderungsanalyse werden i.d.R. in einem Anforderungsdokument (User Requirements Document) schriftlich festgelegt. Dieses Dokument muß von den Nutzern abgenommen werden und
bildet dann die Grundlage für den folgenden Entwurf.
Als nächstes werden die drei Modellierungsphasen beschrieben, die auf die Anforderungsanalyse
folgen.
3.2
Konzeptionelle Modellierung
In der konzeptionellen Modellierungsphase wird der Ausschnitt der realen Welt, der in der Datenbank gespeichert werden soll - genannt auch Miniwelt - mit Hilfe eines Datenmodells dargestellt.
Ergebnis ist das konzeptionelle Schema, das unabhängig vom später eingesetzten Datenbanksystem ist.
Als Modell für die Darstellung des konzeptionellen Schemas haben sich das Entity-RelationshipModell (ERM) und die Unified Modeling Language (UML) durchgesetzt. Diese werden im folgenden ansatzmäßig beschrieben.
3.2.1
ERM
Das Entity-Relationship-Modell ist das populärste Modell, das im konzeptionellen Entwurf verwendet wird. Zur Veranschaulichung verwendet es Entity-Relationship-Diagramme. Die zentralen Begriffe des ERM sind Entität und Relation.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
7
Grundlagen der Datenbankmodellierung: Konzeptionelle Modellierung
Eine Entität ist eine Informationseinheit, die mehrere atomare Attribute besitzen kann. Die
Zusammenfassung dieser Attribute zu einer Entität ist die einzige Möglichkeit der Typenbildung,
die das ERM unterstützt.
Beziehungen zwischen Entitäten werden durch Relationen dargestellt. Je nach verwendeter
Darstellung der Kardinalitäten, -Restriktionen, Verbindungslinien und -pfeile etc. unterscheidet
man verschiedene ERM-Notationen:
o
Notation IDEF1X
o
Notation Bachmann
o
Notation Information Engineering
o
Notation UML
Der Erfolg des ER-Modells läßt sich dadurch erklären, daß sich ER-Diagramme durch relativ einfache Algorithmen in relationale Schemata überführen lassen - die Entitäten und Relationen lassen sich leicht auf Tabellen abbilden. Häufig ist bei gut durchdachten ER-Diagrammen eine
Normalisierung nicht mehr notwendig. Dadurch sind ER-Diagramme ideal für die Dokumentation relationaler Datenbank-Schemata.
3.2.2
UML
Für den konzeptionellen Entwurf von objektorientierten Systemen hat sich die UML (Unified
Modeling Language) etabliert. Diese Sprache stellt eine Reihe von unterschiedlichen Diagrammen für das Modellieren von Struktur und Verhalten der Objekte bereit.
Die Klassen-Diagramme sind sowohl für das Modellieren der Struktur der objektorientierten Programme als auch für Datenbanken geeignet. Besonders ausdruckkräftig ist das Modellieren von
Objektbeziehungen in UML.
Der Vorteil gegenüber dem Entity-Relationship-Modell ist die Tatsache, daß UML Konzepte wie
o
Generalisierung / Spezialisierung
o
Assoziation
o
Aggregation
o
Realisierung
o
Vererbung
unterstützt. Diese ermöglichen die Modellierung von komplexen objektorientierten Systemen.
Der Nachteil der Nutzung solcher Konzepte ist, daß diese in rein relationale Schemata schwierig
(teilweise unmöglich) zu überführen sind. Hierzu müssen die Schemata um die notwendigen
objektorientierten Elemente erweitert werden (objektrelationale Schemata). Existiert keine derartige Erweiterung, so wird i.d.R. das Klassendiagramm als Anforderungsspezifikation verwendet,
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
8
Grundlagen der Datenbankmodellierung: Logische Modellierung
um daraus ER-Diagramme zu erzeugen.
3.3
Logische Modellierung
In der logischen Modellierungsphase erfolgt eine Umsetzung des in der vorherigen Phase
erzeugten Datenmodells - des konzeptionellen Schemas - in das zu verwendende Datenbankschema. Das logische Modell ist zwar (idealerweise) unabhängig von der später eingesetzten
Datenbank, man muß aber bereits entschieden haben, was für ein Datenmodell man benutzt (hierarchisches, Netzwerk-, relationales, objektorientiertes, objektrelationales Datenmodell).
Meist wird hierbei das relationale Modell benutzt. In diesem Fall werden hier die entsprechenden
Relationentabellen generiert. Diese Tabellen müssen nun auf Einhaltung der Normalformen überprüft werden. Normalformen dienen der Vermeidung von Anomalien und Redundanzen, die zu
Inkonsistenzen im Datenbankinhalt führen können. Relationentabellen, die nicht den Normalformen genügen, müssen entsprechend umgeformt werden.
Diese Phase liefert als Ergebnis das logische Schema.
3.4
Physische Modellierung
Die physische Modellierung ist die Entwurfsphase, die am stärksten abhängig vom gewählten
Datenbanksystem ist. Sie ist verantwortlich für die Umsetzung des logischen Schemas in das physische Modell. Hierfür werden die Sprachen des jeweiligen Datenbanksystems verwendet: die
data definition language (DDL) zur Definition von Tabellen, Sichten und zur Implementierung
von referenzieller Integrität, und evtl. die data manipulation language (DML) zur Implementierung von Triggern und stored procedures. Ergebnis dieser Phase ist das physische DatenbankSchema.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
9
Anforderungen an die Tools: Fragenkatalog
4.
Anforderungen an die Tools
4.1
Fragenkatalog
Für die Ermittlung der Anforderungen im Rahmen von Interviews wurde ein Fragebogen erstellt.
Dieser ist im Anhang vollständig abgedruckt. Da sich dieser Fragebogen an fachkundige Mitarbeiter wendet, werden hier nicht alle einzelnen Punkte erläutert. Stattdessen sollen in diesem Kapitel
ausgewählte Punkte erläutert werden, welche in den Interviews zu Missverständnissen geführt
haben.
4.1.1
Arbeitsweise (Punkt 4)
Die tastatur-orientierte Bearbeitung verwendet Shortcuts und Tabulator-Reihenfolgen durch die
häufig wiederkehrende Funktionen ohne Verwendung einer Maus durchgeführt werden können.
Diese resultieren in identischen Modifikationen der graphischen Modelle, wie sie durch eine
Point-and-Click-Bearbeitung vorgenommen werden könnten.
4.1.2
manuelle DDL-Nachbearbeitung (Punkt 17)
Die manuelle DDL-Nachbearbeitung ist nur dann von Belang, wenn eine direkte Anbindung der
Datenbank an das Modellierungstool erfolgt. Ist diese Anbindung nicht vorhanden, so muss ohnehin die DDL über die Zwischenablage oder über Textdateien zur Datenbank transferiert werden,
wobei eine Nachbearbeitung ausserhalb des Tools möglich ist.
4.2
Ergebnisse der Befragung
Dieser Fragebogen wurde mit 9 Mitarbeitern der Abteilung Anwendersoftware durchgesprochen
und entsprechend ausgefüllt.
Die Antworten wurden in einer Excel-Tabelle zusammengefasst und durch Mittelwertbildung
entsprechend korreliert. Die Ergebnisse sind in der folgenden Tabelle zusammengestellt. Fragen,
welche durchgängig mit “unwichtig” beantwortet wurden, sind aus Übersichtsgründen weggelassen. Ergebnisse in Klammern bedeuten “nice-to-have”. Die Spalte “durchschnittliche Bewertung”
gibt jeweils das Interview-Ergebnis an. Die Ergebnisse lassen sich in zwei Kategorien einteilen:
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
10
Anforderungen an die Tools: Ergebnisse der Befragung
• Bewertungsfragen:
Hier wird das arithmetische Mittel aller Einstufungen (von 0-9) angegeben. Diese Angaben
sind auf eine Nachkommastelle mathematisch gerundet angegeben
• Ja/Nein-Fragen:
Hier ist die Summe der positiven Antworten (Kreuzchen) angegeben. Diese Angaben sind am
Fehlen von Nachkommastellen erkennbar.
Bereich
Teil
durchschn.
Bewertung
Arbeitsplatz
PC
9
Workstation
3
Englisch
7
Deutsch
(2)
Tastatur-orientiert
5,9
9,0
Point-and-Click
7,3
9,0
Skripting
3,9
8,0
Unix/Linux
7,8
9,0
Windows
8,1
9,0
fester Rechner
5
unterschiedliche Rechner
4
wissenschaftlich
8
kommerziell
0
Open-Source
1
Vorlesung
0
Übung
2
Praktika
7
Projekte
4
Studien-/Diplomarbeit
3
Forschung
1
DB/2
8,0
9,0
Oracle
2,1
9,0
Informix
1,4
7,0
Postgres
1,0
9,0
Sprachen
Arbeitsweise
Plattformen
Arbeit am Rechner
Nutzungsarten
Einsatzbereiche
verwendete DBMS
Fachstudie
1. October 2002
max.
Bewertung
IPVR, Universität Stuttgart
11
Anforderungen an die Tools: Ergebnisse der Befragung
Bereich
Teil
durchschn.
Bewertung
max.
Bewertung
Access
1,7
7,0
SQL-Server
2,6
9,0
mySQL
1,3
7,0
ODBC allgemein
2,6
9,0
Entitäten (Min/Avg/Max)
9,3 / 28,9 /
47,8
200
Relationen (Min/Avg/Max)
8,9 / 28,3 /
44,4
200
ERM allgemein
6,2
9,0
ERM Notation UML
4,8
9,0
UML-Klassendiagramm
6,6
9,0
1:1, n:1, 1:m
6,9
9,0
n:m
6,9
9,0
automatische Umsetzung
7,1
9,0
Kontrolle der Automatik
6,7
9,0
logische Sichten
Unterstützung
6,7
9,0
Konstrukte
Trigger
6,4
9,0
Schemata
5,8
9,0
Domänen
4,4
9,0
Stored Procedures
4,6
9,0
Benutzerrechte
4,3
9,0
constraints (ohne RI)
6,3
9,0
referentielle Integrität (RI)
6,7
9,0
Trennung
logisch-physisch
7,7
9,0
Aspekte bei Trennung
automatische Umsetzung
7,8
9,0
mehrere physische Sichten
5,7
9,0
Reverse-Engineering
5,1
8,0
Synchronisation
7,1
9,0
manuelle Nachbearbeitung
6,3
9,0
Mengengerüste
Modellunterstützung
attributierte
gen
DDL
Fachstudie
Beziehun-
1. October 2002
IPVR, Universität Stuttgart
12
Anforderungen an die Tools: Ergebnisse der Befragung
Bereich
Teil
durchschn.
Bewertung
max.
Bewertung
Validierungsfunktionen
3NF
6,0
9,0
BCNF
3,3
7,0
Undo-Funktion
Existenz
8,3
9,0
parallele Bearbeitung
ja / nein
6/3
Versionsverwaltung
Integrationsmöglichkeit
4,3
8,0
CVS
2,7
8,0
PVCS
0,3
3,0
ClearCase
0,6
5,0
VisualSourceSafe
0,1
1,0
SCC
0,2
2,0
XML
6,2
9,0
DDL, SQL-Standard
6,4
9,0
DDL, DBMS-spezifisch
2,4
8,0
3,3
9,0
XMI
3,9
9,0
MDL
2,6
8,0
ERX
0,0
0,0
existierende DB
3,4
9,0
XML
6,7
9,0
DDL, SQL-Standard
7,0
9,0
DDL, DBMS-spezifisch
4,6
9,0
2,9
9,0
XMI
2,9
9,0
MDL
2,8
8,0
ERX
0,0
0,0
direkte DB-Änderung
4,0
9,0
HTML
7,8
9,0
Importmöglichkeiten
UML-Klassendiagramm,
spez.
Export
UML-Klassendiagramm,
spez.
Dokumentation
Fachstudie
1. October 2002
tool-
tool-
IPVR, Universität Stuttgart
13
Bereich
Anforderungen an die Tools: Ergebnisse der Befragung
Teil
durchschn.
Bewertung
max.
Bewertung
RTF
1,8
7,0
PDF
5,6
9,0
PS
3,7
9,0
PPT
3,8
8,0
GIF
2,8
8,0
JPEG
1,0
4,0
WMF
1,8
9,0
Vektorgrafik (z.B. EPS)
1,8
9,0
Java
8,9
9,0
C++
4,9
9,0
Zugriffsschichten
automatische Generierung
5,8
9,0
Tools
Erfahrungen
Access,
Rose,
Together,
SQL-Server
Testanforderung
Visio, Rose,
PowerDesigner,
Erwin,
Together
Programmiersprachen
Bei den Mittelwerten ist zu beachten, dass diese nicht immer die realen Anforderungen wiederspiegeln. In den Gesprächen wurden Einstufungen erkennbar, welche sich nicht alleine durch
Wichtigkeits-Noten ausdrücken lassen. Andererseits können auch nicht die Maximalwerte direkt
verwendet werden, da sonst die Anforderungen von sehr anspruchsvollen Interviewpartnern
dominieren und somit eine vernünftige Auswahl nicht ermöglichen würden.
Aus diesen Gründen darf folgende Abbildung von mittleren Einstufungen auf Kategorien nur als
grobe Richtung verstanden werden.
Fachstudie
von
bis
Kategorie
6,5
9,0
zwingend erforderlich
4,1
6,4
sollte möglich sein
2,1
4,0
nice-to-have / nützlich
1. October 2002
IPVR, Universität Stuttgart
14
Anforderungen an die Tools: Kriterienkatalog
von
bis
Kategorie
0,0
2,0
unwichtig
In Einzelfällen weichen die Interview-Ergebnisse stark voneinander ab. Diesem Sachverhalt wird
durch die Einstufung in andere Kategorien, als durch die o.g. Tabelle vorgegebenen, Rechnung
getragen. Diese Einstufungen erfolgen gemäß den im Gespräch ermittelten Anforderungen.
Die Anforderungen eines Interviewpartners zielen auf ein anderes Einsatzgebiet ab. Dieser
benötigt ein Tool zur Modellierung und Konfiguration von Repositories. Da alle anderen Partner
das Tool zur Modellierung von einzelnen Datenbanken einsetzen wollen, wird dieses Einsatzgebiet im Vordgrund stehen. Für die Verwaltung von Repositories wird wahrscheinlich eine eigene
Tool-Auswahl erforderlich werden.
4.3
Kriterienkatalog
Dieser Kriterienkatalog ist zusammen mit den oben genannten Einstufungen die Grundlage für
die Auswahl und Bewertung der in Frage kommenden Tools. Er spiegelt grob die Anforderungen
an ein entsprechendes Tool wieder.
Da die verfügbaren Tools sehr unterschiedlichen Funktionsumfang haben und teilweise nicht
direkt vergleichbar sind, müssen für die endgültige Bewertung die Einzelergebnisse der Interviews mit berücksichtigt werden.
4.3.3
Plattform und Umgebung
Das Tool soll sowohl unter Unix als auch unter Windows auf PCs und Workstations eingesetzt
werden. Da das Einsatzgebiet Projekte und Praktika umfasst, werden beide Plattformen parallel
eingesetzt. Das Tool muss also entweder plattformunabhängig sein, oder für beide Plattformen
mit gemeinsamen Datenformaten verfügbar sein.
Die englische, eventuell zusätzlich auch in Deutsch verfügbare graphische Benutzeroberfläche
unterstützt eine Point-and-Click-Arbeitsweise. Für oft benötigte Funktionen, wie beispielsweise
die Anlage von Attributen ist eine tastatur-orientierte Arbeitsweise möglich, beispielsweise über
Shortcuts. Zur Abrundung wäre eine Skripting-basierte Steuerung schön.
Die Oberfläche besitzt eine, idealerweise mehrstufige, Undo-Funktion.
Da das Tool auch in Praktika und Übungsgruppen eingesetzt werden soll, soll die Oberfläche intu-
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
15
Anforderungen an die Tools: Kriterienkatalog
itiv bedienbar sein und keine größeren Schulungsmassnahmen erfordern.
4.3.4
Nutzung
Die Nutzung ist ausschliesslich rein wissenschaftlich. Eine kommerzielle Nutzung erfolgt nicht,
jedoch soll das Tool ebenso für Open-Source-Projekte eingesetzt werden.
Wichtigstes Einsatzgebiet sind Praktika. Weiterhin soll das Tool für Projekte, Diplom- und Studienarbeiten, sowie in Übungsgruppen eingesetzt werden,
Für die Arbeiten der Mitarbeiter wird das Tool immer auf denselben Rechnern eingesetzt. Bei studentischen Arbeiten werden viele verschiedene Rechner eingesetzt.
Meist erfolgt eine parallele Bearbeitung der Modelle. Daher müssen entsprechende Synchronisations und Sperr-Funktionalitäten vorhanden sein. Eine Versionsverwaltung sollte an das Tool
angebunden werden können, meist soll hier CVS eingesetzt werden.
4.3.5
verwendete DBMS
Eine Unterstützung von DB/2 ist zwingend erforderlich.
In einzelnen Fällen wird Oracle, Postgres, SQL-Server, Informix und Access eingesetzt. Diese
sollten daher ebenso unterstützt werden.
4.3.6
Mengengerüste und Modellierungssprachen
Im Schnitt werden ca. 30 Entitäten und 30 Relationen in einer Datenbank verwendet. Jedoch sind
Maximalwerte bis jeweils 200 durchaus denkbar. Als Modellierungssprache werden hauptsächlich ERM- und UML-Klassendiagramme eingesetzt. Dabei ist bei den ERM-Diagrammen die
spezielle Notation nicht wichtig.
4.3.7
attributierte Beziehungen
In den Modellen müssen attributierte Beziehungen in allen Ausprägungen dargestellt werden können. Es muss die Möglichkeit bestehen, aus diesen automatisch entsprechende Entitäten zu erzeugen, wobei der Anwender eine Kontrolle, z.B. in Bezug auf Tabellennamen, besitzen soll.
4.3.8
logische Sichten
Das Tool unterstützt den Einsatz logischer Sichten. Diese können von den physischen Sichten
getrennt modelliert werden. Aus den logischen Sichten können automatisch passende physische
Sichten erzeugt werden. Es sollte dabei die Möglichkeit existieren, mehrere physische Sichten,
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
16
Anforderungen an die Tools: Kriterienkatalog
z.B. für verschiedene DBMS-Systeme zu definieren.
Eine spätere Synchronisation zwischen den Sichten ist bei Änderungen sowohl der physischen als
auch der logischen Sicht möglich.
Vorteilhaft wäre die Möglichkeit des Reverse-Engineerings, das bedeutet die Erstellung einer
logischen Sicht basierend auf einer physischen Sicht wird durch das Tool unterstützt.
4.3.9
erweiterte Funktionaliäten
Eine Unterstützung der referentiellen Integrität ist obligatorisch.
Idealerweise können ebenso Trigger, weitere constraints, Schemata, Stored-Procedures, Domänen
und Benutzerrechte über das Tool verwaltet werden.
Als Programmiersprache für Stored-Procedures, sowie Anwendungsprogramme wird Java eingesetzt. Zusätzlich sollte C++ unterstützt werden.
Die entstehenden Modelle sollten auf die Anforderungen der 3. Normalform überprüft werden
können. Optional wäre zusätzlich eine Überprüfungsmöglichkeit auf Boyce-Codd-Normalform
nützlich.
Es sollte ausserdem die automatische Erzeugung von Datenbank-Zugriffsschichten für die
Anwendungsprogramme möglich sein.
4.3.10 Export-Schnittstellen
Aus den erstellten Modellen muss eine dem Standard folgende DDL generiert, und möglichst
manuell nachbearbeitet werden können. Weiterhin sollte eine DB/2-spezifische DDL generiert
werden können.
Weiterhin muss ein Export in ein XML-Format möglich sein.
Optional wäre die Möglichkeit zusätzlich direkte Datenbank-Änderungen veranlassen zu können
nützlich.
Zur weiteren Verarbeitung der Modelle in anderen Programmen wären Speicherung in tool-spezifische UML-Klassendiagrammen, XMI und MDL nützlich.
4.3.11 Dokumentationsschnittstellen
Als Dokumentationsformat muss HTML, PDF und PostScript unterstützt werden.
Bei Möglichkeit sollte zusätzlich RTF erzeugt werden können.
Für Bilder ist GIF das wichtigste Format, in Einzelfällen wären vektor-orientierte Grafikformate
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
17
Anforderungen an die Tools: Kriterienkatalog
wie EPS oder WMF vorteilhaft.
4.3.12 Import-Schnittstellen
Existierende DDL-Dateien müssen importiert werden können. Dabei ist der Standard geringfügig
wichtiger als DBMS-spezifische Statements.
Da bereits in mehreren Projekten Rational Rose eingesetzt wurde, sollten diese Daten ebenfalls
durch entsprechende Import-Formate wie MDL oder XMI unterstützt werden.
Weiterhin sollte XML als Importformat unterstützt werden.
4.3.13 vorhandene Erfahrungen und bekannte Tools
Bei den Interviews wurden zwar einige Tools genannt, welche bereits mal angeschaut wurden,
jedoch existieren keine verwendbaren Erfahrungen. Das bedeutet, dass diese Tools auf ihre
Tauglichkeit überprüft werden.
Im einzelnen sind dies folgende Tools:
Fachstudie
Hersteller
Produkt
Computer-Associates
Erwin
Microsoft
Access
Microsoft
SQL-Server
Microsoft
Visio
Rational
Rose
Sybase
PowerDesigner
Togethersoft
Together
1. October 2002
IPVR, Universität Stuttgart
18
Vorstellung der getesteten Tools: Corporate Modeler
5.
Vorstellung der getesteten Tools
5.1
Corporate Modeler
Hersteller:
URL:
Version:
Plattformen:
CASEWise
http://www.casewise.com/
2000
Windows
Lizensmodell:
Preise:
899,- DM
Beschreibung:
Corporate Modeler ist ein integriertes Programmpaket von Geschäftsprozess Modellierungswerkzeugen, Zusatzprodukten, Verknüpfungen und Methoden zur Modellierung des Unternehmens, welches formell unterschiedliche Bereiche von Analyse & Techniken zum Modellieren von
Daten, Finanzen, Personal, Prozess und Operationen in einer gemeinsamen Ansicht umfasst.
5.2
Data Design Studio
Hersteller:
URL:
Version:
Plattformen:
Chilli Source
http://www.chillisource.com/dds/index.html
Windows
Lizensmodell:
Commercial Single-User License
Educational Single-User License
Preise:
Runtergeladen: $99
CD:
$189
Beschreibung:
• Project Management of database files, including schemas, scripts, ERDs, ODBC DSNs,
table views, Datastores and other project files.
• Entity Relationship Diagram (ERD) editor. Supports the full Chen ER model.
• Full cardinality and connectivity support for Foreign Key placement, update and delete
rules.
• New "Constraints Editor" for adding column level constraints and table level constraints
(index, check, default, etc). It also allows the reordering of columns within a table
(drag them in the tree view) and renaming of foreign keys (double click on the label in
the tree view).
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
19
Vorstellung der getesteten Tools: ERWin
• Support for ANSI, Ingres, InterBase, Informix, SQLBase, MicroSQL, Microsoft Access,
Microsoft SQL Server, MySQL and Oracle DBMSs as well as Microsoft Visual Basic
and Java (with JDBC) source code.
• Automatic Data Structure Diagram (DSD) from ERD.
• Automatic SQL "CREATE TABLE" schemas from ERD for the above DBMS implementations.
• Automatic SQL scripts for populating the database.
• Automatic "DROP TABLE" scripts for dropping the tables from the database.
• Stand-alone SQL Console (ODBC connectivity to any data source).
• Tree view of any ODBC data source including primary and foreign key details (where
the ODBC driver supports it) within the SQL Console.
• Create, access and query a local MS-Access database based upon your model without the
need to even own MS-Access, all from within the DDS environment.
• Fully constrained off-line Datastore for creation of data that can be uploaded into your
database.
• Java source code for creating and dropping tables within your JDBC accessible database
(JDK is not included).
• Full-screen view for all document views (ERD, SQL, Java, etc).
• Fully integrated Java edit, build, run environment.
• Syntax high-lighting of reserved and keywords in SQL, Java and VB editors.
• Complete build/run environment for any Project file (SQL, Java, JSQL, etc).
• ODBC DSN Manager integration.
5.3
ERWin
Hersteller:
URL:
Version:
Plattformen:
Computer Associates
http://www.cai.com/products/alm/erwin.htm
Windows
Lizensmodell:
Preise:
Beschreibung:
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
20
5.4
Vorstellung der getesteten Tools: Dezign
Dezign
Hersteller:
URL:
Version:
Plattformen:
Lizensmodell:
Preise:
Datanamic
http://www.datanamic.com/dezign/
Windows
Single-User-Lizenz
5-User-Lizenz
10-User-Lizenz
Single UserLizenz: Download - $139, CD: $148
5-User-Lizenz: Download - $599, CD: $608
10-User-Lizenz: Download - $1099, CD: $1108
Beschreibung:
5.5
ERStudio
Hersteller:
URL:
Version:
Plattformen:
Embarcadero
http://www.embarcadero.com/products/design/erdatasheet.htm
4.22
Windows
Lizensmodell:
Preise:
Beschreibung:
5.6
Dia
Hersteller:
URL:
Version:
Plattformen:
Lizensmodell:
Preise:
Beschreibung:
Fachstudie
Gnome Office
http://www.gnome.org/gnome-office/dia.shtml
Unix/Linux
Open Source
Free
1. October 2002
IPVR, Universität Stuttgart
21
5.7
Vorstellung der getesteten Tools: IBMS Case Tool
IBMS Case Tool
Hersteller:
URL:
Version:
Plattformen:
MDB
http://viu.eng.rpi.edu/overview2.html
Windows
Lizensmodell:
Preise:
Beschreibung:
5.8
Visio
Hersteller:
URL:
Version:
Plattformen:
Lizensmodell:
Preise:
Microsoft
http://www.microsoft.com/office/visio/
Windows
Standard
Technical
Professional
Enterprise
$199
$399
$399
$999
Beschreibung:
5.9
Access
Hersteller:
URL:
Version:
Plattformen:
Microsoft
http://www.microsoft.com/office/access/default.htm
2000
Windows
Lizensmodell:
Preise:
Beschreibung:
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
22
Vorstellung der getesteten Tools: Innovator
5.10 Innovator
Hersteller:
URL:
Version:
Plattformen:
MID
http://www.mid.de/german/mainframe.html
7.0
Windows
Unix/Linux
Lizensmodell:
Preise:
Beschreibung:
5.11 Designer
Hersteller:
URL:
Version:
Plattformen:
Lizensmodell:
Preise:
Beschreibung:
Oracle
$ 200
5.12 System Architect 2001
Hersteller:
URL:
Version:
Plattformen:
Popkin
http://www.popkin.com/products/sa2001/product.htm
2001
Windows
Lizensmodell:
Preise:
Beschreibung:
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
23
Vorstellung der getesteten Tools: QDesigner
5.13 QDesigner
Hersteller:
URL:
Version:
Plattformen:
Quest
http://www.quest.com/qdesigner/
Windows
Lizensmodell:
Preise:
Beschreibung:
5.14 Rose
Hersteller:
URL:
Version:
Plattformen:
Rational
http://www.rational.com/products/rose/
Windows
Lizensmodell:
Preise:
Beschreibung:
5.15 Enterprise Architect
Hersteller:
URL:
Version:
Plattformen:
Sparx Systems
http://www.sparxsystems.com.au/ea.htm
Windows
Lizensmodell:
Preise:
$ 99
Beschreibung:
UML Analysis & Design Tool and very affordable.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
24
Vorstellung der getesteten Tools: Data Architect (Power Designer)
5.16 Data Architect (Power Designer)
Hersteller:
URL:
Version:
Plattformen:
Sybase
http://www.sybase.com
8.0
Windows
Lizensmodell:
Preise:
Beschreibung:
$ 2000
5.17 Together
Hersteller:
URL:
Version:
Plattformen:
Togethersoft
http://www.togethersoft.de/
4.2
Windows
Unix/Linux
Lizensmodell:
Preise:
Beschreibung:
5.18 Visible Analyst
Hersteller:
URL:
Version:
Plattformen:
Visible Systems Corporation
http://www.visible.com
7.5
Windows
Lizensmodell:
Preise:
Beschreibung:
The industry's first design tool with an enterprise-class repository that simplifies UML object modeling and data modeling - including Java and XML
This next generation modeling tool combines the functionality of Sybase's leading database design
product with powerful UML-based object modeling.
PowerDesigner Main Features:
• Extended UML support, Use Case and Sequence Diagram
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
25
•
•
•
•
•
•
•
•
•
•
•
•
•
Vorstellung der getesteten Tools: Visible Analyst
Improved, customizable user interface
Improved Enterprise-class repository, extended inter-application links management
Generic code generator from Class diagram, now includes Visual Basic, IDL, C++, etc
PowerDesigner Features/Benefits
UML Use case, Sequence and Class diagrams: supports Analysis & Design phases effectively
Entity/Relationship modeling: the most effective technique to model RDBMS
State-of-the-art graphical user interface, single environment for all modeling techniques: ease
of use and reduced learning curve
Documentation generation: easy application maintenance and reuse
Code generation (database structures and application logic): increased productivity
Reverse-engineering (RDBMS and applications): document or re-engineer existing applications
Round-trip engineering: always keep models and actual database and application in-sync
Enterprise class Repository: effectively manage, share and re-use all modeling information
Flexible modular offering: minimize costs
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
26
Auswertung der Tools: Bewertungskatalog
6.
Auswertung der Tools
6.1
Bewertungskatalog
6.2
Tool 1
6.3
Tool 2
6.4
...
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
27
7.
Zusammenfassung der Ergebnisse: ...
Zusammenfassung der Ergebnisse
Im Test hat sich herausgestellt, daß es zur Zeit kein Tool auf dem Markt gibt, das den Anforderungen aus Kapitel 4 genügt.
Es gibt einerseits Tools, wie z. B. Sybase PowerDesigner (bzw. Quest QDesigner), die für die
Modellierung sehr gut geeignet sind und den größten Teil der gewünschten Features unterstützen.
Diese Funktionalität wird aber durch den Verlust der Portabilität erkauft.
Es gibt kaum Modellierungstools, die unter Linux und anderen Unix-ähnlichen Betriebssystemen
lauffähig sind. Dieses zeigt, daß diese Betriebssysteme in der Industrie - im Gegensatz zum universitären Bereich - auf dem Desktop zur Zeit noch eine untergeordnete Rolle spielen, auch wenn
sie nach wie vor den Server-Sektor dominieren. Die Ursache ist klar: sie ist auf das altbekannte
Henne-Ei-Problem zurückzuführen: so lange das Software-Angebot für professionellen Einsatz
unter Unix bescheiden ist, werden sich die Entscheidungsträger in der Industrie für Windows
entscheiden. Da die Nachfrage dadurch relativ gering bleibt, konzentrieren sich die SoftwareUnternehmen auf Entwicklung unter Windows.
Tools wie Together zeigen andererseits, daß es heutzutage kein Problem ist, durch den Einsatz
von portablen Sprachen wie Java ohne Mehraufwand komplexe Tools zu entwickeln, die auf den
meisten Betriebssystemen lauffähig sind. Leider liegt der Schwerpunkt von Together woanders,
es ist primär ein UML-basiertes Case-Tool zur Unterstützung von Spezifikation und Entwurf von
Softwaresystemen, so daß die Funktionalität zur Datenmodellierung ziemlich beschränkt ist und
einer Erweiterung bedarf. Innovator von MID ist ein anderes Beispiel für ein portables Tool, leider ist es schwierig zu bedienen und für die Modellierung von Datenbanken völlig ungeeignet.
Die meisten Case-Tools, die auf UML basieren, wurden nachträglich erweitert, so daß sie in
irgend einer Form Modellierungs-Features für Datenbanken unterstützen. Leider werden diese
Erweiterungen meistens nicht nahtlos integriert, nicht selten wirken sie wie “draufgeschraubte“
Plugins, die nur mit viel Mühe bedient werden können, und die Funktionalität läßt meist auch sehr
viel zu wünschen übrig. Im Falle einer parallelen Unterstützung von UML und ERM werden
Konzepte manchmal durcheinandergebracht (z. B. bei Rational Rose), so daß die Modellierung
mit der Logik nicht vereinbar ist.
Was die Bedienung angeht, sind die Tools breit gefächert. Manche sind sehr intuitiv zu bedienen,
bei anderen scheitert man schon an der Modellierung von einfachen ER-Diagrammen mit wenigen Entitäten. Dementsprechend ist der Einarbeitungsaufwand auch sehr unterschiedlich. Eins
haben die meisten Tools gemeinsam: sie bieten keine Undo-Funktion. Dieses ist sehr störend,
zumal man heutzutage aus fast jeder Anwendung daran gewöhnt (bzw. verwöhnt) ist. Daß eine
mehrstufige Undo-Funktion nicht schwer zu implementieren ist, zeigt Database Design Studio,
das aber leider durch wenig Funktionalität glänzt.
Manche Funktionalität, wie zum Beispiel die Erstellung von Modell-Dokumentation im Postscript- oder PDF-Format, wird auch von den Tools der engeren Wahl nicht unterstützt. Hier muß
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
28
Zusammenfassung der Ergebnisse: ...
man sich mit einem Postscript-Druckertreiber oder einem PDF-Writer abhelfen. Dieses ist in der
Regel kein Problem, da diese Tools saubere druckbare Dokumentation (z. B. im RTF-Format)
generieren. Die erzeugten Diagramme sind meistens als GIF-Format in der HTML-Dokumentation enthalten, so daß sie leicht kopiert und in anderen Dokumenten weiterverwendet werden können.
Als positiv hat sich die Trennung zwischen den verschiedenen Modellierungsebenen erwiesen.
Durch die verschiedenen Abstraktionsstufen wird der Entwurf eines Datenmodells erleichtert,
und oft ist die Bedienung des Tools dadurch intuitiver, da die Komplexität - die in einem durchschnittlichen Datenmodell nicht zu vernachlässigen ist - sich durch hierarchische Strukturen
leicher bewältigen läßt. Nicht zu vernachlässigen ist die Tatsache, daß sich durch diese Trennung
manche Schritte automatisieren lassen, z. B. die Generierung mehrerer physischer Modelle aus
einem logischen, oder die Synchronisierung verschiedener Modelle.
Ein Problem, unter dem die meisten Tools - und vielmehr: ihre Anwender - zu leiden haben, ist
die mangelnde Erweiterbarkeit. So läßt sich z. B. die DBMS- oder die Sprachenunterstützung nur
da erweitern, wo sie nicht fest im Tool eincodiert ist. Vorbildhaft wurde dieses Problem durch den
PowerDesigner umgangen, indem die Unterstützung in XML-Dateien abgelegt wurde. Benötigt
man z. B. Unterstützung für ein weiteres DBMS, so kann eine weitere XML-Datei erzeugt werden, manuell oder mit dem integrierten Editor. Diese leichte Erweiterbarkeit spiegelt sich auch in
der Vielfalt der unterstützten DBMS wieder, die meisten aktuellen Versionen werden unterstützt.
Ermäßigungen für nichtkommerziellen bzw. universitären Einsatz gibt es kaum. Together stellt
eine Ausnahme dar: es kann an Universitäten kostenlos verwendet werden. Floating Licenses sind
eine Seltenheit, Mengenrabatt ebenso. Der Preis wird auf den Webseiten der Anbieter nicht
immer genannt. Als Grund wird manchmal angegeben, daß der Preis von der “spezifischen Konfiguration” abhängt, die vom Kunden erwünscht wird. Hier ist eventuell ein Verhandlungsspielraum vorhanden.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
29
8.
Empfehlung: ...
Empfehlung
Von den getesteten Tools glänzte Sybase PowerDesigner durch optimale Unterstützung der
meisten geforderten Features. Die intuitive Bedienung des Tools erfordert keinen Einarbeitungsaufwand, so daß PowerDesigner für alle Einsatzgebiete geeignet ist: sowohl für die Vorlesung
und Übung zur Veranschaulichung von ERM- und UML-Datenmodellen, als auch für mittlere
und große Projekte, da das Repository, das für Konsistenz und Versionierung sorgt, von mehreren
Anwendern bei der Modellierung verwendet werden kann. Das Tool kann leicht erweitert werden,
so daß z. B. für die Unterstützung neuer DBMS oder Programmiersprachen kein Update erworben
werden muß.
Angesichts der sehr guten und flexiblen Modellierungsfähigkeiten ist der hohe Preis von ca.
14.000 DM für die umfangreichste Variante (Object Architect) gerechtfertigt. Leider konnten
keine Informationen über eventuelle Vergünstigungen oder Rabatte gefunden werden. Die
genauen Konditionen müssen eventuell in einem Gespräch zwischen der Universität und Sybase
ausgehandelt werden.
Kann man auf die Modellierung von objektorientierten Modellen mittels UML verzichten, so
steht die Variante Data Architect zur Verfügung, die wesentlich günstiger ist (ca. 8.400 DM).
Diese unterstützt physische und konzeptionelle Modelle in vollem Umfang.
Wie bereits erwähnt, ist Sybase PowerDesigner nur für Windows-Plattformen verfügbar. Im
Zweifelsfall muß man sich mit einer PC-Karte in Solaris-Workstations verhelfen oder eventuell
eine Software zur Emulation eines Rechners (wie z. B. VMware) erwerben, so daß man die
Möglichkeit hat, parallel Windows-Programme auszuführen. Diese Mögichkeit wurde aber nicht
getestet, da dieses den zeitlichen Umfang der Fachstudie gesprengt hätte.
Die Firma Quest vermarktet das gleiche Produkt unter dem Namen QDesigner. Der Preis liegt
geringfügig höher als beim Sybase PowerDesigner, aber in dem Preis ist auch ein Jahr Support
enthalten.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
30
Empfehlung: ...
A. Fragebogen zur Ermittlung der
Anforderungen an ein DBModellierungs-Tool
Dieser Fragebogen dient der Ermittlung Ihrer Anforderungen an ein Datenbank-ModellierungsTool.
An manchen Stellen werden Sie aufgefordert, Noten zu vergeben. Dabei bedeutet 0=absolut
unwichtig bis 9=absolutes KO-Kriterium.
Benötigen Sie an einer Stelle mehr Platz, so fügen Sie bitte einen Verweis ein und benutzen Sie
ein Extrablatt.
A.1 Umfeld
3. Bitte geben Sie zunächst für den Fall von Rückfragen Informationen über Ihre Person an
Name
Raum
Telefon
email:
4. Bitte beantworten Sie ein paar Fragen zu Ihrem Arbeitsplatz:
PC
Terminal
5. Werden ausser Englisch weitere Landessprachen zwingend benötigt?
nein
ja / welche?
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
31
Empfehlung: ...
6. Wie wichtig ist Ihnen eine Unterstützung der folgenden Arbeitsweisen?
Arbeitsweise
Note
(0-9)
Tastatur-orientiert
Point-and-Click
Skripting
7. Wie wichtig ist Ihnen eine Unterstützung der folgenden Plattformen?
Plattform
Note
(0-9)
Unix/Linux
Windows
MacOS
BeOS
8. Arbeiten Sie immer an demselben Rechner, oder an unterschiedlichen?
immer derselbe Rechner
unterschiedliche Rechner
9. Welche Nutzungsarten benötigen Sie?
rein wissenschaftlich
teils wissenschaftlich / teils kommerziell
rein kommerziell
10.In welchen Bereichen wollen Sie ein entsprechendes DBM-Tool einsetzen?
Vorlesung
Übungen
Praktika
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
32
Empfehlung: ...
A.2 Modellierung
11.Welche DBMS werden von Ihnen verwendet, und wie wichtig ist Ihnen eine
entsprechende Unterstützung?
DBMS
Version
Wichtigkeit
(0-9)
DB/2
DB/3
Oracle
Informix
Postgres
Access
Interbase
dBase
Sybase
SQL-Server
mySQL
ODBC allgemein
IMS
Adabas
ISAM
Paradox
12.Bitte geben Sie Ihre Einschätzungen zu den Mengengerüsten, der von Ihnen modellierten
Datenbanken an:
Min
Avg
Max
# Entitäten
# Relationen
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
33
Empfehlung: ...
13.Wie wichtig ist Ihnen eine Unterstützung der folgenden Modelle?
Modell
Note
(0-9)
ERM allgemein
ERM, Notation “IDEF1X”
ERM, Notation “Bachmann”
ERM, Notation “Information Engineering”
ERM, Notation “UML”
UML-Klassen
14.Wie wichtig ist Ihnen eine Unterstützung attributierter Beziehungen?
Aspekt
Note
(0-9)
Möglichkeit bei 1:1, 1:n und n:1-Relationen
Möglichkeit bei n:m-Relationen
automatische Umsetzung in Tabellen
Kontrolle in Bezug auf Tabellennamen, etc. der
dadurch entstehenden Entitäten
15.Wie wichtig ist Ihnen eine Modellierung logischer Sichten?
Wichtigkeit
16.Wie wichtig ist Ihnen die Unterstützung folgender Konstrukte durch das DBM-Tool?
Konstrukt
Note
(0-9)
Trigger
Schemata
Domänen
Stored-Procedures
Benutzerrechte
constraints
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
34
Empfehlung: ...
Konstrukt
Note
(0-9)
referentielle Integrität
17.Wie wichtig ist Ihnen eine strikte Trennung zwischen logischer und physischer Sicht?
Wichtigkeit
18.Wie wichtig sind Ihnen folgende Aspekte bei logischen und physischen Sichten?
(Gehen Sie davon aus, dass eine Trennung vorgenommen wird)
automatische Überführung von logisch nach physisch
mehrere physische Sichten
Reverse-Engineering: von physisch nach logisch
Synchronisation zwischen logischem und physischen
Design
19.Wie wichtig ist Ihnen die Möglichkeit der manuellen DDL-Nachbearbeitung?
Wichtigkeit
20.Wie wichtig sind Ihnen folgende Validierungsfunktionalitäten?
Überprüfung auf 3NF
Überprüfung auf BCNF
21.Wie wichtig ist Ihnen eine Undo-Funktion?
Wichtigkeit
22.Werden Modelle parallel von mehreren Personen bearbeitet?
ja
nein
23.Ist Ihnen eine Integration in ein Versionskontrollsystem wichtig?
Integrationsmöglichkeit an sich
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
35
Empfehlung: ...
CVS
PVCS
ClearCase
Visual Source Safe
SCC
A.3 Schnittstellen
24.Wie wichtig ist Ihnen eine Unterstützung der folgenden Import-Möglichkeiten?
Import-Möglichkeit
Note
(0-9)
XML
DDL, SQL-Standard
DDL, DBMS-spezifisch
UML-Klassendiagramm, Tool-spezifisch
XMI
MDL
ERX
existierende DB
25.Wie wichtig ist Ihnen eine Unterstützung der folgenden Export-Möglichkeiten?
Import-Möglichkeit
Note
(0-9)
XML
DDL, SQL-Standard
DDL, DBMS-spezifisch
UML-Klassendiagramm, Tool-spezifisch
XMI
MDL
ERX
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
36
Empfehlung: ...
Import-Möglichkeit
Note
(0-9)
direkte DB-Änderung
26.Wie wichtig ist Ihnen eine Unterstützung der folgenden Dokumentationsformate?
Format
Note
(0-9)
HTML
GIF
JPEG
RTF
PDF
PS
PPT
27.Wie wichtig ist Ihnen eine Unterstützung der folgenden Programmiersprachen?
Sprache
Note
(0-9)
Java
C++
28.Wie wichtig ist Ihnen eine automatische Generierung von DB-Zugriffsklassen?
Wichtigkeit
A.4 Organisation und sonstiges
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
37
Empfehlung: ...
29.Wie stellen Sie sich die Arbeit mit einem DBM-Tool vor?
30.Wie hoch ist das Budget für die Beschaffung eines DBM-Tools?
Dafür bin ich nicht zuständig
Es ist kein Budget bisher definiert
Folgendes Budget ist für die Beschaffung (für die
ganze Abteilung) festgelegt:
EUR
31.Haben Sie bereits Erfahrungen mit entsprechenden Tools gemacht?
nein
ja, welche:
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
38
Empfehlung: ...
32.Sollen Ihrer Meinung nach spezielle Tools getestet werden? Wenn ja, welche?
33.Fehlen Ihnen auf diesem Fragebogen noch Punkte? Wenn ja, welche?
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
39
Empfehlung: ...
B. Testergebnisse
In diesem Anhang werden die gesamten Ergebnisse aller durchgeführten Tests aufgeführt.
B.1 Access (Microsoft)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Access ist nicht zur Modellierung geeignet
Dieses Produkt kommt nicht aus mehreren Gründen nicht als Kandidat für die Modellierung in
Frage. Aus diesem Grund wurde der Test auch abgebrochen:
• Access kann nur seine eigenen Datenbanken und insbesondere keine DB/2-Datenbanken modellieren.
• Die Funktionalität beschränkt sich auf die Möglichkeiten von Access, in welchem insbesondere keine Schemata, Domänen, Trigger und Benutzerrechte enthalten sind.
• Access kann keine DDL generieren.
• Fremde Datenbanken können nur ungenau über einen ODBC-Import eingefügt werden. Hierbei gehen jedoch sehr viele Informationen verlohren, bzw. werden falsch interpretiert.
H.0.2 Access ist dagegen zu Anschauungszwecken geeignet
Obwohl Access nicht für die Modellierung von externen Datenbanken geeignet ist, lässt es sich
jedoch gut in Vorlesungen als Anschauungsmaterial verwenden, da es einerseits einfach zu bedienen ist und andererseits auch komfortable grafische Darstellungen der Modelle und Daten bietet.
B.2 Database Design Studio (Chilli Source)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Ein-
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
40
Empfehlung: ...
schränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Chilli Source
Produktname
Database Design Studio
URL
http://www.chillisource.com/dds
getestete Version
1.09.2
verfügbar auf Windows
ja
verfügbar auf Unix
nein
Anwendungstyp
ERM-Tool
UI-Sprache
englisch
Dokumentationsumfang
Online-Tutorial, Hilfe-System
spezielle Anforderungen
keine
Varianten
keine
Lizenzmodell
benutzergebunden; Commercial oder Educational License
Preise
educational, download version: 45 US $, jede weitere
Lizenz 40 US $
Umgebungsanforderungen
keine Angaben
getestet von
Ralf Terdic
Testumgebung
P-III 1000, 128 MB RAM, Windows XP Beta 2)
Speicherplatzbedarf
ca. 15 MB
H.0.2 grundlegende Bedienung und Oberfläche
Das Tool bietet sehr beschränkte Funktionalität, dementsprechend ist die Bedienung auch ziemlich einfach. Eine mehrstufige Undo-Funktion ist vorhanden und erleichtert die Arbeit.
Es gibt zwei Anzeigemöglichkeiten für ER-Diagramme: die ERD (Entity Relationship Diagram) Ansicht, in der nur die Entitäten und Relationen angezeigt werden, und die DSD (Data Structure
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
41
Empfehlung: ...
Diagram) - Ansicht, in der auch Attribute angezeigt werden.
H.0.3 Arten der Datenbank-Anbindung
Eine direkte DB-Anbindung gibt es nur zu Access. DDL-Dateien können generiert, aber nicht
eingelesen werden, da jegliche Reverse Engineering-Möglichkeiten fehlen.
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version 7
nein
Oracle
ja
Informix
ja
Postgres
nein
Access
ja, 2000
SQL-Server
ja
mySQL
ja
ODBC allgemein
ja
User-Extendable
nein
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
Es wird nur das ERM unterstützt.
H.0.5.2 attributierte Beziehungen
Bei m:n-Relationen können Attribute definiert werden.
H.0.5.3 Referentielle Integrität
RI-Aktionen werden nicht unterstützt.
H.0.5.4 Views
Es können keine Views definiert werden.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
42
Empfehlung: ...
H.0.5.5 Sichtentrennung
Eine Trennung zwischen logischer und physischer Sicht ist nicht gegeben.
H.0.5.6 Anwendungs-Code
Stored Procedures und Datenbank-Zugriffsschichten können nicht erzeugt werden. Java und Visual Basic werden unterstützt, jedoch nur als Ersatz für DDL-Skripte, d.h. das Schema kann direkt
aus einem Programm erzeugt werden.
H.0.5.7 Validierungsfunktionen
Validierungsfunktionen sind nicht vorhanden.
H.0.5.8 erweiterte Modellierung
Es gibt keine zusätzlichen Modellierungskonstrukte, wie Trigger, Constraints, Schemata etc.
H.0.5.9 Import-Möglichkeiten
Das Programm bietet keine Import-Möglichkeiten.
H.0.5.10 Export-Möglichkeiten
Exportiert werden kann nur DDL. Dafür wird eine SQL-Konsole bereitgestellt, mit deren Hilfe
man eine Verbindung zur Datenbank über ODBC erstellen und das DDL-Skript ausführen kann.
H.0.5.11 Modell-Dokumentation
Es kann ein ERD-Report und ein DSD-Report (DSD = Data Structure Diagram) erzeugt werden,
die jedoch nur ausgedruckt werden können. Um diese abzuspeichern, muß man z.B. mit einem
Postscript-Treiber in eine Datei drucken.
H.0.5.12 weitere Möglichkeiten
Zusätzliche Features besitzt DDS nicht.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
Database Design Studio ist, ganz im Gegensatz zu dem, was der Name suggeriert, ein kleines
Tool mit sehr beschränkter Funktionalität.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
43
Empfehlung: ...
H.0.6.2 Bewertung der Einsatzmöglichkeiten
Das Tool ist hauptsächlich für Vorlesungen geeignet, zur Veranschaulichung des Entity Relationship-Modells. Es eignet sich sicherlich auch für Übungen und Mini-Projekte, so lange man nicht
auf die fehlende Funktionalität angewiesen ist, aber im großen Ganzen hilft es nicht wirklich bei
der Datenmodellierung.
H.0.6.3 Bewertung der Bedienung
Die Bedienung ist relativ einfach und intuitiv. Die mehrstufige Undo-Funktion erleichtert die
Arbeit erheblich.
H.0.6.4 Stärken
Einfachheit, leichte Bedienbarkeit, mehrstufige Undo-Funktion
H.0.6.5 Schwächen
Sehr beschränkte Funktionalität, keine Schnittstellen zu anderen Tools, keine Multiuser-Fähigkeiten.
H.0.6.6 Bewertung der Einsatzfähigkeit
Aufgrund des sehr begrenzten Funktionsumfangs, den Database Design Studio bietet, ist es kaum
für den Einsatz an Universitäten geeignet. Es eignet sich hauptsächlich für die Veranschaulichung
des Entity Relationship-Modells.
B.3 Dezign (Datanamic)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Datanamic
Produktname
Dezign
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
44
Empfehlung: ...
URL
http://www.datanamic.com/dezign/
getestete Version
2.4.3
verfügbar auf Windows
Ja
verfügbar auf Unix
Nein
Anwendungstyp
ERM-Tool
UI-Sprache
Englisch
Dokumentationsumfang
Hilfe, im Programm integriert, keine Index-Suche und
Glossar; Tutorial als PDF-Datei
spezielle Anforderungen
keine
Varianten
keine
Lizenzmodell
Einzel, 5 und 10 Benutzer Lizenzen
Preise
1 Benutzer $139 Download (CD $148)
5 Benutzer $599 Download (CD $608)
10 Benutzer $1099 Download (CD $1108)
Umgebungsanforderungen
Windows 95 / 98 / ME / NT / 2000
4 MB RAM
486 Prozessor
4 MB Speicherplatz auf Festplatte
getestet von
Christian Scheibel
Testumgebung
AMD Duron 800, 256 MB RAM
Windows 2000
Speicherplatzbedarf
incl. aller Zusatzprogramme zum Import von Tabellen,
Scripten, MySQL und Access: 8 MB
H.0.2 vom Hersteller versprochene Features
Hier werden alle laut Herstellerangaben vorhandenen Features angegeben, gleichgültig ob dies
der Realität entspricht oder nicht. Die Realität wird für die im Rahmen dieser Toolauswahl relevanten Features in den folgenden Abschnitten erarbeitet.
H.0.3 grundlegende Bedienung und Oberfläche
Die Bedienung erfolgt am besten über die Point-and-Click Methode. Alle wichtigen Menupunkte
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
45
Empfehlung: ...
zur Erzeugung eine Diagramms kann man schnell über eine Tool-Icon-Leiste erreichen. Pop-Up
Menus erleichtern die Arbeit mit der Maus. Es gibt zwar die Möglichkeit mit Short-Cuts einige
Funktionen zu starten, aber da nicht alle Fuktionen auf diese Weise angesprochen werden können,
ist diese Arbeitsweise etwas mühselig. Man kann auch keine eigenen Short-Cuts definieren.
Scripting wird vom Programm nicht unterstützt. Die Arbeit wird durch eine fehlende UNDOFunktion ausserdem noch zusätzlich erschwert.
H.0.4 Arten der Datenbank-Anbindung
Dezign ist nur ein Modellierungstool. Es kann aus einem modellierten Schema ein DDL Script für
eine Zieldatenbank erzeugen. Änderungen in der Datenbank kann es nicht erkennen. Es kann nur
über Zusatzprogramme alte Datenbanken importieren. Zusätzlich zu den unten aufgeführten
Datenbank
Anbindung
DB/2 Version 7
ja
Oracle
ja
Informix
ja
Postgres
ja
Access
ja (95/97/2000),
Zusatzprogramm
SQL-Server
ja, Import von SQL-Files mit
DDL BEschreibung per Zusatzprogramm
mySQL
Import per Zusatzprogramm
ODBC allgemein
nein
User-Extendable
nein
Import
per
Datenbanken werden noch Folgende vom Programm unterstützt: ANSI Level 2, dBase, Ingres,
Interbase, paradox, SQL Anywhere und Sybase.
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
ERM wird unterstützt.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
46
Empfehlung: ...
H.0.5.2 attributierte Beziehungen
Attributierte Beziehungen kann man mit Datanamic Dezign nicht modellieren.
H.0.5.3 Referentielle Integrität
Nein.
H.0.5.4 Views
Nein.
H.0.5.5 Sichtentrennung
Nein.
H.0.5.6 Anwendungs-Code
H.0.5.7 Validierungsfunktionen
Sind im Programm nicht vorhanden.
H.0.5.8 erweiterte Modellierung
Schemata und Domänen können in der Modellierung eingesetzt werden
H.0.5.9 Import-Möglichkeiten
Der Import funktioniert nur über Extra-Programme. Es können bisher Scripte (DDL), Tabellen,
Access und mySQL importiert werden.
H.0.5.10 Export-Möglichkeiten
Export in alle oben angegebenen Datenbanken jederzeit möglich.
H.0.5.11 Modell-Dokumentation
Die Dokumentation im Modell erfolgt über einfache Textfelder, in die jede Information hineingeschrieben werden kann, die man benötigt. Allerdings muss man sämtliche Informationen von
Hand eintragen, automatisch funktioniert es nicht. Ausserdem können diese Textfenster frei verschoben werden und so ist die Zugehörigkeit im Modell nicht ohne weiteres ersichtlich.
Für jede Entität, Relation und jedes Attribut können Beschreibungen eingegeben werden.
H.0.5.12 weitere Möglichkeiten
Keine.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
47
Empfehlung: ...
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
Datanamic Dezign ist ein nettes kleines Modellierungstool, dass vor allem durch Einfachheit
besticht. Die Modellierungsmöglichkeiten sind allerdings stark beschränkt auf einfache Konstrukte.
H.0.6.2 Bewertung der Einsatzmöglichkeiten
Datanamic Dezign ist bedingt geeignet für Vorlesung und evtl. Übung.
Es ist nicht geeignet für Praktika, Projekte, Studien-/Diplomarbeiten, Forschung, da der Funktionsumfang zu gering ist.
H.0.6.3 Bewertung der Bedienung
Die Bedienung ist sehr einfach gehalten. Mittels Point-and-Click kann das Programm einfach
bedient werden. Der Einarbeitungsaufwand ist durch den geringen Umfang sehr klein. Schon
nach kurzer Zeit kann man passable Ergebnisse vorweisen.
H.0.6.4 Stärken
Das Programm ist klein und billig.
H.0.6.5 Schwächen
Kann nur sehr wenig. Eine UNDO-Funktion fehlt.
H.0.6.6 Bewertung der Einsatzfähigkeit
Datanamic Dezign ist nur bedingt einsatzfähig im Universitätsbereich. Durch den geringen Funktionsumfang ist es nur für die kleine Datenbank geeignet. Durch die Möglichkeit, modellierte
Datenbanken in MS Access zu importieren, wird dieses Tool vor allen Dingen für Vorlesungen
interessant, um die Ergebnisse der Modellierung als Datenbank für die Zuhörer schnell und
bequem sichtbar zu machen.
B.4 Enterprise Architect (Sparx Systems)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Ein-
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
48
Empfehlung: ...
schränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Sparx Systems
Produktname
Enterprise Architect
URL
http://www.sparxsystems.com.au/ea.htm
getestete Version
2.10 Build 250
verfügbar auf Windows
ja
verfügbar auf Unix
nein
Anwendungstyp
Case-Tool für UML-basierte Analyse und Entwurf
UI-Sprache
englisch
Dokumentationsumfang
Online-Dokumentation, PDF-Dateien, White Papers zu
UML
spezielle Anforderungen
keine
Varianten
EA Desktop Edition und EA Professional Edition. Letztere
unterstützt Code-Import und -Export und Mehrbenutzermodellierung
Lizenzmodell
es werden mehrstufige Lizenzen für Bildungseinrichtungen angeboten
Preise
US $ 45 (1 User Educational EA Desktop) - US $ 7000
(Unlimited Site License, EA Professional).
Umgebungsanforderungen
nicht angegeben, aus dem Test ergaben sich keine besonderen Anforderungen
getestet von
Ralf Terdic
Testumgebung
P-III 1000, 128 MB RAM, Windows XP Beta 2
Speicherplatzbedarf
ca. 8 MB
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
49
Empfehlung: ...
H.0.2 vom Hersteller versprochene Features
Im folgenden werden einige Eigenschaften des Tools aufgelistet. Diese wurden von verschiedenen Stellen, an denen sie vom Hersteller veröffentlicht wurden (Website, Hilfedatei,
Dokumentation), gesammelt.
Feature
Kurzbeschreibung
UML 1.1-Support
Use Case-Modell, Business Process-Modell, dynamische Modelle, logische Modellierung, Componentund Deployment-Diagramme etc.
Flexible Dokumenta- RTF-Export mit flexiblen Optionen, Templates köntion
nen für die Wiederverwendung gespeichert werden,
RTF Bookmarks
Source Code Engineering
Forward und Reverse Engineering für C++, C#, Java,
VB, Delphi
Intuitive,
flexible Oberfläche ähnlich dem Windows Explorer; verBenutzeroberfläche
schiedene Anzeigeoptionen
Unterstützung
Test
für Unterstützung für Modul-, Integrations- und Systemtest, Aczeptanztests, Szenarien
Unterstützung
Wartung
für Change control-Details,
recording
Mehrbenutzer-Unterstützung
Maintenance
and
fault
Nur in der Professional-Version
H.0.3 grundlegende Bedienung und Oberfläche
Die Bedienung des Tools erfolgt größtenteils per Point-and-Click. Auf den ersten Blick sieht man
schon, daß das Tool nicht auf Datenmodellierung ausgerichtet ist. Tabellen sind nichts anderes als
Klassen - der einzige Unterschied ist, daßder Name des Reiters “Class Details“ in “Table Details“
umbenannt wird, wenn man eine Klasse als Tabelle (über den Stereotyp “table”) deklariert. Dieser Reiter bietet drei Buttons, mit deren Hilfe man Attribute und Methoden definieren und eine
DDL-Datei generieren kann. Dabei muß man für jede einzelne Tabelle in einer Dropdown-Liste
das Ziel-Datenbanksystem wählen. Erst nachdem hier etwas gewählt wurde und mit “OK” das
Dialogfenster verlassen wurde, kann man einem Attribut einen Typ zuweisen.
Eine Undo-Funktion wird nicht angeboten. Insgesamt ist die Bedienung des Tools sehr benutzerunfreundlich.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
50
Empfehlung: ...
H.0.4 Arten der Datenbank-Anbindung
Die Anbindung von Datenbanken erfolgt durch die Generierung von DDL-Skripten, welche als
Textdateien abelegt werden. Eine direkte Änderung der Datenbank ist nicht möglich.
Bei der Generierung kann gewählt werden, ob für die einzelnen Tabellen “DROP TABLE”-Statements erzeugt werden sollen, oder nicht.
Ein Import bestehender Datenbanken oder von DDL-Skripten ist nicht verfügbar, ebenso merkt
sich das Tool keine bereits erzeugten DDL-Skripte, so dass bei der Erzeugung jeweils neue
Tabellen angelegt werden. Das bedeutet, dass eventuell bestehende Datenbestände ohne manuelle
Nachbearbeitung der Skripte verlorengehen.
H.0.5 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version 7
nein
Oracle
ja
Informix
nein
Postgres
nein
Access
ja
SQL-Server
ja (Version 7)
mySQL
nein
ODBC allgemein
nein
User-Extendable
ja (auf Datentypen beschränkt)
H.0.6 Bewertung
Da Enterprise Architect schon bei der Erstellung von primitiven Modellen scheitert, und seine
Benutzerfreundlichkeit sehr zu wünschen übrig läßt, wird die Modellierung mit diesem Tool nicht
weiter untersucht. Da der Schwerpunkt der Zielsetzung dieses Tools woanders liegt, und die
meisten der im Kriterienkatalog enthaltenen Features nicht unterstützt werden, wird dieses Tool
als ungeeignet für die Datenbank-Modellierung betrachtet.
B.5 ER/Studio (Embarcadero Technologies)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
51
Empfehlung: ...
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Embarcadero Technologies
Produktname
ER/Studio
URL
http://www.embarcadero.com/products/design/
erdatasheet.htm
getestete Version
4.21
verfügbar auf Windows
ja
verfügbar auf Unix
nein
Anwendungstyp
ERM-basiertes Modellierungstool
UI-Sprache
englisch
Dokumentationsumfang
Online-Dokumentation (White Papers, User’s Guide),
Hilfesystem
spezielle Anforderungen
keine
Varianten
keine
Lizenzmodell
nicht angegeben
Preise
nicht angegeben
Umgebungsanforderungen
<angegebene Minimalanforderungen>
getestet von
Ralf Terdic
Testumgebung
P-III 1000, 128 MB RAM, Windows XP Beta 2
Speicherplatzbedarf
ca. 40 MB
H.0.2 grundlegende Bedienung und Oberfläche
ER/Studio macht einen benutzerfreundlichen Eindruck. Die Funktionalität ist gut strukturiert in
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
52
Empfehlung: ...
den Menüs, die Toolbars lassen sich zwar nicht anpassen, aber ein- und ausschalten, so daß man
den Überblick behält. Insgesamt ist die ganze Bedienoberfläche sehr übersichtlich gestaltet.
Man geht bei jedem Datenmodell vom logischen Modell aus, das vom physischen getrennt ist.
Hat man das logische Modell erstellt, so kann man aus diesem verschiedene physische Modelle
generieren, wobei für jedes die Zieldatenbank angegeben werden kann. Die Generierung dieser
Modelle, und allgemein, jeder Schritt, in dem das Tool etwas automatisch generiert, wird über
einen Assistenten (Wizard) gesteuert. Dieses ist zwar am Anfang komfortabel und flexibel, wenn
man aber die Schritte oft wiederholen muß, kann er auch lästig werden.
Eine Undo-Funktion ist leider nicht vorhanden, so daß man bei kritischen Schritten wie z. B. das
Löschen einer Entität vorsichtig sein muß.
H.0.3 Arten der Datenbank-Anbindung
Die DB-Anbindung kann über DDL-Dateien oder direkt über die ODBC-Schnittstelle realisiert
werden. Sowohl Reverse als auch Forward Engineering wird hierbei unterstützt. Ferner kann theoretisch zu IBM DB/2, Microsoft SQL Server, Sybase ASE und Oracle auch eine native Verbindung aufgebaut werden. Im Test konnte die Verbindung zu einem DB/2 7.1-Server nicht
aufgenommen werden, es wurde folgende Fehlermeldung angezeigt: “Reverse engineering DB/2
is not supported“. Das kann unter Umständen daran liegen, daß DB/2 nur bis zur Version 6 unterstützt wird. Andererseits funktionierte das Reverse Engineering einer MySQL-Datenbank problemlos, obwohl dieses DBMS laut Dokumentation nicht unterstützt wird.
Der Import eines DB/2-DDL-Skripts funktionierte jedoch ohne Probleme.
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version 7
nein, nur Version 6.x
Oracle
ja, Version 8
Informix
ja, SE und ONLINE
Postgres
nein
Access
ja, Version 2000
SQL-Server
ja, Version 2000
mySQL
Fachstudie
nein
ODBC allgemein
ja
User-Extendable
nein
1. October 2002
IPVR, Universität Stuttgart
53
Empfehlung: ...
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
ER/Studio unterstützt die Modellierung nach dem ERM.
H.0.5.2 attributierte Beziehungen
Zu m:n-Relationen kann man Attribute zuweisen, jedoch nur im im physischen Modell. Diese
werden auch nach einer Synchronisierung des logischen Modells in diesem nicht angezeigt.
H.0.5.3 Referentielle Integrität
Es können alle RI-Aktionen definiert werden (set null, set default, restrict, cascade).
H.0.5.4 Views
Views können sowohl durch Auswahl der Tabellen und Spalten, als auch durch Eingabe einer
SQL-Query definiert werden.
H.0.5.5 Sichtentrennung
Es existiert eine strikte Trennung zwischen logischem und physischem Modell. Typischerweise
erstellt man zuerst ein logisches Modell, daraus kann man anschließend ein oder mehrere physische Modelle generieren lassen. Führt man danach Änderungen an einem Modell durch, so lassen sich die anderen Modelle synchronisieren (merge), wobei die Änderungen, die dazu
automatisch gemacht werden, genau kontrolliert werden können.
Beim Reverse Engineering wird ebenso ein logisches Modell erstellt, aus dem man anschließend,
wie erwähnt, mehrere physische generieren kann.
H.0.5.6 Anwendungs-Code
Es können Stored Procedures erstellt werden, jedoch nur für Oracle, Sybase Adaptive Server und
Microsoft SQL Server. ER/Studio kann Java-Zugriffsklassen erzeugen, jedoch auch nur für diese
drei Plattformen.
H.0.5.7 Validierungsfunktionen
Eine primitive Validierungsfunktion ist enthalten, sie prüft das Modell auf ein paar einfach Kriterien (z. B. ob alle Entitäten Attribute bzw. Primärschlüssel enthalten etc.).
H.0.5.8 erweiterte Modellierung
Trigger können für Oracle, Sybase Adaptive Server und Microsoft SQL Server implementiert
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
54
Empfehlung: ...
werden. Domänen, Regeln (rules) und benutzerdefinierte Typen lassen sich auch definieren.
H.0.5.9 Import-Möglichkeiten
Reverse Engineering von Datenbanken über DDL oder ODBC; ERwin interchange Format
(ERX)
H.0.5.10 Export-Möglichkeiten
DDL und ODBC; XML DTD, XML Schema
H.0.5.11 Modell-Dokumentation
Flexible, professionell aussehende Dokumentation im HTML oder RTF-Format. Als Teil der
HTML-Dokumentation (auch Intranet Dictionary genannt) wird das ER-Diagramm leider als
JPG-Datei mit hoher Kompressionsrate gespeichert, dieses führt zu verschwommener Beschriftung. Man kann jedoch das Diagramm auch einzeln als BMP, WMF oder EMF exportieren.
H.0.5.12 weitere Möglichkeiten
Eine komfortable SQL-Konsole namens ISQL wird angeboten; diese unterstützt u.a. Syntax
Highlighting.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
ER/Studio macht insgesamt einen guten Eindruck, es ist benutzerfreundlich, intuitiv und sehr
leicht zu bedienen und bietet ausserdem einen überdurchschnittlichen Funktionsumfang.
H.0.6.2 Bewertung der Einsatzmöglichkeiten
Das Tool ist sowohl in der Vorlesung als auch in Übungen und Praktika einsatzfähig. Der Einsatz
in größeren Projekten wäre auch denkbar, so lange man eines der besser unterstützten DBMS einsetzt (z.B. Sybase oder Oracle) und die Modellierung durch mehrere Benutzer nicht notwendig ist
(da es weder integrierte Repositories noch Versionierungssysteme hat).
H.0.6.3 Bewertung der Bedienung
Die Bedienung ist benutzerfreundlich, jedoch können unter Umständen die vielen Assistenten
etwas stören.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
55
Empfehlung: ...
H.0.6.4 Stärken
Leicht zu bedienendes Tool, das viele Modellierungskonzepte unterstützt.
H.0.6.5 Schwächen
Kein integriertes Repository oder Versionierungssystem, daher nicht multiuserfähig. Die DBMSUnterstützung für erweiterte Modellierungs-Features wie z. B. Trigger und Stored Procedures läßt
etwas zu wünschen übrig, da sie sich auf drei Plattformen beschränkt und nicht erweiterbar ist.
Die DB/2-Unterstützung ist etwas bescheiden.
Eine Undo-Funktion existiert nicht.
H.0.6.6 Bewertung der Einsatzfähigkeit
ER/Studio ist zwar im Vergleich zu anderen Tools sehr leicht und ohne Einarbeitungsaufwand zu
bedienen. Angesichts der etwas mageren DB/2-Unterstützung und der fehlenden MultiuserUnterstützung ist es aber nur bedingt einsatzfähig.
B.6 ERwin (Computer Associates)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
56
Empfehlung: ...
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Computer Associates
Produktname
ERwin
URL
http://ca.com/products/alm/erwin.htm
getestete Version
4.0 (Build 1298)
verfügbar auf Windows
ja
verfügbar auf Unix
nein
Anwendungstyp
Reines DB-Modellierungstool (ERM-basiert)
UI-Sprache
englisch
Dokumentationsumfang
PDF-Dateien erhältlich auf Website; Hilfedatei und Tutorial
spezielle Anforderungen
CA Modelmart für Mehrbenutzermodellierung
Varianten
keine
Lizenzmodell
unbekannt (muß evtl. noch ermittelt werden)
Preise
unbekannt (muß evtl. noch ermittelt werden)
Umgebungsanforderungen
85 MB Festplatte, 64 MB RAM (128 MB für umfangreiche
Modelle)
getestet von
Ralf Terdic
Testumgebung
P-III 1000, 128 MB RAM, Windows XP Beta 2
Speicherplatzbedarf
ca. 60 MB
H.0.2 grundlegende Bedienung und Oberfläche
Die BEdienung erfolgt hauptsächlich über Point-And-Click. Hotkeys werden nur sehr begrenzt
unterstützt. Die Erstellung erster Fassungen von Entitäten ist aber sehr schnell und einfach
möglich (Entität erstellen, Namen für Entität eingeben, Tab drücken, Namen für Primärschlüssel
eingeben, Tab drücken, Namen für Attribute eingeben, Enter drücken, um zum nächsten Attribut
zu kommen), dabei wird der Default-Typ den Attributen zugewiesen, diesen kann man natürlich
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
57
Empfehlung: ...
einstellen
Eine Undo-Funktion ist nicht vorhanden.
Es gibt verschiedene Display Level, die die angezeigten Details bestimmen (Entity, Attribute, Primary Key, Definition, Icon).
Man kann beliebige Icons (Bitmaps) zu Entitäten zuordnen.
Die Anzeigeoptionen sind sehr flexibel. So können diese als Profile gespeichert werden.
Das Programm untstützt die Übersichtlichkeit mit Layout-Hilfen (Align Top etc.).
Der Verlauf der Relationen-Linien kann sehr genau angepaßt werden, die Anpassung kann aber
auch mittels Autolayout automatisch vorgenommen werden.
Zur besseren Gliederung der Modelle kann man Subject Areas (Untermodelle) anlegen.
Eine Zoom-Funktion zum Verkleinern und Vergrößern ist vorhanden, eine Lupe fehlt jedoch.
Die gesamte Arbeitsoberfläche ist intuitiv bedienbar und daher ist keine Schulung notwendig.
Eine Modelmart-Unterstützung ist geplant und auch in der Benutzeroberfläche vorhanden, jedoch
ohne Funktionalität, da Modelmart 4 noch nicht verfügbar ist (noch in Entwicklung). Modelmart
= Repository, das parallele Bearbeitung von Modellen ermöglicht; sorgt für Sicherheit, Konsistenz durch Sperren, und Versionsverwaltung. Ältere Modelmart-Versionen werden nicht unterstützt.
Es sind weder CVS noch andere Versionsverwaltungssysteme integriert, dazu soll in Zukunft
Modelmart dienen.
H.0.3 Arten der Datenbank-Anbindung
Die Datenbankanbindung erfolgt über ODBC zur Synchronisation von physischem Modell und
Datenbank. DDL-Dateien können geparst und generiert werden. Import und Export können flexibel eingestellt werden. Hat im Test gut funktioniert.
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version
Fachstudie
nur 6.1
Oracle
8.x
Informix
9.2x
Postgres
nein
Access
2000
1. October 2002
IPVR, Universität Stuttgart
58
Empfehlung: ...
SQL-Server
2000
mySQL
nein
ODBC allgemein
ja
User-Extendable
nein
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
Es wird nur das ERM-Modell unterstützt.
Dabei wird eine Trennung zwischen logischem und physischem Modell vorgenommen.Es können
jedoch auch kombinierte physisch/logische Modelle erstellt werden, die laufend automatisch synchronisiert werden.
Einem Modell kann man ein oder mehrere Quellmodelle zuweisen (source models), so daß
dadurch sowohl forward als auch reverse engineering zwischen Modellen möglich ist.
Vorgehen: Entweder man erstellt zuerst ein logisches Modell und danach ein leeres physisches
und gibt hier als Source das logische Modell an, wobei dann alles notwendige generiert wird, oder
man kann ein logisch/physisches Modell erstellen, so daß Änderungen an einem Modell an das
andere weitergegeben werden, damit man keine Synchronisation manuell aufrufen muß.
H.0.5.2 attributierte Beziehungen
Attributierte Beziehnungen werden nicht unterstützt.
m:n-Relationen werden unterstützt. Im rein physischen Modell können diese aufgelöst werden
(dazu gibts einen Wizard). Löst man sie nicht auf, so fehlen die Relationen in der generierten DB
komplett.
Aus den sonstigen Relationen entstehen keine Tabellen; sie werden mit Hilfe von Fremdschlüssel-Constraints implementiert
Mehrfache Relationen zwischen Entitäten sind erlaubt, Zyklen jedoch nicht.
H.0.5.3 Referentielle Integrität
RI-Aktionen können für jede Relation angegeben werden (nur cascade und restrict)
Es können RI-Trigger definiert werden, hierbei wird man durch vordefinierte Templates und
Makros unterstützt.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
59
Empfehlung: ...
H.0.5.4 Views
Views können erzeugt werden, sowohl durch Auswahl der Tabellen und Spalten, als auch direkt
in SQL.
H.0.5.5 Sichtentrennung
Eine Sichtentrennung wird zwar vorgenommen - logisches und physisches Modell, jedoch ist die
Trennung nicht besonders strikt (Relationen gibt es auch in physischem Modell).
H.0.5.6 Anwendungs-Code
Stored Procedures können in physischen Modellen sowohl auf Modell- als auch auf Tabellenebene erzeugt werden, hierbei wird man durch Makros unterstützt.
Es können SQL-Pre- und Post-Scripts definiert werden, die unmittelbar vor oder nach der
Schema-Generierung oder nach der Erstellung einer Tabelle oder eines Views aufgerufen werden.
Diese können zusammen mit Makros benutzt werden, so daß z.B. für jede Tabelle ein Code-Teil
aufgerufen wird (Beispiel: alle Tabellen, die im Schema erstellt werden, werden vorher gelöscht)
H.0.5.7 Validierungsfunktionen
Validierungsfunktionen sind nicht vorhanden.
H.0.5.8 erweiterte Modellierung
Trigger werden unterstützt. RI-Trigger werden automatisch zur Abbildung von Relationen in der
Datenbank generiert. Bei der Generierung hat man keine Möglichkeit, eventuell vorhandene Trigger automatisch löschen zu lassen, wie es bei Tabellen der Fall ist. Dieses führte im Testmodell
wiederholt zu Problemen, so daß die Trigger gelöscht werden mußten, entweder manuell oder
durch Anpassung des DDL-Skripts.
Constraints können mit Hilfe von sogenannten “Validation rules“ definiert werden. Domänen
können definiert werden, auch als Vererbungshierarchien. Eine Möglichkeit zur Modellierung
von Benutzerrechten gibt es nicht. Sofern es sich bei dem Ziel-DBMS um DB2 handelt, können
auch Tablespaces erstellt werden.
H.0.5.9 Import-Möglichkeiten
Importiert werden können DDL, Access (*.mdb), dBASE (*.DBF), Erwin XML (siehe ExportMöglichkeiten; nur mit installiertem Patch möglich), Oracle Designer/2000.
H.0.5.10 Export-Möglichkeiten
Exportiert werden kann in das ERwin XML Format, welches das ERX-Format ersetzt. Es ist sehr
umfangreich und beinhaltet das gesamte Modell (sogar Bitmaps zur Darstellung von EntitätenIcons). Ferner kann das Modell noch im Oracle Designer/2000-Format gespeichert werden.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
60
Empfehlung: ...
H.0.5.11 Modell-Dokumentation
ERwin unterstützt HTML, RTF und Text-Dateien als Format für die erzeugte Dokumentation. Es
können Templates zur Generierung benutzt werden.
H.0.5.12 weitere Möglichkeiten
ERwin bietet leider keine Möglichkeit zur Erweiterung. Mit der Fertigstellung des ModelMart
wird man die Möglichkeit haben, ERwin für die Modellierung im Team einzusetzen.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
ERwin ist eines der besseren Modellierungstools, die auf dem Entity-Relationship-Modell
basieren. Es unterstützt die meisten Modellierungskonzepte, und die Bedienung ist einfach und
intuitiv, aber die Tatsache, daß das ModelMart-Repository zur Zeit noch nicht angeboten wird,
macht das Tool für die Uni (wegen fehlender Teamunterstützung) nicht so interessant. Ebenso
lassen die mageren Schnittstellen zu anderen Tools zu wünschen übrig.
H.0.6.2 Bewertung der Einsatzmöglichkeiten
ERwin eignet sich als Modellierungstool für mittlere Projekte, zum Beispiel Praktika oder Studienarbeiten, die nicht auf Modellierung im Team angewiesen sind. Prinzipiell kann man mit
ERwin auch große Datenbank-Schemata modellieren und warten, dieses wird vor der Fertigstellung des ModelMart dadurch erschwert, daß man für die Modellierung im Team andere Komponenten wie z.B. CVS einsetzen muß, die zwar Versionsverwaltung und Sicherheit, aber bei
weitem nicht die Möglichkeiten eines auf das Modellierungstool abgestimmten Repositories
bieten.
H.0.6.3 Bewertung der Bedienung
Die Bedienung ist sehr intuitiv, und benötigt kaum Einarbeitung, obwohl die Arbeitsoberfläche
sehr flexibel konfigurierbar ist.
H.0.6.4 Stärken
Einfach zu bedienendes Tool, das die meisten Modellierungskonzepte unterstützt. Forward und
Reverse Engineering funktioniert auf allen Ebenen zufriedenstellend. Flexible Dokumentationsgenerierung. XML-Export, sehr detailliert (kann auch als Nachteil empfunden werden).
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
61
Empfehlung: ...
H.0.6.5 Schwächen
Noch nicht teamfähig (ModelMart fehlt). Wenige Schnittstellen zu anderen Tools. Die ER-Diagramme können nicht direkt im Grafikformat abgespeichert werden, sie müssen aus der generierten HTML-Dokumentation manuell extrahiert werden. Keine Unterstützung von Sprachen wie
Java oder C++, keine Generierung von Zugriffsklassen. DB2 wird in der aktuellen Version (7.1)
nicht unterstützt (nur bis Version 6.1), im Test gab es aber in dieser Hinsicht keine Schwierigkeiten. (eventuell noch nach anderen KO-Kriterien bei mir nachfragen)
H.0.6.6 Bewertung der Einsatzfähigkeit
ERwin ist ein flexibles Modellierungstool, das mehr als nur grundlegende Modellierungsmöglichkeiten bietet. Es eignet sich gut für die Modellierung von Datenbankschemata nach dem ERModell, jedoch ist es zur Zeit noch nicht im Team einsatzfähig, da es mangels eines Repositories
keine parallele Bearbeitung unterstützt.
B.7 Innovator (MID)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
MID
Produktname
Innovator
URL
getestete Version
7.0
verfügbar auf Windows
ja
verfügbar auf Unix
ja
Anwendungstyp
Case-Tool
UI-Sprache
Englisch, Deutsch
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
62
Empfehlung: ...
Dokumentationsumfang
online-Doku, kurze Papier-Einführung
spezielle Anforderungen
<z.B. Server notwendig, zusätzliche Tools, ...>
Varianten
Lizenzmodell
<z.B. Arbeitsplatzgebunden, Benutzergebunden, Floating,
...>
Preise
Umgebungsanforderungen
<angegebene Minimalanforderungen>
getestet von
Michael Wenig
Testumgebung
P-III 800, 512MB RAM, Windows NT 4.0 (SP6a)
Speicherplatzbedarf
H.0.2 Evaluierung abgebrochen
Die Evaluierung von Innvoator wurde abgebrochen, da die Bedienung weder intuitiv ist, noch
eine entsprechende Dokumentation vorhanden ist.
Beispielsweise konnten keine Attribute erstellt werden, da die in der Hilfe angegebene Funktion
nicht verfügbar war.
B.8 PowerDesigner (Sybase)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
63
Empfehlung: ...
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Sybase
Produktname
PowerDesigner
URL
http://www.sybase.com/products/enterprisemodeling/
powerdesigner
getestete Version
8.0.0.203
verfügbar auf Windows
ja
verfügbar auf Unix
nein
Anwendungstyp
Case-Tool mit Möglichkeit zur ERM- und UML-Modellierung
UI-Sprache
englisch
Dokumentationsumfang
Hilfesystem, White Papers, Online-Dokumentation,
gedrucktes Handbuch
spezielle Anforderungen
keine
Varianten
Physical Architect (für physische Modelle)
Data Architect (für physische und konzeptionelle Modelle)
Object Architect (für physische, konzeptionelle und objektorientiere Modelle)
Developer (für physische und objektorientierte Modelle)
Lizenzmodell
nur arbeitsplatzgebunden
Preise
Physical Architect: 2.790,00 DM
Data Architect: 8.410,00 DM
Object Architect: 14.030,00 DM
Developer: 8.410,00 DM
Umgebungsanforderungen
Pentium 90, 32 MB RAM (64 MB empfohlen), 100 MB
Festplatte
getestet von
Ralf Terdic
Testumgebung
P-III 1000, 128 MB RAM, Windows XP Beta 2
Speicherplatzbedarf
ca. 90 MB
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
64
Empfehlung: ...
H.0.2 grundlegende Bedienung und Oberfläche
Schon auf den ersten Blick merkt man, daß man es mit einem komplexen Tool zu tun hat, das auf
Design-Schnickschnack verzichtet, und Wert auf Funktionalität legt. Auf den ersten Blick ist man
von dem Umfang überwältigt, aber schon bald merkt man, daß eine Einarbeitung kaum notwendig ist, da die angebotenen Funktionen logisch passend gruppiert sind, so daß die Bedienung
im großen Ganzen sehr intuitiv ist. Für die meisten Funktionen, die das Tool anbietet, sind Toolbars vorhanden, die angepaßt werden können.
Die Modellierung erfolgt innerhalb eines Workspace. Hier kann man Modelle erzeugen, und zwar
konzeptionelle, objektorientierte und physische Modelle. Zwischen diesen drei Ebenen ist sowohl
Forward als auch Reverse Engineering möglich, wobei man bei der Synchronisation von Modellen die zu ändernden Objekte und die Änderungsrichtung genau festlegen kann.
Eine mehrstufige Undo-Funktion erleichtert die Bedienung erheblich und fördert die Experimentierbereitschaft.
H.0.3 Arten der Datenbank-Anbindung
PowerDesigner’s Datenbank-Anbindung läßt nicht viel zu wünschen übrig. ODBC-Anbindung in
beide Richtungen und DDL-Generierung bzw. DDL-Einlesen funktionierte tadellos im Test. Synchronisation (Merging) ist möglich. Man kann genau auswählen, welche Datenbank-Objekte synchronisiert werden sollen, hierzu hat man die Möglichkeit, die Richtung der Änderung zu
bestimmen (von DB zu physikalischem Modell oder umgekehrt).
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
65
Empfehlung: ...
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version 7
ja
Oracle
8.1.6
Informix
9.x
Postgres
7
Access
2000
SQL Server
2000
mySQL
3.23
ODBC allgemein
ja
User-Extendable
ja
PowerDesigner unterstützt alle gängigen aktuellen DBMS. Das Geheimnis hinter dieser optimalen Unterstützung ist ein einfaches Format basierend auf XML. Für jedes unterstützte DBMS
muß so eine Datei existieren. Diese Dateien sind einfach zu generieren, wenn man die Spezifikation des SQL-Dialekts genau kennt. Dazu verwendet man den ’DBMS Properties’-Dialog.
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
PowerDesigner unterstützt sowohl ERM als auch UML 1.3 Klassen-, Use Case- und Sequenzdiagramme. Diese zwei Modellierungsarten können flexibel kombiniert werden.
H.0.5.2 attributierte Beziehungen
Attributierte Beziehungen werden nicht direkt unterstützt, jedoch hat man die Möglichkeit, eine
Relation durch eine Entität zu ersetzen. Hierzu steht ein Wizard zur Verfügung.
H.0.5.3 Referentielle Integrität
Im physischen Modell können RI-Constraints als Eigenschaften von Referenzen zwischen Tabellen angegeben werden, und zwar folgende: restrict, cascade, set null, set default. Im gleichen Dialog kann man eine Vorschau des dazugehörenden SQL-Codes betrachten.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
66
Empfehlung: ...
H.0.5.4 Views
Einfache Views können durch Auswahl mit der Maus erstellt werden. Für komplexere Views
kann man den dazugehörenden SQL Code direkt eingeben. Die Berücksichtigung von business
rules ist hierbei auch möglich.
H.0.5.5 Sichtentrennung
Wie schon erwähnt, wird zwischen konzeptionellem, objektorientiertem und physischem Modell
getrennt. Auf konzeptioneller Ebene hat man ERM-Elemente zur Verfügung. Auf OO-Ebene
kann man Klassendiagramme modellieren, sich diese durch Reverse Engineering einer OOSprache generieren lassen, oder umgekehrt, aus Klassendiagrammen Stubs in den unterstützten
Sprachen erzeugen lassen. Vordefinierte Sprachen sind C#, C++, IDL, Java, PowerBuider, Visual
Basic und XML, man kann aber diese Liste erweitern, indem man bei Bedarf zusätzliche Sprachenunterstützung definiert. Diese wird, wie die DBMS-Unterstützung, in XML-Dateien abgespeichert und ist direkt aus PowerDesigner generierbar (’Object Language Properties’-Dialog).
Schließlich kann man beliebig viele physische Modelle aus den oben erwähnten generieren, und
diese durch Views, Trigger, RI etc. anreichern.
H.0.5.6 Anwendungs-Code
Stored Procedures können in physischen Modellen erzeugt werden. Hierzu steht eine kleine Entwicklungsumgebung zur Verfügung, die Syntaxhervorhebung unterstützt und die gängigen Funktionen (avg, max, etc.) anbietet. Bei Bedarf kann man auch einen externen Editor dazu
verwenden. Unterstützt werden jeweils die Sprachen, in denen Stored Procedures in dem jeweiligen DBMS implementiert werden (z.B. C bei DB2). Dieses kann man jedoch anpassen.
Zugriffsklassen können nicht erzeugt werden, jedoch kann man aus dem OO-Modell Stubs in den
unterstützten Sprachen generieren lassen. Im Test wurde brauchbarer Java-Code erzeugt.
Das Reverse Engineering aus kompiliertem Java-Bytecode klappt auch hervorragend. Im Test
wurde die Java Runtime Bibliothek analysiert. PowerDesigner lieferte hierbei sehr gute Ergebnisse trotz der riesigen Menge an Klassen (ein paar Tausend).
H.0.5.7 Validierungsfunktionen
Jede Modellebene in PowerDesigner hat eine Check-Funktion, die sehr flexibel angepaßt werden
kann. Zum Beispiel kann überprüft werden, ob Mehrfachvererbung vorhanden ist, oder ob jede
Entität einen Primärschlüssel besitzt. Die Check-Funktion kann keine Überprüfung auf bestimmte
Normalformen (3NF oder BCNF) vornehmen, sie ist viel feiner gegliedert. Das Ziel ist jedoch das
gleiche, und zwar die Konsistenz der zu erzeugenden Datenbank.
H.0.5.8 erweiterte Modellierung
Im physischen Modell können Trigger für jede Tabelle definiert werden. Hierzu steht die gleiche
Entwicklungsumgebung zur Verfügung, die man auch für Stored Procedures verwendet. Hier sind
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
67
Empfehlung: ...
die vordefinierten Templates von Nutzen, die die Erstellung von Triggern erheblich erleichtern.
Es können Checks und Constraints festgelegt werden, für letztere kann man vorhandene Templates verwenden und neue definieren.
Es können Benutzer erstellt werden, und jeder Tabelle kann ein Benutzer als Eigentümer zugewiesen werden.
H.0.5.9 Import-Möglichkeiten
Unterstützt werden von den bekannteren Formaten das ERX und das MDL-Format. Wie bereits
erwähnt, läßt sich ein DB-Schema aus einer DDL-Datei oder direkt aus der Datenbank über
ODBC einlesen. Reverse Engineering einer XML-Datei wird auch unterstützt.
H.0.5.10 Export-Möglichkeiten
DDL, XML, Datenbank über ODBC
H.0.5.11 Modell-Dokumentation
Flexible Dokumentation ist zu jedem Modelltyp generierbar. Die zur Verfügung stehenden
Sprachen sind englisch und französisch. Unterstützte Formate sind HTML und RTF. Templates
unterstützen die Generierung. Auch Multi-Model-Reports werden unterstützt.
H.0.5.12 weitere Möglichkeiten
Multi-User-Modellierung ist durch ein Repository möglich. Es gibt Repository mit verschiedenen
Sicherheitsstufen: database administrators, data administrators, team leaders und users. Repository ist kein proprietäres Produkt, das Repository-Schema wird automatisch generiert, es muß nur
eine ODBC-DSN angegeben werden. Ausführliche Dokumentation sowohl zum Repository als
auch zum gesamten Tool ist im Hilfesystem vorhanden.
Das Tools besitzt sehr umfangreiche Funktionalität, abhängig vom jeweiligen Modell, das gerade
bearbeitet wird. Unterstützte Sprachen und DBMS sind leicht erweiterbar.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
Sybase PowerDesigner macht insgesamt einen sehr guten Eindruck, und unterstützt alle
geforderten Features.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
68
Empfehlung: ...
H.0.6.2 Bewertung der Einsatzmöglichkeiten
Das Tool ist sehr gut geeignet für alle Einsatzgebiete, sowohl für Vorlesungen und kleine Projekte, als auch für große Forschungsprojekte, da es einerseits die Modellierung im Team durch die
Repository-Funktionalität, andererseits alle notwendigen Features unterstützt.
H.0.6.3 Bewertung der Bedienung
Die Bedienung des Tools ist sehr intuitiv, keine Einarbeitung notwendig, die umfangreiche Funktionalität kann man durch Toolbars in den Griff bekommen, indem man diese auf seine Bedürfnisse anpasst.
H.0.6.4 Stärken
Leicht zu bedienen, sehr umfangreiche Funktionalität, alles funktioniert wie gewünscht, sehr gut
anzupassen.
H.0.6.5 Schwächen
Generierung von DB-Zugriffsklassen wird nicht unterstützt. Lizenzierungsmodell ist nicht flexibel (weder Mehrbenutzerlizenzen noch Ermäßigung für nichtkommerzielle Zwecke verfügbar).
Nur unter Windows verfügbar.
H.0.6.6 Bewertung der Einsatzfähigkeit
Sybase PowerDesigner ist für den Einsatz zur Modellierung von Datenbanken sehr gut geeignet,
es unterstützt die meisten Features, die in der Modellierung benötigt werden, ist sehr anpassungsfähig und leicht zu bedienen.
B.9 QDesigner (Quest)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Die getestete Version des QDesigners war identisch mit dem getesteten Produkt PowerDesigner
von Sybase, anscheinend wurde lediglich der Startbildschirm geändert. QDesigner ist jedoch um
einiges teurer als PowerDesigner, da im Preis ein Jahr Support inbegriffen ist.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
69
Empfehlung: ...
B.10 Rose (Rational)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Rational
Produktname
Rose Enterprise Edition
URL
www.rational.com
getestete Version
2001 (inkl. Datamodeler Version 2.0)
verfügbar auf Windows
ja
verfügbar auf Unix
Anwendungstyp
Case-Tool mit ERM-Addin
UI-Sprache
Englisch,
Dokumentationsumfang
<z.B. online-Doku, gedruckt, Modellierungshilfen, ...>
spezielle Anforderungen
für den Einsatz von Floating-Lizenzen ist ein dedizierter
Lizenzserver nötig
Varianten
Lizenzmodell
Node-Locked-Lizenzen und Floating-Lizenzen vrfügbar
Preise
Umgebungsanforderungen
min. Pentium 300MHz, 128MB RAM, 500MB HDD
empf. Pentium 600MHz, 256MB RAM, 500MB HDD
getestet von
Michael Wenig
Testumgebung
P-III 800, 512MB RAM, Windows NT 4.0 (SP6a)
Speicherplatzbedarf
nach dem Start: ca. 45MB RAM
Festplatte: 366MB (Trial-Version)
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
70
Empfehlung: ...
H.0.2 grundlegende Bedienung und Oberfläche
Nach einer relativ langen Startdauer, welche allerdings durch den Einsatz einer Testversion
begründet sein könnte, bietet sich dem Anwender eine übersichtliche Oberfläche. Ein ObjektBrowser bietet eine Übersicht über alle Diagramme, welche in sog. Views unterteilt sind (UseCase-View, Logical-View, Component-View, Deployment-View und Model-Properties)
Der Diagramm-Editor setzt sich zusammen aus einem Diagramm-spezifischen Toolbar, welche
vom Benutzer angepasst werden kann, und einer grafischen Editier-Oberfläche.
In das aktuelle Diagramm können Elemente per Mausclick eingefügt werden, welche dann durch
eine Unzahl an Dialogen mit den gewünschten Daten gefüllt werden können. Die Bearbeitung ist
allerdings zum größten Teil nur per Point-and-Click möglich, wodurch insbesondere schnelle
Ketten-Bearbeitungen (wie z.B. das Anlegen mehrerer Spalten) eine exzessive und zeitaufwendige Nutzung von Maus und Tastatur bedingen.
Beispielsweise erfordert die Anlage einer neuen Spalte folgende Schritte:
34.Maus-Click auf ein Tool-Icon (neue Spalte)
35.Maus-Click auf ein Tool-Icon (Spalten-Eigenschaften)
36.Eingabe des Spaltennamens
37.Wechseln einer Registerkarte
38.Auswahl eines Datentyps
39.evtl. Eingabe von Check-Constraints
Zu jedem Element kann ein Kommentar angegeben werden.
Versehentliche Fehler können durch eine Undo-Funktion korrigiert werden. Allerdings erlaubt
diese nur die Zurücknahme des letzten Schrittes, wobei sich diese auf optische Verschiebungen
beschränkt.
H.0.3 Arten der Datenbank-Anbindung
Für den Import sind Datenbanken entweder direkt oder über existierende DDL-Statements angebunden.
Für den Export kann wahlweise nur eine DDL-Datei erzeugt werden, oder diese zusätzlich
automatisch ausgeführt werden.
Für die Generierung sind diverse Einstellungen möglich. Insbesondere kann gewählt werden
welche der folgende Teilaspekte in der erzeugten DDL enthalten sein sollen:
• Comments
• Tables
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
71
•
•
•
•
•
•
•
•
Empfehlung: ...
Indexes
Stored Procedures
Views
Triggers
Tablespaces
Fully qualified names (Schema-Namen enthalten)
Quoted Identifiers
Drop-Statements
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version 7
ja (Versionen 5.x, 6.x und 7.x,
sowie 5.x und 6.x auf OS/390)
Oracle
ja (Version 7.x und 8.x)
Informix
nein
Postgres
nein
Access
nein
SQL-Server
ja (Versionen 6.x, 7.x und 2000.x)
mySQL
nein
ODBC allgemein
Ansi-SQL 92
User-Extendable
nein
sonstige
Sybase Adaptive Server 12.x
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
Rose unterstützt alle UML-Diagramme, sowie ERM. Die Unterstützung der relevanten Diagramme ist vollständig.
Der vorgesehene Weg ist ausgehend von einem Klassendiagramm ein physisches Schema zu erstellen und aus diesem dann ein komponentenorientiertes Verteilungsschema zu erstellen. Dieses
kann dann schließlich in Datenbanken exportiert werden.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
72
Empfehlung: ...
H.0.5.2 attributierte Beziehungen
Attributierte Beziehungen werden nicht unterstützt - diese müssen manuell mittels eigener
Entitäten modelliert werden. Dadurch ist natürlich eine vollständige Kontrolle über Tabellen- und
Spaltennamen vorhanden.
Im Klassendiagramm können zwar attributierte Beziehungen angelegt werden, jedoch wurden
diese im Test nicht korrekt im ERM-Diagramm erstellt.
H.0.5.3 Referentielle Integrität
Aspekte der referentiellen Integrität können vollständig angegeben werden, und wurden im Test
auch korrekt in DB/2-DDL-Statements umgesetzt.
H.0.5.4 Views
Views können beliebig erzeugt werden. Dabei kann eine beliebige Where-Clause angegegeben
werden, welche die in der View enthaltenen Daten filtert.
H.0.5.5 Sichtentrennung
Eine explizite Sichtentrennung wird nicht vorgenommen. Stattdessen erfolgt die Modellierung
auf Schema-Ebene, wobei pro Schema die Zielumgebung ausgewählt wird.
H.0.5.6 Anwendungs-Code
Stored-Procedures können angelegt werden in den Sprachen
•
•
•
•
•
•
Assembler
C
Cobol
java
PL/1
SQL
DB-Zugriffsschichten können nicht automatisch erzeugt werden - Hierfür müsste ein externes
Produkt verwendet werden.
H.0.5.7 Validierungsfunktionen
Validierungsfunktionen sind nicht vorhanden.
H.0.5.8 erweiterte Modellierung
Folgende erweiterten Funktionalitäten werden bereitgestellt:
• Trigger
• constraints
• Clustering-Informationen
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
73
Empfehlung: ...
• Domänen
Benutzer und deren Rechte können nicht modelliert werden.
H.0.5.9 Import-Möglichkeiten
Der Versuch des Imports einer existierenden DB/2-Datenbank erfolgte problemlos. Nach
Auswahl der gewünschten Datenbank, Eingabe von User/Passwort konnte die zu importierende
Datenbank ausgewählt werden und dann aus den vorhandenen Schemata die zu importierenden
ausgewählt werden.
Der Import (in Rose “Reverse-Engineer” genannt) kann sowohl auf basierenden Datenbanken, als
auch mittels existierender DDL-Skripte durchgeführt werden. Dies erfolgte im Test problemlos.
MDL-Dateien werden als Standard-Speicherstruktur verwendet und können daher natürlich auch
gelesen werden.
H.0.5.10 Export-Möglichkeiten
Als Export-Möglichkeiten kommen MDL-Files als Standard-Speicherstruktur in Frage.
Die DDLs der Datenmodelle können in Text-Dateien gespeichert werden.
H.0.5.11 Modell-Dokumentation
Die Dokumentation kann mittels eines Publishers in HTML-Form erstellt werden. Für die Navigation wird ein Java-Apllt eingesetzt, wodurch der Client-Browser java-fähig sein muss.
Ferner kann eine Dokumentation ausgedruckt werden, wobei diese aber nur dürftig beeinflusst
werden kann.
H.0.5.12 weitere Möglichkeiten
Rose erlaubt leider nicht die Erweiterung durch eigene Komponenten, wodurch eventuelle Bugs
und Schwächen nur durch den Hersteller ausgeräumt werden können.
Da es sich bei dem Tool um ein erweitertes CaseTool handelt, können alle UML-Konstrukte wie
beispielsweise UseCases in eigenen Diagrammen definiert werden. Das Tool vermischt jedoch
ERM-Konstrukte mit UML-Diagrammen. So wird beispielsweise in einem Klassendiagramm
beim Anlegen einer neuen Klassen, deren Name mit dem einer Tabelle identisch ist, standardmäßig dann die Tabelle eingefügt, obwohl Tabellen in Klassendiagrammen nicht zulässig sind.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
74
Empfehlung: ...
H.0.6.1 Gesamteindruck
Das Tool bietet eine umfassende Unterstützung der gesamten Entwicklung von Anwendungen.
Aufgrund der umständlichen Bedienung wird jedoch eine effiziente Nutzung in Frage gestellt. Da
keine schnellen Eingabemöglichkeiten existieren, gleichzeitig die Nutzung nur der relevanten
Funktionen in Verbindung mit anderen Tools pratisch nicht möglich ist, ergeben sich keine sinnvollen Einsatzmöglichkeiten.
H.0.6.2 Bewertung der Einsatzmöglichkeiten
Aufgrund der umständlichen, zeitaufwendigen Bedienung eignet sich das Tool maximal für kleinere Projekte.
Für Vorlesungen eignet sich das Tool aufgrund der umständlichen, zeitaufwendigen Bedienung
gar nicht.
H.0.6.3 Bewertung der Bedienung
Wie bereits mehrfach angesprochen, ist die Bedienung der größte Schwachpunkt des Tools
H.0.6.4 Stärken
Rose bietet eine Vielzahl an Funktionen und Möglichkeiten. So erfüllt Rose fast alle geforderten
Eigenschaften, wobei die elementar wichtigen Eigenschaften alle erfüllt werden.
H.0.6.5 Schwächen
Rational Rose erschlägt den Anwender mit einer Fülle von Funktionen. Die verschiedenen unterstützten Programmiersprachen treten an vielen Stellen zutage.
Für eine sinnvolle Bedienung ist ein relativ hoher Einarbeitungsaufwand erforderlich.
Die Bedienung ist extrem umständlich und zeitaufwendig, aber auch logisch strukturiert. Für
einen sinnvollen praktischen Einsatz ist die Bedienung völlig falsch strukturiert. Die vielen
Dialogfelder verbrauchen derart viel Zeit, so dass ein geübter Entwickler wahrscheinlich ohne
dieses Tool schneller wäre. Dadurch entsteht die Gefahr, dass lediglich die Hälfte der Entwicklung über das CaseTool erfolgt und damit keine verwertbare Dokumentation entsteht. Durch die
ausschließliche Repository-Speicherung von Rose ist eine parallele Benutzung anderer Tools
praktisch nicht möglich. Dies stellt jedoch keinen sinnvollen Ansatz dar.
Die Nutzung einer Versionsverwaltung ist durch die Repository-Speicherung auf das RationalProdukt “ClearCase” beschränkt.
Insgesamt legt Rose derart große Beschränkungen auf das Tool-Umfeld, so dass der Anwender
praktisch gezwungen ist, ausschließlich Rational-Produkte einzusetzen.
Wie bei allen Rational-Produkten fällt auch hier auf, dass Rose nach rein logischen und wissenschaftlichen Belangen aufgebaut und der praktische Einsatz völlig ignoriert wurde.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
75
Empfehlung: ...
H.0.6.6 Bewertung der Einsatzfähigkeit
Trotz des großen Funktionsumfangs ist Rose aufgrund seiner schlechten Bedienung praktisch
nicht für den Einsatz geeignet. Insbesondere für Studenten ist ein Einsatz aufgrund der großen
Einarbeitungszeit nicht sinnvoll.
B.11 System Architect 2001 (Popkin Software and Systems
Inc.)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
76
Empfehlung: ...
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Popkin Software and Systems Inc.
Produktname
System Architect 2001
URL
http://www.popkin.com/products/sa2001/
systemarchitect.htm
getestete Version
8.1.23
verfügbar auf Windows
ja
verfügbar auf Unix
nein
Anwendungstyp
Enterprise Modeling Tool (unterstützt unter anderem:
Simulation, UML-Modellierung, ERM-Datenmodellierung, Structured Analysis + Design etc.)
UI-Sprache
englisch
Dokumentationsumfang
umfangreiches Hilfesystem, Online-Dokumentation, User
Guide steht zum Download bereit, auch gedruckte Dokumentation kann bestellt werden
spezielle Anforderungen
keine
Varianten
keine
Lizenzmodell
arbeitsplatzgebunden (mit Dongle) und Floating License
Preise
keine Angaben
Umgebungsanforderungen
keine Angaben
getestet von
Ralf Terdic
Testumgebung
P-III 1000, 128 MB RAM, Windows XP Beta 2
Speicherplatzbedarf
ca. 60 MB
H.0.2 grundlegende Bedienung und Oberfläche
System Architect ist ein sehr komplexes Tool, primär zur Unternehmensmodellierung gedacht.
Die Datenmodellierung deckt neben Geschäftsprozessmodellierung, objektorientierter Modellierung mittels UML und strukturierter Analyse und Design nur einen kleinen Teil der sehr
umfangreichen Funktionalität des Tools. Dieser riesige Umfang führt dazu, daß ein effizienter
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
77
Empfehlung: ...
Einsatz des Tools ohne eine Einarbeitungsphase gar nicht möglich ist. Eine komplette Evaluierung des Tools würde aus diesen Gründen den zeitlichen Rahmen dieser Fachstudie bei weitem
sprengen. Daher beruhen die im folgenden beschriebenen Aspekte entweder auf ersten Eindrücken oder auf Angaben des Herstellers.
Die Bedienoberfläche ist nicht besonders intuitiv, man verliert sich leicht in den schlecht strukturierten Menüs. Eine Undo-Funktion ist zwar vorhanden, sie funktioniert aber nicht mit allen
Änderungen. Löscht man zum Beispiel eine Entität oder eine Relation, so kann man dieses nicht
mehr rückgängig machen.
Das Hilfesystem ist nicht besonders hilfreich, insbesondere stört die etwas unlogische Gliederung.
Ferner können neue Toolbars erstellt und angepaßt werden.
Ein Modell kann von mehreren Benutzern bearbeitet werden, da das Versionierungssystem PVCS
integriert ist.
H.0.3 Arten der Datenbank-Anbindung
Eine Datenbankanbindung ist direkt über die ODBC-Schnittstelle oder über DDL-Generierung
bzw. -Parsen möglich. Reverse Engineering und DB-Generierung funktionierten zufriedenstellend im Test, sowohl über ODBC als auch über DDL.
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version 7
nein, nur Version 5
Oracle
ja, Version 8
Informix
ja, Version 7
Postgres
nein
Access
ja
SQL-Server
ja, Version 7
mySQL
nein
ODBC allgemein
ja
User-Extendable
nein
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
78
Empfehlung: ...
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
UML und ERM werden unterstützt. Aus UML-Klassendiagrammen können automatisch ER-Diagramme erstellt werden und umgekehrt.
H.0.5.2 attributierte Beziehungen
Attributierte Beziehungen sind bei m:n-Kardinalität möglich.
H.0.5.3 Referentielle Integrität
RI-Aktionen werden theoretisch laut Hilfesystem unterstützt, im Test konnten leider keine definiert werden, da der dazugehörige Dialog nicht gefunden werden konnte.
H.0.5.4 Views
System Architect unterstützt keine Erstellung von Views.
H.0.5.5 Sichtentrennung
Es wird unterschieden zwischen ER- und physischem Datenmodell. Eine Synchronisierung
zwischen diesen zwei Modelltypen ist jedoch nicht möglich. Ferner kann man aus UML-Klassendiagrammen ER-Modelle erzeugen und umgekehrt. Hier fehlt jedoch auch die Möglichkeit zur
Synchronisation, so daß bei Änderungen das zu synchronisierende Modell neu erstellt werden
muß.
H.0.5.6 Anwendungs-Code
Es können weder Stored Procedures noch Datenbankzugriffsschichten erzeugt werden.
H.0.5.7 Validierungsfunktionen
Es wird nur auf einige Kriterien der Normalformen geprüft. Scheinbar kann man diese Kriterien
nicht auswählen.
H.0.5.8 erweiterte Modellierung
Trigger sind, wie RI-Aktionen auch, zumindest theoretisch möglich, im Test konnten jedoch
keine erzeugt werden, da der dazu benötigte Dialog nicht gefunden wurde.
H.0.5.9 Import-Möglichkeiten
Der Import bechränkt sich auf folgende Möglichkeiten: XML, DDL, DB über ODBC
H.0.5.10 Export-Möglichkeiten
XML, DDL, DB über ODBC
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
79
Empfehlung: ...
H.0.5.11 Modell-Dokumentation
Es können Modell-Dokumentationen erstellt werden, und zwar in Word-Format (dazu wird Word
benötigt!) und als HTML-Dokumente. Die Formatierung läßt jedoch zu wünschen übrig.
H.0.5.12 weitere Möglichkeiten
System Architect unterstützt neben der Datenmodellierung Features zur Geschäftsprozessmodellierung, objektorientierte Modellierung mittels UML und strukturierte Analyse und Design. Diese
werden jedoch nicht näher betrachtet, da der direkte Zusammenhang zur Datenmodellierung fehlt.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
System Architect ist ein sehr umfangreiches Tool, das aber nicht speziell auf Datenmodellierung
ausgerichtet ist. Dementsprechend bietet es nur beschränkten Komfort und Funktionalität beim
Versuch der Bewältigung dieser Aufgabe.
H.0.6.2 Bewertung der Einsatzmöglichkeiten
System Architect ist bedingt geeignet für große Projekte, die sowohl auf UML-Diagramme (Klassen-, Use Case- und Sequenz-Diagramme) als auch auf ER-Diagramme angewiesen sind. Der
Einarbeitungsaufwand ist jedoch nicht zu vernachlässigen. Aus diesem Grund kommt der Einsatz
in der Vorlesung, in Übubngen und in Praktika gar nicht in Frage.
H.0.6.3 Bewertung der Bedienung
Das Tool ist schwierig zu bedienen, ohne Einarbeitung fast unmöglich. Es ist nicht auf Datenmodellierung zugeschnitten.
H.0.6.4 Stärken
System Architect bietet umfangreiche Funktionalität (Geschäftsprozessmodellierung, objektorientierte Modellierung mittels UML, strukturierte Analyse und Design), der Umfang der Möglichkeiten für die Datenmodellierung ist jedoch im Vergleich zu anderen Tools eher bescheiden.
H.0.6.5 Schwächen
Nicht ausreichende Funktionalität, mühsame Bedienung.
H.0.6.6 Bewertung der Einsatzfähigkeit
Angesichts der erwähnten Nachteile, mit denen man bei der Datenmodellierung mit System
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
80
Empfehlung: ...
Architect 2001 konfrontiert wird, ist das Tool für diese Aufgabe nicht geeignet.
B.12 Together (Togethersoft)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Togethersoft
Produktname
Together Control Center
URL
www.togethersoft.com
getestete Version
5.02
verfügbar auf Windows
ja
verfügbar auf Unix
ja
Anwendungstyp
Case-Tool
UI-Sprache
Englisch
Dokumentationsumfang
Online-Doku
spezielle Anforderungen
für den Einsatz von Floating-Lizenzen ist ein dedizierter
Lizenzserver nötig
Varianten
Lizenzmodell
Node-Locked-Lizenzen und Floating-Lizenzen vrfügbar
Preise
kostenfrei für universitäre/wissenschaftliche Anwendung
Umgebungsanforderungen
<angegebene Minimalanforderungen>
getestet von
Michael Wenig
Testumgebung
P-III 800, 512MB RAM, Windows NT 4.0 (SP6a)
Speicherplatzbedarf
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
81
Empfehlung: ...
H.0.2 grundlegende Bedienung und Oberfläche
Die Oberfläche ist in drei Bereiche unterteilt:
• Explorer-Bereich
• Diagramm-Bereich
• Source-Code-Bereich
Die Oberfläche lässt sich per Point-and-Click bedienen, jede öfter benötigte Funktion ist ebenso
über einen Shortcut erreichbar, so dass eine Bedienung praktisch ohne Maus möglich ist. Durch
die Single-Source-Technologie, können Änderungen in Source-Code-bezogenen Diagrammen
wahlweise über die Oberfläche oder manuell direkt im Source-Code vorgenommen werden. Die
Änderungen im Source-Code können entweder mittels der eingebauten Entwicklungsumgebung
oder extern mittels einer beliebigen Umgebung, welche direkt auf den Source-Dateien arbeitet,
vorgenommen werden.
Die Bedienung ist auf Basis von verschiedenen Diagrammen aufgebaut. In die Projektstruktur
können die verschiedenen UML-Diagramme, sowie Together-eigene Diagramme, wie ERM,
erzeugt werden.
Sehr positiv fällt der Umstand auf, dass eigene Diagramme, Funktionen und Elemente erzeugt
werden können, so dass praktisch für jedes Einsatzgebiet oder mangelhafte Implementierung
eigene Funktionalitäten eingebaut werden können.
Die Anzahl der Dialogfelder ist auf ein sinnvolles Minimum reduziert. Für die Eingabe weiterer
Informationen existiert ein zentraler Dialog, welcher automatisch bei Auswahl eines anderen Diagrammelementes dessen Eigenschaften bearbeitet. Dies hat zur Folge, dass dieser Dialog nicht
geschlossen werden muss.
Für den Fall von Bedienungsfehlern ist eine mehrstufige Undo- und Redo-Funktion eingebaut.
H.0.3 Arten der Datenbank-Anbindung
Der Import ist nur aus bestehenden Datenbanken per Abfrage möglich.
Exportiert werden können DDL-Skripte, welche auch automatisch ausgeführt werden können.
Eine manuelle Nachbearbeitung ist vor der Ausführung möglich.
Existierende Tabellen werden über DROP-TABLE-Statements vor der Neuanlage gelöscht.
Die Verbindung zur Datenbank wird mittels JDBC-Treibern vorgenommen, wobei weitere Datenbanken vom Benutzer hinzugefügt werden können. Einzige Voraussetzung ist die Existenz eines
entsprechenden JDBC-Treibers
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
82
Empfehlung: ...
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2
ja, Version 6.1
Oracle
ja Version 7.3x, 8.x
Informix
nein
Postgres
nein
Access
ja Version 97 + 2000
SQL-Server
ja, Version 7.0
mySQL
ja, Version 3.23
ODBC allgemein
ja
User-Extendable
ja
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
H.0.5.1 unterstützte Modelle und deren Umfang
Das Tool unterstützt alle UML-Diagramme, sowie desweiteren einige in der Entwicklung
benötigte Together-spezifische Diagramme, darunter auch ER.
Durch eine umfangreiche API ist die Definition eigener Diagramme, erweiterter Eigenschaften,
sowie Diagrammelementen möglich.
Standardmäßig können im ER-Diagramm Entitäten, identifizierende und nicht-identifzierende
Verweise, sowie n:m-Beziehungen modelliert werden. Wie jedes UML-Diagramm, so können
auch im ER-Diagramm Notizen eingefügt werden und mit Entitäten optisch verbunden werden.
Attributierte Beziehungen werden nicht unterstützt, könnten jedoch als benutzerspezifische
Erweiterungen eingebaut werden.
H.0.5.2 Referentielle Integrität
RI wird grundlegend unterstützt, jedoch können hierbei keine Aspekte wie beispielsweise deleteand-update-propagation angegeben werden.
H.0.5.3 Views
Views werden nicht unterstützt.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
83
Empfehlung: ...
H.0.5.4 Sichtentrennung
Eine explizite Trennung der Schichten ist nicht vorhanden, jedoch werden die Eigenschaften grob
nach logisch und physisch eingeteilt. Beim Export der Datenbank kann jedoch das Zielsystem
ausgewählt werden, wodurch mehrere verschiedene DBMS parallel verwendet werden können.
H.0.5.5 Anwendungs-Code
Stored-Procedures können nicht angegeben werden.
H.0.5.6 Validierungsfunktionen
Validierungsfunktionen stehen nicht zur Verfügung
H.0.5.7 erweiterte Modellierung
Erweiterte Datenbank-Elemente, wie Trigger, Domänen oder Benutzerrechte können nicht modelliert werden.
H.0.5.8 Import-Möglichkeiten
Ein Import existierender Datenbanken wird angeboten, jedoch konnte dies im Test mit DB/2 nicht
durchgeführt werden, da nach Auswahl eines Schemas die dort enthaltenen Tabellen nicht
angezeigt wurden.
Laut Dokumentation erfolgt der Import in folgenden Schritten:
40.Auswahl der Datenbank und Angabe von Verbindungsinformationen
41.Sofern zutreffend, Auswahl des Schemas und der Tabellen
42.Angabe eines Diagrammnamens
Der Versuch, eine Access-Datenbank zu importieren, funktionierte problemlos.
Als weitere Import-Möglichkeiten werden XMI, MDL sowie Java und C++-Source-Code angeboten. Beim Source-Code genügt eine Kopie ins Projektverzeichnis.
Der Import funktioniert soweit problemlos.
H.0.5.9 Export-Möglichkeiten
Für den Export werden in Bezug auf Datenbanken Textdateien mit DDL-Statements angeboten.
Wahlweise können diese auch automatisch ausgeführt werden. bei Schema-fähigen Datenbanken
werden allerdings die Schema-Namen nur bei der automatischen Ausführung eingesetzt - ansonsten wird jeweils als Ersatz “%SCHEMA_NAME%” eingesetzt
Beim Export (mit Ausführung) wird leider nicht überprüft, ob die entsprechende Tabelle bereits
vorhanden ist. Stattdessen werden grundsätzlich DROP TABLE-Statements eingefügt, welche bei
neuen Datenbanken/Tabellen mittels der manuellen Nachbearbeitung entfernt werden müssen.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
84
Empfehlung: ...
H.0.5.10 Modell-Dokumentation
Zu jedem Modell können verschiedene Modell-spezifische Eigenschaften eingegeben werden,
sowie ein freier Dokumentationstext und Verweise auf andere Diagramme und externe Dateien/
URLs.
Aus diesen Informationen kann jederzeit eine HTML-basierte oder RTF-basierte Dokumentation
erzeugt werden.
H.0.5.11 weitere Möglichkeiten
Da es sich bei dem Tool um ein erweitertes CaseTool handelt, können alle UML-Kosntrukte wie
beispielsweise UseCases in eigenen Diagrammen definiert werden. Im Sinne einer Traceability in
Bezug auf die Anforderungen können Elemente der ER-Diagramme mit Elementen anderer Diagramme logisch verknüpft werden, so dass eine nachvollziehbare Dokumentation möglich ist.
Das Tool kann beliebig erweitert werden, um eigene Diagramme, eigene Eigenschaften und
eigene Funktionen. Die existierende Darstellung kann ebenso beeinflusst werden, wie auch existierende Eigenschaften.
Die Definition eigener Erweiterungen erfolgt mittels der mitgelieferten Java-API. Diese ist gut
dokumentiert. Erweiterungen werden durch Entwicklung eigener Java-Klassen erzeugt.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
Together zeigt sich als sehr gut intuitiv bedienbares Werkzeug, welches praktisch alle für die
Anwendungs-Entwicklung bis hin zu EJB/J2EE-Anwendungen nötigen Modellierungs- und
Dokumentations-Funktionalitäten bereitstellt. Allerdings ist die DB-Modellierung nur sehr
schmal ausgeführt.
H.0.6.2 Bewertung der Einsatzmöglichkeiten
Für die Entwicklung ist Together für alle Vorlesungen, Übungen, Praktika und sonstiger Arbeiten
gut geeignet. Insbesondere bietet es den Vorteil, dass alle Schritte im Projektverlauf mit einem
einzigen Produkt durchgeführt werden können, dies aber nicht erzwingen.
Soll das Tool für die Datenmodellierung eingesetzt werden, so muss dieses entsprechend erweitert werden, beispielsweise im Rahmen einer Studien-Arbeit oder eines weiteren Fachpraktikums.
H.0.6.3 Bewertung der Bedienung
Der Einarbeitunsaufwand ist aufgrund der durchgängig intuitiven Bedienung sehr gering.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
85
Empfehlung: ...
H.0.6.4 Stärken
Die Stärken liegen insbesondere in der Bedienung, der Single-Source-Technologie und der
Erweiterbarkeit durch den Benutzer.
Da Together selbst in Java geschrieben ist, ist ein Einsatz auf Unix und Windows gleichermaßen
möglich.
Beliebige Versionsverwaltungssysteme können eingebunden werden.
Darüberhinaus ist Together für studentische und universitäre Anwendungen kostenfrei.
H.0.6.5 Schwächen
Die mangelhafte Unterstützung der Datenmodellierung ist eine Schwäche, wodurch dieses Tool
nicht direkt einsetzbar ist.
Für den Einsatz von Together sollte der Rechner großzügig mit Hauptspeicher ausgestattet sein.
Als Minimum sollten 256 MB vorgesehen werden, so dass eine ruckel- und wartezeitenfreie
Bedienung möglich ist.
Allerdings hat sich die in Together 4 vorhandene starke Abhängigkeit von der Hauptspeichergröße in der Version 5 stark verringert. So war bei 512MB Hauptspeicher ein Arbeiten mit parallel geöffneten Together 4, Together 5, Rational Rose, Framemaker, WinCVS und Netscape, ohne
Ruckeln möglich.
H.0.6.6 Bewertung der Einsatzfähigkeit
In unveränderter Form ist Together für die Datenmodellierung nicht einsetzbar. Jedoch bietet es
eine sehr gute Basis insbesondere in Bezug auf die Bedienung.
Werden Erweiterungen vorgenommen, so ist auch die Datenmodellierung mit den geforderten
Funktionalitäten möglich.
B.13 Visible Analyst Database Engineer (Visible Systems
Corp.)
Dieses Kapitel beschreibt die Eigenschaften des o.g. Tools in Bezug auf das Einsatzgebiet zur
Modellierung von Datenbanken. Aus Übersichtsgründen werden aufgefallene Mängel oder Einschränkungen teilweise gesammelt am Ende des jeweiligen Abschnittes oder am Ende dieses
Kapitels beschrieben. Die Existenz von Mängeln oder Einschränkungen werden durch Klammern
gekennzeichnet.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
86
Empfehlung: ...
H.0.1 Produktübersicht
Dieses Kapitel soll zunächst einen kurzen Überblick über das Tool und dessen Fähigkeiten geben.
Hersteller
Visible Systems Corp.
Produktname
Visible Analyst Database Engineer
URL
http://www.visible.com/dataapp/dappprods/vadbe.htm
getestete Version
7.5.4
verfügbar auf Windows
ja
verfügbar auf Unix
nein
Anwendungstyp
ERM-Tool
UI-Sprache
englisch
Dokumentationsumfang
Hilfesystem, gedruckte Dokumentation
spezielle Anforderungen
keine
Varianten
Commercial Edition und Student bzw. University Edition
(letztere sind in der Funktionalität beschänkt)
Lizenzmodell
single user bzw. multiuser
Preise
keine Angaben
Umgebungsanforderungen
486, Windows, 8 MB RAM, 10 MB Festplattenplatz
getestet von
Ralf Terdic
Testumgebung
P-III 1000, 128 MB RAM, Windows XP Beta 2
Speicherplatzbedarf
ca. 13 MB
H.0.2 grundlegende Bedienung und Oberfläche
Im Test ließ sich Visible Analyst sehr mühsam bedienen. Schon allein die Modellierung eines
kleinen Datenbankschemas mit drei Entitäten scheiterte an dem sehr eigentümlichen Bedienkonzept.
Im linken Teil der Bedienoberfläche befindet sich, wie bei den meisten Tools dieser Art, ein
Object Browser, dessen Aufgabe es ist, das Auffinden und die Bearbeitung von Elementen zu
erleichtern. Leider bietet der Object Browser nur bescheidene Funktionalität, und dessen Bedienung ist nicht sehr intuitiv. Die Funktionalität ist meistens in den Menüs versteckt, die Toolbars
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
87
Empfehlung: ...
lassen sich nicht anpassen. Die Struktur der Menüs wirkt insgesamt etwas chaotisch.
Eine Trennung zwischen logischem und physischem Modell ist nicht zu erkennen, was die Modellierung sehr erschwert und die Flexibilität des Tools erheblich einschränkt.
Eine Undo-Funktion ist zwar im Menü vorhanden, im Test war sie jedoch dauernd deaktiviert, so
daß sie nicht genutzt werden konnte. Aus dem Hilfesystem ist ersichtlich, daß es sich hierbei nicht
um eine Undo-Funktion in eigentlichem Sinne handelt, so daß man sich zum Beispiel beim
Löschen eines Elements auf diese nicht verlassen kann.
Insgesamt läßt sich die Logik, auf der die Bedienung des Tools basiert, schwer erkennen, so daß
eine geraume Einarbeitungszeit vor dem Einsatz des Tools eingeplant werden muß.
H.0.3 Arten der Datenbank-Anbindung
Das Reverse Engineering hat sowohl über ODBC-Schnittstelle als auch aus einer DDL-Datei
zufriedenstellend funktioniert. Hingegen ließ sich aus dem eingelesenen Schema nur durch mühsame Änderungen ein DDL-Skript generieren. Ebenso gab es Schwierigkeiten mit der direkten
Erstellung einer Datenbank über ODBC.
H.0.4 angebundene Datenbanken
Datenbank
Anbindung
DB/2 Version 7
ja
Oracle
ja
Informix
ja
Postgres
ja
Access
ja
SQL-Server
ja
mySQL
nein
ODBC allgemein
ja
User-Extendable
ja
H.0.5 Modellierung
In diesem Kapitel werden die Eigenschaften des Tools in Bezug auf die Modellierung und deren
Möglichkeiten untersucht
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
88
Empfehlung: ...
H.0.5.1 unterstützte Modelle und deren Umfang
Visible Analyst unterstützt die Modellierung von ERM-Diagrammen. Es werden verschiedene
Typen von Relationen unterstützt, und auch deren Kardinalität kann man genau angeben. Jedoch
ist die Modellierung aus den oben genannten Gründen sehr mühsam.
H.0.5.2 attributierte Beziehungen
Attributierte Beziehungen werden nicht unterstützt.
H.0.5.3 Referentielle Integrität
Für jede Relation kann man folgende RI-Aktionen definieren: cascade, set null und set default.
Restrict scheint zu fehlen.
H.0.5.4 Views
Es können auf flexible Art und Weise Views definiert werden, sowohl durch Auswahl von Tabellen und Spalten, als auch durch Angabe einer SQL-Query.
H.0.5.5 Sichtentrennung
Es ist keine strikte Trennung zwischen logischem und physischem Modell erkennbar. Dies
erschwert die Modellierung erheblich und macht das Tool unflexibel.
H.0.5.6 Anwendungs-Code
Die Bearbeitung von Anwendungs-Code (z.B. Stored Procedures) oder die Erzeugung einer DBZugriffsschicht wird von Visible Analyst nicht unterstützt.
H.0.5.7 Validierungsfunktionen
Es gibt die Möglichkeit eines einfachen Syntax-Checks, bei dem man auch eine Option zur Überprüfung auf Normalformen angeben kann. Im Test hat diese Option zufriedenstellend funktioniert.
H.0.5.8 erweiterte Modellierung
Visible Analyst unterstützt die Erstellung und Bearbeitung von Triggern und Constraint Checks,
wobei für diese Aufgabe kaum mehr als ein einfacher Editor zur Verfügung gestellt wird.
H.0.5.9 Import-Möglichkeiten
Reverse Engineering aus DB über ODBC, DDL und XML. Ferner werden noch das ERwin- und
das PowerBuilder-Format unterstützt.
H.0.5.10 Export-Möglichkeiten
DDL, direkte DB-Änderung über ODBC, ferner: ERwin, PowerBuilder
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
89
Empfehlung: ...
H.0.5.11 Modell-Dokumentation
Die Modelldokumentation kann nicht in einem der gewünschten Formate abgespeichert werden,
sie kann lediglich ausgedruckt werden. Es gibt eine Option, die eine Vorschau in HTML-Format
anbietet, diese sieht aber eher unprofessionell aus.
H.0.6 Bewertung
In diesem Kapitel werden die einzelnen Funktionalitäten des Tools in ihrer Gesamtheit bewertet.
Ebenso werden die besonderen Features, sowie auch eventuelle Fehler oder Misstände nochmals
zusammengefasst. Durch seine Natur ist dieses Kapitel teilweise sehr subjektiv!
H.0.6.1 Gesamteindruck
Insgesamt macht das Tool keinen besonders guten Eindruck, weder was die ziemlich magere
Funktionalität betrifft, noch was die wenig intuitive, manchmal unlogische Bedienung angeht.
H.0.6.2 Bewertung der Einsatzmöglichkeiten
Angesichts der bereits erwähnten negativen Aspekte des Tools ist es weder für kleine Projekte,
noch für Studienarbeiten oder Forschungsprojekte geeignet.
H.0.6.3 Bewertung der Bedienung
Die Bedienung des Tools ist schwierig, nicht intuitiv, und manchmal unlogisch.
H.0.6.4 Stärken
Das Tool verbraucht wenig Hardware-Ressourcen. Im Test verhielt es sich stabil.
H.0.6.5 Schwächen
Der mangelhafte Bedienungs-Komfort, wenige Schnittstellen, kaum erweiterbar.
H.0.6.6 Bewertung der Einsatzfähigkeit
Angesichts der vielen negativen Eigenschaften des Tools wird es für eine effiziente DatenbankModellierung als ungeeignet betrachtet.
B.14 Sonstige Tools
Desweiteren wurden folgende Tools in Betracht gezogen:
• Dia (Gnome Office)
• Visio (Microsoft)
Fachstudie
1. October 2002
IPVR, Universität Stuttgart
90
Empfehlung: ...
• Corporate Modeller (CASEWise)
• Designer (Oracle)
• IBMS Case Tool (MDB)
Dia ist ein Zeichentool, dessen Vorbild Visio ist. Die Modellierungsfähikeiten sind beschränkt
nach Information der Webseite. Es ist ein Teil des Gnome Office. Eine Installation unter KDE
scheiterte. Unter Windows gibt es Dia nicht.
Visio wurde bestellt. Die Demo kostete 9,90 DM und ist bis heute noch nicht bei uns eingetroffen.
Deswegen wurde es auch nicht getestet.
Eine Testversion des Corporate Modeller von CASEWise war schlichtweg nicht zu bekommen.
Anfragen per Mail verliefen im Nichts.
<Oracle Designer>
IBMS Case Tool schließlich ist eine Version von 1998. Die Homepage wurde auch seitdem nicht
aktualisiert. Die Fähigkeiten sind beschränkt.
All diese Gründe haben uns dazu bewogen, diese Tools nicht weiter zu evaluieren.
Fachstudie
1. October 2002
IPVR, Universität Stuttgart