Start

Unternehmen

Buch-Katalog

Seminare

Leserservice

Comelio-Blog

Datenbanken SQL MS SQL Server Oracle Trigger Module Pakete SQLX SysXMLGen XDB: Sichten XDB: XML Schema XDB: XSLT XDB: XMLType XDB: Konzepte XDB: PL/SQL XML-Speicheransätze SQLJ PHP UML C#.NET XML Schema XSLT

Übersicht

Alle Seminare Info-Broschüre Anmeldeformular Hotels & Anfahrt AGB

Comelio GmbH
Rellinghauser Straße 10
D-45128 Essen
Deutschland
Fon: 0201-437517-0
Fax: 0201-437517-10
info@comelio.com

Comelio GmbH
Goethestraße 34
D-13086 Berlin
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Glockengießerwall 17
D-20095 Hamburg
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Mainzer Landstraße 27-31
D-60329 Frankfurt
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Stiglmaierplatz/Dachauer Str. 37
D-80335 München
Deutschland
info@comelio.com

Comelio GmbH (Ecos)
Liebknechtstr. 33
D-70565 Stuttgart
Deutschland
info@comelio.com

Comelio GmbH
Nevinghoff 16
D-48147 Münster
Deutschland

Comelio GmbH
Friedrich - List - Platz 1
D-04103 Leipzig
Deutschland

Comelio GmbH
St. Johanner Strasse 41-43
D-66111 Saarbrücken
Deutschland

Comelio GmbH
Kaiser-Wilhem-Ring 27–29
D-50672 Köln
Deutschland

Comelio GmbH
Münsterstraße 248
D-40470 Düsseldorf
Deutschland

Comelio GmbH
Fürther Strasse
D-90429 Nürnberg
Deutschland

Comelio GmbH

Bremen
Deutschland

Comelio-Blog > Oracle > Pakete

Pakete

PL/SQL bietet über das Konzept der Pakete eine Möglichkeit, einige Vorteile der Objektorientierung auch mit Hilfe von prozeduralen Mitteln umzusetzen. Dazu zählen die Erstellung von Softwaremodulen und damit die Architektur von größeren Softwareeinheiten aus mehreren solchen Paketen sowie die Unterscheidung in sichtbare (öffentliche) und unsichtbare (private) Strukturen. Dieser Artikel stellt das Paketkonzept von PL/SQL in Grundzügen dar.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > Oracle > Pakete Freitext

Oracle: Pakete in PL/SQL

Mit Hilfe der PL/SQL-Pakete (Packages) führt man Funktionen und Prozeduren sowie weitere PL/SQL-Elemente zu großen modularen Strukturen zusammen. Einige der vorhandenen PL/SQL-Pakete sind Ihnen bereits in den zurückliegenden Erläuterungen begegnet. Sie haben dabei gesehen, dass sie Prozeduren genauso wie Funktionen enthalten und dass man diesen Modulen Werte übergeben kann, um überaus interessante und nützliche Ergebnisse schnell und unkompliziert zu erhalten. Dies ist das Grundprinzip des objektorientierten Designs und der modernen Software-Entwicklung, wenn auch PL/SQL selbst nicht vollständig objektorientiert ist. Dies mag sich irgendwann ändern, aber bis jetzt und auch noch in der nächsten Zeit kann man ähnliche Entwicklungsmuster über den Einsatz von Paketen erreichen.

Definition und Strukturen

