Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.06.1989 - 

Moderne Entwicklungssysteme arbeiten mit 4GL-Tools:

Anwendungen unabhängig von DB-Produkten entwickeln

Die Programmierer wollen mehr, als die Entwicklungstools der Datenbank-Management-Systeme (DBMS) in der Regel bieten. Adrian Schommers* setzt hier auf Entwicklungssysteme mit Techniken der vierten Generation. Voraussetzung sei jedoch, daß diese nicht an ein bestimmtes DBMS-Produkt gekettet werden.

Applikations-Entwickler erkennen schnell den Wert eines leistungsfähigen Datenbank-Management-Systems (DBMS). Ergänzend zum Kern solcher Systeme wurden Werkzeuge zur effizienten Entwicklung von Software geschaffen, Werkzeuge wie Report-Writer, Masken-Generator, Menü-Manager oder ein Design-Dictionary. Im Laufe der Zeit wurden diesen individuellen Werkzeugen weitere Möglichkeiten zur Seite gestellt, die jedoch ebenfalls einen ausgesprochenen individuellen Charakter aufweisen. Sie teilen bestenfalls das minimale Data-Dictionary mit dem DBMS-Kern.

Nach den Erkenntnissen der Software-Technologie ist ein Zugriff dieser Werkzeuge auf ein vollständiges Anwendungs-Daten-Lexikon, das mehr enthält als nur Datentypen und Spaltenbreiten, vorzuziehen. Da jedoch die Werkzeuge an ein bestimmtes Datenbank-System gebunden sind, ist der Zugriff auf Daten anderer Quellen, beispielsweise RMS-Dateien, ausgeschlossen. Offensichtlich ist ein grundlegender Ansatz zur Unterstützung der Anwendungsentwickler nötig, die den steigenden Anforderungen der Endanwender gewachsen bleiben wollen.

Moderne Entwicklungssysteme in 4GL-Technik erfüllen diese Anforderungen. Als architektonisches Grundkonzept hat sich die Drei-Schemata-Architektur nach dem ANSI/ISO-Standard bewährt. Direkt im Anschluß an die Phase der Daten Analyse kann hier der Entwickler die konzeptionelle Datenstruktur erstellen (Entities und Relationen) ebenso wie alle Integritäts-Regeln, Verarbeitungs-Constraints und Default-Spezifikationen.

Bewährt hat sich die Drei-Schemata-Architektur

Das konzeptionelle Schema bildet dabei die Grundlage für den gesamten Prozeß der Anwendungs-Entwicklung. Danach definiert der Entwickler die externen Schemata. Damit sind die Masken gemeint, mit denen der Endanwender arbeitet (also die Daten-Strukturen für eine Transaktion in Form von Masken). Er kann ferner externe Variationen für eine konzeptionelle Definition festlegen, wie sie für jede Maske benötigt werden.

Das interne Schema gibt dem System ein hohes Maß an Unabhängigkeit vom jeweiligen DBMS: Es bietet eine offene Schnittstelle, an die eine breite Palette unterschiedlicher Datenbanken und Dateisystemen angeschlossen werden können.

Die Schemata werden mittels einer Workbench erstellt und in einem zentralen Design-Daten-Lexikon abgelegt. Zur Laufzeit der Anwendung stehen diese Definitionen (die zum Erzielen einer hohen Performance kompiliert werden) bei der Kontrolle der Endanwender-Transaktionen mit dem Datenbestand zur Verfügung. Der Endanwender darf eine ansprechende, moderne, einheitliche und vollintegrierte Benutzeroberfläche erwarten.

Informationen, die über Maskeninhalte hinausgehen, präsentieren sich ein einer modernen Oberfläche beispielsweise als Pop-up-windows. Das Konzept dafür wird durchgehend für alle Dialog-Funktionen mit unterschiedlichen Maskentypen wie Menü, Index- und Code-Listen eingesetzt. So kann man statt eines zusätzlichen Report-Generators gleich Masken in einem professionellen Seitenlayout und mit Zwischenergebnissen ausdrucken lassen.

Von zentraler Bedeutung sind Benutzeroberflächen

Datenstrukturen sind leicht "einsichtig", wenn ein scrollbarer Rahmen Entities umschließt. Ein Rahmen im Rahmen weist auf eine Relation hin. Die Rahmen enthalten stets konsistente Daten, was unabhängige Blöcke ausschließt. Felder werden in Fenstern gezeigt, die man scrollen und zoomen kann. Ein Struktur-Editor der Daten, für Abfragen und Aktualisierungen, zum Drucken und zur Steuerung der Anwendung erleichtert die Bedienung, insbesondere wenn strukturierte Befehle, wie REMOVE OCCURRENCE, NEXT FIELD sowie ein vollständiger Satz Full-screen-Editierfunktionen zur Verfügung stehen. Auch das Aufrufen anderer Masken in beliebiger Schachtelungs-Tiefe darf kein Problem aufwerfen.

Beim Bearbeiten und Hin- und Herspringen zwischen den verschiedenen Masken sollten unmerklich für den Endanwender verschiedene Verarbeitungsroutinen wie Eingabe-Validierung, feldinhaltsabhängige Ansteuerung weiterer Eingabefelder, Umbelegung von Funktionstasten, Abgleich der Datenintegrität oder eine Datensperrung ablaufen. Solche Aktionen werden im konzeptionellen und/oder im externen Schema definiert und zur Laufzeit automatisch ausgeführt, sobald der Endanwender die entsprechenden Trigger auslöst.

