PL/SQL- Funktionen von SQL aus aufrufen - beim O'Reilly Verlag

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.
HINWEIS
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

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
IS
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

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

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

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 sales_pkg.calc_sales@NEW_YORK (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

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 IS 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

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
IS
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

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 RAISE_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 IS 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

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

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
IS
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.
HINWEIS
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-00542 gemeldet.
Wenn der Rumpf des Packages company_financials folgendermaßen aussieht
588

Funktionen in Packages von SQL aus aufrufen
CREATE OR REPLACE PACKAGE BODY company_financials
IS
FUNCTION company_type (type_code_in IN VARCHAR2)
RETURN VARCHAR2
IS
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
IS
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

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
IS
PRAGMA RESTRICT_REFERENCES (configure, WNDS, WNPS);
user_name VARCHAR2(100);
END configure;
PACKAGE BODY configure
IS
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
IS
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

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

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

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
IS
CURSOR tot_cur
IS
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

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

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
IS
return_value DATE;
595

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

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
IS
CURSOR grp_cur
IS
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

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

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
IS
CURSOR grp_cur
IS
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

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
IS
v_stat_type VARCHAR2(20) := UPPER (stat_type_in);
CURSOR grp_cur
IS
SELECT SUM (salary) sumsal,
MAX (salary) maxsal,
MIN (salary) minsal,
AVG (salary) avgsal,
COUNT (DISTINCT 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

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

Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen
YEAR NUMBER Q1 RESULTS Q2 RESULTS Q3 RESULTS Q4 RESULTS
------------ ---------- ---------- ---------- ----------
1993 12000 14005 22000 40000
1994 10000 15000 21000 55004
Es ist zwar sehr nützlich, DECODE für solche Berichte zu verwenden, aber die dafür
notwendige SQL-Anweisung ist doch etwas einschüchternd. Das DECODE für Q1
RESULTS läßt sich etwa so übersetzen: » Wenn das Versanddatum größer oder gleich
dem ersten Datum im ersten Quartal und kleiner oder gleich dem letzten Datum im
ersten Quartal ist, dann addiere eins zur Summe aller Bestellungen, die in diesem Quartal
ausgeliefert worden sind. Ansonsten addiere 0.«
Unglücklicherweise werden Sie die vertrackten SQL-Anweisungen nur mit viel Erfahrung
mit DECODE entschlüsseln können. Auch die Wiederholungen im SELECT
schreien geradezu nach einer Modularisierung. Diese erreichen wir mit der folgenden
gespeicherten Funktion (incr_in_range steht für increment if in the range (inkrementieren,
wenn im Bereich)):
FUNCTION incr_in_range
(ship_date_in IN DATE, sdate_in IN DATE, edate_in IN DATE)
RETURN INTEGER
IS
BEGIN
IF ship_date_in BETWEEN sdate_in AND edate_in
THEN
RETURN 1;
ELSE
RETURN 0;
END IF;
END;
Ja, das ist wirklich schon alles! Mit der Funktion incr_in_range wird die lange und
verworrene SQL-Anweisung zu einem einfachen:
SELECT FC.year_number,
SUM (incr_in_range (ship_date, q1_sdate, q1_edate)) Q1_results,
SUM (incr_in_range (ship_date, q2_sdate, q2_edate)) Q2_results,
SUM (incr_in_range (ship_date, q3_sdate, q3_edate)) Q3_results,
SUM (incr_in_range (ship_date, q4_sdate, q4_edate)) Q4_results
FROM orders O,
fiscal_calendar FC
GROUP BY year_number;
Die gespeicherte Funktion beseitigt die Code-Redundanz und macht die SQL-Anweisung
sehr viel lesbarer. Außerdem könnte diese Funktion auch noch in anderen SQL-
Anweisungen verwendet werden, wo die gleiche Logik benötigt wird.
Partielle Spaltenwerte mit GROUP BY
Die GROUP BY-Klausel in einer SELECT-Anweisung ermöglicht es Ihnen, Daten über
mehrere Datensätze hinweg zu sammeln und anhand einer oder mehrerer Spalten zu
gruppieren. Die folgende SELECT-Anweisung berechnet beispielsweise den Gesamtbe-
602

Beispiele eingebetteten PL/SQL-Codes
trag der Gehälter, die an alle Mitarbeiter mit jeweils dem gleichen Titel ausgezahlt werden:
SELECT job_title_desc, SUM (salary)
FROM employee E, job_title JT
WHERE E.job_title_id = JT.job_title_id
GROUP BY job_title_desc;
Ein Auszug aus der Ergebnismenge dieser Abfrage könnte so aussehen:
ACCOUNT MANAGER 32000
OFFICE CLERK 4000
PROJECT MANAGER 10006
SHIPPING CLERK 4200
Was wäre aber, wenn Sie eine Gesamtsumme der Gehälter für jeden Typ oder jede
Titelkategorie sehen wollten? Wieviel verdienen die verschiedenen Angestellten in der
Firma? Und wie ist es mit den verschiedenen Managern und Geschäftsführern?
Mit nativem SQL ist so etwas ziemlich schwierig zu schreiben. Was Sie eigentlich wollen,
ist, mit GROUP BY die verschiedenen Kategorien zusammenzufassen, aber diese
Kategorien gibt es nicht als separate Tabelle. Sie sind in die Titelbezeichnungen denormalisiert
worden, die GROUP BY-Klausel kann aber nur auf alle vollständigen Spaltenwerte
angewendet werden. Glücklicherweise bieten gespeicherte Funktionen in SQL
eine naheliegende Lösung für dieses Problem. Die folgende Funktion job_category
erwartet als ihren Parameter den Primärschlüssel der Titeltabelle und liefert die Jobkategorie
zurück. Das geschieht mittels einer LIKE-Operation über den Text dieses Jobtitels
– etwas, was man in einer GROUP BY-Klausel nicht direkt machen kann.
FUNCTION job_category (title_id_in IN job_title.job_title_id%TYPE)
RETURN VARCHAR2
IS
CURSOR title_cur IS
SELECT job_title_desc FROM job_title
WHERE job_title_id = title_id_in;
title_rec title_cur%ROWTYPE;
BEGIN
OPEN title_cur; FETCH title_cur INTO title_rec;
IF title_cur%NOTFOUND
THEN
CLOSE title_cur;
RETURN NULL;
ELSE
CLOSE title_cur;
IF title_rec.job_title_desc LIKE '%CLERK%'
THEN
RETURN 'CLERK';
ELSIF title_rec.job_title_desc LIKE '%VICE PRESIDENT%'
THEN
RETURN 'VICE PRESIDENT';
ELSIF title_rec.job_title_desc LIKE '%MANAGER%'
THEN
603

Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen
RETURN 'MANAGER';
END IF;
END IF;
END;
Jetzt kann ich meine Abfrage mit der Funktion job_category neu schreiben und all die
Konfusionen mit meinen denormalisierten Stellenbezeichnungen vermeiden:
SELECT job_category (job_title_id) as title, SUM (salary)
FROM employee
GROUP BY title;
Ich verwende diese Funktion sowohl in der SELECT-Liste als auch in der GROUP BY-
Klausel. Mit dieser Abfrage kann ich nun etwa folgendes Resultat bekommen:
CLERK 8200
MANAGER 42006
VICE PRESIDENT 75000
Sequentielle Verarbeitung eines Spaltenwerts
Es ist sehr leicht, mit der Funktion INSTR herauszufinden, ob ein bestimmtes Wort oder
eine Menge von Zeichen in einem String steht. Es ist ebenfalls leicht, in SQL zu bestimmen,
welche Zeilen eine Spalte haben, die ein bestimmtes Wort enthält. Aber es ist sehr
viel schwieriger, nur mit SQL herauszufinden, wie oft ein bestimmtes Wort oder eine
Menge von Zeichen in einem String in einer einzigen Zeile auftaucht. Die eingebaute
mengenbezogene Verarbeitung von SQL kennt kein iteratives oder Schleifenverhalten
innerhalb einer Zeile – nur über Zeilen hinweg.
Wenn ich eine iterative Analyse oder Berechnung auf einem bestimmten Wert in einer
einzigen Zeile ausführen möchte, dann muß ich eine PL/SQL-Funktion verwenden.
Schauen wir uns an, wie man das macht.
Zunächst der SQL-Code, der mir alle Zeilen in der Tabelle text ausgibt, die das Wort
»der« enthalten:
SELECT text
FROM notes
WHERE INSTR (text, 'der') > 0;
Ich kann sogar INSTR benutzen, um alle Zeilen herauszufinden, die das Wort »der« mindestens
dreimal enthalten:
SELECT text
FROM notes
WHERE INSTR (text, 'der', 1, 3) > 0;
Und bevor man mich schlägt, könnte ich auch alle Zeilen ermitteln, die das Wort »der«
genau dreimal enthalten:
SELECT text
FROM notes
604

Beispiele eingebetteten PL/SQL-Codes
WHERE INSTR (text, 'der', 1, 3) != 0
AND INSTR (text, 'der', 1, 4) = 0;
Wenn INSTR also einen von Null verschiedenen Wert für das dritte Auftreten von »der«,
aber 0 für das vierte Auftreten zurückgibt, dann heißt das, daß der Teilstring genau dreimal
im String vorkommt.
Wenn ich aber einen Bericht benötige, der die Anzahl von »der«-Vorkommnissen in
jeder meiner Notizen aufführt, oder wenn ich die Anzahl der Vorkommnisse von »der«
mit GROUP BY zusammenfassen möchte, dann läßt SQL mich im Stich. Ich kann meinen
Wunsch höchstens in Pseudocode ausdrücken:
SELECT anzahl-von-der-im-text, text
FROM notes
GROUP BY anzahl-von-der-im-text;
Als nichtprozedurale Sprache, die mengenorientiert (und zwar in Bezug auf Mengen
von Zeilen) ist, kennt SQL keine Möglichkeit, programmatisch den Inhalt einer
bestimmten Spalte analysieren zu lassen. PL/SQL ist dagegen perfekt dafür ausgerüstet,
um diese Art von Problemen zu lösen. Das Package ps.parse auf der Diskette zeigt,
wie man eine Funktion schreibt, welche die Anzahl von Atomen (Wörter und/oder
Begrenzungszeichen) in einem String ermittelt. Ich werde die Implementierung dieses
Packages hier nicht wiederholen, aber Ihnen zumindest zeigen, wie man diese Funktion
in SQL einsetzen könnte:
• Anzeigen, wie oft »der« in jeder Zeile von text vorkommt:
SELECT text,
ps_parse.number_of_atomics (text, 'der')
FROM notes;
• Anzeigen, wie oft das Wort »dringend« über die Tage der Woche verteilt ist, aber
nur die Texte berücksichtigen, in denen dieses Wort mindestens einmal auftaucht:
SELECT TO_CHAR (note_date, 'DAY')day,
SUM (ps_parse.number_of_atomics (text, 'dringend')) urgent_count
FROM notes
WHERE urgent_count > 0;
GROUP BY TO_CHAR (note_date, 'DAY');
Rekursive Verarbeitung in einer SQL-Anweisung
SQL unterstützt keine Rekursion, auch wenn diese mächtige Programmiertechnik
manchmal doch sehr wichtig für die Lösung eines Problems ist. PL/SQL erlaubt aber das
rekursive Aufrufen von Funktionen, so daß Sie die rekursiven Aufrufe bei Bedarf in eine
Funktion stecken können, wenn Sie in SQL Rekursion benötigen.
Nehmen wir an, Sie schreiben eine Anwendung, die Schecks ausdruckt. Ein Scheck enthält
sowohl die numerische Betragsangabe (beispielsweise DM 99,70) als auch die ausgeschriebene
Version des Betrags (neunundneunzig Mark und siebzig Pfennige). Mit
SQL können Sie den numerischen Scheckbetrag (der in der Datenbank steht) nicht in
die ausgeschriebene Version umsetzen. Mit PL/SQL geht das aber, auch wenn wir dafür
605

Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen
ein bißchen tiefer in die Trickkiste greifen müssen. Dabei bekommen wir Rekursion,
globale Daten und PL/SQL-Tabellen zu fassen und können damit eine sehr elegante
Lösung finden.
Das untenstehende Package checks ermöglicht genau diese Konvertierung. 2
/* Dateiname auf der Begleitdiskette: checks.spp */
PACKAGE checks
IS
/* Zahl in Worte konvertieren */
FUNCTION num2words (number_in IN NUMBER) RETURN VARCHAR2;
/* Das ist ein Package, ich muss den Reinheitsgrad zusichern */
PRAGMA RESTRICT_REFERENCES (num2words, WNDS);
END checks;
PACKAGE BODY checks
IS
/* Tabellenstruktur, welche die Namen der numerischen Komponenten enthaelt. */
TYPE numwords_tabtype IS TABLE OF VARCHAR2(20)
INDEX BY BINARY_INTEGER;
words_table numwords_tabtype;
/* Wird im Initialisierungsabschnitt verwendet */
v_date DATE;
FUNCTION num2words (number_in IN NUMBER) RETURN VARCHAR2
IS
my_number NUMBER;
BEGIN
/* Sorry, aber wir kuemmern uns hier nicht um Pfennige! */
my_number := FLOOR (number_in);
/* $1000+ */
IF my_number >= 1000
THEN
/* In zwei rekursive Aufrufe von num2words aufteilen */
RETURN num2words (my_number/1000) ||
' Thousand ' ||
num2words (MOD (my_number, 1000));
END IF;
/* $100-999 */
IF my_number >= 100
THEN
/* In zwei rekursive Aufrufe von num2words aufteilen */
RETURN num2words (my_number/100) ||
' Hundred ' ||
2 Diese Implementierung von number-to-words wurde zuerst von Mike Burnside von Oracle Australia auf
der International Oracle User's Week in San Francisco im September 1994 vorgestellt. Ich habe einige kleinere
Änderungen vorgenommen.
606

Beispiele eingebetteten PL/SQL-Codes
END IF;
num2words (MOD (my_number, 100));
/* $20-$99 */
IF my_number >= 20
THEN
/* In das Zehnerwort und den letztlichen Dollarbetrag aufteilen */
RETURN words_table (FLOOR (my_number/10)) ||
' ' ||
num2words (MOD (my_number, 10));
END IF;
/* Wir sind bei 19 oder weniger. Wort aus dem "oberen Register" der Tabelle
holen */
RETURN words_table (my_number + 10);
END num2words;
BEGIN
/* Initialisierungsabschnitt des Packages, wird nur einmal pro Sitzung ausgefuehrt
*/
/* Manuell die Zehnernamen konstruieren */
words_table (1) := 'Ten';
words_table (2) := 'Twenty';
words_table (3) := 'Thirty';
words_table (4) := 'Forty';
words_table (5) := 'Fifty';
words_table (6) := 'Sixty';
words_table (7) := 'Seventy';
words_table (8) := 'Eighty';
words_table (9) := 'Ninety';
/* Bei 0 NULL zurueckgeben */
words_table (10) := NULL;
/* Zahlnamen von eins bis neunzehn erzeugen */
FOR day_index IN 1 .. 19
LOOP
v_date := TO_DATE (to_char(day_index) || '-JAN-94');
words_table (day_index+10) :=
INITCAP (TO_CHAR (v_date, 'DDSP'));
END LOOP;
END checks;
Hier einige Beispiele der Konvertierung von ganzen Zahlen in Worte:
checks.num2words (99) ==> Ninety Nine
checks.num2words (12345) ==> Twelve Thousand Three Hundred Forty Five
checks.num2words (5) ==> Five
607

Kapitel 17: PL/SQL-Funktionen von SQL aus aufrufen
Ich kann diese Package-Funktion auch in meiner SQL-Anweisung verwenden, um alle
Informationen, die ich zum Drucken des Schecks benötige, aus der Datenbank zu
holen:
SELECT TO_CHAR (SYSDATE, 'Month DD, YYYY'),
payee,
amount,
checks.num2words (amount),
comment
FROM bill
WHERE bill_status = 'UNPAID'
608