Erfahrungen bei der Entwicklung eines Informationssystems auf RDBMS- und 4GL-Basis

Transkript

1 Arbeitsbericht Nr. 1 Erfahrungen bei der Entwicklung eines Infrmatinssystems auf RDBMS- und 4GL-Basis Christine Blte Karl Kurbel Mahmud Mazzami Wlfram Pietsch Dipl.-Wirtsch.-Ing. Christine Blte, Prf. Dr. Karl Kurbel, Mahmud Mazzami, M. S., Dipl.-Kfm. Wlfram Pietsch, Institut für Wirtschaftsinfrmatik, Westfälische Wilhelms- Universität Münster, Grevener Str. 91, 4400 Münster, Tel. 0251/ Februar 1991

2 - 2 - Inhalt 1 Systementwicklung mit Sprachen der 4. Generatin 3 2 Das zu entwickelnde Infrmatinssystem 5 3 Das Entwicklungswerkzeug 8 4 Erfahrungen mit der Datenmdellierung ER-Mdell und Relatinenmdell Erfahrungen mit dem Datenbanksystem 14 5 Erfahrungen mit dem 4GL-Ansatz Allgemeine Bebachtungen Erfahrungen mit den 4GL-Tls vn Oracle 16 6 Erfahrungen mit dem Prttyping-Ansatz 19 7 Zusammenfassung 22 Literatur 23 Zusammenfassung Anläßlich der Entwicklung eines grßen Infrmatinssystems wurde die Entscheidung getrffen, ein Werkzeug der vierten Generatin (4GL) und ein relatinales Datenbanksystem (Oracle) zu verwenden. Der Beitrag beschreibt die Erfahrungen, die bei der Datenmdellierung auf Basis des Entity-Relatinship-Ansatzes und der Überführung in ein Relatinenmdell swie mit den Oracle-spezifischen 4GL-Werkzeugen und der dadurch ermöglichten Entwicklungsmethdik (Prttyping) gesammelt wurden. Das Infrmatinssystem selbst ist an anderer Stelle beschrieben 1). 1 ) Vgl. Blte u.a. (1990).

3 - 3-1 Systementwicklung mit Sprachen der 4. Generatin Eine gebräuchliche Klassifikatin vn Prgrammiersprachen basiert auf der Einteilung in "Generatinen". Hinsichtlich der ersten drei Generatinen ist die Abgrenzung relativ einfach und weithin akzeptiert. Für die vierte Generatin, die sgenannten 4GL (Furth-generatin languages, Sprachen der 4. Generatin), kann dies jedch nicht mehr behauptet werden. In Frschung und Praxis werden die unterschiedlichsten Sftwarewerkzeuge der vierten Generatin zugerechnet. Für das Verständnis der nachflgenden Ausführungen und zur Bewertung der Erfahrungen erscheint deshalb eine Standrtbestimmung zweckmäßig. Die Verwendung vn 4GL wird im allgemeinen mit einer Verbesserung der Prgrammierprduktivität mtiviert. Die Werkzeuge stellen meist prduktivitätsfördernde Sprachelemente bzw. Funktinen zur Verfügung. Nach ihren Ursprüngen und den Ansätzen zur Leistungsverbesserung kann man grundsätzlich zwei Katagrien unterscheiden 2) : Zum einen wurden 4GL auf der Basis vn Datenbankmanagementsystemen der Datenbankabfragesprachen entwickelt mit der primären Zielrichtung, die Eingabe, Ausgabe, Verwaltung und Manipulatin vn Daten zu erleichtern. Zum anderen handelt es sich um Werkzeuge, die auf Sprachen der Sprachknzepten der dritten Generatin aufbauen und diese um leistungsfähigere Elemente für die Anwendungsentwicklung erweitern. Das Leistungsspektrum der 4GL ist breit gefächert. Es reicht vn relativ einfachen, PC-gestützten Endbenutzerwerkzeugen bis hin zu umfassenden Sftwareentwicklungsumgebungen mit einem Data Dictinary 3). Die meisten Werkzeuge verfügen über eine integrierte Prgrammierumgebung. Wenn man mit dieser arbeitet, tritt der eigentliche Prgrammcde weitgehend der vllständig in den Hintergrund. Einige 4GL verfügen über keine textuell dargestellte Sprache wie die klassischen Prgrammiersprachen. Grundsätzlich sind 4GL eher als anwendungsrientierte Werkzeuge denn als Übersetzer für Prgrammiersprachen knzipiert. Einerseits fördern sie bei klar umrissenen Anfrderungsdefinitinen die Prduktivität, andererseits unterstützen sie aber auch die Erfrschung neuer Lösungsansätze (Explratin) und das Experimentieren mit möglichen Lösungen (Prttyping). Die Kreativität der Entwickler und die Flexibilität bei der Systementwicklung werden unterstützt. 2 ) Vgl. Disterer (1987), S. 285 f.; Kurbel, Eicker (1988), S. 21.

4 - 4 - Wichtige Ziele beim Prttyping sind die Evaluierung des Entwicklungsergebnisses, die Überprüfung, b Ausgangsprblem und Implementierung übereinstimmen, swie das Sammeln vn Erfahrungen im Umgang mit dem Werkzeug. Die schnelle Entwicklung der Veränderung eines Systems im Sinne des "Rapid Prttyping" ist mit Sprachen der dritten Generatin wie Cbl der Frtran kaum möglich bzw. wirtschaftlich nicht sinnvll. Die Verfügbarkeit vn 4GL ist eng mit der Entstehung des Prttyping verbunden und stellt eine ntwendige Vraussetzung hierfür dar. Der mit dem 4GL-Einsatz erreichten Prduktivitätssteigerung und Flexibilität im Hinblick auf schnelle Änderungen stehen aber auch Nachteile gegenüber. Zwar wird der Prgrammierer durch deklarative Sprachelemente der Generatren vn der detaillierten Beschreibung, wie ein bestimmtes Ergebnis erzielt werden sll, entlastet. Dadurch verliert er jedch auch die Kntrlle über die Details bei der Ausführung einer bestimmten Aktin; der Gestaltungsspielraum wird eingeengt, und es besteht die Gefahr, daß nur die Lösungen in Betracht gezgen werden, die sich mit dem speziellen Werkzeug realisieren lassen. Bereits bei der Auswahl des Werkzeugs sllte deshalb darauf geachtet werden, daß der erfrderliche Spielraum möglichst gut abgedeckt wird 4). Dies ist in der Praxis jedch nur möglich, wenn ausreichende Erfahrungen mit einem Werkzeug vrhanden sind. Die Möglichkeiten und Beschränkungen zeigen sich meist erst bei intensiver Nutzung. Wenn das Werkzeug nicht den Anfrderungen des Prjekts entsprechend ausgewählt bzw. gewechselt werden kann, besteht die Gefahr, daß das Ergebnis der Prttypentwicklung mit den Eigenschaften des Werkzeugs steht und fällt. Die starke Anwendungsrientierung und der Werkzeugcharakter bringen Nachteile hinsichtlich der Sftwarequalität mit sich. In der Regel wird mit einer 4GL nicht ein zusammenhängendes, lesbares und verständliches Prgramm im Sinne der knventinellen Prgrammiersprachen prduziert, sndern ein Knglmerat vn Einzelfunktinen. Eine Dkumentatin des "Quellcde" ist nicht der nur eingeschränkt möglich. Gängige Methden zur Qualitätssicherung, z.b. Review-Techniken wie "Structured walkthrugh", lassen sich nur begrenzt anwenden. 3 ) Vgl. N.N. (1989), S ) Vgl. Eltzer (1989), S. 192.