Ein Paket ist also eine abgeschlossene Einheit von Prozeduren und Funktionen, die unter einem gemeinsamen Namen zusammengefasst werden. Dabei bieten sie in ihrer Gesamtheit Werkzeuge für unterschiedliche Einsätze innerhalb eines durch die Paket-Struktur bzw. seinen Namen und/oder eine Bedeutung abgegrenzten Bereichs innerhalb der Software an. In dem Ihnen schon bekannten Paket UTL_FILE befinden sich verschiedene Werkzeuge für das Erzeugen von Dateihandles, das Öffnen und Schließen sowie natürlich das Verarbeiten (Lesen und Schreiben) von Textdateien. Neben den gerade erwähnten Prozeduren und Funktionen lassen sich allerdings auch Cursor, Variablen, Ausnahmen, Sammlungen und Datensatztypen innerhalb von Paketen speichern. Dies eröffnet beispielsweise die Möglichkeit, Sammlungen zwischen Modulen und der aufrufenden Umgebung auszutauschen, wie wir es in einem der zurückliegenden Abschnitte mit Hilfe eines anonymen Blocks realisiert hatten, indem wir in seinem Deklarationsabschnitt den benötigten Sammlungstyp deklarierten.

Die Syntax für die Erstellung eigener Pakete und die Notation, um fremde bzw. eingebaute Pakete in Anwendungen einzusetzen, ist relativ simpel und im Gegensatz zu vielen anderen Strukturen überaus leicht verständlich. Letztendlich fassen Pakete tatsächlich nur andere Sprachelemente zu einer Gruppe zusammen und bieten sie unter einem gemeinsamen Namen an. Interessant dagegen und lohnenswert für Diskussionen und Planungsgedanken ist die korrekte Umsetzung von Software-Anforderungen und die Lösung von Schnittstellenproblemen bei der Entwicklung eigener Pakete. Dies hat allerdings wenig mit der Syntax gemein, sondern lässt sich nur durch allgemeine Regeln der Software-Technik und der eigenen Erfahrung meistern.

Vorteile durch die Verwendung von Paketen

Die Vorteile, die sich durch einen konsequenten Einsatz der Pakete (sowie aller weiteren modularen Strukturen) für die Entwicklung, Wartung und Bereitstellung von Software(-Komponenten) bieten, lassen sich im direkten Vergleich zum OOP-Ansatz folgendermaßen darstellen:

Quasi-Objektorientierung

Mit OOP verbindet man gemeinhin andere Elemente und Strukturen als die, die eine prozedurale Sprache wie PL/SQL bietet. Sie werden auch nicht die gleichen Bedingungen vorfinden, die die Beschreibung als objektorientiert verdienten. Allerdings steht in PL/SQL dennoch durch die Pakete eine Methode zur Verfügung, mit der eine Modularisierung von Software-Komponenten, die Entwicklung von Schnittstellen sowie eine leichte Wartbartkeit und Wiederverwendbarkeit umgesetzt werden können. Dies sind die Vorteile von Objektorientierung, die mit Hilfe der Pakete auch in PL/SQL zur Verfügung stehen.

Klare Schnittstellen

Durch die Entwicklung von modularen Elementen in einer größeren Software-Umgebung realisiert man gleichzeitig eine klare Schnittstellenstruktur, die einheitlich für alle anderen Entwickler bzw. Benutzer vorliegt. Dies erfordert einen größeren Planungsaufwand, bietet allerdings bei einer guten Umsetzung den Vorteil, dass sich Programmänderungen aufgrund von Änderungen in der Datenstruktur einer Datenbank etc. nicht automatisch auf die Schnittstellen auswirken, sondern in den meisten Fällen zunächst nur die Ausführungsabschnitte der nicht sichtbaren (siehe Kapselung) Elemente betreffen. Für die anderen Entwickler bzw. Benutzer ändert sich in diesen Fällen nichts, da sie weiterhin nur die Schnittstellen und deren Datenstrukturen zu berücksichtigen haben.

Kapselung

Die Paketstruktur selbst teilt sich in öffentliche und private Elemente. Die öffentlichen Elemente sind außerhalb des Pakets sichtbar, während die privaten nur innerhalb des Pakets angesprochen werden können. Dadurch lassen sich nformationen über Entwicklungsmuster, Datenstrukturen und Programmtechniken verstecken und nur diejenigen Elemente freilegen, die tatsächlich auch für alle anderen Entwickler / Benutzer sichtbar sein sollen.

