Der Einsatz von Tabellen ist längst eine Selbstverständlichkeit. Vor allem bei neuen Anwendungprojekten wird heute nicht mehr darüber diskutiert, ob ein Tabellensystem eingesetzt wird, sondern nur, wie der Einsatz optimiert werden kann.

Zwischen der einfachen Verwendung von Tabellen in Programmen und der konsequenten Entwicklung tabellarisch gesteuerter Software besteht ein großer Unterschied. Ein Tabellensystem erfüllt nur dann alle Erwartungen,

- wenn die Verantwortlichkeit für die Definition, Erfassung und Pflege eindeutig den Fachabteilungen zugeordnet wird, denn erst dann wird die DV-Abteilung von Routinetätigkeiten entlastet;

- wenn die Projektentwicklung im gesamten Software-Lebenszyklus unterstützt wird.

Selbst DV-unerfahrene Anwender neigen intuitiv dazu, bereits in den Anfangsphasen eines Projektes die Probleme ihrer fachlichen Welt tabellarisch abzubilden. Das Tabellensystem, das bereits in dieser Phase einsetzbar sein soll, muß eine einfach zu bedienende Dialogoberfläche und einen komfortablen Editor bieten. Da in der Regel weder die Tabelleninhalte noch deren Struktur so bleiben, wie sie anfangs entworfen werden, müssen sie leicht änderbar sein: Felder und Attribute können entfallen oder hinzukommen, ohne daß die bisher erfaßten Daten und

Informationen verlorengehen dürfen.

Die Zuordnung klarer Verantwortlichkeiten für Tabellen ist ein weiterer wichtiger Aspekt: Bereits bei der Anlage muß festlegbar sein, wer die Pflege übernehmen soll. Bei anwendungsbezogenen Übersichten resultiert hieraus eine unmittelbare, erhebliche und andauernde Aufwandsminderung für die DV.

Hinzu kommt: Die meisten Tabellen liegen in maschinenlesbarer Form vor. Eine sequentielle Schnittstelle zur Daten. Übernahme ist deshalb unbedingt erforderlich. Umgekehrt kann es nötig sein, sie wieder in ein sequentielles Format zu konvertieren. Aussagekräftige Projektunterlagen bedingen zudem eine umfassende Dokumentationsfunktion.

Bereits bei der Tabellendefinition werden - im allgemeinen - logische Zusammenhänge erkannt: Ein Feld kommt in verschiedenen Übersichten vor. Diese können künftig nicht mehr unabhängig voneinander geändert werden. Ein Tabellensystem muß diese Zusammenhänge darstellen und den Sachbearbeiter im Bedarfsfall darauf aufmerksam machen.

Dieses Problem kann durch Zusammenlegen der betroffenen Tabellen gelöst werden. Praktikabel ist dieses Verfahren allerdings nur bei einfachen Strukturen und geringen Datenmengen. Andernfalls entstehen hochkomplexe und nicht mehr durchschaubare Datensammlungen. Überdies besteht die Gefahr, mehrere fachliche Aspekte untereinander und zusätzlich mit technischen Aspekten zu vermischen, so daß die Verantwortlichkeit meist nicht mehr eindeutig zuzuordnen ist. Hierdurch entstehen außerdem Redundanzen, deren Pflege äußerst fehleranfällig ist. Die während der Analyse erfaßten Daten müssen in späteren Phasen weiterverwendet werden können. Da zu diesem Zeitpunkt noch kein Programmdesign vorliegt, darf mit der Definition und Anlage einer Tabelle keine Festlegung auf Zugriffsarten und -wege verknüpft sein. Sich in der Programmierphase zu entscheiden, mit welchen Begriffen nach welchen Feldern gesucht, Bord, ermöglicht erst die generelle Verwendbarkeit von Tabellen.

Ein reibungsloser Übergang von der Analyse- zur Entwicklungsphase wird durch die Weiterverwendung der erfaßten Tabellendaten gewährleistet jetzt kommen weitere, technisch orientierte Tabellen hinzu, die von der DV zu definieren und zu pflegen sind, während die anwendungsbezogenen Übersichten der ersten Phase weiterhin vom Fachbereich verwaltet werden.