5 - 5-2 Das zu entwickelnde Infrmatinssystem Zum besseren Verständnis der Erfahrungen und Bewertungen sll die Aufgabenstellung kurz skizziert werden 5) : Am Lehrstuhl für Wirtschaftsinfrmatik wurde im Auftrag eines Beratungsunternehmens ein grßes Infrmatinssystem erstellt. Das System sll Mitarbeiter des Unternehmens bei der Beratung auf dem Gebiet der Expertensystemtechnlgie unterstützen. Besnderes Interesse galt den Anwendungsmöglichkeiten vn Expertensystemen in der mittelständischen Wirtschaft, aber auch in anderen Bereichen. Typische Fragestellungen, denen sich der Berater gegenübersieht, sind etwa die flgenden: "Welcher Ansprechpartner eines Anwenderunternehmens kann über bestimmte Expertensysteme in der Prduktinplanung und -steuerung referieren? Gibt es Veröffentlichungen über diese Anwendungen?" (Beispiel 1) der "Welche Expertensysteme gibt es im Bankensektr? Welche Sftware wurde zu deren Erstellung verwendet?" (Beispiel 2) Im Rahmen des Prjekts wurde einerseits das Infrmatinssystem entwickelt, zum anderen wurden die Daten erhben und erfaßt. Inhaltlich besteht das System aus 19 Relatinen mit insgesamt Datensätzen. Diese fallen in fünf Kategrien: Expertensystemanwendungen, Literatur, Hardware, Sftware swie Dienstleistungsunternehmen. Ein Schwerpunkt der Auswertungen liegt auf den Zusammenhängen zwischen den Kategrien, wie die bigen Anfragen verdeutlichen. Neben den verschiedenen Möglichkeiten zur Auswertung der Infrmatinen werden Funktinen zur Datenverwaltung bereitgestellt, s daß sich insgesamt die flgenden sechs Sparten ergeben: - Erfassen vn Datensätzen - Ändern vn Daten - Anzeigen vn Datensätzen - Suche vn Daten nach klassifizierten Eigenschaften (Schlagwrtrecherche) - Kmplexe Anfragen 5 ) Eine ausführliche Beschreibung des Infrmatinssystems findet sich in Blte u.a. (1990).

6 Administratinsaufgaben "Einfache Abfragen" wie das Suchen und Anzeigen vn Datensätzen sind in Frm vn Bildschirmmasken realisiert. Die angebtenen Auswertungsmöglichkeiten unterscheiden sich grundlegend: Bei der "Suche nach Daten" (Schlagwrtrecherche) werden Daten, die mit einem klassifizierenden Eintrag in Verbindung stehen, aus verschiedenen Relatinen der Datenbank herausgesucht. Die Klassifikatinsmerkmale werden bei der Datenanalyse vergeben und bei der Erfassung eingegeben. Beispiel 2 zeigte eine Anfrage, die mit dieser Auswertungsstrategie durchgeführt wird. "Banken" ist dabei die Klassifizierung, nach der die Datenbank durchsucht wird. Der Anzeigemdus dagegen durchsucht einzelne Felder einer Relatin nach bestimmten Einträgen. Der Einstieg in diesen Mdus ist nicht durch ein bestimmtes Attribut vrgegeben. Es kann praktisch nach jedem Feld eines Datensatzes selektiert werden. Damit ist zum Beispiel eine Ausgabe aller Expertensystemanwendungen möglich, in deren Bezeichnung der Wrtteil "Bank" vrkmmt der die in einem bestimmten Jahr erstellt wurden. Mit den Auswertungen "Suchen" und "Anzeigen" kann bereits ein grßer Teil der Infrmatinen für eine Beratung aufbereitet werden. Sie sind aber aufgrund der vrdefinierten Maskenstruktur relativ starr. Unter "Kmplexe Anfragen" wurden Auswertungen zusammengefaßt, bei denen es aufgrund der Verschiedenartigkeit der Auswertungsmöglichkeiten der des Umfangs nicht sinnvll ist, die Ergebnisse in starre Bildschirmmasken zu pressen. Statt dessen werden die Resultate in Frm eines Reprts auf dem Bildschirm der in eine Druckdatei ausgegeben. Sind einem Benutzer die Beziehungen innerhalb des Datenmdells bekannt, s kann er die kmplexen Abfragen relativ einfach mdifizieren und seinen Auswertungswünschen anpassen. Eine Reihe recht verschiedenartiger Abfragen sind bereits vrdefiniert, s daß auch ein in der Abfragesprache nicht geübter Benutzer kleinere Veränderungen durchführen der zumindest Anhaltspunkte für die Frmulierung eigener Anfragen gewinnen kann. Die ben als Beispiel 1 bezeichnete Anfrage beschreibt eine derartige kmplexe Auswertung. Die Auswertungsstrategien wurden zusammen mit dem Auftraggeber ausgearbeitet. In einer Reihe vn Gesprächen wurden typische Beratungsszenarien, wie sie täglich auftreten, ermittelt und anschließend umgesetzt.

