Wykład 11
Struktury danych | Rozszerzenia proceduralne | Więzy integralności | Transakcje | Blokady | Rozszerzenia obiektowe
Przegląd wybranych możliwości systemu Oracle 8
Jako przykład innego (niż głównie omawiany dotąd w ramach wykładu MySQL) RDBMS omówię teraz system Oracle 8, jeden z czołowych komercyjnych systemów relacyjnych baz danych, produkcji Oracle Corporation. Z konieczności omówienie to ograniczone będzie jednak do pobieżnego przeglądu wybranych możliwości tego systemu, wykraczających poza funkcjonalność oferowaną przez (np.) MySQL. W przygotowaniu tego omówienia opieram się głównie na firmowej dokumentacji. Tam też należy szukać szczegółów dotyczących np. składni właściwych dla Oracle rozszerzeń SQL czy dostarczanych wraz z systemem narzędzi do tworzenia aplikacji -- tutaj celem jest jedynie pobieżne poinformowanie o bogactwie dostępnych w Oracle możliwości.
Fakt, że do omówienia na wykładzie wybrałem akurat Oracle 8 nie powinien być rozumiany jako rekomendacja stosowania akurat tego RDBMS do konkretnych wdrożeń (ani wręcz przeciwnie). Autor osobiście sam nigdy z żadnej wersji systemu Oracle nie korzystał, co nie stwarza podstaw do jakichkolwiek rekomendacji. Podobnie, MySQL został wybrany jako baza do wykładu i ćwiczeń ze względów jedynie praktyczno/dydaktycznych, z uwagi na swoją względną prostotę, łatwą dostępność i niewielkie wymagania sprzętowe.
Struktury danych w Oracle 8
Baza danych Oracle charakteryzuje się pewną strukturą fizyczną (zestawem plików w których zapisane są dane składające się na bazę oraz dodatkowe dane wykorzystywane przez serwer), i odrębną od niej strukturą logiczną (określającą sposób w jaki serwer Oracle prezentuje te dane aplikacjom-klientom).
W MySQL ,,fizyczna'' struktura plików bazy danych blisko odwzorowuje logiczną strukturę bazy: poszczególnym bazom danych w terminologii MySQL, tj. grupom tabel, odpowiadają podkatalogi katalogu danych serwera, a poszczególnym tabelom -- pliki w tych podkatalogach (dokładniej: każdej tabeli odpowiadają trzy pliki, zawierające opis definicji tabeli, indeksy oraz właściwe dane
Na strukturę logiczną bazy danych Oracle składają się tzw. przestrzenie tabel (tablespaces) oraz schematy (schemas). Podział na przestrzenie tabel związany jest ze strukturą fizyczną bazy danych (każdy tablespace zawiera jeden lub więcej fizycznych plików danych), i umożliwia np. grupowanie danych wykorzystywanych przez poszczególne aplikacje obsługiwane przez jeden serwer Oracle dla celów administracyjnych. Każdy tablespace może być w danej chwili udostępniany bądź nie aplikacjom, co pozwala na selektywne ,,wyłączenie'' części bazy danych w celu wykonania czynności administracyjnych które tego wymagają.
Z kolei schemat jest zbiorem obiektów będących strukturami logicznymi bezpośrednio odnoszącymi się do danych zapisanych w bazie. Obiekty takie to np. tabele, indeksy, widoki, procedury, klastry, i szereg innych struktur danych swoistych dla systemu Oracle. Nie ma żadnego (koniecznego) związku pomiędzy podziałem bazy danych na przestrzenie tabel a podziałem na schematy.
Widok (view) to coś w rodzaju wirtualnej tabeli. Widoki same w sobie nie zawierają danych, lecz czerpią dane ze swojej tabeli lub tabel bazowych. Z pewnymi ograniczeniami, widoki dopuszczają te same operacje SQL co tabele, z tym że operacje prowadzące do modyfikacji danych powodują modyfikację danych w tabelach bazowych. Widokiem można się posłużyć np. w celu ukrycia części kolumn tabeli przed pewnymi użytkownikami lub aplikacjami, ukrycia złożoności oryginalnych danych poprzez ujęcie w widoku np. jedynie pewnych wartości sumarycznych lub też wartości uzyskanych poprzez zapytania posługujące się złączeniami; można je wykorzystywać jako pewien sposób trwałego zapisu złożonych zapytań, itp.
Klastry (clusters) są to grupy tabel posiadających wspólną kolumnę lub kolumny, zapisywane przez system w specjalny sposób -- tak by zminimalizować wielokrotny zapis tych samych danych i zoptymalizować szybkość dostępu, szczególnie w przypadkach gdy przewiduje się częste stosowanie zapytań odnoszących się do złączeń tych tabel. Obsługa klastrów jest przezroczysta dla aplikacji.
Funkcje, procedury i rozszerzenia proceduralne
System Oracle rozszerza język SQL poprzez rozszerzenia proceduralne, zwane PL/SQL. Obejmują one instrukcje sterujące takie jak IF ... THEN ..., WHILE i LOOP. Rozszerzenia proceduralne mogą być stosowane w budowie zapytań każdorazowo wysyłanych przez aplikację-klienta do serwera, lecz możliwe jest również trwałe zapisywanie procedur i funkcji w bazie danych jako obiektów schematu w celu późniejszego wielokrotnego odwoływania się do nich. Procedury, funkcje i inne obiekty (takie jak np. zmienne) mogą być również grupowane w tzw. pakiety (packages) i w tej postaci zapisywane jako obiekty bazy danych.
Szczególnym przypadkiem procedur są tzw. triggers; są to procedury wykonywane automatycznie w wyniku operacji takich jak INSERT, UPDATE czy DELETE wykonywanych na określonej tabeli. Mogą one służyć np. do automatycznego generowania danych pochodnych, rejestrowania modyfikacji danych, egzekwowania złożonych reguł integralności, itp.
Więzy integralności
W dodatku do znanych już nam z MySQL postaci więzów integralności wprowadzanych deklaracjami NOT NULL, UNIQUE i PRIMARY KEY, system Oracle obsługuje również więzy integralności referencyjnej wprowadzane deklaracją FOREIGN KEY, oraz w zasadzie dość dowolne więzy dające się wyrazić za pomocą wyrażenia logicznego (deklaracja CHECK). Również wspomniane powyżej triggers mogą posłużyć za narzędzie do implementowania reguł integralności nie dających się wyrazić w inny sposób.
Obsługa transakcji w Oracle 8
W RDBMS Oracle 8, transakcja jest logiczną jednostką zadania składającą się z jednej lub wielu instrukcji SQL. Transakcja stanowi jednostkę atomową: to znaczy, że albo zastosowane (committed) zostaną wszystkie składające się na transakcję instrukcje SQL, powodując odpowiednie zmiany stanu bazy danych, albo transakcja jako całość zostanie cofnięta (rollback) a baza danych pozostanie w stanie z przed początku transakcji.
Początkiem transakcji jest pierwsza wykonywalna instrukcja SQL (pierwsza która wystąpiła po zamknięciu poprzedniej transakcji). Zamknięcie transakcji następuje w wyniku:
* wydania instrukcji COMMIT lub ROLLBACK
* wydania jednej z instrukcji związanych z definicją danych (CREATE, DROP, RENAME, ALTER) -- co powoduje zamknięcie (zastosowanie) bieżącej transakcji (o ile zawiera ona instrukcje modyfikujące dane) i wykonanie instrukcji definicji danych jako nowej transakcji
* rozłączenia się klienta z serwerem bazy danych -- transakcja zostaje zastosowana
* anomalnego zerwania sesji użytkownika -- transakcja zostaje cofnięta.
Zastosowanie transakcji (COMMIT wykonane jawnie lub implicite, jak opisano powyżej) powoduje trwałe zapisanie w stanie bazy danych skutków instrukcji SQL składających się na tę transakcję. Ulegają równocześnie zniesieniu blokady nałożone na dane w ramach tej transakcji.
Drugi sposób zamknięcia transakcji -- jej cofnięcie (ROLLBACK) unieważnia skutki wszystkich instrukcji SQL składających się na tę transakcję, pozostawiając dane w stanie z przed jej rozpoczęcia. Blokady danych również zostają zniesione.
Możliwe jest również dzielenie dłuższych transakcji na mniejsze części, poprzez deklarowanie znaczników pośrednich (savepoints). Umożliwia to wycofanie w razie błędu jedynie fragmentu transakcji, i ponowienie próby jego wykonania (np. ze zmienionymi parametrami) bez powtarzania całej transakcji od początku. Częściowe cofnięcie transakcji do znacznika nie zamyka transakcji.
Blokady w Oracle 8
Blokady stanowią mechanizm strzegący integralności danych w sytuacji wielodostępu, poprzez zapewnienie określonemu klientowi wyłączności dostępu do modyfikowanych przez niego danych, gdy jest to niezbędne aby zapobiec błędom które mogłyby wyniknąć z ,,przemieszania'' modyfikacji danych wykonywanych przez różnych klientów. Blokady stosowane są zarówno do struktur danych widocznych dla użytkownika (tabele, wiersze), jak i do wewnętrznych struktur danych systemu.
System Oracle stosuje blokady automatycznie, w sposób niewidoczny dla użytkownika, w ramach obsługi transakcji. W szczególnych przypadkach może być potrzebne (i jest możliwe) jawne deklarowanie blokad lub zmiana przez użytkownika blokad stosowanych implicite, sytuacje takie są jednak wyjątkiem. Przykłady takich sytuacji: pewna transakcja wykonuje jedynie odczyt danych z pewnych tabel (instrukcjami SELECT) -- co nie wiąże się automatycznie z blokadą dostępu, lecz musi mieć zagwarantowaną niezmienność tych tabel w ramach transakcji; pewna transakcja musi mieć zagwarantowany wyłączny dostęp do potrzebnych jej danych, ponieważ nie może z jakichś względów czekać na zwolnienie blokad które mogą być nałożone na te dane przez innych klientów. Do takich celów istnieje m. in. instrukcja LOCK TABLE.
Przykładowo, instrukcja
LOCK TABLE tabela IN SHARE MODE
uniemożliwia innym, jednocześnie wykonywanym transakcjom dokonywanie modyfikacji danych w podanej tabeli, oraz nakładanie blokad wyłącznych (p. poniżej). Pozwala natomiast na nałożenie analogicznych blokad (SHARE MODE) przez inne transakcje -- wówczas żadna z transakcji nie będzie mogła dokonać modyfikacji danych.
Z kolei
LOCK TABLE tabela IN EXCLUSIVE MODE
dopuszcza inne transakcje jedynie do odczytu danych z zablokowanej tabeli, uniemożliwiając im jakiekolwiek inne operacje (łącznie z nakładaniem własnych blokad).
System blokad w Oracle 8 jest dość złożony; jawne blokady należy stosować raczej oszczędnie, uwzględniając blokady stosowane niejawnie przez system w wyniku występowania w transakcji instrukcji modyfikujących dane. Istnieje poważna możliwość doprowadzenia do sytuacji, w których kilka transakcji może czekać w nieskończoność na zwolnienie zablokowanych zasobów.
Rozszerzenia obiektowe
Tzw. rozszerzenia obiektowe do systemu Oracle 8 oferowane są jako opcja w ramach wersji Enterprise Edition. Opcja ta stwarza możliwość korzystania ze złożonych typów danych definiowanych przez użytkownika -- typów obiektowych (object types), oraz typów kolekcji (collection types).
Typy obiektowe są złożonymi typami danych, zbliżonymi do klas występujących w obiektowych językach programowania. Typ obiektowy charakteryzuje się nazwą, i łączy w sobie atrybuty oraz metody. Za atrybuty obiektu służyć mogą zarówno proste (wbudowane) typy danych, takie jak te które funkcjonują w roli typów danych kolumn tabeli relacyjnej, jak i inne (zdefiniowane przez użytkownika) typy obiektowe. Metodami natomiast mogą być funkcje lub procedury, zarówno stworzone w PL/SQL i przechowywane w samej bazie danych (jako obiekty schematu), jak i procedury zewnętrzne, napisane w innym języku programowania np. C. Metody służą do wykonywania operacji na atrybutach obiektów. Każdy typ obiektowy jest automatycznie wyposażony w metodę zwaną konstruktorem; jej wywołanie powołuje do istnienia instancję danego typu -- inaczej mówiąc, obiekt utworzony według wzorca zadanego przez typ -- inicjalizując zarazem jego atrybuty.
Zdefiniowane przez użytkownika typy obiektowe można wykorzystywać całkiem podobnie jak proste typy danych, tj. jako typy danych występujących w kolumnach tabel relacyjnych. Istnieją też jednak dodatkowe możliwości -- można tworzyć tzw. tabele obiektów, mogące funkcjonować w dwóch różnych rolach: jako jednokolumnowe tabele relacyjne, gdzie typem kolumny jest dany typ obiektu, i jako tabele o kolumnach zawierających poszczególne atrybuty tych obiektów.
Typami kolekcji są z kolei tablice (VARRAY) oraz tabele zagnieżdżone (nested tables). Typ VARRAY jest zbliżony do tablicy w ,,standardowych'' językach programowania; jest to uporządkowany zbiór wartości jednego typu, indeksowanych kolejnymi liczbami naturalnymi. Tablice mogą być zmiennej wielkości, przy deklaracji typu należy jednak podać wielkość maksymalną z jakiej będzie się korzystać. Tablice VARRAY mogą być wykorzystywane jako typy kolumn, typy atrybutów obiektów, oraz jako zmienne i parametry procedur w PL/SQL.
Tabele zagnieżdżone są to tabele jednokolumnowe, gdzie typem kolumny może być zarówno typ prosty jak i typ obiektowy. Mogą one również służyć jako typ kolumny tabeli relacyjnej, typ atrybutu obiektu, oraz zmienne i parametry procedur. Podobnie jak tabele obiektów, mogą one również funkcjonować jako tabele wielokolumnowe o kolumnach zawierających poszczególne atrybuty obiektów stanowiących wiersze (o ile oczywiście jako typ kolumny zadeklarowano jakiś obiektowy typ danych).