Klare Datenstrukturen

Pakete sorgen nicht nur für klare Schnittstellen, die Schwierigkeiten bei der Änderung von internen Datenstrukturen zu vermeiden helfen. Mit Paketen können Sie auch globale Variablen bzw. globale Datenstrukturen für alle Anwendungen bereitstellen, die mit der gesamten Software arbeiten. Dies verhindert, dass globale und sich angeblich nie ändernde Werte z. B. direkt in Programme eingearbeitet werden. Solche Werte führen automatisch dazu, dass bei Änderungen an allen Orten, an denen diese globalen Daten vorkommen, Wartungsarbeiten notwendig werden. Stattdessen kann man sie (wie auch Cursor) in einem Paket unterbringen und so von allen Seiten aus benutzbar machen.

Aufbau von Paketen

Ein Paket besteht aus zwei Bereichen, die bei der Erstellung eines gesamten Pakets unabhängig voneinander programmiert und kompiliert werden müssen. Dies ist ein deutlich anderes Vorgehen als bei den modularen Strukturen von Funktionen und Prozeduren.

Es handelt sich dabei um folgende zwei Bereiche:

Spezifikation

Mit der Spezfikation erstellt man einen Kopf-Bereich eines Pakets. Hier befinden sich alle öffentlichen Elemente, also alle diejenigen Inhalte eines Pakets, auf die von außen zugegriffen werden kann. Man definiert hier alle Elemente, die im Paket selbst dann auch wieder erscheinen müssen. Vor Prozeduren und Funktionen platziert man z. B. den Namen und die Schnittstellen, also ihre Parameter nebst Parameter-Modi. Da nicht alle Elemente, die in der Spezifikation eines Pakets beherbergt werden können, auch einen Körper haben, kann es in gewissen Fällen auch körperlose Pakete geben. Dies ist beispielsweise bei Datentypen, Konstanten, Variablen und Ausnahmen der Fall. In der Einleitung erwähnten wir als möglichen Einsatzbereich von Paketen die Speicherung von globalen Variablen für die gesamte Anwendung. Entwickelt man für einen solchen Zweck ein Paket, ist dies tatsächlich wenig Aufwand, da nur die globalen Datenstrukturen gespeichert werden. Beim Aufruf kann man dann sehr gut durch die Punktnotation und am Paketnamen erkennen, welche Variablen(-werte) aus dem globalen Datenstrukturbereich einer Anwendung stammen. Dies fördert also zusätzlich neben den anderen erwähnten Aspekten die Lesbarkeit und die Verständlichkeit des Quelltextes.
Die folgende allgemeine Syntax zeigt zum einen, welche Elemente überhaupt in einer Paket-Spezifikation erscheinen können, und fasst zum anderen kurz zusammen, mit welchen Inhalten sie deklariert werden müssen:

        
CREATE [OR REPLACE] PACKAGE package_name
[AUTHID {CURRENT_USER | DEFINER}]
{IS | AS}
 [PRAGMA SERIALLY_REUSABLE;]
 [collection_typ_definition ...]
 [record_typ_definition ...]
 [subtype_definition ...]
 [collection_deklaration...]
 [constant_deklaration...]
 [exception_deklaration...]
 [object_deklaration...]
 [record_deklaration...]
 [variable_deklaration...]
 [cursor_spezifikation ...]
 [function_spezifikation...]
 [procedure_spezifikation...]
 [call_spec ...]
 [PRAGMA RESTRICT_REFERENCES(assertions) ...]
END [package_name];

      

Körper / Rumpf

