Allein die Investition in eine Sprache der vierten Generation (4GL) bedeutet noch keine Herstellerunabhängigkeit meint Dieter Jenz*. Die fehlende Normierung der 4GL-Werkzeuge schafft nämlich auf der anderen Seite enge Bindungen zu den Anbietern relationaler Datenbanksysteme, die mit dem Versprechen der Produktivitätssteigerung auf Kundenfang gehen.
Relationale Datenbanksysteme werden sich - nicht zuletzt aufgrund neuer, leistungsfähiger Architektur ("Multi-Server"-Konzept) - durchsetzen. Die oft CPU-intensive Optimierung von Abfragen kann durch das Parallelrechner-Konzept im Mehrbenutzerbetrieb wirkungsvoll unterstützt w erden. Mit außerdem steigender Hardwareleistung tritt das bisher oft genannte Problem des geringeren Durchsatzes in der Zukunft in den Hintergrund. Signifikante Leistungsverbesserungen lassen erwarten, daß auch mit relationalen Datenbanksystemen in nicht allzu ferner Zukunft Transaktionsraten erreichbar sind, wie sie bisher nur den konventionellen Datenbanksystemen (hierarchische DBs, Netzwerk-DBs) vorbehalten waren.
Die Softwareinvestitionen stellen mittlerweile bei DV-Lösungen die wichtigste Komponente für unternehmerische Entscheidungen dar. Die Produktivitätsfortschritte der letzten Jahre bei der Software-Erstellung können auch bei optimistischer Grundeinstellung nur in Teilbereichen als befriedigend bezeichnet werden. Damit ist der Boden für Sprachen der vierten Generation bereitet, denn diese versprechen einen wesentlich verkürzten Entwicklungs- und Wartungsaufwand. Darüber hinaus soll es dem Endanwender mit einer Sprache der vierten Generation ermöglicht werden, seine Aufgaben selbst zu formulieren und damit die "Abhängigkeit" von spezialisierten Softwareentwicklern abzubauen.
Mit einer Sprache der vierten Generation allein ist es jedoch nicht getan. Weitere Werkzeuge, wie zum Beispiel Bibliotheksverwaltungssystem, Masken-Editor und -Generator sowie Berichts-Generator müssen hinzukommen, um eine geschlossene Entwicklungsumgebung herzustellen. Erst dann ist der Anspruch auf signifikante Produktivitätssteigerung nachhaltig erfüllbar. Es gibt deshalb keinen Hersteller eines relationalen Datenbanksystems, der nicht zusätzlich eine Reihe von Software-Entwicklungswerkzeugen anbietet.
Das Marketing-Argument der Zeit und Kostenersparnis hat durchaus seine Berechtigung. Untersuchungen unseres Unternehmens ergaben, daß nicht wenige Anwendungen durchaus in einem Zehntel und weniger der Zeit entwickelt werden können, die für die Entwicklung mit konventionellen Programmiersprache n der dritten Generation angesetzt werden muß. Dennoch verlangt die Entscheidung zum Einsatz dieser Werkzeuge Sorgfalt. Im Gegensatz zum Prinzip der Herstellerunabhängigkeit droht hier die enge Bindung an den Hersteller, denn Sprachen der vierten Generation sind bis dato noch nicht genormt.
Der Produktivitätsvorteil hängt zunächst sehr stark mit dem Konstruktionsprinzip der Sprache, der Grundphilosophie zusammen. Im Dialog-Betrieb liegt die Initiative der Anwendungssteuerung beim Bediener. Er steuert die Anwendung durch Tastendruck, das heißt, die Anwendung muß auf Ereignisse von außen reagieren. Ein sequentieller Ablauf des Programms ist nur in den wenigsten Fällen möglich. In Batch-Anwendungen ist es zwar nicht der Anwender, der von außen eingreift, dennoch lassen sich auch für Batch-Anwendungen "Ereignisse" identifizieren, die sich steuernd auf den Programmablauf auswirken. Dazu zählt beispielsweise der Gruppenwechsel.
Im Batch-Betrieb kann jedoch mit jedem "Ereignis" eine vorgegebene Aktion verknüpft werden, so daß sich letzten Endes doch ein sequentieller Programmablauf ergibt. Die Reaktion auf ein "Ereignis" kann vorbestimmt werden, da sich aufgrund der Aufgabenstellung keine Alternativen anbieten. Auch bei Dialog-Betrieb kann für jedes Ereignis eine Aktion in Form von Programmcode vorgesehen werden. Dem Bediener stehen im Regelfall mehrere Alternativen der Steuerung offen, so daß sich die Reaktion des Anwenders nicht unbedingt vorbestimmen läßt.
Die Grundphilosophien lassen sich deshalb grob in die zwei Kategorien "ereignisgesteuerter" und "programmflußgesteuerter" Ablauf einteilen. "Ereignisgesteuert" bedeutet, daß die Ausführung eines Programms nicht sequentiell erfolgt. Jedes Ereignis fungiert als Auslöser ("Trigger") einer Folge von Befehlen im Programm. Angewandt auf eine Dialog-Anwendung bedeutet dies, daß nach einem Tastendruck das Anwendungsprogramm die Kontrolle erhält und entscheidet, welches Code-Fragment auszuführen ist oder eine mit einer Taste verbundene Programm-Routine ausgeführt wird.
Ereignis- oder Programmfluß-Steuerung
Bei CICS/VS wird die Kontrolle an das Anwendungs-Modul übergeben, nachdem eine Taste, die eine Unterbrechung auslöst, gedrückt wurde. Anwendungslogik wird gespart, wenn eine Funktionstaste bereits fest mit einer Befehlsfolge verbunden werden kann. Vertreter dieser Philosophie sind zum Beispiel Ingres/ABF und SQL * Forms (Oracle). Der "ereignisgesteuerte" Ablauf eröffnet gleichzeitig die grundsätzliche Möglichkeit, die Anwendung so wohl auf "Block Mode" - als auch auf "Character Mode"-Terminals ab laufen zu lassen. Eine "Ereignissteuerung" setzt jedoch gleichzeitig einen Basis-Programmablauf voraus, das heißt, die mit Ereignissen verknüpften Code-Fragmente stellen lediglich eine Ergänzung zu einer vorgegebenen Programmstruktur dar. Auf diesem Prinzip beruht eine Vielzahl von Generatoren wie auch RPGII beziehungsweise RPGIII.
Das Prinzip der Steuerung durch den Programmfluß ist mehr für sequentielle Abläufe geeignet und entspricht der herkömmlichen Programmiertechnik mit Programmiersprachen der dritten Generation. Dies hat beispielsweise zur Folge, daß-bezogen auf eine Dialoganwendung - die Betätigung einer Funktionstaste nur dann eine Wirkung hat, wenn mit der Funktionstaste im gerade in der Abarbeitung befindlichen Code-Segment eine Aktion verknüpft ist. Dieser Philosophie folgen ebenfalls einige Sprachen der vierten Generation wie Informix-4GL.
Ein weiteres wichtiges Unterscheidungsmerkmal bildet der Grad der Vorstrukturierung einer Anwendung. Dialoganwendungen folgen mit wenigen Ausnahmen einem gemeinsamen Konstruktionsprinzip. Aus diesem Grund liegt es nahe, bereits einen Dialograhmen vorzugeben und nur noch anwendungsindividuelle Arbeitsschritte zu programmieren. So kann zum Beispiel die Codierung der Programmierlogik für die Verwaltung von Bildschirmtabellen zum Blättern völlig entfallen. Bei einer konsequenten Verfolgung dieses Prinzips wird es möglich, den Aufwand für die Programmierung einer Dialog-Anwendung auf die Erzeugung einer Bildschirm- Maske zu reduzieren. Ingres/ABF und SQL*Forms folgen diesem "Programming-by-exception"- Ansatz .
Vorstrukturierung erhöht den Anpassungsaufwand
Neben dem Vorteil drastisch verringerten Codieraufwandes muß jedoch auch eine Einschränkung der Flexibilität bedacht werden. Sind betriebsindividuelle Anwendungsnormen zu berücksichtigen, kann sich das "Korsett" als zu eng erweisen, so daß die Anpassung einer Anwendung an betriebsindividuelle Konventionen zu überproportionalem Aufwand (SQL*Forms) führen kann. Andere Entwicklungswerkzeuge wie Informix-4GL strukturieren die Anwendung kaum vor. Dies bedeutet jedoch andererseits, daß viele Standard-Funktionen ausprograrammiert werden beziehungsweise als Modul zur Verfügung gestellt werden müssen.
Aufgabenspezifische Werkzeuge mit einem hohen Strukturierungsgrad haben noch einen weiteren Vorteil: ein höheres Maß an Programm-Unabhängigkeit. So können Blätterfunktionen ohne Zwischenschritt über eine Tabelle im 4GL-Programm gelöst werden. Die Pufferung der gelesenen Tabellenzeilen wird dem Programmierer somit abgenommen, und auch das "Mapping" zwischen einer Programm-Tabelle und einer Tabelle auf dem Bildschirm entfällt. Dies ist beispielsweise bei Ingres/ABF und SQL*Forms in dieser Weise gelöst, während mit Informix- 4GL die Dimensionierung einer Programm-Tabelle vorgegeben werden muß, daß alle Tabellenzeilen in die Programm-Tabelle passen. Ein Anpassungsbedarf ist somit immer latent vorhanden.
Wird dem Entwickler zuviel Arbeit abgenommen, können sich jedoch auch negative Auswirkungen bemerkbar machen. Im konkurrierenden Mehrbenutzerbetrieb muß strikt darauf geachtet werden, daß Transaktionen möglichst von kurzer Dauer sind, um gegenseitige Behinderungen der Anwender weitgehend zu vermeiden. SQL*Forms bestimmt selbst, wann eine Transaktion gestartet wird, überläßt jedoch die Beendigung einer Transaktion dem Anwender (per vordeffnierter Funktionstaste). Beendet der Anwender eine Transaktion nicht, können sich entsprechende unliebsame Folgen einstellen. Der Entwickler muß selbst eingreifen und dafür sorgen, daß Transaktionen rechtzeitig beendet werden.
Der Professionalitätsgrad bestimmt den Sprachumfang
Aus Entwicklersicht wird die Anwendungsfreundlichkeit natürlich zu einem hohen Grad vom Sprachumfang und den Strukturierungsmöglichkeiten der 4GL-Sprache bestimmt. Hier besteht von vornherein ein Widerstreit zwischen der Endbenutzerorientierung, die eine einfache Sprache verlangt, und den Anforderungen effizienter, "professioneller" Programmierung. Es gibt durchaus 4GL-Sprachen, deren Sprachumfang mit dem von 3GL-Sprachen vergleichbar ist. In diese Kategorie fällt Informix-4GL, eine Sprache, die in ihrer Struktur sehr an die Programmiersprache "C" erinnert, die jedoch bei weitem nicht an die Funktionsvielfalt von "C" herankommt (Pointer-Hierarchien sind zum Beispiel nicht implementiert).In der Tat wird aus einem Informix- 4GL-Programm zunächst direkt ein "C"-Programm generiert, das dann vom Compiler weiterverarbeitet wird.
Anderen Sprachen wie Ingres-4GL fehlen wesentliche Komponenten einer konventionellen Programmiersprache wie beispielsweise die Tabellenverarbeitung. Ebenso sind Einschränkungen hinsichtlich der Modularisierung der Anwendungen hinzunehmen. Dies hat seinen Grund der Dialogorientierung dieser Sprachen. Klassische Aufgaben der Batch-Verarbeitung können - abgesehen von der Berichterstellung - nur mit großen Einschränkungen durchgeführt werden und bleiben eher einer konventionellen Programmiersprache vorbehalten.
Das Zauberwort "SQL-Kompatibilität" bedarf ebenfalls einer genauen Überprüfung. Obwohl nahezu alle Entwicklungswerkzeuge über eine SQL-Schnittstelle verfügen, bedeutet dies noch lange nicht, daß damit tatsächlich Kompatibilität auf Sprachebene hergestellt werden kann. In der Implementierung des SQL-Standards ergeben sich bekanntlich viele kleine, teilweise aber auch schwerwiegende Unterschiede. Zunächst müssen zwei Ebenen der ANSI-SQL-Implementierung, nämlich Stufe 1 und Stufe 2, unterschieden werden. Die Stufe 1 bildet eine Untermenge der Stufe-2-Implementierung und unterstützt deshalb einige wichtige Ausprägungen der ANSI-SQL-Sprache nicht.
Aus einem anderen Blickwinkel betrachtet, läßt sich durchaus noch eine weitere Einteilung treffen: ANSI-SQL-Standard und DB2-Standard. DB2 unterstützt im Gegensatz zu ANSI- SQL die Ausführung von DDL(Data Definition Language)- und DML(Data Manipulation Language) Kommandos sowohl interaktiv als auch im Kontext eines Programms. ANSI-SQL beschränkt die Verwendung von DDL-Befehlen hingegen auf die interaktive Ausführung. Außerdem ist das Konzept eines System-Katalogs nicht im Standard enthalten. Die DB2-Ausprägung von ANSI-SQL hingegen ermöglicht die Abfrage des Katalogs mit SQL-Select- Befehlen. Darüber hinaus unterstützt der DB2-Ansatz einen erweiterten Befehlssatz, der die Verwaltung der verschiedenen Datenbank-Objekte erleichtert.
Es ist nicht erforderlich, sehr enge Maßstäbe anzulegen, um festzustellen, daß die ANSI-SQL- und DB2-SQL- Implementierungen derzeit nicht völlig kompatibel sind. In einigen Teilbereichen geht die DB2-SQL-Implementierung über den Standard hinaus, bleibt jedoch in anderen - allerdings weniger wichtigen - hinter dem ANSI-SQL-Standard zurück.
Ein Vergleich von SQL-Implementierungen der verbreitetsten Datenbanksysteme ergibt ein diffuses Bild. Die meisten Hersteller-Implementierungen unterstützen mittlerweile den ANSI-Standard Level 2, aber nicht durchgängig. Die aktuelle Ingres-Implementierung (Version 5) enthält zwar bereits Level-2-Elemente, ist jedoch eher dem Level 1 zuzuordnen (die nahezu vollständige Unterstützung der Stufe 2 ist für die Version 6 vorgesehen). Allen gängigen Sprach-Implementierungen gemeinsam ist jedoch die Unterstützung der DB2-Philosophie.
SQL-Befehle wirken auf die gesamte Anwendung
Zusätzlich erschwert wird eine Zuordnung durch herstellerspezifische Erweiterungen, die zwar alle komforterhöhend wirken, aber nicht mehr dem eigentlichen SQL-Standard entsprechen. So bietet Informix zum Beispiel die Möglichkeit mit "Grant" für den SQL-Befehl "Select" Privilegien für eine Tabelle auf Tabellenspaltenebene zu vergeben. Hier entsteht eine teilweise Kollision mit "Views", da mit beiden Möglichkeiten die Absicht verfolgt wird, die Benutzersicht auf eine Tabelle auf bestimmte Tabellenspalten zu beschränken.
Obwohl unsere Untersuchungen zeigen, daß SQL-Befehle in vielen Anwendungen nur etwa zehn bis fünfzehn Prozent der Befehle ausmachen, darf daraus keinesfalls auf eine geringe Bedeutung des SQL-Standards geschlossen werden. Die "Ausstrahlung" der SQL-Befehle auf die Gesamtstruktur einer Anwendung ist nicht zu unterschätzen. Dies trifft insbesondere dann zu, wenn Integritätsbedingungen nicht mehr im Anwendungsprogramm, sondern vom Datenbanksystem selbst geprüft werden.
Integrität auf Tabellenebene und referentielle Integrität müssen zwar derzeit noch hauptsächlich von der Anwendung sichergestellt werden (Ausnahmen sind zum Beispiel Ingres mit einer Möglichkeit zur Sicherung der Integrität auf Tabellenebene sowie DB2 mit referentieller Integrität ab Version 2.1), aber CS wird in Zukunft möglich sein, Integritätsbedingungen vom Datenbanksystem zentral prüfen zu lassen. Der ANSISQL-Standard wird entsprechend fortgeschrieben werden. Nur dadurch ist gewährleistet, daß Prüflogik nicht immer wieder redundant in den Anwendungsprogrammen vorhanden sein muß und dadurch gleichzeitig ein echter Produktivitätsvorteil erzielt wird.
Bei der Betrachtung von 4GL-Entwicklungsumgebungen darf das Thema Homogenität nicht zu kurz kommen . Unter dem Begriff Homogenität sei hier die einheitliche Entwicklungstechnik, das einheitliche Erscheinungsbild der verschiedenen Komponenten einer 4GL-Entwicklungsumgebung verstanden. Kurz: der Entwickler soll nicht für Dialoganwendungen die eine "Sprache" und für die Erstellung von Berichten eine andere "Sprache" erlernen müssen. Hier ist eine prozedurale 4G- Sprache aufgrund konzeptioneller Nähe zu konventionellen Programmiersprachen im Vorteil. Alle Anwendungen, ob Dialog- oder Batch- Anwendung, ob Stammdatenpflege- Programm oder Umsatzliste, können mit einem einheitlichen Sprachvorrat entwickelt werden.
Anders ist dies beim "Programming-by-exception"- Ansatz. Typische Dialog- und Batchaufgaben bedingen einen unterschiedlichen Basis-Programmablauf. Es lag deshalb nahe, für Dialog- und Batchaufgaben unterschiedliche Werkzeuge bereitzustellen. Leider ergaben sich dadurch syntaktische Stilbrüche. So muß der Entwickler bei Ingres/ABF zwei unterschiedliche "Sprachen" lernen, wenn er Dialoganwendungen und Auswertungen mit Berichterstellung entwickeln will, nämlich Ingres- 4GL und Ingres-Report-Writer. Nicht anders ergeht es ihm beim Einsatz der Oracle-Produkte SQL*Forms und SQL*Report (künftig SQL*Report Writer).
Im Blickpunkt steht insbesondere die Einbindung der verschiedenen Module in eine Anwendung. Ingres/ ABF als Beispiel strukturiert eine Anwendung in einzelne Module ("Frames"). Mehrere Arten von "Frames" werden unterschieden: "Anwender-definierte Frames" " Report Frames" und "OBF Frames" (QBF = Query-By-Forms)."Anwender-definierte Frames" werden hauptsächlich zur Durchführung von Dialog-Arbeitsschritten erstellt und enthalten Ingres-4GL-Code; "Report Frames" enthalten (" Report-Writer")-Anweisungen zur Berichterstellung und "QBF Frames" fungieren gewissermaßen als Schnittstelle zum Ingres-Standard-Modul "Query-By-Forms".
Die verschiedenen Module ("Frames") lassen sich zu einer hierarchisch geordneten Gesamtanwendung zusammenbinden, da jeder "Frame" die Kontrolle an einen anderen "Frame" abgeben und ein gerufener "Frame" die Kontrolle wieder an den rufenden "Frame" zurückgeben kann. Im Vergleich dazu geschieht das Einbinden verschiedener Anwendungs-Module in eine Anwendung bei Oracle mit SQL* Menü . Dieses Produkt verfügt über einen Menü-Generator, der es ermöglicht, Anwendungs-Module zum Beispiel ,(SQL * Forms-Anwendungen) als Menü-Optionen einzubinden und aufzurufen. SQL*Menu ist jedoch derzeit noch nicht in allen Oracle-Versionen verfügbar.
Data Dictionaries mit Objekten für Anwendungen
In nahezu jedem Hersteller-Prospekt ist die Rede von einem "Data Dictionary". Gebraucht wird dieser Begriff oft im Sinne des System-Kataloges, welcher die Beschreibung aller Datenbank-Objekte enthält. Um den Entwicklungs- und Wartungsprozeß effektiv unterstützen zu können, muß das Data Dictionary jedoch ,auch anwendungsbezogene Objekte, wie Masken-Definitionen, aufnehmen können. Dies ist jedoch nicht immer der Fall: Informix-4GL speichert zwar auch anwendungsbezogene Objekte, jedoch nur Attribute und Validierungsvorschriften. Besser im Vergleich schneidet Ingres ab, denn alle Masken, Berichts-Definitionen, Programm-Module werden im Data Dictionary gespeichert. Bei Oracle hingegen werden zwar SQL*Form-Definitionen, nicht jedoch SQL*Report-Definitionen in das Data Dictionary eingetragen.
Die Verbindung von Data Dictionary und Anwendungen läßt im Hinblick auf die Unabhängigkeit und Wartungsfreundlichkeit der Anwendungen teilweise zu wünschen übrig. Gesetzt den Fall, daß im Anwendungs-Modul eine lokale Variable definiert werden muß, deren Fomat von einer Tabellenspalte in einer Relation abhängt, so ist für die Wartungfreundlichkeit entscheidend, ob die Attribute aus der zugehörigen Tabellenspalte übernommen werden können oder nicht. Kann dies geschehen, so führt eine spätere Änderung der Definition der Tabellenspalte zu keinen Problemen. Das Anwendungs-Modul muß lediglich neu umgewandelt werden. Im anderen Fall muß jedes Anwendungs-Modul angepaßt werden, falls sich die Definition der Tabellenspalte ändert.
Die fehlende Normierung von 4GL-Sprachen führt zwar einerseits zu sprachlichem Wildwuchs und Inkompatibilitäten, hat jedoch durchaus auch ihre positiven Aspekte. Normen können bekanntlich aus Innovationen behindern und sind doch keine uneingeschränkte Garantie dafür, daß wirkliche Kompatibilität und Portabilität gewährleistet wird. Verwiesen sei in diesem Zusammenhang nur auf Cobol, wo die Dialogschnittstelle zur Maskenbehandlung nicht genormt ist. Die verschiedenen Ansätze (herstellerspezifische Erweiterungen der Cobol- Syntax oder "Call- Schnittstelle") führen letzten Endes auch dort zu schwerwiegenden Kompatibilitätsdefiziten und zu Herstellerabhängigkeit.
Trotz des Zeit- und Kostenvorteils darf nicht gefolgert werden, daß die Softwareentwicklung mit 4GL- Sprachen insgesamt einfacher würde. Die Einbindung in den Softwareentwicklungs-Prozeß gestaltet sich teilweise sogar schwieriger. Bewährte Prinzipien des Software-Engineering lassen sich nicht immer realisieren, so daß zum Beispiel der Prozeß der Modulbildung nach anderen Gesetzmäßigkeiten abläuft. Einige Datenbank Hersteller gehen dieses Problem an und bieten Design-Hilfsmittel an.
Für die Modulbildung gelten andere Gesetze
Oracle stellte mit SQL*Design Manager bereits ein Produkt vor, Relational Technology entwickelt derzeit ebenfalls ein Produkt. Damit ist zwar das Problem in der Gesamtheit noch nicht gelöst, die Ansätze gehen, jedoch in die richtige Richtung.
Konventionelle 4GL-Sprachen wie Informix-4GL sind im Vorteil, wenn es um die Modularisierungstechnik geht. Hier können dieselben Grundsätze, die auch für 3GL-Anwendungen gelten, angewandt werden. Bei anderen Produkten sind jedoch teilweise erhebliche Einschränkungen hinzunehmen. So können in Ingres- 4GL-Prozeduren, die für externe Module stehen, keine lokalen Variablen deklariert werden. Alle Daten, auf die das Modul zugreift, müssen über die Schnittstelle übergeben werden. Die Folge sind breite Schnittstellen. die Komplexität der Schnittstellen kann in umfangreichen Anwendungen zur Immobilität führen, da nachträgliche Änderungen weitreichen Folgen haben können. Auch mit der derzeitigen Version von Oracle SQL* Forms müssen Einschränkungen beachtet werden. "Trigger" sind zwar an sich bereits Module, jedoch fehlt in der derzeitigen Version ein Bibliothekskonzept, um externe Module, das heißt Code-Segmente, die in mehreren Anwendungen verwendet werden, zu verwalten. Derzeit müssen identische Code-Segmente ("Trigger") für jede Anwendung separat codiert werden, was zu einer unheilvollen Code-Redundanz führen kann. Gemildert werden kann dieses Problem dadurch, daß CodeTeile aus dem Data Dictionary dynamisch aufgerufen werden. Allerdings führt dies wiederum zu einem Leistungsverlust.
Ein gewichtiger zeitlicher Anteil der Entwicklungsphase wird vom Anwendungstest beansprucht. Entscheidend ist hier, wie die Testaktivitäten unterstützt werden. Zunächst ist festzustellen, daß in einer 4GL- Anwendung nicht unbedingt weniger Fehler auftreten können als in einer 3GL-Anwendung. Für 3GL-Anwendungen ist mittlerweile eine Vielzahl von Textwerkzeugen verfügbar, die von den in die Sprache "eingebauten" Möglichkeiten über "Debugger" bis hin zu Test-Monitoren mit komfortablen Instrumentierungsmöglichkeiten reichen. Dies ist bei 4GL-Werkzeugen noch nicht der Fall. Teilweise sind sogar erhebliche Defizite festzustellen. So gibt es bei SQL*Forms zwar eine Möglichkeit die Ausführung der "Trigger" zu verfolgen, jedoch erstreckt sich diese Möglichkeit nicht auf die "Trigger Steps". Diese wäre jedoch erforderlich, da "Trigger Steps" innerhalb eines "Triggers" konditionell ausgeführt werden können. Ingres-4GL verfügt über keine Möglichkeit der Ablaufverfolgung. Informix-4GL hingegen bietet über die Komponente ."Rapid Development System" einen "Debugger" an.
Nicht zuletzt muß der Aspekt der Datensicherung gebührend berücksichtigt werden. Es ist zweifellos von Vorteil und vermeidet Inkonsistenzen, wenn alle Objekte zentral im Data Dictionary gehalten werden. Ergibt sich im Data Dictionary jedoch aufgrund eines Systemfehlers eine Inkonsistenz, so kann dies den Totalverlust aller Informationen bedeuten. Tabellen- und "View"- Definitionen können problemlos wiederhergestellt werden, falls diese in Prozeduren außerhalb des Data Dictionary gehalten werden. Probleme können jedoch bei Maskendefinitionen entstehen, wenn die Schnittstelle "nach außen" fehlt; dies ist zum Beispiel bei Ingres und bedingt bei Oracle der Fall. Es ist deshalb dringend erforderlich, regelmäßige Datensicherungen des Data Dictionary in mehreren Generationen durchzuführen.
Oft wird voreilig nur die Softwareentwicklung in die Betrachtung einbezogen. Die Zeit- und Kostenvorteile können jedoch drastisch schwinden und sich sogar ins Gegenteil verkehren, wenn die Wartung der 4GL- Anwendungen zu aufwendig wird. Ausschlaggebend dafür ist in erster Linie die Transparenz der Codierung. Diese ist bei konventionellen 4GL-Sprachen sicher gegeben, anders sieht es jedoch bei Werkzeugen nach dem "Programming-by-exception" -Ansatz aus. So wird bei Oracle-SQL * Forms keine " Programm-Liste " zur Dokumentation erzeugt. Eine mit vertretbarem Aufwand interpretierbare Dokumentation kann nur mit einem im Standard-Lieferumfang nicht enthaltenen Werkzeug erstellt werden. Mit SQL*Forms alleine kann die Wartung einer komplexen Anwendung sehr aufwendig werden.
Schließlich sollte noch der Schulungsaufwand gebührend berücksichtigt werden. Obwohl die Hersteller- Prospekte die Anwendungserstellung als eine einfache Angelegenheit ausgeben, darf dieser keinesfalls unterschätzt werden. Unseres Erachtens darf nicht weniger budgetiert werden als bei Schulungen für konventionelle Anwendungen. Sollen Endanwender selbst Anwendungen erstellen, muß eher ein noch höherer Aufwand angesetzt werden. Die Gefahr, daß sich Benutzer durch ungeschickte Transaktionsgestaltung gegenseitig blockieren, ist groß.
Es wäre auch verfehlt, zu diesen Zeitpunkt davon zu sprechen, daß 4GL-Entwicklungsumgebungen au breiter Front den erforderlichen Integrationsgrad erreicht haben. Viele Datenbankhersteller kamen mit ernstzunehmenden Datenbankprodukten erst Anfang der achtziger Jahre auf den Markt. Erst jetzt ist festzustellen, daß den 4GL-Produkten größere Bedeutung beigemessen wird. Für die nahe Zukunft sind ins besonders in diesem Segment beachtliche Fortschritte zu erwarten.
Die Bindung an den Hersteller stellt sicherlich das größte Problem dar, wenn es um die Entscheidung für oder gegen den Einsatz eines herstellerspezifischen 4GL-Entwicklungssystems geht. Enorme Investitionen stehen auf dem Spiel, da der spätere Umstieg auf eine andere Lösung nur noch mit großem finanziellen Aufwand bewerkstelligt werden kann. Es sind keine Standard-Werkzeuge vorhanden, um zum Beispiel eine Ingres/ABF-Anwendung in eine Oracle-SQL * Form-Anwendung umzusetzen und umgekehrt. Diese Problematik kann teilweise durch Einsatz eines "Hybrid"-Produkts entschärft werden. Ein solches Produkt bietet eine eigene 4GL-Oberfläche und ermöglicht die Unabhängigkeit vom spezifischen Datenbanksystem.
Noch zu oft beschränkt sich Datenbank-Evaluation auf die Funktionalität der Datenbank. Falls nicht von vornherein die Absicht besteht, alle Anwendungen mit konventionellen Programmiersprachen zu entwickeln, muß genauso großes Gewicht auf die Evaluation der Entwicklungswerkzeuge gelegt werden. Wird eine Fehlentscheidung getroffen, kann sich diese im Vergleich zu konventioneller Anwendungsentwicklung sogar schwerwiegender auswirken und unter Investitionsgesichtspunkten mindestens genauso drastische Folgen zeitigen.
*Dieter Jenz ist Geschäftsführer der Jenz und Partner GmbH, Bad Homburg.