PL/SQL- Funktionen von. SQL aus aufrufen. Das Problem. In diesem Kapitel: Das Problem

Transkript

1 In diesem Kapitel: Das Problem Die Syntax für den Aufruf gespeicherter Funktionen in SQL Bedingungen an gespeicherte Funktionen in SQL Einschränkungen von PL/SQL-Funktionen in SQL Funktionen in Packages von SQL aus aufrufen Die Präzedenz von Spaltenund Funktionsnamen Die rauhe Wirklichkeit: PL/SQL-Funktionen in SQL aufrufen Beispiele eingebetteten PL/SQL-Codes 17 PL/SQL- Funktionen von SQL aus aufrufen PL/SQL ist eine prozedurale Spracherweiterung zu SQL. Daher können Sie aus Ihren PL/SQL-Programmen auch native SQL-Anweisungen wie SELECT, INSERT oder UPDATE aufrufen. Bis zur Version 2.1 von PL/SQL (die zur Oracle-Datenbank 7.1 gehört) konnten Sie allerdings keine eigenen PL/SQL-Funktionen in einer SQL-Anweisung verwenden. HINWE Die in diesem Kapitel beschriebenen Möglichkeiten stehen erst ab PL/SQL Version 2.1 zur Verfügung. Das Problem Die fehlende Möglichkeit, PL/SQL-Funktionen in SQL-Anweisungen verwenden zu können, führte oft zu häßlichen SQL-Anweisungen und redundanten Implementierungen von Geschäftsregeln. Nehmen wir beispielsweise an, Sie müssen das Gesamtgehalt eines Mitarbeiters sowohl in nativem SQL als auch in Ihren Formularen berechnen. Die Berechnung selbst ist einfach genug: Total compensation = salary + bonus Meine SQL-Anweisung würde diese Formel enthalten SELECT employee_name, salary + NVL (bonus, 0) FROM employee; 579

2 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen während mein Post-Query-Trigger in meiner Oracle Forms-Anwendung den folgenden PL/SQL-Code verwenden würde: :employee.total_comp := :employee.salary + NVL (:employee.bonus, 0); In diesem Fall ist die Berechnung sehr einfach, aber trotzdem müssen Sie all diese hartkodierten Berechnungen sowohl in den SQL-Anweisungen als auch in den Anwendungskomponenten im Frontend einzeln ändern, wenn sich die Formel zur Berechnung des Gesamtgehalts aus irgendeinem Grunde ändern sollte. Sehr viel besser ist es, eine Funktion zu schreiben, die das Gesamtgehalt zurückgibt: FUNCTION total_comp (salary_in IN employee.salary%type, bonus_in IN employee.bonus%type) RETURN NUMBER BEGIN RETURN salary_in + NVL (bonus_in, 0); END; Diese Formel kann ich dann folgendermaßen in meinem Code einsetzen: SELECT employee_name, total_comp (salary, bonus) FROM employee; :employee.total_comp := total_comp (:employee.salary, :employee.bonus); Vor der Version 2.1 von PL/SQL führte das zu folgendem Fehler ORA-00919: invalid function weil es in SQL keinen Mechanismus gab, Referenzen auf in der Datenbank abgespeicherte, vom Programmierer definierte Funktionen aufzulösen. Inzwischen ist die Verbindung zwischen PL/SQL und SQL aber ausgeglichener. Das ist auch sinnvoll so, denn die Funktionen werden ohnehin in der Datenbank abgelegt (wie nicht anders zu erwarten, in einer Tabelle) und stehen daher der SQL-Schicht über eine SELECT-Anweisung zur Verfügung. Seit der Version 2.1 von PL/SQL können Sie jetzt an jeder Stelle in einer SQL-Anweisung, in der ein Ausdruck erlaubt ist, gespeicherte Funktionen aufrufen, darunter in den SELECT-, WHERE-, START WITH-, GROUP BY-, HAVING-, ORDER BY-, SET- und VALUES-Klauseln (weil gespeicherte Prozeduren selbst ausführbare PL/SQL-Anweisungen sind, können diese nicht in eine SQL-Anweisung eingebettet werden). Sie können Ihre eigenen Funktionen genauso wie die Built-in- SQL-Funktionen wie etwa TO_DATE, SUBSTR oder LENGTH verwenden. Auf der Begleitdiskette ist ein Package namens ps.parse (bestehend aus den Dateien psparse.sps und psparse.spb) enthalten, in dem es eine Funktion gibt, welche die Anzahl der Atome (Worte und/oder Begrenzungszeichen) in einem String zurückgibt. Das kann ich direkt in einer SQL-Anweisung verwenden, um die Verteilung der Worte in einer Reihe von Textnotizen anzuzeigen: 580

3 Das Problem SELECT line_number, ps_parse.number_of_atomics (line_text) AS num_words FROM notes ORDER BY num_words DESC; Beachten Sie, daß ich in diesem Fall dem Funktionsaufruf mit der»as«-syntax einen Spaltenalias zugewiesen habe. Diesen kann ich dann in ORDER BY verwenden, ohne die Syntax des Funktionsaufrufs selbst erneut angeben zu müssen. Die Möglichkeit, programmiererdefinierte PL/SQL-Funktionen in SQL zu verwenden, ist eine sehr mächtige Erweiterung der Oracle-Entwicklungsumgebung. Mit diesen Funktionen können Sie folgendes tun: Die Logik von Geschäftsregeln in einer kleinen Anzahl optimierter und leicht wartbarer Funktionen zusammenfassen. Sie müssen diese Logik nicht über die einzelnen SQL-Anweisungen und PL/SQL-Programme verteilen. Dieser Punkt ist wahrscheinlich der weitreichendste und wichtigste Vorteil bei der Verwendung von Funktionen. Die Performanz Ihrer SQL-Anweisungen verbessern. SQL ist eine nichtprozedurale Sprache, aber die Anforderungen der Anwendung bedingen doch oft prozedurale Logik in Ihrem SQL-Code. SQL ist robust genug, so daß Sie immer irgendwie an die Antwort kommen können, aber in manchen Situationen ist das zu ineffizient. Eingebettetes PL/SQL kann den Job manchmal schneller erledigen. Natürlich kostet es auch ein wenig, diese Funktionen aufzurufen, weswegen Sie sorgfältig abwägen und ausprobieren müssen, wo und wann PL/SQL-Funktionen in SQL am meisten nützen. Ihre SQL-Anweisungen vereinfachen. All die Gründe, aus denen sie PL/SQL-Code verwenden sollten, gelten auch für SQL, insbesondere wenn es darum geht, komplizierte Ausdrücke und komplizierte Logik hinter einer Funktionsspezifikation zu verstecken. Von der DECODE-Anweisung bis zu verschachtelten, korrelierten Subselects können programmiererdefinierte Funktionen die Lesbarkeit vieler SQL- Anweisungen verbessern. Aktionen in SQL durchführen, die sonst unmöglich wären. SQL ist eine Sprache, die immer eine Menge zur Zeit bearbeitet, die aus Zeilen besteht, auf die dann irgendwelche Aktionen angewendet werden. Iterative Verarbeitung über einzelne Spaltenwerte ist nicht möglich. Wenn Sie beispielsweise die Anzahl der Vorkommnisse eines Substrings in den Namen von Firmen ermitteln wollen, dann geht das mit reinem SQL nicht. Sie können aber in einer SELECT-Liste eine PL/SQL-Funktion über den Firmennamen laufen lassen, der diese Art von iterativer Verarbeitung durchführen kann. Sie können Funktionen in einer VALUES-Liste, einer SET-Klausel oder einer GROUP BY-Klausel verwenden. Hier folgen ein paar Beispiele dazu: VALUES-Liste. Schauen Sie sich das folgende Beispiel an: INSERT INTO notes (call_id, line_text, line_number) 581

