Język PL/SQL jest proceduralnym rozszerzeniem języka SQL, co ma swoje odzwierciedlenie również na poziomie jego nazwy (ten akronim rozwija się do „Procedural Language extensions to the Structured Query Language”). Dodaje on najbardziej typowe konstrukcje programistyczne (zmienne, pętle itp), by tym sposobem przezwyciężyć pewne oczywiste ograniczenia SQL. Natomiast w tym kontekście mówi się zazwyczaj o “rozszerzeniu”, ponieważ jest rodzaj wbudowanego języka, który działa wyłącznie na środowisku Oracle. Innymi słowy, nie da się napisać programu PL/SQL, który działałby poza bazą danych Oracle.
To co mi najbardziej rzuca się w oczy, to fakt, że w odróżnieniu od innych języków programowania, gdzie do wyznaczania bloków programu używane są zazwyczaj nawiasy klamrowe ({}), w PL/SQL służą do tego pewne słowa kluczowe, które tną program na ściśle “wyspecjalizowane” sekcje. Tutaj widoczna jest duża zbieżność z SQL jako takim.
Jeśli chodzi strukturę typowego bloku anonimowego (co to oznacza, o tym na końcu tego wpisu), to składa się on z trzech sekcji:
- sekcja deklaracji (declaration section),
- sekcja wykonawcza (execution section),
- sekcji obsługi wyjątków (exception-handling section).
Właściwie wyżej powinienem był napisać, że blok anonimowy może się składać z tych trzech sekcji, ponieważ jedynie druga z nich (execution section) jest obowiązkowa, podczas gdy pozostałe dwie są opcjonalne (można je pominąć, jeśli nie są one z punktu widzenia programu potrzebne).
SEKCJA DEKLARACJI
To pierwsza w kolejności występowania sekcja w bloku PL/SQL, ale – jak już zostało wspomniane wyżej – jest ona opcjonalna. Ta sekcja zaczyna się od słowa kluczowego DECLARE, zaś kończy się na instrukcji BEGIN.
W jej obrębie są umieszczane deklaracje zmiennych, kursorów, wyjątków, podprogramów, kolekcji oraz innych obiektów, o których piszący te słowa ma mniej lub bardziej mgliste pojęcie. Sekcji tej a właściwie zmiennym, poświęcony będzie kolejny wpis tego cyklu, dlatego na ten moment tyle wiedzy wystarczy.
SEKCJA WYKONAWCZA
Część wykonawcza należy do “zestawu obowiązkowego” i jest bez dwóch zdań sercem każdego bloku anonimowego (dla procedur czy funkcji nazwanych rzecz jasna jest tak samo). To w jej obrębie jest wykonywany właściwy kod, a ponieważ PL/SQL oczekuje instrukcji z tego bloku, nie może być ona pusta, czyli musi zawierać co najmniej jedną instrukcję, choćby to miał być NULL. Skoro już przy instrukcjach jesteśmy to należy wspomnieć, że niestety każda z nich musi kończyć się średnikiem (napisałem “niestety”, ponieważ dla mnie jest to zło w czystej postaci, będące de facto reliktem przeszłości).
Wracając jednak do tematu: to co należy wiedzieć o tej sekcji można sprowadzić do następujących punktów:
- Może zawierać zarówno kod PL/SQL oraz SQL.
- Może zawierać jeden lub wiele bloków wewnątrz (dopuszcza się ich zagnieżdżanie).
- Sekcja ta zaczyna się od słowa kluczowego BEGIN.
- Kończy się słowem kluczowym END lub EXCEPTION – w tym drugim wypadku, gdy w naszym programie występuje blok obsługi wyjątków (o czym za chwilę).
SEKCJA OBSŁUGI WYJĄTKÓW
Sekcja ta zaczyna się od słowa kluczowego EXCEPTION i jej rolą jest przechwytywanie, a następnie – jak sama nazwa wskazuje – obsługa wyjątków zgłaszanych w wyniku realizacji kodu z sekcji wykonawczej. Można ona rzecz jasna zawierać instrukcje PL/SQL.
To co na ten moment warto zapamiętać:
- Sekcja ta jest opcjonalna.
- Jeśli jednak występuje w naszym programie, to ostatnią częścią bloku PL/SQL – sterowanie z tej sekcji nie może wrócić do bloku wykonawczego.
- Dlatego po tej sekcji należy zawsze umieścić słowo kluczowe „END”.
Zbierając to wszystko do kup, to schemat bloku wygląda jak niżej:
DECLARE –opcjonalnie
<deklaracje zmiennych, kursorów etc>
BEGIN –obowiązkowe
<instrukcje do wykonania – minimum jedna>
EXCEPTION –opcjonalne
<obsługa wyjątków>
END; –obowiązkowe
ANONIMOWE BLOKI
W dużym uproszeniu bloki anonimowe to bloki PL/SQL, którym nie przypisano żadnej nazwy. Tym samym nie są one przechowywane na serwerze jako obiekt bazy danych i z tego też powodu nie są one prekompilowane (kompilacja oraz wykonanie kodu odbywają się w tym samym czasie).
Oczywiście tego typu programy mogą być – i bardzo często są – zapisywane w postaci skryptów tj. plików tekstowych zawierających kod możliwy do ponownego (wielokrotnego) użycia. Tym niemniej równie często stosowane są dla rozwiązań ad hoc do zaadresowania jakiegoś doraźnego problemu, no i rzecz jasna jako poręczne narzędzie do nauki.
Poniżej znajduje się kilka dodatkowych cech bloków anonimowych.
- Bloki te zaczynają się od słowa kluczowego „DECLARE” lub „BEGIN”.
- Mogą wywoływać inne nazwane bloki, ale wywołanie anonimowego bloku nie jest możliwe, ponieważ rzecz jasna nie ma do nich żadnej referencji na serwerze bazy danych (wszak nie są one na nim zapisane w żadnej postaci).
- Bloki te mogą mieć wszystkie trzy sekcje kodu, przy czym sekcja wykonawcza jest obowiązkowa, pozostałe dwie są opcjonalne.
NAZWANE BLOKI
Nazwane bloki to takie (pod)programy, które posiadają specyficzną i niepowtarzalną nazwę. Ważniejsze jest jednak to, że są one przechowywane na serwerze jako obiekty bazy danych. W związku z tym ostatnim faktem można się do nich odwoływać w innych blokach kodu (również blokach anonimowych) lub uruchamiać na żądanie lub jako część innego procesu (np. przy pomocy jakiegoś joba).
Poniżej znajduje się kilka dodatkowych cech nazwanych bloków.
- Bloki te można wywoływać z poziomu innych bloków.
- Bloki te mogą być zagnieżdżane w innych blokach. Sam też mogą zawierać zagnieżdżone bloki.
- Struktura bloku jest taka sama jak bloku anonimowego, z wyjątkiem tego, że nigdy nie zaczyna się od słowa kluczowego „DECLARE”. Zamiast tego rozpocznie się od “nagłówka” ze słowem kluczowym „CREATE”, dzięki czemu instruujemy kompilator, aby utworzył go jako obiekt bazy danych.
- Do bloków nazwanych zalicza się procedury, funkcje, wyzwalacze oraz pakiety. Każdy z nich zostanie bardziej szczegółowo omówiony w kolejnych tekstach z niniejszego cyklu.
NA ZAKOŃCZENIE
Dosłownie dwa słowa na koniec tego wpisu, nie związane bezpośrednio z omawianym dzisiaj tematem. Otóż kolejne teksty będą miały już bardziej “praktyczny” charakter, więc pojawiać się będą tam przykładowe fragmenty kodu. Ponieważ – co sygnalizowałem w poprzednim tekście – zakładam, że osoba śledząca wpisy pojawiające się w ramach tego cyklu, jest już nieźle zaznajomiona z dialektem SQL od Oracle’a, w związku z tym przyjąłem również domniemanie, że posiada dostęp do jakiegoś klienta PL/SQL oraz tym samym odpowiedniej bazy danych (ewentualnie biedaczysko klepie kod w SQL*Plus). Dlatego nie należy się spodziewać w najbliższym czasie żadnego tekstu opisujące jak osiągnąć taki “stan posiadania”.
Druga kwestia, którą chciałbym tutaj poruszyć jest bardziej trywialna. Chodzi o pewną dość powszechną konwencję, którą zapewne sam nie raz będę stosował, w przypadku prezentowania ogólnej postaci pewnych poleceń czy struktur programistycznych. Chodzi mianowicie o nawiasy kwadratowe “[ ]”. Otóż ich użycie będzie oznaczało, że dany element w te nawiasy ujęty jest opcjonalny, tak jak chociażby sekcja DECLARE czy EXCEPTION, o których dzisiaj była mowa. Rzecz jasna będę starał się o tym za każdym razem przypominać.
