Portabilität auf der Betriebssystemebene ist nur der Anfang:

Standard-Datenbanksysteme erhöhen die Übertragbarkeit

27.05.1988

Beim Stichwort "Portabilität" drängt sich sofort der Gedanke an das Betriebssystem auf. Doch ein entscheidender Anteil an der Übertragbarkeit von Anwendungssoftware kommt auch dem Datenbank-Management-System (DBMS) zu. Ulrich Zacharias* erläutert das am Beispiel einer Anwendung im Bereich Finanzbuchhaltung.

Die Forderung nach Portabilität und Hardware-Unabhängigkeit setzt die Verwendung einer einheitlichen, auf Standards basierenden Anwendungsumgebung voraus. Das Betriebssystem Unix erfüllt diese Ansprüche: Es ist auf unterschiedlichster Hardware - vom PC bis zum Mainframe - verfügbar; darüber hinaus kann es aufgrund seiner inneren Struktur rasch auf neue Architekturen portiert werden.

Unix-Applikationen können über einfachen Dateitransfer auf unterschiedliche Rechner gebracht werden. Innerhalb kürzester Zeit - oft weniger als eine Stunde - sind bei beispielwiese Teile einer Finanzbuchhaltung von einer Unisys-Anlage auf einen IBM-Rechner des Typs RT 6150 sowie auf die Nixdorf-Maschinen Targon 31 und Targon 35 zu portieren.

Neben der leichten Übertragbarkeit ist auch die Entwicklungs-Produktivität bei der Verwendung von Unix-Systemen höher. Hier sind nämlich keine tiefen Kenntnisse unterschiedlicher Betriebssysteme und folglich auch keine verschiedenen Spezialisten erforderlich.

Im Datenmanagement sollten ebenfalls Standardkomponenten verwendet werden, die einerseits auf einer Vielzahl von Systemen verfügbar sind und andererseits eine hohe Entwicklungs-Produktivität gewährleisten. Die Verfügbarkeit des DBMS auf unterschiedlicher Hardware und unter verschiedenen Betriebssystemen erlaubt nämlich, die Applikationen relativ problemlos zu portieren. Die Portabilität des Datenbanksystems kann also die Übertragbarkeit der Anwendungen über den Unix-Rahmen hinaus auf andere Betriebssystemwelten wie IBM/MVS, VM, DOS/VSE, BS2000, DBC/VMS und OS/2 erweitern.

User-Wünsche werden stärker berücksichtigt

Leistungsfähige Software-Tools machen es möglich, den Endbenutzer bei der Entwicklung kundenspezifischer Lösungen starker einzubeziehen. Dadurch können die Applikationen laufend an neue User-Wünsche angepaßt werden.

Der Einsatz einer relationalen Datenbank erlaubt es, verschiedene Anwendungsbereiche über eine gemeinsame, redundanzfreie Speicherung der Daten zu verbinden. Somit treten keine Abstimmungsprobleme mehr auf. Durch die einheitliche und vollständige Datengrundlage kann ein erheblicher Informationsvorsprung erzielt werden. Ein Beispiel hierfür ist die Integration wichtiger Bereiche innerhalb des Rechnungswesens wie Auftragsbearbeitung, Fakturierung, Lagerverwaltung, Fibu, Bebu, Anlagenbuchhaltung sowie Lohn- und Gehaltsabrechnung.

In der Datenbank sind möglichst "unverarbeitete" Rohdaten gespeichert, die erst für die Auswertungen in der gewünschten Form aufbereitet werden. Über eine entsprechende Zusammenstellung der Information lassen sich jetzt neue Auswertungsanforderungen rasch realisieren. Probleme hinsichtlich der Datenkonsistenz werden somit also vermieden.

Relationale Architektur ist datenunabhängig

Das DBMS leistet selbständig viele Aufgaben, die mit einer herkömmlichen Dateiverwaltung erst noch programmiert werden müßten. Über ein "aktives Data-Dictionary" sorgt das System für Konsistenz und Integrität der Daten, die sich online verarbeiten lassen. Das sogenannte Transaktionskonzept - "alles oder nichts" - gewährleistet, daß sich der Datenbankzustand nur in einer definierten, konsistenten Weise ändert.

Ein Maskengenerator schließlich ermöglicht den komfortablen Zugriff auf die Datenbank. Dabei wird der Benutzer geführt und unterstützt alle Eingaben werden zum frühestmöglichen Zeitpunkt auf Vollständigkeit und Konsistenz geprüft, Fehleingaben mit einer erklärenden Meldung zurückgewiesen. Außerdem ist die relationale Datenbankarchitektur datenunabhängig, wodurch sich bestehende Applikationen leicht an neue Benutzeranforderungen anpassen und erweitern lassen.