7 - 7 - Zu den Datenadministratinsaufgaben gehören das Löschen vn Daten, ihre Sicherung und der uneingeschränkte Zugriff auf die Datenbank. Der Datenbankadministratr hat die Möglichkeit, aus dem Infrmatinssystem zur Sicherung die gesamte Datenbank zu exprtieren und sie (der eine andere) zu imprtieren, hne daß er auf Betriebssystemebene arbeiten muß. Die Administratinsprgramme wurden ebenfalls in den Menübaum integriert. Sie sind aber nur mit besnderen Zugriffsrechten erreichbar. Abb. 1: Aufbau des Infrmatinssystems Die Menüstruktur für die Datenpflege und -auswertung läßt sich anhand einer Matrix darstellen, die auch in Abbildung 1 zu erkennen ist. Die Spalten zeigen die funktinale Trennung der Mdule des Infrmatinssystems (Erfassen, Ändern, Suchen und Anzeigen vn Daten), während hrizntal die inhaltliche Aufteilung entsprechend der fünf Bereiche Anwendungen, Entwicklungswerkzeuge, Dienstleister, Hardware und Literatur erflgt. Der Menüpunkt "Thesaurus" unter den Funktinen "Daten erfassen" und "Daten ändern" dient der Eingabe bzw. Veränderung der Klassifizierungen. Die entsprechenden Masken sind nur für manche Benutzer zugänglich. Dadurch sll einem Wildwuchs der Klassifizierungen Einhalt gebten werden. Das Infrmatinssystem enthält Daten aus verschiedenen Bereichen, die bei einer Auswertung gemeinsam betrachtet werden. Die inhaltlichen Zusammenhänge zwischen den Bereichen sind daher besnders wichtig, eine Tatsache, der bereits bei der Erfassung der Daten Rechnung getragen wird. Ein Beispiel sll dies verdeutlichen:

8 - 8 - Im Rahmen der Suche nach Expertensystemanwendungen sll auch das Entwicklungswerkzeug mit angezeigt werden. Dies bedeutet, daß bereits bei der Erfassung der Anwendungen der Zusammenhang zwischen Anwendung und Sftware hergestellt wird. Dabei wird mehrmals die Vllständigkeit und Knsistenz der Eingaben überprüft (Beispiel: Existiert die zugerdnete Sftware überhaupt?). Die erfrderlichen Übergänge zwischen verschiedenen Zweigen des Menübaums werden als "Shrt cuts" bezeichnet. Wird etwa bei der Erfassung einer Anwendung ein Werkzeug mit eingegeben (Erfassungsmaske 'Anwendung'), s findet eine Überprüfung statt, b das Werkzeug bereits in der Datenbank vrhanden ist. Falls nicht, werden alle bisher eingegebenen Daten zwischengespeichert, und es findet ein autmatischer Wechsel in die Erfassungsmaske für Werkzeuge statt. Nach abgeschlssener Erfassung erflgt ein Rücksprung in die ursprünglich aufgerufene Maske; alle bzgl. der Anwendung erfaßten Daten werden wieder eingeblendet, und die Eingabe wird im Feld nach 'Werkzeug' frtgesetzt. 3 Das Entwicklungswerkzeug Zur Erstellung des Infrmatinssystems wurde das relatinale Datenbanksystem Oracle (RDBMS Oracle) mit den dazugehörigen Werkzeugen verwendet. Ausschlaggebend für diese Entscheidung des Auftraggebers war die breite Verfügbarkeit vn Oracle auf verschiedener Hardware und unterschiedlichen Betriebssystemen. Dies sllte die Übertragung des Systems mit beschränktem Aufwand erlauben. Oracle bietet dem Systementwickler Werkzeuge auf verschiedenen Ebenen; die wichtigsten sind - SQL*Plus - SQL*Frms - SQL*Reprt - SQL*Menu - PRO*C swie weitere, die aber bei der Realisierung des Infrmatinssystems nicht zum Einsatz kamen (SQL*Calc für Tabellenkalkulatin, SQL*Net als Netzwerkkmpnente, aber auch Schnittstellen zu anderen przeduralen Sprachen als C). Im Sinne der in Kapitel 1 einge-

9 - 9 - führten Unterscheidung der 4GL können die zuerst angeführten Tls der Kategrie vn Werkzeugen, die auf der Basis vn Abfragesprachen entstanden, zugerdnet werden. SQL*Plus ist ein SQL-Interpreter, der eine Erweiterung des ANSI-SQL-Standards für Oracle darstellt. Ähnliche Versinen sind etwa ESQL (für Ingres) der XSQL (für Infrmix). Derartige Erweiterungen sind für praktische Anwendungen ft ntwendig bzw. sinnvll, da der SQL-Standard nur einen beschränkten Befehlsumfang bietet. S sind z.b. keine Befehle zur Steuerung der Zugriffsrechte auf verschiedene Datenbankbereiche der Befehle zum Umleiten der Ausgaben in eine Datei (und damit die Erstellung druckbarer Dateien) verfügbar. Die Funktin "Rllback", die ein Zurücksetzen der Datenbank auf den Stand beim letzten "Cmmit" (Übernahme vn Änderungen in die Datenbank) ermöglicht, ist ebenfalls nur in der Erweiterung vrhanden. SQL*Frms ist der Anwendungsgeneratr unter den Oracle-Tls, der das Prttyping besnders unterstützt. Das Objektprgramm wird autmatisch erzeugt. Der Entwickler definiert "nur" die lgische Struktur der Daten (Tabellen) und ihre Benutzerberfläche (Masken). Dabei können einfache Defaultmasken innerhalb kürzester Zeit erstellt und anschließend den individuellen Bedürfnissen angepaßt werden. SQL*Menu ist ein kmfrtables Tl, welches auf relativ einfache Art und Weise die Generierung vn Menüs und ihren gegenseitigen Aufrufen erlaubt. Die besnderen Vrteile werden in Abschnitt 5.2 nch erläutert. SQL*Reprt unterstützt die Erstellung vn Auswertungslisten. Trtz der umfangreichen Möglichkeiten, welche die Oracle-Tls bieten, muß in einigen Fällen eine Sprache der dritten Generatin herangezgen werden. Mit dem Werkzeug Pr*C können in C-ähnlicher Ntatin Prgramme geschrieben werden, in die sich Datenbankanfragen einbinden lassen. Mit Hilfe eines Precmpilers werden diese Prgramme in C-Cde umgesetzt. Ähnlich verläuft die Vrübersetzung, wenn Schnittstellen zu anderen przeduralen Sprachen (z.b. Pr*Cbl, Pr*Frtran) verwendet werden. Bei der Realisierung unseres Infrmatinssystems wurde auf die Mdule SQL*Menu, SQL*Frms, SQL*Plus und Pr*C zurückgegriffen. Auf den Einsatz vn SQL*Reprt wurde verzichtet, da sich unsere Vrstellungen nicht innerhalb des vn SQL*Reprt gesetzten Rahmens verwirklichen ließen. Statt dessen wurden die Reprts in Pr*C entwickelt.