4 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen VALUES (:call.call_id, :note.text, next_line_number (:call.call_id)); Die Funktion next_line_number holt die nächste laufende Nummer der Notizen zu diesem Vorfall (Sie könnten zwar einen Folgenummerngenerator verwenden, um die nächste eindeutige Vorfallnummer zu erhalten, aber die line_number für Notizen fängt immer wieder bei 1 an, so daß man hier keinen Folgenummerngenerator verwenden kann). SET-Klausel. Die Funktion max_compensation gibt das höchstmögliche Gehalt in der Abteilung eines Angestellten wieder. UPDATE employee SET salary = max_compensation (department_id) WHERE employee_id = 1005; In diesem Fall ersetzt die Funktion max_compensation ein Subselect, das die Funktion AVG verwenden würde, um den Wert zu berechnen. GROUP BY-Klausel. Meine Firma hat die Vereinheitlichung der Titel nicht besonders gut hinbekommen; es gibt 15 verschiedene Versionen von stellvertretenden Geschäftsführern, 20 verschiedene Manager usw. Die folgende SELECT-Anweisung räumt mit dieser Verwirrung auf und zeigt das Gesamtgehalt für jede Job-»Kategorie«an. SELECT job_category (job_title_id) as title, SUM (salary) FROM employee GROUP BY title; Die Funktion wird sowohl in der SELECT-Liste als auch in der GROUP BY-Klausel verwendet. Die Syntax für den Aufruf gespeicherter Funktionen in SQL Eine gespeicherte Funktion wird aus einem SQL-Ausdruck mit der gleichen Syntax wie in einem PL/SQL-Ausdruck aufgerufen: [schema_name.][package_name.][funktions_name[@db_link_name][parameter_liste] Hierbei ist schema_name der optionale Name des Datenbankschemas, in dem die Funktion definiert ist (üblicherweise Ihr Oracle-Benutzerkonto), Package_name ist der optionale Name des Packages, in dem die Funktion definiert ist (wenn es sich nicht um eine freistehende Funktion handelt), funktions_name ist der Name der Funktion, db_link_name ist der optionale Name der Datenbankverbindung, wenn Sie einen entfernten Prozeduraufruf (remote procedure call) ausführen, und parameter_liste ist die optionale Liste der Parameter der Funktion. Wenn die Funktion calc_sales folgendermaßen definiert ist 582

5 Bedingungen an gespeicherte Funktionen in SQL FUNCTION calc_sales (company_id_in IN company.company_id%type, status_in IN order.status_code%type := NULL) RETURN NUMBER; dann kann diese Funktion von SQL aus wie folgt aufgerufen werden: Als freistehende Funktion: SELECT calc_sales (1001, 'O') FROM orders; Als Funktion in einem Package: SELECT sales_pkg.calc_sales (1001, 'O') FROM orders; Als entfernter Aufruf einer Funktion in einem Package: SELECT (1001, 'O') FROM orders; Als freistehende Funktion in einem bestimmten Schema: SELECT scott.calc_sales (1001, 'O') FROM orders; SQL kann all diese Variationen korrekt parsen, aber Sie sollten es vermeiden, das Schema des Moduls und die Datenbankverbindung in Ihren SQL-Anweisungen hart zu kodieren (wie es im dritten und vierten Punkt gemacht wurde). Statt dessen sollten Sie Synonyme dafür anlegen, die diese Information verstecken. Damit müssen Sie nur das Synonym ändern, und nicht alle einzelnen SQL-Anweisungen, die diese Funktion aufrufen, wenn Sie jemals den Eigentümer der Funktion ändern oder zu einer anderen Datenbankinstanz wechseln sollten. Wenn Sie eine gespeicherte Funktion in einer SQL-Anweisung verwenden, dann müssen Sie die Zuordnung über Positionen verwenden, das Mischen der Zuordnung über den Namen und über die Position ist nicht erlaubt. Sie können calc_sales nur durch Angabe der beiden Argumente in der richtigen Reihenfolge aufrufen. Bedingungen an gespeicherte Funktionen in SQL Es gibt eine Reihe von Bedingungen, die eine programmiererdefinierte PL/SQL-Funktion erfüllen muß, damit sie von einer SQL-Anweisung aus aufgerufen werden kann. Die Funktion muß in der Datenbank gespeichert sein. Eine Funktion, die in einer PL/SQL-Bibliothek von Oracle Developer/2000 oder einem einzelnen Formular gespeichert ist, kann nicht von SQL aus aufgerufen werden. SQL hat keine Möglichkeit, die Referenz auf eine solche Funktion aufzulösen. 583

6 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen Die Funktion muß eine zeilenspezifische Funktion sein, keine Spalten- oder Gruppenfunktion. Die Funktion kann nur auf eine einzelne Zeile mit Daten angewendet werden, nicht auf eine gesamte Spalte, die sich über mehrere Zeilen erstreckt. Alle Funktionsparameter müssen den IN-Modus verwenden. Weder IN OUT- noch OUT-Parameter sind in gespeicherten Funktionen erlaubt, die von SQL aus aufgerufen werden sollen; aber Sie sollten ohnehin nie IN OUT- oder OUT-Parameter in Funktionen verwenden. Egal ob Sie die Funktion in einer SQL-Anweisung verwenden oder nicht, erzeugen solche Parameter Seiteneffekte zusätzlich zum Hauptzweck der Funktion, der ja die Rückgabe eines einzigen Wertes ist. Die Datentypen der Parameter der Funktion wie auch der Datentyp der RETURN- Klausel müssen Oracle Server bekannt sein. Während alle Datentypen von Oracle Server in PL/SQL gültig sind, hat PL/SQL neue Datentypen hinzugefügt, die von der Datenbank (noch) nicht unterstützt werden. Zu diesen Datentypen gehören BOO- LEAN, BINARY_INTEGER, PL/SQL-Tabellen, PL/SQL-Datensätze und programmiererdefinierte Subtypen. Funktionen, die in Packages definiert sind, müssen das Pragma RESTRICT_ REFERENCES verwenden. Wenn Sie von SQL aus eine in einem Package definierte Funktion aufrufen wollen, müssen Sie der Package-Spezifikation ein Pragma hinzufügen, das explizit angibt, daß diese Funktion zur Ausführung aus SQL-Anweisungen heraus zugelassen ist. Der Abschnitt»Funktionen in Packages von PL/SQL aus aufrufen«enthält nähere Informationen hierzu. Die folgenden Funktionsspezifikationen würden zurückgewiesen werden, wenn sie in einer SQL-Anweisung verwendet würden: /* SQL weiss nichts ueber PL/SQL-Tabellen */ TYPE string_tabtype TABLE OF VARCHAR2(30) INDEX BY BINARY_INTEGER; FUNCTION temp_table RETURN string_tabtype; /* SQL weiss nichts ueber Boolesche Werte */ FUNCTION call_is_open (call_id_in IN call.call_id%type) RETURN BOOLEAN; FUNCTION calc_sales (company_id_in IN NUMBER, use_closed_orders_in IN BOOLEAN) RETURN NUMBER; Einschränkungen von PL/SQL-Funktionen in SQL Gespeicherte Funktionen in SQL sind sehr mächtig. Aber Sie können sich vielleicht denken, daß diese Mächtigkeit auch die Möglichkeit zum Mißbrauch und die Notwendigkeit verantwortungsvollen Handelns mit sich bringt. Im Zusammenhang mit SQL besteht der Mißbrauch in der Verwendung von Seiteneffekten in einer Funktion. Schauen Sie sich die folgende Funktion an: 584

7 Einschränkungen von PL/SQL-Funktionen in SQL FUNCTION total_comp (salary_in IN employee.salary%type, bonus_in IN employee.bonus%type) RETURN NUMBER BEGIN UPDATE employee SET salary = salary_in / 2; RETURN salary_in + NVL (bonus_in, 0); END; Diese kleine Berechnung, die ich am Anfang des Kapitels schon eingeführt hatte, aktualisiert das Gehalt aller Mitarbeiter auf die Hälfte des angegebenen Wertes. Dieser Vorgang beeinflußt die Ergebnisse der Abfrage, aus der total_comp aufgerufen werden könnte, aber schlimmer noch, er beeinflußt alle anderen SQL-Anweisungen in dieser Sitzung. Neben der Modifikation von Datenbanktabellen ist die Modifikation von Package-Variablen ein anderer Seiteneffekt von gespeicherten Funktionen in SQL. Package-Variablen dienen in der jeweiligen Sitzung als globale Variablen. Eine Funktion, die eine Package- Variable verändert, könnte andere gespeicherte Funktionen oder Prozeduren beeinflussen, was wiederum die SQL-Anweisung beeinflußt, welche die gespeicherte Funktion verwendet. Eine PL/SQL-Funktion könnte auch einen Seiteneffekt in der WHERE-Klausel einer Abfrage verursachen. Der Anfrageoptimierer kann die Reihenfolge der Prädikate in der WHERE-Klausel umstellen, um die Anzahl der zu verarbeitenden Zeilen zu minimieren. Eine Funktion, die in dieser Klausel ausgeführt wird, könnte also den Optimierungsprozeß der Anfrage unterlaufen. Ich würde ganz allgemein empfehlen, daß die Funktion sich ganz eng darauf beschränken sollte, einen Wert zu berechnen und zurückzugeben. Aber eine Empfehlung ist nicht genug, wenn es um die Integrität der Datenbank geht: Um sich gegen häßliche Seiteneffekte und unvorhersagbares Verhalten zu schützen, läßt der Oracle Server die folgenden Aktionen in Ihren gespeicherten Funktionen nicht zu: Die gespeicherte Funktion darf keine Datenbanktabellen verändern. Sie kann keine INSERT-, DELETE- oder UPDATE-Anweisung ausführen. Eine gespeicherte Funktion, die entfernt oder parallelisiert aufgerufen wird, darf weder lesend noch schreibend auf Package-Variablen zugreifen. Der Oracle Server erlaubt keine Seiteneffekte, welche die Grenzen der aktuellen Benutzersitzung überschreiten. Eine gespeicherte Funktion kann die Werte von Package-Variablen nur dann ändern, wenn diese Funktion in einer SELECT-, VALUES- und SET-Klausel aufgerufen wird. Wenn diese Funktion in einer WHERE- oder GROUP BY-Klausel aufgerufen wird, kann sie keine Package-Variablen beschreiben. Vor Oracle 8 konnten Sie nur sehr wenige Programme in Built-in Packages in einer von SQL aus verwendeten Funktion aufrufen. Zu den verbotenen Programmen bzw. Packages gehörten beispielsweise DBMS_OUTPUT.PUT_LINE, DBMS_PIPE und 585

8 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen DBMS_SQL, um nur einige zu nennen. Das ist auch manchmal ganz gut so. Wenn Sie keine UPDATE-Anweisung ausführen dürfen, sollten Sie auch nicht über DBMS_SQL eine UPDATE-Operation»an der Zensur«vorbei einschleusen dürfen. Aber bei einigen anderen Packages sind diese Einschränkungen unnötig und nur vorhanden gewesen, weil Oracle diese Programme nicht aktiviert hatte. In Oracle8 wurden einige dieser Einschränkungen aufgehoben. Sie können jetzt DBMS_ OUTPUT.PUT_LINE aus einer von SQL aus aufgerufenen Funktion aufrufen und sogar Informationen durch Datenbank-Pipes schicken. 1 Vor Oracle8 konnten Sie RAE_APPLICATION_ERROR nicht aus einer gespeicherten Funktion aufrufen. In Oracle Server 7.3 können Sie keine PL/SQL-Tabellenmethoden (COUNT, FIRST, LAST, NEXT, PRIOR usw.) in einer gespeicherten Funktion verwenden, die von SQL aus verwendet wird (das ist ein»bekannter Bug«, der in Oracle8 behoben wurde). Beispielsweise kann eine Funktion, die den folgenden Code enthält, in SQL nicht verwendet werden: DECLARE TYPE emptabtype TABLE of emp%rowtype INDEX BY BINARY_INTEGER; emptab emptabtype; BEGIN IF emptab.count > 0 THEN -- Wird in SQL zurueckgewiesen Die gespeicherte Funktion darf kein anderes Modul (gespeicherte Prozedur oder Funktion) verwenden, das eine der obigen Regeln verletzt. Eine Funktion ist nur so rein wie alle Module, die sie selber aufruft. Die gespeicherte Funktion darf keine Sicht verwenden, die eine der obigen Regeln verletzt. Eine Sicht ist eine gespeicherte SELECT-Anweisung; die SELECT-Anweisung der Sicht kann gespeicherte Funktionen verwenden. Wenn Ihre Funktion gegen eine dieser Regeln verstößt oder eine Funktion aus einem Package ist, in dem das Pragma RESTRICT_REFERENCES fehlt, bekommen Sie den gefürchteten Fehler ORA-06571: ORA-06571: Function TOTAL_COMP does not guarantee not to update database Wie im Abschnitt»Die rauhe Wirklichkeit: PL/SQL-Funktionen in SQL aufrufen«erwähnt, kann es manchmal sehr schwierig (oder schlichtweg unmöglich) sein, diesen Fehler zu vermeiden. In anderen Situationen gibt es aber einfache Lösungen (schauen Sie aber auf jeden Fall durch die obige Liste der Beschränkungen). 1 Mein Buch Oracle Built-In Packages, 1998, O Reilly & Associates, enthält eine umfassende Besprechung der Funktionen aus Packages, die von SQL aus verwendet werden können. 586

9 Funktionen in Packages von SQL aus aufrufen Funktionen in Packages von SQL aus aufrufen Wie in Kapitel 16, Packages, beschrieben, sind die Spezifikation und der Rumpf eines Packages getrennt voneinander; eine Spezifikation kann (und muß) existieren, bevor der Rumpf definiert wird. Dieses Feature von Packages macht das Leben schwieriger, wenn es darum geht, Funktionen von SQL aus aufzurufen. Wenn eine SELECT-Anweisung eine Funktion aus einem Package aufruft, dann ist nur die Information aus der Spezifikation des Packages verfügbar. Andererseits ist es aber der Inhalt des Package- Rumpfes, der festlegt, ob eine Funktion von SQL aus ausgeführt werden darf. Als Konsequenz aus dieser Situation ergibt sich, daß Sie Code zu Ihrer Package-Spezifikation hinzufügen müssen, um eine Funktion aus einem Package von SQL aus aufrufbar zu machen. Man spricht davon, daß Sie den»reinheitsgrad«einer gespeicherten Funktion (der Grad, in dem die Funktion frei von Seiteneffekten ist) in der Package-Spezifikation»zusichern«müssen (assert the purity level). Der Oracle Server kann damit beim Kompilieren des Package-Rumpfes bestimmen, ob die Funktion diesen»reinheitsgrad«erfüllt oder nicht. Erfüllt sie ihn nicht, wird ein Fehler gemeldet, und Sie stehen der manchmal gewaltigen Aufgabe gegenüber, herauszufinden, wo und wie diese Verletzung vorkommt. Die Zusicherung des Reinheitsgrades einer Funktion geschieht mit dem Pragma RESTRICT_REFERENCES, das wir uns im nächsten Abschnitt ansehen werden. Das Pragma RESTRICT_REFERENCES Wie ich bereits erwähnt habe, ist ein Pragma eine Direktive für den PL/SQL-Compiler. Wenn Sie jemals eine programmiererdefinierte, benannte Ausnahme verwendet haben, dann sind Sie Ihrem ersten Pragma schon über den Weg gelaufen. Im Falle des Pragmas RESTRICT_REFERENCES teilen Sie dem Compiler den Reinheitsgrad mit, von dem Sie glauben, daß ihn Ihre Funktion mindestens erreicht. Jede Funktion im Package, die Sie in einer SQL-Anweisung verwenden wollen, benötigt ein eigenes Pragma, das nach der Funktionsdeklaration in der Package-Spezifikation stehen muß (im Package-Rumpf muß das Pragma dagegen nicht angegeben werden). Um den Reinheitsgrad mit dem Pragma zuzusichern, verwenden Sie die folgende Syntax: PRAGMA RESTRICT_REFERENCES (funktions_name, WNDS [, WNPS] [, RNDS] [, RNPS]) Hierbei ist funktions_name der Name der Funktion, deren Reinheitsgrad Sie zusichern wollen. Die vier verschiedenen Codes haben die folgenden Bedeutungen: WNDS Writes No Database State. Sichert zu, daß die Funktion keine Datenbanktabellen verändert. WNPS Writes No Package State. Sichert zu, daß die Funktion keine Package-Variablen verändert. 587

10 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen RNDS Reads No Database State. Sichert zu, daß die Funktion nicht aus Datenbanktabellen liest. RNPS Reads No Package State. Sichert zu, daß die Funktion nicht aus Package-Variablen liest. Nur WNDS muß im Pragma stehen. Das ist auch konsistent mit der Beschränkung, daß gespeicherte Funktionen in SQL keine UPDATE-, INSERT- oder DELETE-Anweisung ausführen dürfen. Alle anderen Zusicherungen sind optional. Sie können Sie in beliebiger Reihenfolge aufführen, aber WNDS muß immer dabei sein. Kein Argument folgt aus einem der anderen. Ich kann in die Datenbank schreiben, ohne aus ihr zu lesen, und aus einer Package-Variable lesen, ohne darauf zu schreiben. Hier ein Beispiel für zwei verschiedene Zusicherungen der Reinheit von Funktionen im Package company_financials: PACKAGE company_financials FUNCTION company_type (type_code_in IN VARCHAR2) RETURN VARCHAR2; FUNCTION company_name (company_id_in IN company.company_id%type) RETURN VARCHAR2; PRAGMA RESTRICT_REFERENCES (company_type, WNDS, RNDS, WNPS, RNPS); PRAGMA RESTRICT_REFERENCES (company_name, WNDS, WNPS, RNPS); END company_financials; In diesem Package liest die Funktion company_name aus der Datenbank, um den Namen der angegebenen Firma zu ermitteln. Beachten Sie, daß ich beide Pragmas an das Ende der Package-Spezifikation gestellt habe, die Pragmas müssen den Funktionsspezifikationen nicht unmittelbar folgen. Ich habe mir außerdem die Mühe gemacht, die Argumente WNPS und RNPS bei beiden Funktionen anzugeben. Oracle Corporation empfiehlt, immer den höchstmöglichen Reinheitsgrad anzugeben, so daß der Compiler die Funktion nie unnötig zurückweist. HINWE Wenn eine Funktion, die Sie von SQL aus aufrufen wollen, eine Prozedur in einem Package aufruft, dann muß auch für diese Prozedur das Pragma RESTRICT_ REFERENCES angegeben werden. Sie können die Prozedur zwar nicht direkt von SQL aus aufrufen, aber wenn sie indirekt von SQL aufgerufen werden soll, dann muß sie sich ebenfalls an die Regeln halten. Fehler bei Pragmaverstößen Wenn Ihre Funktion gegen ihr Pragma verstößt, wird der Fehler PLS gemeldet. Wenn der Rumpf des Packages company_financials folgendermaßen aussieht 588

11 Funktionen in Packages von SQL aus aufrufen CREATE OR REPLACE PACKAGE BODY company_financials FUNCTION company_type (type_code_in IN VARCHAR2) RETURN VARCHAR2 v_sal NUMBER; BEGIN SELECT sal INTO v_sal FROM emp WHERE empno = 1; RETURN 'bigone'; END; FUNCTION company_name (company_id_in IN company.company_id%type) RETURN VARCHAR2 BEGIN UPDATE emp SET sal = 0; RETURN 'bigone'; END; END company_financials; / dann bekomme ich beim Kompilieren den folgenden Fehler: 3/4 PLS-00452: Subprogram 'COMPANY_TYPE' violates its associated pragma Der Grund dafür ist, daß die Funktion company_type aus der Datenbank liest, obwohl ich den Reinheitsgrad RNDS angegeben habe. Auch wenn ich diese dumme SELECT- Anweisung entferne, bekomme ich immer noch den folgenden Fehler 11/4 PLS-00452: Subprogram 'COMPANY_NAME' violates its associated pragma weil die Funktion company_name die Daten in der Datenbank aktualisiert, obwohl ich WNDS angegeben habe. Manchmal werden Sie auf Ihre Funktion starren und sagen,»he, diesmal verletzte ich den angegebenen Reinheitsgrad wirklich nicht. Hier ist ja gar kein UPDATE, DELETE oder INSERT«. Vielleicht haben Sie recht. Aber es ist nicht unwahrscheinlich, daß Sie ein Built-in Package aufgerufen oder auf andere Weise gegen die Regeln verstoßen haben. Zusichern des Reinheitsgrades im Initialisierungsabschnitt des Packages Wenn Ihr Package einen Initialisierungsabschnitt (ausführbare Anweisungen nach einer BEGIN-Anweisung im Package-Rumpf) enthält, dann müssen Sie auch den Reinheitsgrad dieses Abschnitts zusichern. Der Initialisierungsabschnitt wird automatisch ausgeführt, wenn das erste Mal auf ein Objekt aus dem Package zugegriffen wird. Wenn eine Funktion aus einem solchen Package also in einer SQL-Anweisung ausgeführt wird, kann sie die Ausführung dieses Codes bewirken. Wenn der Initialisierungsabschnitt Package-Variablen oder Daten in der Datenbank modifiziert, dann muß dies dem Compiler über das Pragma mitgeteilt werden. 589

12 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen Sie können den Reinheitsgrad des Initialisierungsabschnitts entweder explizit oder implizit zusichern. Für die explizite Zusicherung verwenden Sie die folgende Variation des Pragmas RESTRICT_REFERENCES: PRAGMA RESTRICT_REFERENCES (Package_name, WNDS, [, WNPS] [, RNDS] [, RNPS]) Anstelle des Namens der Funktion geben Sie hier den Namen des Packages selbst an, worauf wieder die Zustandsargumente folgen. Im folgenden Beispiel sichere ich nur WNDS und WNPS zu, weil der Initialisierungsabschnitt Daten aus der Konfigurationstabelle und aus einer globalen Variable eines anderen Packages (session_pkg. user_id) liest. PACKAGE configure PRAGMA RESTRICT_REFERENCES (configure, WNDS, WNPS); user_name VARCHAR2(100); END configure; PACKAGE BODY configure BEGIN SELECT lname ', ' fname INTO user_name FROM user_table WHERE user_id = session_pkg.user_id; END configure; Warum kann ich hier WNPS zusichern, obwohl ich die Package-Variable user_name beschreibe? Die Antwort ist, daß es sich um eine Variable aus dem gleichen Package handelt, weswegen diese Aktion nicht als Seiteneffekt zählt. Sie können den Reinheitsgrad des Initialisierungsabschnitts des Packages auch implizit zusichern, indem Sie den Compiler den Reinheitsgrad aus den Reinheitsgraden aller Pragmas der einzelnen Funktionen im Package ableiten lassen. In der folgenden Version des Packages company kann der Oracle Server aus den beiden Pragmas für die Funktionen einen Reinheitsgrad von RNDS und WNPS für den Initialisierungsabschnitt ableiten. Der Initialisierungsabschnitt kann also nicht aus der Datenbank lesen und keine Package-Variablen beschreiben. PACKAGE company FUNCTION get_company (company_id_in IN VARCHAR2) RETURN company%rowtype; FUNCTION deactivate_company (company_id_in IN company.company_id%type) RETURN VARCHAR2; PRAGMA RESTRICT_REFERENCES (get_company, RNDS, WNPS); PRAGMA RESTRICT_REFERENCES (deactivate_name, WNPS); END company; 590

13 Die Präzedenz von Spalten- und Funktionsnamen Üblicherweise ist es besser, den Reinheitsgrad des Initialisierungsabschnitts explizit anzugeben. Das macht es denjenigen, die das Package später einmal warten müssen, leichter, Ihre Absichten und Ihr Verständnis des Packages zu durchschauen. Die Präzedenz von Spalten- und Funktionsnamen Wenn Ihre Funktion den gleichen Namen wie eine Tabellenspalte in einer SELECT- Anweisung und keine Parameter hat, dann hat die Spalte Vorrang vor der Funktion. Die Tabelle employee habe eine Spalte namens salary. Wenn Sie nun auch eine Funktion namens salary erzeugen CREATE TABLE employee (employee_id NUMBER,..., salary NUMBER,...); FUNCTION salary RETURN NUMBER; dann bezieht sich salary in einer SELECT-Anweisung immer auf die Spalte und nicht auf die Funktion: SELECT salary INTO calculated_salary FROM employee; Wenn Sie diese Präzedenz der Spalte umgehen wollen, müssen Sie den Namen der Funktion mit dem Namen des Schemas, dem diese Funktion gehört, qualifizieren: SELECT scott.salary INTO calculated_salary FROM employee; Damit wird die Funktion ausgeführt, anstatt den Spaltenwert zu holen. Die rauhe Wirklichkeit: PL/SQL-Funktionen in SQL aufrufen Die Möglichkeit, PL/SQL-Funktionen in SQL aufzurufen, gibt es schon seit der Version 2.1, aber trotzdem kann das in vielerlei Hinsicht (zumindest vor dem Erscheinen von Oracle8) als»brandneue«technologie betrachtet werden. Warum ist das so? Sie müssen in Ihrem Code die RESTRICT_REFERENCES-Pragmas von Hand eintragen, und Sie müssen selbst herausfinden, wo diese nötig sind. Wie man das macht, wird in einem späteren Abschnitt beschrieben. Die Funktionen werden außerhalb des Lesekonsistenzmodells der Oracle-Datenbank ausgeführt (!). Auch das wird in einem späteren Abschnitt näher erläutert. Es ist immer noch teuer, eine Funktion von SQL aus aufzurufen. Die genauen Kosten eines Funktionsaufrufs (verglichen beispielsweise mit Inline-SQL-Code) sind schwer zu bestimmen, sie unterscheiden sich von Computer zu Computer und sogar von Instanz zu Instanz oder von aufgerufener Funktion zu aufgerufener 591

14 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen Funktion. Ich habe von einer zusätzlichen halben Sekunde bis zu erstaunlichen zusätzlichen fünfzig Sekunden gehört (auch wenn ich im letzteren Falle vorschlagen würde, ein wenig mehr zu analysieren und zu debuggen). Aber egal wie schnell der Aufruf wirklich ist, die Verzögerung kann für den Anwender spürbar sein. Sie müssen sie also in Ihren Design- und Testplänen berücksichtigen. Tuning-Mechanismen wie EXPLAIN PLAN berücksichtigen den SQL-Code nicht, der in Funktionen aufgerufen werden könnte, die wiederum von Ihren SQL- Anweisungen aufgerufen werden. PL/SQL-Funktionen werden von EXPLAIN PLAN nicht berücksichtigt. Damit wird es schwierig, die Flaschenhälse zu erkennen, die man zur Performanzsteigerung beseitigen muß. Ein großer Teil der Oracle-Technologie, und dabei wiederum insbesondere jener Teil, der in Built-in Packages steckt, ist für Funktionen in SQL verboten. Denken Sie nur an DBMS_OUTPUT. Sie können dieses Package nicht in von SQL aus aufgerufenen Funktionen verwenden. Normalerweise möchten Sie aber die gleichen Funktionen in SQL und PL/SQL verwenden. Auch fügen Sie zum Debuggen möglicherweise am Anfang und am Ende Ihrer Funktionen und Prozeduren Aufrufe ein und verwenden sehr wahrscheinlich DBMS_OUTPUT (oder UTIL_FILE oder DBMS_PIPE, was Sie wollen, diese Funktionen sind alle zumindest vor Oracle8 verboten). Tja, tut mir leid. Diese Funktionen können Sie von SQL aus nicht verwenden. Also müssen Sie Code aus der Funktion herausnehmen. Am Ende haben Sie zwei Versionen Ihres Codes: eine für PL/SQL, eine für SQL, ein Alptraum für Software-Entwickler. Schauen wir uns jetzt zwei dieser Probleme genauer an. Manuelles Eintragen der Pragmas Sie müssen die RESTRICT_REFERENCES-Pragmas überall in Ihrem Code eintragen und auch herausfinden, wo diese hingehören. Dieser Vorgang ähnelt oft einer detektivischen Spurensuche, Sherlock Holmes läßt grüßen! Sie kompilieren ein Package und erhalten eine Meldung über einen Verstoß gegen ein Pragma. Der Grund dafür kann sein, daß Ihr Programm eine Regel verletzt (indem es beispielsweise Daten verändert), oder andere Programme aufruft, die eine Regel verletzen. In letzterem Fall stehen Sie womöglich vor fünf oder sechs anderen Funktionen oder Prozeduren, müssen also in all diesen ebenfalls die Pragmas eintragen. Damit sichern Sie aber Reinheitsgrade zu, wo das vorher nicht geschah, und handeln sich damit im besten Fall weitere Fehler ein, im schlechtesten Fall aber weitreichende Konsequenzen für die Architektur Ihrer Anwendung. Nehmen wir beispielsweise an, daß Sie auf einmal einer Prozedur im Package X ein Pragma anbeistellen müssen. Dieses Package hat aber einen Initialisierungsabschnitt, so daß Sie auch diesen mit Pragmas versehen müssen. In diesen Abschnitten werden oft PL/SQL-Tabellen für die Datenmanipulation im Speicher eingerichtet. Wenn Sie aber PL/SQL-Tabellenmethoden für die Initialisierung solcher Tabellen verwenden, wird das Pragma fehlschlagen. 592

15 Die rauhe Wirklichkeit: PL/SQL-Funktionen in SQL aufrufen Dieser Vorgang kann ziemlich frustrierend sein und manchmal dazu führen, daß Sie am Ende darauf verzichten, eine Funktion von SQL aus aufzurufen. Ich habe die Erfahrung gemacht, daß man so weit wie möglich im vornherein die Bereiche der Anwendung festlegen sollte, die von SQL aus aufgerufen werden sollen. Sie können dann diesen Code besonders»sauber«und beschränkt auf die eigentliche Aufgabe halten und die Verstrickungen mit anderen Packages sowie die Verwendung Built-in Packages so gering wie möglich halten. Das ist weder einfach noch besonders spaßig. Komplikationen mit dem Lesekonsistenzmodell Ja, es ist kaum zu glauben, aber wahr: Wenn Sie nicht besondere Vorsichtsmaßnahmen treffen, ist es gut möglich, daß Ihre SQL-Abfrage das Lesekonsistenzmodell des Oracle- RDBMS verletzt, ein seit Jahren geheiligtes Territorium in Oracle. Um dieses Problem zu verstehen, werfen Sie bitte einen Blick auf die folgende Abfrage und die von ihr aufgerufene Funktion: SELECT name, total_sales (account_id) FROM account WHERE status = 'ACTIVE'; FUNCTION total_sales (id_in IN account.account_id%type) RETURN NUMBER CURSOR tot_cur SELECT SUM (sales) total FROM orders WHERE account_id = id_in AND year = TO_NUMBER (TO_CHAR (SYSDATE, 'YYYY')); tot_rec tot_cur%rowtype; BEGIN OPEN tot_cur; FETCH tot_cur INTO tot_rec; RETURN tot_rec.total; END; Die Tabelle account hat fünf Millionen aktive Zeilen (offensichtlich ein sehr erfolgreiches Unternehmen!). Die Tabelle orders hat zwanzig Millionen Zeilen. Ich starte die Abfrage um 11 Uhr morgens und rechne damit, daß sie etwa eine Stunde dauert. Um viertel vor zwölf kommt jemand mit der entsprechenden Berechtigung, löscht alle Zeilen aus der Tabelle orders und gibt die Änderung frei. Nach dem Lesekonsistenzmodell von Oracle sollte die Sitzung, welche die Abfrage ausführt, all diese gelöschten Zeilen sehen, bis die Abfrage abgeschlossen ist. Aber wenn das nächste Mal die Funktion total_sales aus der Abfrage heraus aufgerufen wird, findet Sie keine Zeilen in orders mehr vor und gibt NULL zurück und das auch bei allen weiteren Aufrufen. Sie müssen sich also über solche Lesekonsistenzprobleme im klaren sein, wenn Sie in Funktionen, die von SQL aus aufgerufen werden, wiederum Abfragen durchführen. Wenn diese Funktionen von lange laufenden Abfragen oder Transaktionen aufgerufen 593

16 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen werden, sollten Sie vielleicht zwischen den SQL-Anweisungen der aktuellen Transaktion den folgenden Befehl eingeben, um die Lesekonsistenz zu erzwingen: SET TRANSACTION READ ONLY Mehr dazu finden Sie in Kapitel 6, Interaktion mit der Datenbank und Cursoren. Das Arbeiten mit Funktionen in SQL ist schwieriger und komplizierter, als Sie es sich vielleicht auf den ersten Blick vorstellen können. Das hätte man sich eigentlich auch denken können, denn man kann das über fast jeden Aspekt der Oracle-Technologie sagen, insbesondere über die kürzlich hinzugekommenen Neuerungen. Ich hoffe, daß uns Oracle mit der Zeit das Leben leichter machen wird (und in Oracle 8.0 gibt es einige deutliche Verbesserungen). Was wir letztendlich brauchen, ist ein Hilfsprogramm, mit dem ein Entwickler auf eine Funktion verweisen und verlangen kann, daß»diese Funktion für SQL nutzbar gemacht wird«. Dieses Hilfsprogramm trägt dann alle Pragmas ein oder erstellt zumindest einen Bericht über die notwendigen Schritte. Man darf ja schließlich träumen, oder? Beispiele eingebetteten PL/SQL-Codes Je mehr Sie über gespeicherte Funktionen in SQL nachdenken, um so mehr Möglichkeiten werden Ihnen einfallen, diese in jeder einzelnen Ihrer Anwendungen zu verwenden. Um Ihrer Kreativität eine kleine Starthilfe zu geben, zeige ich Ihnen hier einige Beispiele, wie gespeicherte Funktionen in SQL-Anweisungen Ihre Oracle-basierten Systeme verändern können. Eingekapselte Berechnungen In so ziemlich jeder Anwendung müssen Sie immer wieder die gleichen Berechnungen durchführen. Egal ob es sich dabei um die Berechnung des Bruttobetrags, des Standes der Hypothek, des Abstands zweier Punkte auf einer kartesischen Ebene oder einer statistischen Varianz handelt, mit nativem SQL müssen Sie diese Berechnungen in jeder SQL-Anweisung, in der sie benötigt werden, wieder neu schreiben. Für diese Redundanz zahlen Sie einen hohen Preis. Der Code, der Ihre Geschäftsregeln implementiert, ist über die gesamte Anwendung verstreut und wird immer wieder wiederholt. Sogar wenn sich diese Regeln selbst nicht ändern, wird sich wahrscheinlich die Implementierung dieser Regeln irgendwann ändern müssen. Wenn sich die Regel selbst ändert, ist die Lage natürlich noch übler, weil das oft zu ziemlich umfassenden Änderungen im Code führen kann. Um dieses Problem zu lösen, können Sie alle Formeln und Berechnungen in gespeicherten Funktionen verstecken. Diese Funktionen können dann sowohl aus SQL- Anweisungen als auch aus PL/SQL-Programmen heraus aufgerufen werden. Ein schönes Beispiel für die Nützlichkeit eingekapselter Berechnungen entstand, als eine Versicherung Analysen ihrer Konten auf Basis von Datumsangaben durchführen 594

17 Beispiele eingebetteten PL/SQL-Codes mußte. Der letzte Tag im Monat ist natürlich für die meisten Finanzinstitutionen ein sehr wichtiges Datum. Um die Datumsangaben zu manipulieren, sah die IT-Abteilung der Firma vor, die Built-in-Funktion LAST_DAY zu verwenden, um den letzten Tag eines Monats zu bekommen, und mit ADD_MONTHS von einem Monat zum nächsten zu springen. Bald fiel ihnen aber eine sehr interessante Nuance in der Funktion von ADD_ MONTHS auf: Wenn Sie einen Tag an ADD_MONTH übergeben, welcher der letzte Tag des jeweiligen Monats ist, dann gibt SQL immer den letzten Tag im daraus resultierenden Monat zurück, egal, wie viele Tage jeder der einzelnen Monate wirklich hat: Anders ausgedrückt: ADD_MONTHS ('28-FEB-1994', 2) ==> 30-APR-1993 Das ist vielleicht bei manchen Anwendungen und Abfragen auch sinnvoll. Bei der Versicherung war die Anforderung aber, daß man beim Springen von Monat zu Monat immer am gleichen Tag des Monats ankommen muß (oder am letzten Tag, wenn der Tag im Ausgangsmonat nach dem letzten Tag des Zielmonats lag). Ohne gespeicherte Funktionen hätte man folgende SQL-Anweisung verwenden müssen: SELECT DECODE (payment_date, LAST_DAY (payment_date), LEAST (ADD_MONTHS (payment_date, 1), TO_DATE (TO_CHAR (ADD_MONTHS (payment_date, 1), 'MMYYYY') TO_CHAR (payment, 'DD'), 'MMYYYYDD')), ADD_MONTHS (payment_date, 1)) FROM premium_payments; Auf deutsch heißt das:»wenn das Datum der letzten Zahlung auf den letzten Tag des Monats fällt, dann gib als Datum der nächsten Zahlung entweder das Ergebnis der Addition eines Monats zum Datum der letzten Zahlung (mit ADD_MONTHS) oder den gleichen Tag wie den der letzten Zahlung im neuen Monat zurück. Falls die letzte Zahlung nicht am letzten Tag des Monats getätigt wurde, dann verwende zur Bestimmung des nächsten Zahlungsdatums einfach ADD_MONTHS.«Das ist nicht nur schwierig zu verstehen, sondern benötigt auch drei Aufrufe der Builtin-Funktion ADD_MONTHS. Stellen Sie sich jetzt noch vor, daß diese komplexe SQL- Anweisung in jeder SELECT-Liste hätte wiederholt werden müssen, in der ADD_MONTHS verwendet wurde, um die Datumsangaben herauf- oder herunterzuzählen. Sie können sich da wahrscheinlich gut vorstellen, wie froh die Programmierer in dieser Firma waren, als sie die Version 7.1 von Oracle Server installierten und die folgende Funktion in ihren SQL-Anweisungen verwenden konnten (eine vollständige Erklärung der Logik dieser Funktion finden Sie in Kapitel 12, Datumsfunktionen): FUNCTION new_add_months (date_in IN DATE, months_shift IN NUMBER) RETURN DATE return_value DATE; 595

18 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen BEGIN return_value := ADD_MONTHS (date_in, months_shift); IF date_in = LAST_DAY (date_in) THEN return_value := LEAST (return_value, TO_DATE (TO_CHAR (return_value, 'MMYYYY') TO_CHAR (date_in, 'DD'), 'MMYYYYDD')); END IF; RETURN return_value; END new_add_months; Damit wird die SELECT-Anweisung zur Bestimmung des nächsten Zahlungsdatums sehr einfach: SELECT new_add_months (payment_date,1) FROM premium_payments; Je mehr Sie Ihre SQL-Anweisungen durchsehen, um so mehr Möglichkeiten für den Einsatz gespeicherter Funktionen werden Sie finden, mit denen Sie Berechnungen verstekken und damit auf lange Sicht die Stabilität Ihres Codes verbessern können. Es ist zwar wenig wahrscheinlich, daß Sie die Zeit und die Ressourcen haben, um das gesamte SQL-Rückgrat Ihrer Anwendung neu zu schreiben, aber Sie können zumindest entsprechende Funktionen entwickeln und diese in Neuentwicklungen einsetzen. Kombinieren skalarer und aggregierter Werte Die folgende einfache Frage ist in SQL schwer zu beantworten:»zeige mir den Namen und das Gehalt des Mitarbeiters jeder Abteilung, der in dieser Abteilung das höchste Gehalt hat, sowie das Gesamtgehalt aller Mitarbeiter der jeweiligen Abteilungen.«Wenn man diese Frage in zwei Teile aufteilt, ist das nicht schwer. Hier ist der erste Teil: SELECT department_id, last_name, salary FROM employee E1 WHERE salary = (SELECT MAX (salary) FROM employee E2 WHERE E.department_id = E2.department_id) GROUP BY department_id; Und hier der zweite: SELECT department_id, SUM (salary) FROM employee GROUP BY department_id; Es ist aber nicht so einfach, diese beiden zu kombinieren, weil man dabei sowohl skalare Werte (eine einzelne Zeile) als auch aggregierte (sich über mehrere Zeilen erstrekkende) Werte aus ein und derselben Tabelle abfragen müßte. Wie soll ich meine FROM-, WHERE- und GROUP BY-Klauseln schreiben, um sowohl das Gehalt eines einzelnen als auch das aller Abteilungsmitglieder zusammengenommen anzuzeigen? 596

19 Beispiele eingebetteten PL/SQL-Codes SELECT department_id, last_name, salary, SUM (salary) FROM...? WHERE...? GROUP BY...? Vor der Version 2.1 von PL/SQL war die naheliegendste Lösung, eine Sicht zu erzeugen, die das Gehalt jeder Abteilung schon einmal»im voraus«zusammenfaßte: CREATE VIEW dept_salary AS SELECT department_id, SUM (salary) total_salary FROM employee GROUP BY department_id; Mit dieser Sicht kann ich die Antwort mit einer einzigen SQL-Anweisung bekommen: SELECT E.department_id, last_name, salary, total_salary FROM employee E, dept_salary DS WHERE E.department_id = DS.department_id AND salary = (SELECT MAX (salary) FROM employee E2 WHERE E.department_id = E2.department_id); Diese Lösung sieht ja gar nicht so schlecht aus, aber Sie müssen jedesmal, wenn Sie eine solche Berechnung durchführen wollen, eine spezielle Sicht erzeugen. Abgesehen davon, ist dieser SQL-Code auch für viele Programmierer nicht so besonders offensichtlich. Eine bessere Lösung ist es, eine gespeicherte Funktion zu verwenden. Anstatt eine Sicht zu erzeugen, schreiben wir eine Funktion, die genau die gleiche Berechnung durchführt, aber dieses Mal nur für die angegebene Abteilung: FUNCTION total_salary (dept_id_in IN department.department_id%type) RETURN NUMBER CURSOR grp_cur SELECT SUM (salary) FROM employee WHERE department_id = dept_id_in; return_value NUMBER; BEGIN OPEN grp_cur; FETCH grp_cur INTO return_value; CLOSE grp_cur; RETURN return_value; END; Wenn eine Abteilung nicht existiert, gebe ich NULL zurück. Wenn eine Abteilung keine Mitarbeiter hat, gebe ich 0 zurück, ansonsten die Summe der Gehälter aller Mitarbeiter in dieser Abteilung. 597

20 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen Meine Abfrage muß jetzt keine Sicht verwenden, die ein GROUP BY enthält. Statt dessen ruft sie einfach die Funktion total_salary auf und übergibt die ID-Nummer der Abteilung des Mitarbeiters als Parameter: SELECT E.department_id, last_name, salary, total_salary (E.department_id) FROM employee E WHERE salary = (SELECT MAX (salary) FROM employee E2 WHERE E.department_id = E2.department_id); Die daraus resultierende SQL-Anweisung ist nicht nur leichter zu lesen, sondern ist auch schneller, insbesondere bei größeren Tabellen. Ich könnte die SQL-Anweisung noch weiter vereinfachen, indem ich eine Funktion schreibe, die das maximale Gehalt in einer bestimmten Abteilung zurückgibt. Die SELECT-Anweisung lautet dann einfach nur: SELECT department_id, last_name, salary, total_salary (department_id) FROM employee E WHERE salary = max_sal_in_dept (department_id); Ersetzung korrelierter Subabfragen Mit gespeicherten Funktionen in SQL-Anweisungen kann man auch korrelierte Subabfragen ersetzen. Das sind SELECT-Anweisungen innerhalb der WHERE-Klausel einer SQL-Anweisung (SELECT, INSERT oder DELETE), die sich auf eine oder mehrere Spalten der umgebenden SQL-Anweisung beziehen. Im letzten Abschnitt habe ich eine korrelierte Subabfrage verwendet, um den Mitarbeiter mit dem höchsten Gehalt in jeder Abteilung zu bestimmen: SELECT E.department_id, last_name, salary, total_salary (E.department_id) FROM employee E WHERE salary = (SELECT MAX (salary) FROM employee E2 WHERE E.department_id = E2.department_id); Die letzten drei Zeilen der Abfrage enthalten eine SELECT-Anweisung, in der die Abteilungsnummer des»inneren«mitarbeiters (E2) mit der Abteilungsnummer in der»äußeren«mitarbeitertabelle (E1) übereinstimmen soll. Die innere Abfrage wird für jede mit der äußeren Abfrage ermittelte Zeile einmal ausgeführt. Korrelierte Subabfragen sind ein sehr mächtiges Feature von SQL, weil sie den verschachtelten Schleifen prozeduraler Programmiersprachen wie in LOOP LOOP END LOOP; END LOOP; entsprechen. Sie haben aber zwei Nachteile: Die Logik kann ziemlich kompliziert werden. Die resultierende SQL-Anweisung kann schwierig zu verstehen und zu verfolgen sein. 598

21 Beispiele eingebetteten PL/SQL-Codes Sie können diese Nachteile vermeiden, indem Sie gespeicherte Funktionen anstelle der korrelierten Subabfragen verwenden. Im obigen Beispiel bräuchte ich eine Funktion, die das höchste Gehalt in einer bestimmten Abteilung berechnet: FUNCTION max_salary (dept_id_in IN department.department_id%type) RETURN NUMBER CURSOR grp_cur SELECT MAX (salary) FROM employee WHERE department_id = dept_id_in; return_value NUMBER; BEGIN OPEN grp_cur; FETCH grp_cur INTO return_value; CLOSE grp_cur; RETURN return_value; END; Jetzt kann ich sowohl total_salary als auch max_salary in meiner SELECT-Anweisung verwenden. Auf deutsch übersetzt würde diese etwa lauten:»zeige mir den Namen und das Gehalt des Mitarbeiters, der in der jeweiligen Abteilung das höchste Gehalt hat, sowie das Gesamtgehalt aller Mitarbeiter in der Abteilung dieses Mitarbeiters«: SELECT E.department_id, last_name, salary, total_salary (department_id) FROM employee WHERE salary = max_salary (department_id); Vergleichen Sie dieses einfache und selbstdokumentierende Stück SQL mit der Version, die eine Sicht und eine korrelierte Subabfrage benötigt: CREATE VIEW dept_salary AS SELECT department_id, SUM (salary) total_salary FROM employee GROUP BY department_id; SELECT E.department_id, last_name, salary, total_salary FROM employee E, dept_salary DS WHERE E.department_id = DS.department_id AND salary = (SELECT MAX (salary) FROM employee E2 WHERE E.department_id = E2.department_id); Ich bin sicher, Sie werden mir zustimmen, daß gespeicherte Funktionen in SQL Ihr Leben einfacher machen können. Ihnen ist vielleicht aufgefallen, daß die Funktion total_salary aus dem letzten Abschnitt der Funktion max_salary aus diesem Abschnitt sehr ähnlich sieht. Der einzige Unterschied zwischen den beiden ist der, daß der Cursor in total_salary die 599

22 Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen Gruppierungsfunktion SUM und der Cursor in max_salary die Gruppierungsfunktion MAX verwendet. Wenn Sie immer fanatisch darauf aus sind, möglichst viel Ihres Codes in einer möglichst kleinen Anzahl unterschiedlicher»beweglicher Teile«zusammenzufassen, dann könnten Sie auch eine einzige Funktion daraus machen, die abhängig von einem zweiten Parameter, verschiedene Statistiken auf Gruppenebene zurückliefert: FUNCTION salary_stat (dept_id_in IN department.department_id%type, stat_type_in IN VARCHAR2) RETURN NUMBER v_stat_type VARCHAR2(20) := UPPER (stat_type_in); CURSOR grp_cur SELECT SUM (salary) sumsal, MAX (salary) maxsal, MIN (salary) minsal, AVG (salary) avgsal, COUNT (DTINCT salary) countsal, FROM employee WHERE department_id = dept_id_in; grp_rec grp_cur%rowtype; retval NUMBER; BEGIN OPEN grp_cur; FETCH grp_cur INTO grp_rec; CLOSE grp_cur; IF v_stat_type = 'SUM' THEN retval := grp_rec.sumsal; ELSIF v_stat_type = 'MAX' THEN retval := grp_rec.maxsal; ELSIF v_stat_type = 'MIN' THEN retval := grp_rec.minsal; ELSIF v_stat_type = 'COUNT' THEN retval := grp_rec.countsal; ELSIF v_stat_type = 'AVG' THEN retval := grp_rec.avgsal; END IF; RETURN retval; END; 600

23 Beispiele eingebetteten PL/SQL-Codes Die zusätzlichen Kosten, die durch diese Ausdrücke in der SELECT-Liste entstehen und die Verarbeitung der IF-Anweisung sind vernachlässigbar. Mit diesem neuen, generischen Werkzeug sieht meine Gehaltsanalyse nun so aus: SELECT E.department_id, last_name, salary, salary_stat (department_id, 'sum') FROM employee WHERE salary = salary_stat (department_id, 'max'); Wenn ich jemals den SQL-Code, mit dem man die Statistiken über Abteilungen erhält, ändern muß, dann muß ich nur diese eine Funktion anfassen. Ersetzen von DECODE durch IF-Anweisungen Die DECODE-Funktion stellt IF-ähnliche Möglichkeiten in der nichtprozeduralen SQL- Umgebung des Oracle Server bereit. Sie können die DECODE-Syntax verwenden, um Matrixberichte mit einer festen Anzahl von Spalten zu erzeugen, aber auch, um in einer Abfrage komplexe IF-THEN-ELSE-Logik einzubauen. Betrachten Sie das folgende Beispiel für DECODE, in dem bestimmt wird, ob ein Datum innerhalb eines vorgeschriebenen Bereichs liegt und das, wenn ja, die Anzahl der Zeilen, die diese Bedingung erfüllen, inkrementiert: SELECT FC.year_number, SUM (DECODE (GREATEST (ship_date, FC.q1_sdate), ship_date, DECODE (LEAST (ship_date, FC.q1_edate), ship_date, 1, 0), 0)) Q1_results, SUM (DECODE (GREATEST (ship_date, FC.q2_sdate), ship_date, DECODE (LEAST (ship_date, FC.q2_edate), ship_date, 1, 0), 0)) Q2_results, SUM (DECODE (GREATEST (ship_date, FC.q3_sdate), ship_date, DECODE (LEAST (ship_date, FC.q3_edate), ship_date, 1, 0), 0)) Q3_results, SUM (DECODE (GREATEST (ship_date, FC.q4_sdate), ship_date, DECODE (LEAST (ship_date, FC.q4_edate), ship_date, 1, 0), 0)) Q4_results FROM orders O, fiscal_calendar FC GROUP BY year_number; Die Ergebnismenge der Abfrage könnte so aussehen: 601