Das Transaktionskonzept gewährleistet Konsistenz

Beim Beispiel Finanzbuchhaltung sollte das Softwaresystem folgende Ansprüche erfüllen:

- Die Finanzbuchhaltung ist mandantenfähig. Die Zahl der möglichen Mandanten wird nur durch den Speicherplatz beschrankt.

- Buchungsperioden können frei definiert werden. Für alle festgelegten Buchungsperioden ermittelt das System Verkehrszahlen (in dieser Periode angefallener Umsatz Soll/ Haben).

- Die Zahl der offenen und damit jederzeit bebuchbaren Perioden hängt nur von dem zur Verfügung stehenden Speicherplatz ab; das System kann dann entsprechend konfiguriert werden.

- Der Kontenplan sollte über eine. "Strukturdefinition festgelegt werden. Kontonummern können also frei gewählt werden und haben keine implizite Bedeutung. Durch Angabe von Paaren (Oberkonto, Unterkonto) läßt sich ein Kontenbaum beliebiger Tiefe und Breite erzeugen und im laufenden Betrieb dynamisch verändern.

- Zu buchen ist ein vollständiger Buchungssatz "Soll an Haben". Mit der Buchung wird sofort auf alle höheren Ebenen hin verdichtet, so daß die Kontostände im System jederzeit aktuell sind und ohne Abschluß jederzeit eine Summen- und Saldenliste (Zwischenbilanz) zur Verfügung steht.

- Das Transaktionskonzept gewährleistet einen konsistenten Stand der Datenbank. Prüfsummen sind nicht mehr erforderlich.

Schnelle und leichte Implementierung ist wichtig

Diese Forderungen können nur durch den Einsatz moderner Werkzeuge wirtschaftlich realisiert werden. Mit den geeigneten Tools läßt sich in kurzer Zeit ein Funktionsumfang bereitstellen, wie ihn manche Standardpakete erst nach mehrjähriger Entwicklungsgeschichte erreichen. Genauso wichtig wie eine schnelle und leichte Entwicklung ist jedoch die Möglichkeit, das System ebenso schnell und leicht beim Kunden zu implementieren beziehungsweise an dessen spezifische Bedürfnisse anzupassen.

Für eine internationale Baufirma wurde beispielsweise ein fertiges Fibu-Produkt um folgende wesentliche Merkmale erweitert:

- Die Bereiche Fibu und Bebu hat man integriert, so daß mit einer Buchung in der Fibu auch gleichzeitig in der Bebu gebucht wird. Abstimmungsprobleme zwischen den beiden Bereichen treten damit nicht mehr auf.

- Konten werden unterhalb von Kostenstellen geführt, denen wiederum Kostenträger (Bauwerke) zuzuordnen sind.

- Gebucht werden kann nur auf der untersten Ebene (Kostenstelle beziehungsweise Bauwerk). Kostenstellen-übergreifende Buchungen sind innerhalb einer Firma möglich; im Hintergrund werden jedoch zwei Buchungen (jeweils auf Abgrenzungskonten) durchgeführt.

- Durch die Einrichtung von Nebenbuchhaltungen läßt sich über eine komplexere Buchungslogik das Kostenstellen-übergreifende Buchen bewerkstelligen.

- GuV-Konten werden beim ersten Anbuchen auf allen Ebenen dynamisch angelegt; auf einer oberen Ebene ist das GuV-Konto jeweils ein Sammelkonto für die zugehörigen Konten der unteren Ebene.

- Bauwerk-abhängig kann ein bestimmter Währungskurs eingegeben werden, der bei der Buchung zugrunde gelegt wird.

- Für wichtige Dateien (Konten und Bauwerke) erfolgt bei jedem Neueintrag, jeder Änderung und jedem Löschvorgang ein Eintrag in eine "History" -Datei. Die Datenbanksuchfunktionen ermöglichen hier also komfortable Zugriffe und Auswertungen.

- Buchungen auf gesonderte Soll/ Haben-Felder innerhalb des Kontosatzes werden temporär gehandhabt, also nach Ablauf der Buchungsperiode storniert; periodische temporäre Buchungen können von der Vorperiode übernommen werden.

Produktivität plus Übertragbarkeit

Die Applikation wurde im Prototyping-Verfahren und in enger Zusammenarbeit mit dem Anwender erstellt, der unterschiedliche Unix-Systeme einsetzt. Produktivität und Portabilität beim Einsatz von Unix und SQL-Datenbanken ließen nichts zu wünschen übrig. Der allgemein vorherrschende Eindruck, daß es keine komplexen kommerziellen Anwendungen unter Unix gebe, dürfte damit widerlegt sein.

*Ulrich Zacharias ist Leiter Entwicklung kommerzielle Software bei der Hamburger Unica GmbH.