10 Erfahrungen mit der Datenmdellierung Die Erfahrungen mit dem Relatinenmdell bei der Entwicklung des Infrmatinssystems sllen hier vn zwei Seiten beleuchtet werden: Einmal wird die Mdellierungsseite erörtert, zum anderen die Unterstützung durch das Datenbanksystem. 4.1 ER-Mdell und Relatinenmdell Ausgehend vn der Realität wurde ein Entity-Relatinship-Mdell (ER-Mdell) entwrfen 6), das anschließend in ein Relatinenmdell überführt wurde. Nach der Umsetzung wurde wiederhlt festgestellt, daß die Realität im Relatinenmdell nicht krrekt abgebildet war, s daß eine Rückkpplung zwischen dem Relatinenmdell und der Realität erfrderlich wurde. Einige Veränderungen des Relatinenmdells wurden dann, sweit es möglich war, in das ER-Mdell übernmmen. Die Vrgehensweise hat Ähnlichkeiten mit einem "Prttyping bezüglich der Daten". Abb. 2: Mdellierungsschritte Für den ersten Schritt, die Darstellung der Realität im ER-Mdell, bringt die Verwendung eines ER-Diagramms Vrteile, aber auch einige Nachteile mit sich: Die Realität läßt sich relativ leicht und übersichtlich in einem ER-Mdell abbilden, slange die Zahl der Entities und Beziehungen gewisse Grenzen nicht überschreitet. Zwar kann ein Entity mit seinen Beziehungen jederzeit eingefügt werden; der Überblick 6 ) Aus der Methde des ER-Mdells (Chen (1976), S. 9 ff ) wurde nur das ER-Diagramm verwendet. Wenn im flgenden vn ER-Mdell gesprchen wird, ist das ER-Diagramm gemeint.

11 über das Gesamtmdell geht aber bei den zahlreichen Rechtecken, Rauten und Linien verlren. Das Datenmdell, das unserem Infrmatinssystem zugrundeliegt (vgl. Abbildung 3), stößt schn fast an die Grenze der Übersichtlichkeit 7). Besnders zu Beginn der Entwicklungsarbeit bleibt dem Systemanalytiker sehr viel Flexibilität bei seiner Darstellung der Realität. S ist es weitgehend seiner Interpretatin überlassen, b bestimmte Teile als Entities der als Beziehungen repräsentiert werden. Auch können Attribute aus einem Entity herausgenmmen und als eigenständige Entitäten geführt werden; dies ist wichtig, wenn ein Attribut gleichzeitig mehrere Ausprägungen besitzen kann. Ein Nachteil ist jedch die starke Atmisierung der Datenstruktur durch Nrmalisierungsbemühungen. Vr allem grße Mdelle werden dadurch eher unübersichtlich. Abb. 3: Das Datenmdell des Infrmatinssystems Die Erweiterung des klassischen ER-Mdells um die Möglichkeit der Generalisierung ("Is a"-beziehung) knnte in unserem Datenmdell verwendet werden, um die Klas- 7 ) Ein krasses Beispiel für die Grenzen vn ER-Diagrammen stellt das Unternehmensdatenmdell dar, das Scheer seinem Buch "Wirtschaftsinfrmatik" beifügt. Drt sind zwar die Daten eines Industriebetriebs umfassend dargestellt; die Übersichtlichkeit ist jedch weitgehend verlrengegangen; vgl. Scheer (1988), hinterer Umschlag.

12 senbildung für das Entity Text durchzuführen. Unter Text sind swhl Artikel als auch Mngraphien zusammengefaßt. Die Abbildung der Realität in einem ER-Mdell ermöglicht eine Vereinheitlichung der Darstellung und Unabhängigkeit vn speziellen Datenmdellen. Beim zweiten Schritt, der Transfrmatin der Datenstruktur aus dem ER-Diagramm in das Relatinenmdell, traten Schwächen, aber auch einige psitive Aspekte des Relatinenmdells zutage: Zunächst bleibt die Unabhängigkeit vn einem bestimmten Datenbanksystem erhalten, wenn auch die Unabhängigkeit vm Datenmdell verlrengeht. Das einzelne Entity läßt sich im Relatinenmdell wesentlich ausführlicher als im ER- Diagramm beschreiben. Die Unübersichtlichkeit durch Atmisierung wird im Relatinenmdell nch größer als im ER-Mdell, da eine grße Zahl vn Relatinen einfach gleichförmig und hne sichtbare Verbindung nebeneinander steht. Die Umsetzung einiger Aspekte aus dem ER-Diagramm bereitet Mühe. Zwei besndere Punkte sllen an dieser Stelle angeführt werden: Die beschränkte Bildschirmgröße zwang dazu, Texte durch Flgen mehrerer Attribute darzustellen, deren Länge eine Bildschirmzeile nicht übersteigt. Slche Texte sind z.b. Kurzbeschreibungen zu Literaturstellen, Anwendungen swie Hardware und Sftware. Innerhalb des Relatinenmdells gibt es keinen Aufzählungstyp. Um den Status einer Expertensystemanwendung darstellen zu können (Prttyp, Testsystem, Prduktivsystem etc.), mußte eine eigene Relatin angelegt werden, die die Werte für das Statusfeld in der Relatin 'Anwendung' liefert. Insgesamt büßt das Gesamtmdell bei der relatinalen Darstellung an Transparenz ein. Abbildung 4 zeigt eine Bewertung der beiden Darstellungsfrmen. Beide besitzen Vr- und Nachteile. S erkennt man im ER-Mdell die Beziehungen zwischen den Entities besser, während im Relatinenmdell der Überblick fehlt. Hier können allerdings die Attribute und ihre Eigenschaften viel genauer dargestellt werden als im ER-Diagramm.

13 Abb. 4: Bewertung der Übersichtlichkeit vn ER-Mdell und Relatinenmdell Bei der Überprüfung des Datenmdells, wie es nach der Umsetzung im Relatinenmdell vrlag, traten einige Prblemfelder hervr. Manche Teile des Datenmdells waren zwar krrekt aus der Realität in dem ER-Mdell abgebildet und in das Relatinenmdell überführt wrden; sie entsprachen dann aber augenscheinlich nicht mehr der Realität der hätten einfacher realisiert werden können. Die erfrderlichen Änderungen wurden zunächst im Relatinenmdell durchgeführt; zum Teil knnten sie aber nicht in die Darstellung des ER-Mdell übernmmen werden: Ein derartiger Fall ist die Realisierung der Einrdnungen, d.h. der Klassifizierung vn Anwendungen, Texten etc. Im ER-Mdell der Abbildung 3 sind fünf Relatinen - es handelt sich um die Relatinen, die in direkter Verbindung zu "Einrdnung" stehen - eingezeichnet, mit denen die Klassifizierung durchgeführt wird. Tatsächlich existiert jedch nur eine Relatin, in der alle fünf Bereiche klassifiziert werden. Der Schlüssel ist s gewählt, daß anhand der ersten Psitin erkannt werden kann, um welches Objekt es sich im speziellen Fall handelt. Die starke Atmisierung wird durch diese Relatin ein wenig reduziert. Die Veränderung knnte in der beschränkten Darstellungsfrm des ER- Mdells aber nicht berücksichtigt werden, da alle fünf Bereiche lgisch unabhängig sind. Aus dem ER-Mdell geht weiterhin hervr, daß für einen Hardwaretyp beliebig viele Institutinen erfaßt werden können. Dies entspricht auch nicht dem Stand innerhalb des Infrmatinssystems. Da in die Kategrie Institutin swhl Vertreiber als auch Hersteller vn Hardware fallen, wurde die N:M-Beziehung genau genmmen durch eine N:2-