Das konzeptionelle Schema: In ihm weist der Entwickler Entities zu und definiert dafür Schlüsselfelder. Er kann ferner den Datenobjekten Attribute zuordnen oder globale Feldmodelle definieren. Ein erweitertes relationales Datenmodell wird zum Definieren von 1:n Abhängigkeiten zwischen den verschiedenen Entities genutzt. Natürlich sind auch andere Beziehungen möglich.

Starre Löschverfahren schränken zu sehr ein

Für jede Abhängigkeit werden Fremdschlüssel-Felder ebenso definiert wie die Regeln für die Abhängigkeiten der Lösch-Operationen (referential integrity). In Übereinstimmung mit dem ANSI-Standard SQL werden Löschoperationen kaskadiert ausgeführt. Beim Löschen beispielsweise eines Firmeneintrags in einer Datenbank werden die gespeicherten Rechnungen der Firma ebenfalls gelöscht. Die Operation kann aber auch "restricted"(zum Beispiel: keine Löschung, solange die Rechnung noch offen ist oder "nullified" (nur Relation wird gelöscht) durchgeführt werden. "Subtypes" von Entitäten erlauben dem Entwickler, komplexe Strukturen sowie rekursive Abhängigkeiten innerhalb eines Datenobjektes zu definieren (zum Beispiel Firma - Filialen) oder mehrfache Abhängigkeiten zwischen Entities zu erfassen.

Nach der Festlegung der Daten-Strukturen im konzeptionellen Schema kann eine Fülle von Definitionen und Constraints für jedes Datenobjekt jedes Feld oder jede Domäne eingegeben werden. Definitionen unterschiedlicher Syntax-Prüfungen, Rechenformeln, Anzeigeformate, Sortierungen zusätzlicher Daten-Unterstrukturen, Existenzprüfungen und anderer kontextabhängiger Validierungen finden ohne weiteres Platz im konzeptionellen Schema.

Die externe Datenstruktur entsteht am Paint-Tableau

Definitionen werden entweder in der üblichen Weise deklariert oder in komplexen Fällen als Prozeß-Spezifikation erfaßt. Solche Spezifikationen werden in einer produktspezifischen 4GL-Sprache auf Triggerebene geschrieben.

Das externe Schema: Zum Entwerfen der Masken des externen Schemas enthält die Werkbank ein "Paint Tableau". Dieses sollte nicht nur zum Entwerfen der Masken eignen sondern vor allen auch zur Definition der externen Datenstruktur. Der Entwickler legt den Pfad durch das konzeptionelle Schema mit einer Rahmen-im-Rahmen-Technik fest.

Diese Feststellung erleichtert sowohl dem System selber, Abhängigkeiten zwischen Entities zu verstehen und zu überprüfen.

Das Konzept sollte auf Knopfdruck verfügbar sein

Ein Beispiel: Durch Eingeben des Rahmens "Person "in den Rahmen Firma teilt der Entwickler dem System alles mit, was es benötigt, um beispielsweise SQL-Befehle für Abfragen oder Aktualisierungen zu erzeugen. Beim Erstellen der Masken kann das konzeptionelle Schema per Knopfdruck aufgerufen werden. Auf diese Weise lassen sich selbst Masken mit zahlreichen Entities in Minutenfrist erstellen beziehungsweise verbessern.

Beim Erstellen ist es oft sinnvoll zusätzlich Constraints und Definitionen auf Feld-, Entity- und Masken-Ebene zu erfassen. Diese externen Variationen ergänzen die Definitionen und Defaults des konzeptionellen Schemas. Obwohl externe Schemata zahlreiche unterschiedliche Funktionen beherrschen, sind sie alle auf gleiche Weise definiert.

Werden die Daten einer Maske gedruckt, sollte das System automatisch die Entity-Fenster erweitern um alle Einträge zu zeigen.

Durch Kompilieren der externen Schemata entstehen leistungsstarke Tabellen, die anschließend geladen und ausgeführt werden. Externe Schemata sind ohne weiteres funktionstüchtig und können nach der Kompilierung getestet werden.

Portabilität ist ein Bestandteil der Methode

Das interne Schema: Es basiert auf den Definitionen im konzeptionellen Schema. Das System sollte für jede zu unterstützende Datenbank spezielle Treiber zur Verfügung stellen, die DDL und DML in der jeweiligen Datenbank-Sprache erzeugen.

In einem hochintegrierten, modernen System sind die individuellen Masken keine Anwendungen; stattdessen fügen sich eine Vielzahl externer Schemata zu einer Gesamt-Anwendung zusammen Bei der Definition des Programms kann der Entwickler verschiedene Festlegungen treffen. Diese betreffen die Belegung der Tastatur und den Bildschirmplatz für Systemmeldungen ebenso wie Bibliotheken, die Routinen in Sprachen der dritten Generation enthalten oder Prozeduren, die beim Aufruf der Anwendung durchgeführt werden.

Zur konsequenten Verwirklichung dieser Drei-Schema-Architektur gehört auch, auf die Portabilität der Anwendungen zu achten. Nur dann sind die Entwicklungs-Investitionen langfristig gesichert.

*Adrian Schommers ist Referent bei der Gesellschaft für Elektronische Informationsverarbeitung mbH (GEI in Aachen.