Schlüsseltabellen liefern zu einem kurzen Schlüssels ausführlichere, detailliertere Daten. Der Schlüssel kann ein einzelnes Feld sein oder aus mehreren Feldern zusammengesetzt sein. Die aus einem Schlüssel ableitbaren Detaildaten sind i.d.R. in mehrere Feldern aufgeteilt. Diese können selbst auch wiederum als Schlüsselwerte in einer anderen oder gar der gleichen Schlüsseltabelle gedacht sein. Auch können Einträge in einer Schlüsseltabelle mit einem Gültig-Ab Kennzeichen versehen werden, und/oder als nicht mehr gültig markiert werden (historisierte Schlüsseltabelle).
Die TAA bietet Unterstützung für die strukturelle und inhaltliche Definition von Schlüsseltabellen. Auch zur Laufzeit sind diverse Unterstützungen für die Nutzung von Schlüsseltabellen verfügbar. Die Schlüsseltabellendaten sind zur Laufzeit grundsätzlich nur abfragbar und nie modifizierbar.
Die Arbeit mit Schlüsseltabellen gliedert sich prinzipiell in drei Schritte:
Eine Schlüsseltabelle besteht aus zwei Komponenten: einer Datenstruktur, und einer Tabelle. Die Datenstruktur bestimmt die Struktur der Tabelle.
Die Datenstruktur zu einer Schlüsseltabelle wird in Rochade als D-Relation oder Entität erfasst und gepflegt. Diese Struktur kann mit TablEdge oder DataStrEdge angesehen, aber nicht bearbeitet werden.
Der Inhalt der Schlüsseltabelle kann mit dem Tool TablEdge erfasst und gepflegt werden, und wird dann ebenfalls in Rochade gespeichert.
Einige Schlüsseltabellen werden nicht über Rochade und TablEdge, sondern in Datenbanken gepflegt und auch dort gespeichert (ohne Verwendung von TAA-Tools). Diese Tabellen können nur dann mit TAA-Tools (hier: Iedge Reftab) gelesen und weiter verarbeitet werden, wenn die Felder der Tabelle namentlich und im Format genau der Datenstruktur der Schlüsseltabelle entsprechen. 1)
Um den Inhalt einer Schlüsseltabelle für weitere Verarbeitungsschritte verfügbar zu machen, ist es notwendig, diesen zunächst als csv-Datei zu exportieren. Quelle für den csv-Export ist i.d.R. der mit TablEdge erfasste und in Rochade abgelegte Inhalt; es ist aber auch möglich, eine csv-Datei aus einer in einer Access-Datenbank definierten Schlüsseltabelle zu erstellen.
Diese Funktionen werden über Iedge Reftab ausgeführt.
Die Datenstruktur-Datei (i.d.R. <name>.stb) für die Ressourcen-Dll kann separat über die Iedge-Funktion DstrImp erzeugt werden.
Für die csv-Dateien sowie für die Datenstruktur-Datei wird nicht der Langname der D-Relation oder Entität verwendet, sondern eine Kurzbezeichnung, die sich aus der Anwendung und dem Kürzel der Schlüsseltabelle zusammensetzt, z.B. VOSGT für die D-Relation „GEVO-TYP-TABELLE“, Kürzel „SGT“, aus der Anwendung „VO“. Dies ist notwendig, da die Schlüsseltabellen zur Laufzeit unter dieser Bezeichnung gesucht werden.
Anschließend müssen die Schlüsseltabellen (Datenstruktur und i.d.R. auch Inhalt) in einer Ressourcen-Dll bereitgestellt werden.
Um Schlüsseltabellen in Ressourcen-Dlls zur Verfügung zu stellen, müssen die erzeugten csv- und Struktur-Dateien in die betreffende Ressourcen-Dll generiert werden. Die Ressourcengenerierung erfolgt mit dem Batch-Tool taado.
Für Schlüsseltabellen gibt es 3 Typen von Ressourcen:
RefGenResOstr über die Registry einschaltet ist. Die Unterschiede zwischen STBC und STBO sind hier beschrieben.Die erzeugten Ressourcen können mit ReflEdge angesehen werden.
Um von mit der TAA native Api auf Schlüsseltabellen zugreifen zu können, müssen diese in sogenannten Basis-Assemblies zur Verfügung gestellt werden.
Dies erfolgt über das Tool TeamWise.ExpEdge.
Die Inhalte der Schlüsseltabellen können in den Basis-Assemblies als Konstante abgelegt werden, oder zur Laufzeit dynamisch geladen werden, wobei auf die zuvor erstellen Ressourcen-Dlls zugegriffen wird.
Um den Zugriff und die Suche nach Schlüsseltabellen zu steuern, kann ein Eintrag in der Registry-Section dbConfig angelegt werden.
Die meisten der Einträge in dbConfig beziehen sich auf den Zugriff auf Datenbanken. Folgende Settings allerdings sind nur für Schlüsseltabellen relevant, und das auch, wenn deren Inhalte nicht in Datenbanken abgelegt sind:
Zur Optimierung des Laufzeitverhaltens kann die TAA-Infrastruktur Schlüsseltabellenzugriffe cachen, und zwar sowohl Zugriffe auf Einzelsätze als auch ganze Tabellen. Um dieses Feature zu aktivieren, muss in der TAA-Datenbankkonfiguration für die Datenbank, die die Schlüsseltabellen enthält, der Eintrag Caching = 1 gesetzt sein (s. auch hier). Ausnahme: Wenn für einen Zugriff mit Schlüssel mehr als 1 Satz als Ergebnis geliefert wird, werden diese nicht gecacht.
Beim Zugriff über TAA native-Api ist das hier beschriebene Caching irrelevant.
Dieses Setting bewirkt, dass Schlüsseltabellen zuerst in den Ressourcen-Dlls gesucht werden, danach ggf. in der angegeben Datenbank. Es sollte i.d.R. auf true gesetzt sein.
Zusätzlich kann LoadStbcFromResOnly angegeben werden, damit Schlüsseltabellen ausschließlich aus Ressourcen-Dlls geladen werden.
Wenn dieses Setting true ist, versucht die TAA Infrastruktur, Standard-Schlüsseltabellenzugriffsmodule intern auszuführen statt diese aufzurufen, s. hier.
Schlüsseltabellen werden in Form eines TAA-Objekts vom Typ REF zur Verfügung gestellt. Der Objekttyp ist die zugrundeliegende D-Relation oder -Entität (definiert in Rochade). Die Struktur wird aus der Ressourcen-Dll oder der Basis-Assembly gelesen; der Name der Struktur setzt sich zusammen aus dem Anwendungskürzel und dem dreistelligen Kurznamen der Tabelle.
Die Struktur der Schlüsseltabellen wird zur Laufzeit aus der zuvor erstellen Ressourcen-Dll oder Basis-Assembly geladen. Das gleiche gilt i.d.R. für den Inhalt, wobei dieser in einigen Fällen auch aus einer Datenbank gelesen wird (z.B. bei Nutzung von Standard-Zugriffsmodulen).
Der Zugriff auf Schlüsseltabellen über die TAA native Api ist hier beschrieben.
Das Caching einmal geladener Schlüsseltabellen erfolgt bei Nutzung der TAA native-Api immer automatisch. Zusätzliches Vorhalten von Schlüsseltabelleninhalten in der Anwendung ist nicht notwendig, bring keinerlei Laufzeitersparnis, und sollte vermieden werden!
Beim Zugriff über - i.d.R. in Cobol implementierte - standardisierte Datenzugriffsmodule wird die Schlüsseltabelle aus der Datenbank oder der Ressourcen-Dll gelesen.
Für die Standard-Zugriffe gibt es spezielle Objekttypen, die in Rochade aus der D-Relation oder Entität abgeleitet werden. Bei deren Datenstruktur ist dem eigentlichen Tabelleninhalt ein 4-stelliger Header vorangestellt, um die Zugriffsart und das -Ergebnis zu übergeben. Die Namen dieser Objekttypen sind einheitlich aufgebaut, und zwar
DZUG-STRUKTUR-<schlüsseltabellenkurzbezeichnung>, z.B. DZUG-STRUKTUR-VOSGT
Ein Objekt dieses Typs ist immer als Parameterobjekt für den betreffenden Datenzugriff definiert.
Bei der Generierung des Ressourcentyps STBO wird entsprechend ebenso jedem Schlüsseltabellen-Satz dieser Header vorangestellt.
Die TAA-Infrastruktur kann die Aufrufe von Schlüsseltabellenzugriffsmodulen simulieren und selbst die entsprechenden Zugriffe durchführen. Dafür müssen folgende Voraussetzungen erfüllt sein:
Das Verhalten der ursprünglichen COBOL-Zugriffsmodule wird möglichst genau simuliert; der Inhalt des Parameterobjekts ist nach dem Zugriff gleich. Einzige Einschränkung: Es dürfen beim Zugriff über ExecuteInternal nicht zwei Zugriffstypen gemischt werden, d.h. es können nicht in einem Modulaufruf sowohl die gesamte Tabelle als auch einzelne Sätze aus der Tabelle gelesen werden.
Über CompleteRef kann in einem TAA-Modul der Inhalt einer Schlüsseltabelle in ein lokales Objekt vom Typ REF geladen werden. Anschließend kann der Inhalt wie bei einem „normalen“ Listenobjekt abgefragt werden.
Completeref wird untstützt von
Die TAA ISAPI-Extension kennt einen Befehl trf zum Laden einer gesamten Schlüsseltabelle in XML-Format. Der Befehl dst der TAA ISAPI-Extensionunterstützt jetzt auch die Lieferung von Definitionen für Schlüsseltabellen.
Im TAA Monitor werden beim Zugriff auf Schlüsseltabellen Informationen vom Typ „Architetcture Trace and Information“ ausgegeben.
Je nach Relevanz, werden die Informationen zwischen Infolevel 0 und 5 ausgegeben. Um alle Informationen angezeigt zu bekommen, sollte der Infolevel auf mindestens 5 eingestellt werden.
Bei Zugriff auf Ressourcen-Dll:
RefDB: Contents of <typ> <name> retrieved from resource RefDB: Record for <typ> <name> retrieved from resource
Bei Zugriff auf gecachte Daten:
RefDB: Contents of <typ> <name> added to cache as <cacheschlüssel> RefDB: Contents of <typ> <name> retrieved from cache as <cacheschlüssel>" RefDB: Record of <typ> <name> added to cache as <cacheschlüssel> RefDB: Record of <typ> <name> retrieved from cache as <cacheschlüssel>"
Bei Zugriff auf Datenbank:
RefDB: Contents of <typ> <name> retrieved from database
Zugriffe auf Schlüsseltabellendaten über Objektmanager-Operationen (z.B. in Cobol CompleteRef, Get First/Next) werden auch als „Objektmanager Operations“ protokolliert.
Module zum Schlüsseltabellenzugriff werden im Monitor wie alle Module mit Einträgen zu Register und Unregister sowie Performance protokolliert, wenn die entsprechende Option im Monitor eingeschaltet ist.
Wenn die Ausführung simuliert wird, erfolgt zusätzlich ein Architecture-Eintrag auf Infolevel 0:
RefDB-Module <name> executed internally.
In TestEdge gibt es eine Seite „Schlüsseltabellen“, wo die verwendeten Schlüsseltabellen sowie die protokollierten Zugriffe darauf angezeigt werden, sowohl allgemein als auch pro Baustein.
Die Trace-Informationen enthalten im Prinzip dieselben Angaben wie die oben beschriebenen Monitor-Ausgaben.
Einträge in einer Schlüsseltabelle können mit einem Gültig-Ab Kennzeichen versehen werden, und/oder als nicht mehr gültig markiert werden. Diese „Historisierung“ kann bei der Modellierung der Schlüsseltabelle bzw. D-Relation oder Entität in Rochade angegeben werden.
In der TAA native Api gibt es spezielle Zugriffsmethoden für diese Tabellen.
Hier noch einmal die wichtigsten Links, auf die in dieser Seite verwiesen wird:
Zusätzliche Informationen eher technischer Art, die für die Anwendungsentwicklung i.d.R. nicht relevant sind, finden Sie hier.