Die Normalisierung von Daten führt generell zu ihrer tabellarischen Darstellung. Der vollständigen Ablage in einem entsprechenden System stehen lediglich Mengenprobleme gegenüber, da Großbestände in Tabellen kaum pflegbar sind. Andererseits: Häufig benutzte steuernde Parameter sowie Schlüssel und deren Umsetzung in Text gehören unbedingt dorthin.

Ein zentraler Aspekt ist, daß Tabellen nicht nur feldweise weiterbar sein müssen, sondern daß Programmzugriffe über Feldnamen erfolgen können: Nur so werden Tabellenerweiterungen ohne Programmänderungen ermöglicht und die Programme von der physischen Feldstruktur der Tabelle entkoppelt.

Ebenso wichtig ist eine umgebungsneutrale Call-Schnittstelle: Sowohl formal als auch inhaltlich muß gleich sein, ob der Aufruf des Tabellensystems aus CICS, IMS, Batch oder einer sonstigen Umgebung erfolgt.

In jeder DV gibt es getrennte Umgebungen für Entwicklung, Integrationstest, Systemtest, Schulung, Produktion. Ein Tabellensystem muß in der Lage sein, sich jedem Vorhandenen Modell anzupassen. Durchlaufen Programme verschiedene Freigabestufen - von Test bis zur Produktion beispielsweise - müssen das die ihnen zugeordneten Tabellen ebenfalls.

Untersuchungen bei verschiedenen Anwendern haben ergeben, daß je nach Alter und funktionaler Komplexität eines Softwaresystems zwischen 20 und 70 Prozent der Änderungen tabellarische Daten betreffen. Oft wird das nicht erkannt, da in Übersichten darstellbare Probleme meist in den Programmen codiert sind. Unter der Voraussetzung, daß die gesamte Software tabellengesteuert ist, sind beispielsweise bei Änderungen von Steuersätzen selbst bei Umgruppierung einzelner Produktgruppen nur Feldinhalte von Tabellen auszutauschen.

Die Revisionsfähigkeit von Änderungen ist ebenfalls wichtig. Zur Sicherheit gehört ein Auftragsstart-Verfahren, das die Gesamtkonsistenz aller Änderungen kontrolliert und den logischen Zusammenhang der Übersichten kennt.

Sicherheits-Features in Security-System einbinden

Die Änderungsberechtigung muß im Tabellensystem selbst geregelt sein. Die Sicherheits-Features für die Übersichten sind in das bestehende Security-System einzubinden. Das Auftragsabschluß-Verfahren hat dafür zu sorgen, daß die geänderten Tabellen logisch konsistent in die Produktion überführt werden. Wichtig ist eine strikte Trennung von Test- und Produktionstabellen. Auftragsstart- und -abschluß-Verfahren müssen in die jeweilige Entwicklungsumgebung eingebunden werden.

In den meisten Fällen ist es notwendig, daß die alte Version einer geänderten Tabelle auch nach erfolgter Aktualisierung noch erhalten bleibt. Eine Historisierungsoption muß dafür sorgen, daß alte Tabellengenerationen weiter dokumentiert und über Stichdatum und -zeit auswertbar sind: Steuersätze der Vorjahre müssen weiterhin zur Verfügung stehen. Tabellenversionen sind mit zukünftigem Stichtag zu ändern und vorzubehalten.

Natürlich darf auch der Leistungsaspekt nicht vernachlässigt werden. Dafür braucht es Paging-Verfahren auf Tabellen- und Zeitebene, um häufig benötigte Informationen im Hauptspeicher zu halten. Das System muß sich selbst optimieren, da sich die Zugriffserfordernisse zeitabhängig ändern.

Der Einsatz eines Tabellensystems betrifft zunächst alle Neuprojekte. Im weiteren zeitlichen Verlauf sollte die gesamte Software eines Unternehmens sukzessive dieses System nutzen. Es ist dabei zu berücksichtigen, daß die zeitlichen Abhängigkeiten groß sein können und einer Gesamtplanung möglicherweise entgegenstellen. Eventuell müssen bestehende alte Tabellensysteme entweder abgelöst oder simuliert werden. Zusätzlich zum feldweisen Zugriff sind daher zeilen- oder tabellenweise Zugriffe erforderlich.