Für jedes Element, das in der Spezfikation untergebracht wurde, folgt im Paket-Körper schließlich die eigentliche komplette Deklaration. Zusätzlich kann der Körper aber auch weitere Elemente enthalten, die privat und damit von außen nicht zugänglich sind. Sie lassen sich allerdings innerhalb der Deklaration der öffentlichen und privaten Paket-Elemente verwenden. Die folgende allgemeine Syntax zeigt, welche Elemente alle in einem Paket-Körper erscheinen können:

        
[CREATE [OR REPLACE] PACKAGE BODY package_name
{IS | AS}
 [PRAGMA SERIALLY_REUSABLE;]
 [collection_typ_definition ...]
 [record_typ_definition ...]
 [subtype_definition ...]
 [collection_deklaration...]
 [constant_deklaration...]
 [exception_deklaration...]
 [object_deklaration ...]
 [record_deklaration...]
 [variable_deklaration ...]
 [cursor_body ...]
 [function_spezifikation...]
 [procedure_spezifikation...]
 [call_ spezifikation...]
[BEGIN
 anweisungen]
END [package_name];]
      

Die Abbildung illustriert die zuvor erwähnte Struktur von Paketen noch einmal, wobei auf zwei Punkte Wert gelegt wurde: Zum einen erkennt man, dass eine Anwendung, die ebenfalls wie das gesamte Paket in der Datenbank gespeichert ist, lediglich den öffentlichen Teil und damit die Paket-Spezifikation aufruft. Zum anderen erkennt man, dass beide Bereiche des Pakets unabhängig voneinander in der Datenbank gespeichert sind.

Sichtbarkeit und Gültigkeit

Aus der Separation der Paketstruktur in die beiden Bereiche Spezifikation und Körper ergibt sich gleichermaßen die Aufteilung in die beiden Dimensionen öffentlich (Spezifikation) und privat (Körper). Elemente in der Spezifikation lassen sich also von außerhalb aufrufen. Dies gilt für Module genauso wie für Variablen oder Konstanten. Aus Sicht der aufrufenden Umgebung endet die Sichtbarkeit also bei den Elementen der Spezifikation. Es ist daher nicht möglich (Kapselung), auf Module oder Variablen innerhalb des Pakets bzw. im Körper zuzugreifen. Für die Elemente innerhalb der Spezifikation ergibt sich ein anderer Sichtbarkeitsbereich. Sie können sehr wohl auf Elemente zurückgreifen, die lediglich im Paket-Körper definiert wurden. Dies geschieht dann entweder über Wertzuweisungen oder in den Deklarationsabschnitten von Modulen im Körper. Dass die Elemente innerhalb des Körpers ohnehin gegenseitig sichtbar sind bzw. den allgemeinen Sichtbarkeitsregelungen für Blöcke unterworfen sind, versteht sich vermutlich von selbst.

Die Abbildung soll dies noch einmal bildhaft darstellen. Auf der einen Seite erfolgt ein Aufruf durch eine Umgebung, und auf der anderen Seite liegen unterschiedliche Elemente sowohl in der Spezifikation als öffentliche Elemente wie auch im Körper als private Elemente vor. Während die aufrufende Umgebung sehr wohl auf die Elemente mit dem Suffix 1 zugreifen kann, so kann sie keinesfalls auf die Elemente mit dem Suffix 2 zugreifen. Dies ist nur den Elementen selbst gestattet sowie natürlich auch den Elementen im Körper. Die beiden Suffixe kennzeichnen dabei die beiden Sichtbarkeitsbereiche, die sich durch die Paketstruktur ergeben.

Somit bildet die Spezifikation mit ihren Elementen die Schnittstelle zwischen der aufrufenden Anwendung und dem Paket. Dieser Bereich der Schnittstellenplanung bezieht sich ausschließlich auf die Zugriffserlaubnis der im Paket vorhandenen Elemente. Für die Hemisphäre der Datenstrukturen jedoch gelten die Schnittstellen der einzelnen Elemente, da sie wiederum Werte empfangen oder auswerfen, die für die Verarbeitung innerhalb der Module (im Körper des Pakets) erforderlich sind oder die für die Verarbeitung außerhalb des Pakets in der aufrufenden Umgebung benötigt werden.