14 Beziehung realisiert, d.h., für jedes Werkzeug wird genau ein Vertreiber und ein Hersteller erfaßt. Dieses ist eine reine Implementierungsentscheidung, die wegen des hhen Aufwands bei der Maskenentwicklung getrffen wurde. 4.2 Erfahrungen mit dem Datenbanksystem Die Erfahrungen, die wir mit RDBMS Oracle machten, sind fast durchweg psitiv. Die wenigen negativen Aspekte fallen demgegenüber kaum ins Gewicht. Oracle zeichnet sich vr allem durch Verfügbarkeit auf zahlreichen Rechnertypen und Betriebssystemen aus. Das Infrmatinssystem wurde auf zwei verschiedenen Rechnern (Sun 3/60, HP 9000/350) entwickelt und anschließend auf einem dritten (Targn 31) installiert. Darüber hinaus wurden zahlreiche kleinere Tests auf einem PC unter MS-DOS 3.3 durchgeführt. Die Prtabilität erwies sich als hervrragend. Ein Vrteil für den Systemadministratr ist die Tatsache, daß alle Daten in einem Datenpl verwaltet werden. Smit kann die Datenbank in einem Schritt gesichert, exprtiert der rückübertragen werden. Auch der einfache Benutzer kann auf diese Weise seine Daten sichern. Trtz der zentralen Datenhaltung hat der Benutzer nur Zugriff auf die vn ihm angelegten Tabellen, Views etc. der auf die anderer Benutzer, sfern diese ihm Zugriff gewähren. Verschiedene Datenbanken können unabhängig vneinander einem Infrmatinssystem zugerdnet und verwendet werden. S existierte z.b. während der Entwicklungsphase eine Testdatenbank, mit der die erstellten Masken und Tabellen überprüft wurden, während die Erfassungsarbeiten und die Datenvalidierung mit der Originaldatenbank parallel durchgeführt werden knnten. Die Oracle-Erweiterung des SQL-Standards bietet verschiedene Eigenschaften, die das Arbeiten wesentlich erleichtern. Auf einige wird in Abschnitt 5.2 näher eingegangen. Die verfügbaren Datentypen sind gegenüber dem Standard erweitert. Allerdings existiert kein lgischer Datentyp; er muß bei Bedarf auf andere Weise realisiert werden.

15 Der gravierendste Nachteil vn Oracle ist das Fehlen eines dynamischen Query-Optimizers; d.h., bei der Optimierung wird nur die Syntax, aber nicht das Mengengerüst der angesprchenen Tabellen berücksichtigt. Der Entwickler muß demzuflge bereits bei der Systemerstellung vrausschauend die Queries mit Geschick frmulieren. 5 Erfahrungen mit dem 4GL-Ansatz 5.1 Allgemeine Bebachtungen Beim Einsatz vn Sprachen der vierten Generatin macht man ft zu Beginn der Implementierungsarbeiten rasche Frtschritte, s daß das Ziel nahe erscheint. Auch kleinere Anpassungen und Änderungen während der ersten Entwicklungsschritte können nch recht einfach durchgeführt werden; Änderungen in späteren Stadien sind dagegen meist sehr aufwendig. Die schnellen Anfangserflge mit einem 4GL-Werkzeug erwecken zunächst den Anschein, als lasse sich die ganze Entwicklung in der gleichen Geschwindigkeit frtführen. Dabei übersieht man leicht, daß Anfrderungen, die nicht im Rahmen des Werkzeugs liegen, einen überprprtinalen Aufwand erfrdern. Dieser ist ft sgar sehr viel höher als bei Verwendung einer Prgrammiersprache der dritten Generatin. Während einerseits die Mächtigkeit der 4GL-Werkzeuge die Prduktivität erhöhen kann, muß andererseits berücksichtigt werden, daß der Sftwareentwicklung aufgrund der Beschränkungen des Werkzeugs enge Grenzen gesetzt sind. Der Systemanalytiker der -entwickler ist daher ständig der Gefahr ausgesetzt, sich bereits bei der Frmulierung der Anfrderungen an den Möglichkeiten eines knkreten Werkzeugs zu rientieren. Ein entscheidender Nachteil der 4GL ist, wie bereits eingangs erwähnt, in möglichen Rückschritten bei der Sftwarequalität zu sehen. Die für knventinelle Sftwaresysteme akzeptierten (und erwarteten) Qualitätsmerkmale lassen sich bei 4GL ft nicht erreichen. Ein kritischer Punkt ist auch die Prgrammdkumentatin. Häufig wird vm Systementwickler kein Quellcde erstellt; zum Beispiel handelt es sich bei den durch "Prgrammierung" in SQL*Frms erzeugten Prblemlösungen um Interaktinsprtklle, die zwar den (dynamischen) Dialgablauf, aber nicht eine (statische) Prgrammstruktur beschreiben. Demzuflge ist eine Dkumentatin im Sinne einer Beschreibung des "Prgrammtexts" kaum machbar. Die Möglichkeit der Kmmentierung der Interaktinsprtklle erwies sich bei SQL*Frms als höchst unzulänglich.

