Arbeitet man mit Native I/O, so erfolgt der Dateizugriff meist mit Hilfe von geschlüsselten, DDS-beschriebenen logischen Dateien. Da DDS jedoch seit Release V5R3 stabilisiert ist, sollte nach Alternativen für DDS-beschriebene logische Dateien Ausschau gehalten werden. Logische Dateien werden von SQL normalerweise wie Views behandelt.
Da Views immer ungeschlüsselt sind, ist ihr Einsatz in Verbindung mit Native I/O nur in Ausnahmefällen sinnvoll. Schüssel-Informationen werden in SQL-Indices gespeichert. SQL-Indices können zwar in SQL-Statements nicht angegeben werden, mit Native I/O können SQL wie geschlüsselte DDS-beschriebene logische Dateien verwendet werden.
In diesem Artikel wird gezeigt, wie die vorhandenen geschlüsselten Dateien in entsprechende SQL-Indices umgesetzt werden können.
Reverse Engineering von DDS-beschriebenen logischen Dateien
Logische Dateien werden von SQL wie Views behandelt. Da SQL Views jedoch immer ungeschlüsselt sind, für den Zugriff mit Native I/O jedoch i.d.R. Schlüssel erforderlich sind, ist die Umsetzung von logischen Datei in Views wenig sinnvoll.
Ob beim Reverse Engineering von DDS-beschriebenen logischen Dateien der Erstellungs-Code einer View, eines Indexes oder sowohl einer View als auch eines Indices generiert wird, hängt davon ab, ob eine der folgenden Optionen angegeben wurde:
- Generate Index instead of view
= Parameter INDEX_INSTEAD_OF_VIEW_OPTION in Stored Procedure GENERATE_SQL
Wird diese Option angegeben, wird ein CREATE INDEX-Statement generiert. Der Name des Indices entspricht dem Namen der logischen Datei.
Sofern in der ursprünglichen DDS-Beschreibung SELECT/OMIT-Anweisungen vorhanden waren, werden diese in WHERE-Bestimmungen übersetzt und in die CREATE-INDEX-Definition integriert. - Generate Additional Indexes
= Parameter ADDITIONAL_INDEX_OPTION in Stored Procedure GENERATE_SQL
Wird diese Option angegeben, so wird sowohl das Erstellungs-Statement für eine View als auch für einen Index generiert. Der Name der View entspricht dem Namen der ursprünglichen logischen Datei, der Name des Indices wird neu generiert.
Sofern in der ursprünglichen DDS-Beschreibung SELECT-OMIT-Anweisungen vorhanden waren, werden diese in WHERE-Bedingungen übersetzt und sowohl in das Erstellungs-Statement für die View als auch in das Erstellungs-Statement für den Index integriert. - Sofern keine der beiden zuvor beschriebenen Optionen gesetzt wird, wird lediglich das Erstellungs-Statement für eine View generiert. Sofern in der ursprünglichen DDS-Beschreibung SELECT/OMIT vorhanden waren, werden diese in WHERE-Bedingungen konvertiert und in das CREATE-VIEW-Statement integriert. Schlüssel-Informationen gehen an dieser Stelle verloren.
Dabei ist aber folgendes zu beachten: Sofern die neuen Indices die vorhandenen logischen Dateien ersetzen sollen, müssen die logischen Dateien (vor dem Erstellen der Indices) gelöscht werden. Das Löschen von logischen Dateien kann wahlweise über den CL-Befehl DLTF (Datei löschen) oder mit einem der SQL-Befehle DROP VIEW oder DROP INDEX erfolgen. CREATE OR REPLACE ist für Indices nicht möglich.
Quelle: Birgitta HauserDas Beispiel in Bild 1 zeigt den SQL-Generierungs-Code für die DDS beschriebenen logischen Dateien aus unserem Beispiel (s. Teil 2 dieser Artikelserie). Das SQL-Skript wurde mit Angabe der Option Generate Index Instead of View erstellt. Die Schlüssel-Felder werden in der gleichen Reihenfolge in aufsteigender Sortierung, entsprechend der ursprünglichen DDS-Beschreibung ausgegeben.
Das Satz-Format wird aus der DDS-Beschreibung übernommen und explizit in den Erstellungs-Befehl mit Schlüssel-Wort RCDFMT integriert. Die Objekt-Beschreibung wird über den (generierten) Befehl LABEL ON INDEX jeweils zu den Indices hinzugefügt.
Erstellen SQL-Indices
Sofern vor Erstellung der Indices und vor dem Löschen der DDS beschriebenen logischen Dateien die Einträge in der Catalog-View SYSTABLES geprüft werden, werden die logischen Dateien mit TABLE_TYPE L wie im folgenden Beispiel angezeigt.
Quelle: Birgitta HauserDie Catalog-View SYSTABLES enthält Informationen über alle DDS beschriebenen physischen und logischen Dateien, alle SQL-Tabellen, alle SQL Views, alle Materialized Query Tables (MQT) sowie alle Aliase. Sie enthält jedoch keinerlei Informationen über SQL-Indices. Diese Informationen können über die Catalog View SYSINDEXES abgerufen werden.
Im nächsten Schritt werden die logischen Dateien gelöscht. Dies kann wahlweise über den CL-Befehl DLTF (Datei löschen) oder über einen der SQL-Befehle DROP VIEW oder DROP INDEX erfolgen. Alternativ können die vorhandenen logischen Dateien entweder über den IBM i Navigator – Database (Client Access for Windows) oder Access Client Solutions (ACS) – Schemas gelöscht werden. Dabei muss beachtet werden, dass die logischen Dateien unter der Rubrik View zu finden sind.
Nach dem Löschen der logischen Dateien, kann das zuvor generierte SQL-Skript (Bild 2) ausgeführt werden. Prüft man nach erfolgreicher Erstellung der Indices die Einträge in der Catalog-View SYSTABLES, so wird man feststellen, dass die Einträge für die logischen Dateien verschwunden sind, und sich keine Informationen über die erstellten Indices finden lassen, wie Bild 3 beweist.
Quelle: Birgitta HauserPrüft man die Einträge in der Catalog View SYSINDEXES, in der alle SQL-Indices enthalten sind, findet man für die neu-erstellten Indices die entsprechenden Einträge, wie Bild 4 zeigt.
RPG- und Cobol-Programme, in denen zuvor die logischen Dateien über Native I/O verarbeitet wurden, können nach der Konvertierung der logischen Dateien in SQL-Indices unverändert und ohne Probleme ausgeführt werden. Eine Umwandlung der vorhandenen Programme ist nicht erforderlich.
Quelle: Birgitta HauserLogische Dateien mit SELECT/OMIT Anweisungen
Wie bereits erwähnt können auf für DDS beschriebene logische Dateien mit SELECT/OMIT-Anweisungen die entsprechenden SQL-Erstellungs-Befehle ermittelt werden. Abhängig von der Angabe der Optionen „Generate Index instead of View“ oder „Generate additional Indexes“ werden die Erstellungs-Befehle für eine View oder einen Index oder sowohl für eine View als auch einen Index generiert.
Die SELECT/OMIT-Anweisungen werden dabei in WHERE-Bedingungen übersetzt und dem CREATE Statement für die View und/oder den Index zugefügt. Die folgende Abbildung (Bild 5) zeigt die DDS-Beschreibung einer logischen Datei mit SELECT/OMIT-Anweisung. Bei Zugriff auf die logische Datei werden nur die Umsätze aus dem Jahr 2009 (numerisches Datumsfeld) verarbeitet.
Quelle: Birgitta HauserÜber Reverse Engineering mit Angabe der Option „Generate Index instead of View“, wurde das folgende SQL Skript generiert. Die Schlüssel-Felder werden in der gleichen Reihenfolge wie in der DDS-Beschreibung der logischen Datei mit aufsteigender Sortierung implementiert. Die SELECT/OMIT-Anweisung wird in eine WHERE-Bedingung übersetzt und integriert. Das in der DDS-Datei angegebene Satz-Format wird explizit übernommen.
Quelle: Birgitta HauserOb für einen Index WHERE-Bedingungen vorhanden sind und wenn ja welche lässt sich aus der Catalog-View SYSINDEXES ermitteln.
Die folgende Abbildung (Bild 7)zeigt den Eintrag für den (konvertierten) Index SALESL04 in der Catalog-View SYSINDEXES.
Quelle: Birgitta HauserSoweit zur Konvertierung von logischen Dateien in SQL-Indices mit und ohne SELECT/OMIT-Anweisungen. Und nun viel Spaß beim Konvertieren von logischen Dateien und Anlegen von SQL-Indices.
Birgitta Hauser