16 Schließlich ist darauf hinzuweisen, daß Sprachen der vierten Generatin im allgemeinen grßen Speicherbedarf besitzen und bei der Ausführung eher langsam sind. 5.2 Erfahrungen mit den 4GL-Tls vn Oracle Abbildung 1 zeigt für die wesentlichen Bereiche des Infrmatinssystems, welche Werkzeuge zu welchem Zweck verwendet wurden. Auf dem RDBMS Oracle mit der Abfragesprache SQL*Plus setzt das gesamte System auf. Alle anderen Werkzeuge stehen mit der Datenbank über SQL*Plus in Verbindung. SQL*Menu bindet die erstellten Masken zusammen und erlaubt die Auswahl einzelner Arbeitsfelder. Den Grßteil der Entwicklungsarbeit machte die Erstellung der Masken aus. SQL*Frms erwies sich dabei als ein Werkzeug, mit dessen Hilfe sehr schnell einfache Masken erzeugt werden knnten. Das Layut der Masken ist gut gestaltbar; Felder, die in den Defaultmasken zunächst untereinander gesetzt sind, lassen sich verschieben und umstellen. Linien für einen Rahmen der eine Bildschirmunterteilung können mit dem "Screen painter" gezeichnet werden. In den Masken können dann unmittelbar Select-, Insert-, Delete- und Update-Befehle auf der betreffenden Relatin ausgeführt werden. Knsistenzüberprüfungen und Auswertungen über mehrere Relatinen müssen allerdings mit Hilfe vn Triggern realisiert werden. Dies sind kleinere Befehlsflgen, die beim Eintreten eines definierten Ereignisses (z.b. Eingabe des Benutzers in ein bestimmtes Datenbankfeld der Verlassen einer Maskenseite) angestßen werden. Die Generierung der Masken mit SQL*Frms ist, wenn die "natürlichen Grenzen" des Werkzeugs nicht verlassen werden, äußerst kmfrtabel. Einige Funktinen anderer Werkzeuge, die die Implementierung wesentlich vereinfachen können, (z.b. "Cut and paste"), waren in den verwendeten Versinen (Oracle Release und SQL*Frms 2.0) leider nch nicht vrhanden. Wenn z.b. ähnliche Trigger in verschiedenen Feldern benutzt werden sllten, knnten sie nicht einfach kpiert und abgewandelt werden, sndern mußten jedes Mal kmplett neu eingegeben werden. Nur mit viel Geschick - durch Kpieren im völlig unstrukturierten Interaktinsprtkll - ließen sich Trigger mehrfach verwenden. Trtz dieser Einschränkung knnten vll funktinsfähige Masken wesentlich schneller als mit Sprachen der dritten Generatin erstellt werden. Die Verwendung vn SQL*Frms hatte allerdings Einbußen bei der Perfrmance zur Flge, die nicht aufgetreten wären, wenn die Masken mit Pr*C erstellt wrden wären. Ferner stand

17 kein Debugger zur Verfügung, der gerade bei der Prgrammierung der Trigger unbedingt wünschenswert wäre. Slange man den vn SQL*Frms vrgegebenen Rahmen nicht verläßt, ist die Sftwareentwicklung sehr viel einfacher als bei Verwendung einer knventinellen przeduralen Prgrammiersprache. Alle Anfrderungen, die ein Verlassen des Rahmens mit sich bringen, verursachen jedch überprprtinal grßen Prgrammieraufwand. Ein Beispiel mag dies verdeutlichen: In dem Infrmatinssystem sllte bei der Erfassung vn Daten überprüft werden, b einzelne Eingaben bereits im System vrhanden sind ("Shrt cuts", vgl. Abschnitt 2). Dazu ist ein Hin- und Herspringen zwischen verschiedenen Masken erfrderlich, welches in SQL*Frms nicht vrgesehen ist und sich nur mit hhem Aufwand realisieren läßt. Erheblichen Prgrammieraufwand verlangte auch die Frderung nach Rbustheit des Infrmatinssystems. Zwar ist SQL*Frms s rbust, daß die Datenbank - etwa durch eine unglückliche Tastenkmbinatin - nicht zerstört werden kann; die Anfrderungen des Auftraggebers gingen jedch weit über diese "Grundrbustheit" hinaus. Beispielweise sllte in vielen Fällen die Tastatur nach Auswahl einer Funktin gesperrt werden. Da diese Leistung vn SQL*Frms nicht unterstützt wird, mußte ein gesndertes C-Prgramm geschrieben und jeweils über einen "User exit" angesteuert werden. Die genannten Schwachstellen treten allerdings nicht nur bei SQL*Frms, sndern auch bei anderen vergleichbaren Werkzeugen auf. Für das "Nrmale" ist SQL*Frms ein gutes Werkzeug; das "Besndere" verursacht unprprtinal hhen Aufwand. SQL*Plus, die Datenbankabfragesprache vn Oracle, ist nicht einfach zu handhaben; dem gelegentlichen Benutzer erscheint sie kmplex und umfangreich. Dies liegt einmal an der Syntax, zum anderen müssen dem Benutzer Knzepte der Relatinenalgebra bekannt sein. Dies stellt für den sachkundigen Entwickler keine Schwierigkeit dar. Der Endbenutzer steht jedch, wenn ihm das Datenmdell nicht in allen Einzelheiten bekannt ist, einem unüberschaubaren und unstrukturierten Berg vn Infrmatinen gegenüber. Daraus resultiert die Frderung, daß der Endbenutzer auf die direkte Anwendung der Abfragesprache möglichst verzichten können sllte. Dies gilt nicht nur speziell für SQL*Plus, sndern für die meisten Datenbankabfragesprachen. Die Erweiterungen, die SQL*Plus gegenüber dem ANSI-Standard bietet, sind in vielerlei Hinsicht nützlich. SQL*Plus umfaßt z.b. Kmmands, die es erlauben, die Ergebnisse zu frmatieren der Parameter zu setzen 8) ; mit 8 ) Vgl. Mazzami (1989), S. 487.

18 dem Kmmand "Spl name" kann man etwa die Ausgabe zusätzlich in die Datei "name" schreiben, was im Standardsprachumfang nicht möglich ist. SQL*Menu ist ein sehr kmfrtables Werkzeug für die Erzeugung und Verwaltung vn Menüs. Psitiv fiel die Möglichkeit ins Auge, Übergänge zwischen verschiedenen Zweigen des Menübaums zu realisieren, die ein Hangeln durch den ganzen Baum überflüssig machen und einzelne Masken direkt ansteuern. Für einen Anwender, der regelmäßig mit dem System arbeitet, ist dies eine erhebliche Erleichterung. Ferner erlaubt SQL*Menu eine Einteilung aller erstellten und eingebundenen Masken in Gruppen. Dabei ist nicht nur eine hrizntale der vertikale Untergliederung möglich, sndern einzelne Systemteile können beliebig zusammengefaßt und mit unterschiedlichen Zugriffsrechten versehen werden. Damit ist es auf einfache Art und Weise möglich, Funktinen für die Datenbankadministratin besnders abzusichern und der Allgemeinheit der Benutzer zu entziehen. Prbleme traten weder beim Zugriff auf die Datenbankabfragesprache SQL*Plus nch beim Zugriff auf Funktinen des Betriebssystems auf. Derartige Zugriffe wurden z.b. für die "Kmplexen Anfragen" und einige Funktinen der Datenbankadministratin benötigt. Nach dem "Exit" aus SQL*Plus erflgt wieder ein Rücksprung in die betreffenden Menüs. Auch die Ausführung der Funktinen zum Imprt und Exprt der Datenbank, die vn SQL*Menu aus angesteuert und auf Betriebssystemebene gestartet werden, endet mit der Rückkehr in die SQL*Menu-Ebene. Trtz aller Vrteile gibt es auch Einschränkungen. SQL*Menu stellt keine Pp-up- der Pulldwn-Menüs zur Verfügung, die der PC-verwöhnte Benutzer heute erwartet. Für Oracle existieren im PC-Bereich bereits innvativere Oberflächen als die SQL*Menu-Oberfläche. S wurde etwa über Mausunterstützung für Oracle berichtet 9). Da inzwischen SQL*Menu für den PC verfügbar ist, könnten möglicherweise auch hier Pull-dwn-Menüs zum Einsatz kmmen. Eine fenster- und mausrientierte Oberfläche für SQL*Plus und SQL*Frms beschreibt Mazzami 10 ). Prbleme mit SQL*Menu, die bei unserer Entwicklung auftraten, waren vr allem in der teilweise mangelnden Kmpatibilität zweier unterschiedlicher Versinen begründet. Die Versin für einen der Entwicklungsrechner (Sun 3) unterschied sich in einigen Punkten vn der Versin für den Zielrechner (Targn 31). ) Ruhnke (1990), S. 25 ff ; drt wird eine Maussteuerung für verschiedene Oracle-Werkzeuge beschrieben. ) Vgl. Mazzami (1989). 9 10

19 Pr*C ist wie C aufgebaut und bereitet C-Prgrammierern keine Schwierigkeiten. Nur das Einbinden vn SQL-Statements verlangt Kenntnisse der Datenbankabfragesprache. Wird Pr*C allerdings verwendet, um aus SQL*Frms kmplexere Prgramme aufzurufen (sgenannte "User exits"), s müssen einige Besnderheiten berücksichtigt werden. S sllten User exits keine Prgrammteile zur Steuerung der Benutzerberfläche enthalten, da es snst zu Kllisinen mit dem Masken-Layut vn SQL*Frms kmmen kann. Ferner sllte das Transaktinsgefüge nicht beeinflußt werden (d.h. kein Cmmit etc.), um die Gefahr vn Deadlcks zu vermeiden. Das Einbinden der User exits erfrdert Kenntnisse über Oracle und bedarf einer gewissen Einarbeitung. Nachdem das Infrmatinssystem fertiggestellt war, wurde die Entscheidung, SQL*Frms als Masken- und Anwendungsgeneratr zu verwenden, kritischer beurteilt. SQL*Frms war primär aus Prduktivitätsgründen gewählt wrden. Die erkennbaren Restriktinen bezüglich der Flexibilität schienen nach Absprache mit dem Auftraggeber tragbar. Nachdem das System nun installiert ist und eingesetzt wird, fallen die durch SQL*Frms bedingten Einschränkungen stärker ins Gewicht als ursprünglich vermutet. Dies führte einen Mitarbeiter des Auftraggebers zu der Aussage, das ganze System hätte whl dch besser in Pr*C erstellt werden sllen. Erhebliche Schwierigkeiten bereitete auch die Anfrderung des Auftraggebers, statt der vn Oracle vrgesehenen Tastaturbelegung eine andere zu realisieren. Aufgrund unserer Erfahrungen liegt es nahe, anderen Anwendern vn derartigen aufwendigen Mdifikatinen eher abzuraten. Der Knflikt zwischen Prduktivitätszuwachs und Steigerung der Flexibilität ist typisch für viele dedizierte Sftwarewerkzeuge. Dies gilt nicht nur für die 4GL, sndern auch für andere Werkzeuge mit einem eng beschränkten Einsatzgebiet (z.b. Expertensystem-Shells, Spreadsheet-Systeme u.a.). 6 Erfahrungen mit dem Prttyping-Ansatz Das Infrmatinssystem wurde mit einem Team vn sechs Mitarbeiter(innen), die teilweise der ganz für das Prjekt zur Verfügung standen, mit einem Gesamtaufwand vn ca. 2,5 Persnenjahren realisiert. Zusätzlich überwachte ein Supervisr den Prjektrahmen. Die Laufzeit betrug 7,5 Mnate. Drei Mitarbeiter waren primär mit der Systementwicklung und Implementierung betraut, zwei weitere wurden für die Datenexplratin und -erfassung einge-

20 setzt. Ein Mitarbeiter war für das Prjektmanagement zuständig, arbeitete aber auch bei der Implementierung mit. Der Entwicklung wurde ein evlutinäres Vrgehensmdell zugrunde gelegt, das bereits in anderen Prjekten erflgreich zum Einsatz kam 11). Die Entwicklung erflgte in mehreren aufeinander aufbauenden Zyklen, deren Ergebnisse jeweils betriebsfähige Systemversinen darstellten: Initialisierungszyklus: Ausgehend vn einer grben Beschreibung des Leistungsumfangs wurde innerhalb vn fünf Wchen ein Demnstratinsprttyp entwickelt. Dieser wurde mit dem Auftraggeber und den zukünftigen Benutzern diskutiert und zur Erarbeitung der Anfrderungen an das Infrmatinssystem verwendet. Neurientierungszyklus: Unter Einbezug der Erfahrungen aus dem ersten Zyklus wurde ein Knzept für das Zielsystem, in das verschiedene Vrgaben (z.b. eine spezifische Tastaturbelegung) Eingang fanden, erarbeitet und implementiert. Die Realisierung erflgte inkrementell und in zwei Ausbaustufen, die flgendermaßen charakterisiert waren: Stufe I: Hrizntale Funktinsauswahl (vgl. Abbildung 1), geringe Rbustheit, Verwendung vn Testdaten. Stufe II: Restliche Funktinen, Verbesserung der Rbustheit, Menüsystem, Realisierung vn Datenschutz und Datensicherheit, Verwendung vn Realdaten. Beide Stufen dauerten jeweils ca. 3 Mnate. Nach Abschluß jeder Stufe wurde dem Anwender eine Systemversin für den Test im realen Einsatz zur Verfügung gestellt. Mängel wurden in einer Mängelliste festgehalten. Stabilisierungszyklus: Die Mängelliste wurde in regelmäßigen Prjektausschußsitzungen mit Priritäten versehen. Fehler wurden dann entsprechend der festgelegten Reihenflge bearbeitet und anschließend in einem Review überprüft. Der Initialisierungszyklus diente vr allem dem Test des Werkzeugs, der Erprbung vn Knzepten und der Überprüfung vn Implementierungsmöglichkeiten. Dabei beschränkten wir uns zunächst auf einen der fünf Bereiche des Infrmatinssystems ("Literatur"). Schwerpunkte der Arbeit lagen auf der Erstellung der Masken zur Datenerfassung und Schlagwrtrecherche. In dieser Phase wurden wichtige Erfahrungen mit dem Anwendungsprblem und 11 ) Vgl. Kurbel u.a. (1987), Kurbel, Pietsch (1988).

21 Erkenntnisse hinsichtlich der Anfrderungen des Anwenders gesammelt. Der Prttyp wurde später nicht weiter verwendet. In Stufe I des Neurientierungszyklus wurden u.a. die Masken zur Erfassung der Daten und zur Schlagwrtrecherche neu erstellt swie die Generierung vn Reprts für alle fünf Bereiche knzipiert und teilweise implementiert. Mit Hilfe vn SQL*Frms kam die Implementierung anfänglich zügig vran. Die Umsetzung vn spezifischen Anfrderungen des Auftraggebers bezüglich der Tastaturbelegung gestaltete sich jedch erheblich schwieriger und langwieriger als erwartet. Während in dem Initialisierungszyklus alle Masken nach unseren Vrstellungen gestaltet wrden waren, mußten im zweiten Zyklus das beim Anwender snst verwendete Layut der Bildschirmseiten und die Tastaturbelegung berücksichtigt werden; mit Beginn des zweiten Zyklus wurde ein bereits existierender "Standard" vrgegeben. Die Funktinalität des Systems wurde vn der Änderung der Benutzerschnittstelle zwar nicht berührt; das äußere Erscheinungsbild des Zielsystems verschlechterte sich jedch gegenüber dem ersten Prttyp erheblich. Auch die Handhabbarkeit des Systems litt deutlich unter dem Standard. In der zweiten Stufe des Neurientierungszyklus wurden u.a. die Masken zur Änderung und Anzeige vn Daten swie die kmplette Menüstruktur und alle SQL-Scripts des Datenbankadministratrs realisiert. Erst in dieser Stufe erflgte eine permanente Rückkpplung zwischen Entwicklern und Endbenutzern mit regelmäßigen Qualitätssicherungssitzungen. Auch Testinstallatinen auf dem Zielrechner wurden erst in der zweiten Stufe vrbereitet bzw. durchgeführt. Dies erwies sich als nachteilig, weil bei den hhen Anfrderungen des Auftraggebers trtz aller Kmpatibilität vn Oracle Prbleme mit unterschiedlichen Versinen auf den verschiedenen Hardwareknfiguratinen auftraten. Durch frühzeitigere Installatin und Qualitätssicherungsmaßnahmen hätten diese und andere rganisatrische Prbleme vermieden werden können. Die enge Rückkpplung mit dem Anwender hatte einen Effekt, der whl typisch ist und deshalb besnders erwähnt werden sllte: Das Entwicklungsteam wurde ständig mit neuen Wünschen und Vrstellungen knfrntiert. Einmal verabschiedete Punkte mußten wieder geändert, andere neu aufgenmmen der erweitert werden ("Können Sie nicht vielleicht da nch...?"). Teilweise sprengten diese den Rahmen der Prjektkalkulatin und knnten angesichts der geplanten persnellen Ressurcen und der Prjektlaufzeit nicht realisiert werden.

22 Aus der Perspektive der Sftwareentwickler hätte eine klassische lineare Vrgehensweise mit einem vrab definierten Pflichtenheft sicherlich Vrteile gehabt. Das Prttyping ermöglichte zwar eine frühzeitige Validierung der Anfrderungen und einen unter den vrgegebenen Restriktinen relativ hhen ergnmischen Standard. Die frühe Präsentatin eines Prttyps weckte jedch auch Erwartungen an das Entwicklungstemp und die Begehrlichkeit hinsichtlich zusätzlicher Funktinen und nachträglicher Änderungen. Teilweise traten sgar, wie ben erwähnt, Qualitätseinbußen ein. Der Zielknflikt zwischen der Endbenutzerrientierung und stabilen Prjektanfrderungen läßt sich whl nur auf dem Wege der Prjektkalkulatin bewältigen, zumal die Einbeziehung des Endbenutzers heute kaum ernsthaft in Frage gestellt wird. 7 Zusammenfassung Die Entwicklung des Infrmatinssystems ist inzwischen abgeschlssen. Zusammenfassend kann festgehalten werden, daß sie aufgrund der Verwendung vn 4GL-Tls in relativ kurzer Zeit durchgeführt werden knnte. Bei Implementierung in einer Sprache der dritten Generatin wäre sicherlich der Entwicklungsaufwand wesentlich größer gewesen. Diese "Erflge" wurden allerdings durch einige Mängel getrübt: Rbustheit, wie wir sie bei knventinellen Systemen zu verwirklichen suchen, war mit SQL*Frms nicht zu erreichen. Besndere Anfrderungen, die durch den Rahmen des Werkzeugs nicht abgedeckt sind, erfrdern überprprtinal hhen Aufwand. Schließlich ist jedem Entwickler zu empfehlen, die - wenn auch etwas spröde - Tastaturbelegung vn Oracle zu verwenden und nicht mit allen Mitteln zu versuchen, andere Belegungen zu realisieren.

23 Literatur Blte, C., Kurbel, K., Mazzami, M., Pietsch, W.: Ein Schnappschuß der Expertensystemszene in der Bundesrepublik Deutschland; Wirtschaftsinfrmatik 32 (1990) 1, S Chen, P.P.: The Entity-Relatinship-Mdel: Tward a Unified View f Data, ACM Transactins n Database Systems 1 (1976) 1, S Disterer, G.: Nichtprzedurale Prgrammierung; Angewandte Infrmatik 29 (1897) 7, S Eltzer, P.F.: Management vn Sftwareprjekten, Infrmatik Spektrum 12 (1989) 4, S Kurbel, K., Eicker, S.: Ein Streifzug durch die Welt der Prgrammiersprachen; DSWR 17 (1988) 1-2, S Kurbel, K., Labentz, M., Pietsch, W.: Prttyping und Prjektmanagement bei grßen Entwicklungsteams; Infrmatin Management 2 (1987) 1, S Kurbel, K., Pietsch, W.: Prjektmanagement bei einer Expertensystem-Entwicklung; Infrmatin Management 3 (1988) 1, S Mazzami, M.: Query-By-Windws - Eine grafikrientierte Datenbankabfragesprache, Angewandte Infrmatik 11/12 (1989), S N.N.: 4GL: Enttäuschte sind selbst dran schuld; Diebld Management Reprt (1989) 7, S Ruhnke, M: Mausunterstützung für SQL*Frms und RUNFORM; DOAG Newsletter 3 (1990) 3, S Scheer, A.-W.: Wirtschaftsinfrmatik - Infrmatinssysteme im Industriebetrieb; Berlin u.a