446 7. SYSTEMOWE ASPEKTY JĘZYKA SQL

PRZYKŁAD 7.18

Będziemy kontynuować rozważania na temat rezerwowania miejsc, rozpoczęte w przykładach 7.16 i 7.17. Przy założeniu, że funkcja wykonuje się przy po­ziomie izolacji - odczyt powtarzalny, miejsce, które było dostępne przy pierw­szym wykonaniu zapytania, pozostaje niezajęte przy ponawianiu zapytania.

Załóżmy jednak, że relacja Rejsy zmieniła się. Na przykład mogły zo­stać zmienione samoloty i w ten sposób mogła się zwiększyć liczba dostęp­nych miejsc albo niektóre rezerwacje mogły zostać na przykład odwołane. Wówczas w odpowiedziach na kolejne zapytania mogą się pojawić nowe krotki z dostępnymi miejscami.

0

7.2.7. Ćwiczenia do podrozdziału 7.2

Ćwiczenie 7.2.1. Wszystkie ćwiczenia z tego rozdziału dotyczą następujących dwóch relacj i:

Produkt (producent, model, typ)

PC (model, szybkość, ram, hd, cd, cena)

Należy naszkicować programy wykonujące poniższe zadania, stosując instrukcje SQL osadzane w dowolnym języku podstawowym. Należy pamiętać o korzystaniu z in­strukcji coMMZT i RoLLaACK wszędzie tam, gdzie jest to niezbędne, oraz zaznaczeniu we właściwych miejscach, że transakcje są tylko do odczytu.

a) Dla danych wartości szybkości i rozmiaru RAM (jako argumentów funkcji) należy wyszukać wszystkie PC o tej charakterystyce oraz wydrukować nu­mer modelu i cenę każdego z nich.

*b) Dysponując numerem modelu, należy usunąć go z obu relacji Produkt i PC.

c) Dysponując numerem modelu, należy zwiększyć jego cenę o 100 $.

d) Przy zadanych wartościach: producenta, numeru modelu, szybkości, roz­miaru RAM, rozmiaru dysku twardego, szybkości CD oraz cenie należy stwierdzić, że ten model nie występuje w bazie. Jeśli jednak występuje, to należy podać komunikat dla użytkownika. Jeśli takiego modelu nie ma w bazie, to należy wstawić dane o tym produkcie do tabel Produkt i Pc.

!Ćwiczenie 7.2.2. Dla każdego programu z ćwiczenia 7.2.1 należy omówić problem niepodzielności, który może wystąpić podczas awarii systemu powstałej w trakcie przetwarzania tego programu.

!Ćwiczenie 7.2.3. Załóżmy, że transakcja T polega na wykonaniu jednego z czterech programów z ćwiczenia 7.2.1, a inne transakcje polegają na jednoczesnym wykonaniu tego samego programu lub któregoś z pozostałych. Jakie zachowania transakcji T są możliwe do zauważenia przy wykonywaniu na poziomie izolacji READ UNCOMMIT­TED, a które nie wystąpią przy poziomie izolacji SERIALIZABLE? Należy po kolei rozważyć wszystkie programy z ćwiczenia 7.2.1.

7.3. ŚRODOWISKO SQL 447

*!!Ćwiczenie 7.2.4. Załóżmy, że transakcja T jest funkcją nieskończoną, która co godzinę sprawdza, czy w bazie danych występuje PC o szybkości 200 i cenie poniżej 1000 $. Jeśli znajdzie się taki PC, to funkcja wypisuje komunikat i kończy dzialanie. W tym czasie mogą działać inne transakcje, które wykonują programy z ćwicze­nia 7.2.1. Dla każdego z czterech poziomów izolacji: sekwencyjnego, powtarzalnego odczytu, odczytu zatwierdzonego i odczytu niezatwierdzonego należy ola-eślić wynik transakcji T.

7.3. Środowisko SQL

W bieżącym rozdziale omówimy systemy zarządzania bazami danych w sposób możliwie najszerszy. Zobaczymy, w jaki sposób definiuje się bazy danych, a następnie organizuje katalogi, klastry i schematy. Dowiemy się także, w jaki sposób łączy się programy z tymi danymi, na których mają być wykonywane. Wiele tych szczegółów zależy od konkretnej implementacji, a więc skupimy uwagę na podstawowych zasadach, które są objęte standar­dem SQL2.

7.3.1. Środowiska

Środowisko SQL stanowi ramę dla danych i operacji SQL, które na tych danych mogą być wykonywane. W praktyce środowisko SQL utożsamia się z konkretną instalacją systemu zarządzania baz danych. Jeśli na przykład fir­ma ABC kupuje licencję systemu zarządzania bazami danych SQL firmy Dandy-DB i uruchamia ją na swoich systemach komputerowych ABC, to tak działający system nazywamy środowiskiem SQL.

Wszystkie omówione dotychczas elementy bazy danych: tabele, per­spektywy, dziedziny i asercje są definiowane w środowisku SQL. Tworzą one hierarchiczne struktury i każda z nich odgrywa właściwą sobie rolę w syste­mie. Struktury definiowane według standardu SQL2 zostały przedstawione na rys. 7.1 I .

Oto ich krótka charakterystyka.

1. Schematy". Są to zbiory tabel, perspektyw, asercji, dziedzin i innych typów danych, o których nie wspominaliśmy (ale zostały wymienione w ramce zatytułowanej „Co jeszcze należy do schematu?" w p. 7.3.2). Schematy stanowią podstawowe jednostki w systemie i są pojęciowo najbliższe bazom danych, ale są czymś węższym niż baza danych, co wyniknie w punkcie 3.

Zauważmy, że w tym kontekście schemat oznacza schemat bazy danych, a nie relacji.

448

7. SYSTEMOWE ASPEKTY J~ZYKA SQL

Środowisko = Instalacja DBMS

Katalog

Klaster = maksymalny zakres

działań na bazie danych Schemat

Katalog

Schemat

RYSUNEK 7.11

Organizacja elementów bazy danych w środowisku

2. Katalogi. Są to zbiory schematów. Tworzą one jednostki jednolite terminologicznie. W każdym katalogu może znajdować się wiele schematów, każdy z nich w danym katalogu musi mieć jednoznaczną nazwę. Ponadto każdy katalog zawiera specjalny schemat nazwany INFORMATION SCHEMA, który obejmuje informacje o schematach należących do danego katalogu.

3. Klastry. Tworzą je zbiory katalogów. Każdemu użytkownikowi jest przypisany klaster, czyli zbiór tych katalogów, do których ma dostęp (w podrozdziale 7.4 opisano, w jaki sposób organizuje się dostęp do katalogów oraz nadzór nad innymi elementami). W SQL2 nie ma precyzyjnej definicji klastrów, na przykład nie wiadomo, czy może się zdarzyć, że klastry różnych użytkowników się nakładają, a jed­nocześnie nie są identyczne. Z punktu widzenia użytkownika klaster określa maksymalny zakres dla wykonania zapytania, a więc w pew­nym sensie to właśnie klaster stanowi bazę danych dostępną dla użytkownika.

~.3. śxoDOmsKO sQL 449 7.3.2. Schematy

Najprostsza postać deklaracji schematu zawiera następujące elementy:

1. Słowo kluczowe CREATE SCHEMA. 2. Nazwa schematu.

3. Lista deklaracji elementów schematu: podstawowe tabele, perspekty­wy, asercje i dziedziny.

Schemat deklaracji jest więc następujący:

CREATE sCHEMA <nazwa schematu> <deklaracje elementów>

Deklaracje poszczególnych elementów zostały omówione w podrozdzia­łach 5.7, 5.8 i w rozdziale 6. Poza tym istnieją jeszcze inne rodzaje elementów schematu, które zostały wymienione w kolejnej ramce zatytułowanej „Co jeszcze należy do schematu?".

PRZYKŁAD 7.19

Można zadeklarować schemat obejmujący pięć relacji danych o filmach, z których korzystaliśmy w wielu przykładach, oraz inne elementy, takie jak perspektywy. Na rysunku 7.12 przedstawiono szkic deklaracji tego schematu.

CREATE SCHEMA SchematFilm

CREATE DOMAIN DziedzinaCert . . . jak w przykładzie 6.8 Deklaracje innych dziedzin

CREATE TABLE GwiazdaFilmowa . . . jak na rys. 6.4 Instrukcje tworzenia czterech innych tabel

CREATE VIEW FilmProd . . . jak w przykładzie 5.40 Deklaracje innych perspektyw

CREATE ASSERTION BogatyPrez . . . jak w przykładzie 6.10

RYSUNEK 7.12 Deklaracja schematu

O

Nie ma konieczności zadeklarowania całego schematu od razu. Można go bowiem aktualizować lub dodawać do niego nowe elementy, stosując zna­ne już instrukcje CREATE, DROP lub ALTER, np. instrukcja CREATE TABLE, po której umieszcza się nazwę, stanowi definicję nowej tabeli w schemacie. Jedynym problemem może być określenie, do którego schematu ta nowa ta­bela ma zostać dołączona. Przy usuwaniu lub aktualizacji tabeli lub innego elementu schematu także może powstać problem identyfikacji schematu, po­nieważ nazwy elementów mogą się powtarzać w rożnych schematach, a ele­menty są całkiem różne.

450

7. SYSTEMOWE ASPEKTY JĘZYKA SQI,

Schemat bieżący można modyfikować, stosując instrukcję SET SCHEMA. Na przykład:

SET SCHEMA SchematFilm;

powoduje, że od momenfu wykonania tej instrukcji schemat z rys. 7.12 staje się schematem bieżącym. Wówczas wszystkie instrukcje modyfikujące ele­menty schematu dotyczą schematu bieżącego, czyli w tym przypadku sche­matu bazy filmowej.

Co jeszcze należy do schematu?

Poza wspomnianymi już tabelami, perspektywami, asercjami i dziedzinami istnieją jeszcze cztery rodzaje elementów schematu. Przede wszystkim w schemacie można zdefiniować podstawowy zbiór znaków, który zawiera symbole oraz sposoby ich kodowania. Najbardziej znany jest zbiór znaków ASCII, ale w implementacji SQL mogą występować rożne inne możliwo­ści, na przykład alfabet rożnych języków obcych.

Poza tym w schemacie określa się porzc~dek znaków. W punkcie 5.1.3 mówiliśmy już, że teksty są porządkowane leksykograficznie, przy czym wiadomo, co oznacza relacja mniejszości < między dwoma znakami. Porzą dek określa, który znak jest „mniejszy" niż inny. Można na przykład korzy­stać z porządku określonego przez kod ASCII albo można traktować litery małe i wielkie jako te same i nie porównywać znaków innych niż litery.

Do schematów można dołączać tłumaczenia, które umożliwiają za­mianę znaków z jednego alfabetu na inny. Ostatni rodzaj elementów sta­nowi instrukcja GRANT, która umożliwia określanie praw dostępu do da­nych udzielanym użytkownikom. Określanie praw dostępu zostanie omó­wione w podrozdziale 7.4.

7.3.3. Katalogi

Tak jak elementy schematu są definiowane dla określonego schematu, wewnątrz określonego katalogu definiuje się przypisane mu schematy. W zasadzie sposób tworzenia i organizacji katalogów powinien być zbliżony do sposobu tworzenia i organizacji schematów. Jednakże w standardzie SQL2 nie przewidziano takiej instrukcji

CR~ATE CATALOG <nazwa katalogu>

po której wymieniałoby się listę nazw schematów należących do katalogu. Za to w SQL2 przewidziano instrukcję

SET CATALOG <nazwa katalogu>

7.3. ŚRODOWISKO SQL 451

Można dzięki temu ustalić, który katalog jest „bieżący"; definiowane sche­maty zostają przypisane do katalogu bieżącego, a modyfikacje schematów dotyczą schematów należących do katalogu bieżącego, dzięki czemu unika się konfliktu nazw.

7.3.4. Klient-serwer w środowisku SQL

Środowisko SQL jest czymś więcej niż tylko zbiorem katalogów i sche­matów. Zawiera ono również elementy, które wspierają działanie na bazach danych wpisanych w schematy i katalogi. W środowisku SQL istnieją dwa ważne typy procesów: klient SQL i serwer SQL. Serwer służy do wykonywa­nia działań na elementach bazy danych, a klient umożliwia połączenie użyt­kownika z serwerem. Jak można się spodziewać, serwery SQL są instalowane na komputerach o wielkiej mocy obliczeniowej i dużej pamięci pomocniczej i przechowuje się tam zbiory baz danych, a z kolei klient jest instalowany na stacjach roboczych oddalonych od serwem. Jednakże można oba procesy i serwer i klienta posadowić na tym samym komputerze.

Pełna nazwa elementów schematu

Pod względem formalnym nazwa elementu schematu bazy danych jest złożona z nazwy katalogu, nazwy schematu i nazwy własnej elementu, które to fragmenty są oddzielane kropką. A zatem pełna nazw tabeli Film ze schematu schematFilm zapisanego w katalogu KatalogFilm wyglą da następująco:

KatalogFilm.SchematFilm.Film

Jeśli katalog jest standardowy lub bieżący, to można opuścić ten fragment nazwy. Jeśli element należy również do schematu standardowego lub bie­żącego, to można pominąć i ten fragment nazwy, a więc można odwoły­wać się do elementu tylko poprzez jego nazwę własną. Jeśli jednak trzeba się odwołać do elementu nie należącego do bieżącego środowiska, to jest to możliwe dzięki podaniu pełnej nazwy.

7.3.5. Połączenia

Jeśli trzeba uruchomić program w języku SQL z komputera, na którym zainstalowano klienta SQL, to połączenie między klientem a serwerem można utworzyć, wykonując następującą instrukcję SQL: .

CONNECT TO <nazwa serwera> AS <nazwa połączenia>

4S2 7. SYSTEMOWE ASPEKTY J~ZYKA SQL

Nazwa serwem zależy od konkretnej instalacji. Można ją zastąpić słowem DEFAULT i wówczas instrukcja spowoduje dołączenie komputera klienta do tego serwera, który jest specyfikowany jako domniemany.

Nazwa połączenia może być istotna. Możemy się bowiem chcieć do niej odwoływać, jako że SQL2 umożliwia jednoczesne otwarcie kilku połączeń, ale tylko jedno jest aktywne w danej chwili. Aby przełączać się pomiędzy połączeniami stosujemy instrukcję SET CoNNECTION, np. przełączenie się do połączenia connl może być spowodowane w następujący sposób:

SET CONNECTION connl;

Połączenie aktywne uprzednio przechodzi w stan uśpienia aż do chwili po­nownego uaktywnienia na skutek innego polecenia SET CONNECTION, w którym jest jawnie podana jego nazwa.

Z nazwy połączenia korzysta się również przy jego usuwaniu. Na przykład połączenie connl można unieważnić, korzystając z następującej instrukcji:

DISCONNECT connl;

Wykonanie tej instrukcji powoduje zakończenie połączenia connl, w tym przypadku nie jest ono w stanie uśpienia i nie można go już uaktywnić.

Jeśli jednak mamy pewność, że nie zajdzie potrzeba odwołania się do połączenia, to nie trzeba go nazywać i można AS i nazwę pominąć w instruk­cji CoNNECT. Można także wcale nie korzystać z instrukcji CoNNECT To. Jeśli wydamy jakiekolwiek polecenie SQL, to system połączy stację klienta ze standardowym serwerem SQL.

Środowisko

Moduł Agent SQL

Połączenie Klient SQL Serwer SQL

Sesja

RYSUNEK 7.13 Współdziałanie klienta i serwera

7.3. ŚRODOWISKO SQL 453

7.3.6. Sesje

Działania w języku SQL, które są przetwarzane w trakcie połączenia, tworzą sesję. Istnienie sesji jest nieodłączne od połączenia, które ją roz­poczęło. Na przykład, jeśli połączenie przechodzi w stan uśpienia, to sesja także jest w uśpieniu i reaktywacja połączenia przez instrukcje SET CoNNECTZON uaktywnia także uśpioną sesję. Na rysunku 7.13 zostały przedstawione połączenie i sesja jako dwa elementy łącza między klientem a serwerem.

W każdej sesji istnieje katalog bieżący i schemat bieżący w ramach tego katalogu. Można je określić, wykonując instrukcje SET SCHEMA lub SET CATALOG, które omówiliśmy w p. 7.3.2 i 7.3.3. W każdej sesji istnieje także autoryzowany w niej użytkownik, co zostanie opisane w podrozdziale 7.4.

7.3.7. Moduły

ll~loduzz oznacza program użytkowy zapisany w języku SQL2. W standar­dzie SQL2 zostały wyróżnione trzy rodzaje modułów i każda implementacja powinna umożliwiać korzystanie co najmniej z jednego z nich.

1. Generyczny interfejs SQL. Użytkownik może wprowadzać instrukcje SQL bezpośrednio z terminala i są one natychmiast uruchamiane na serwerze. W tym trybie każda pojedyncza instrukcja stanowi mo­duł. Taki właśnie tryb przetwarzania braliśmy pod uwagę w przed­stawianych przykładach, ale w praktyce korzysta się z niego raczej rzadko.

2. SQL osadzony. Ten styl programowania został omówiony w podroz­dziale 7.1; tam instrukcje SQL byty zapisywane wewnątrz programów utworzonych w języku podstawowym i te wstawki SQL poprzedza się instrukcją ExEC SQL. Zakłada się, że instrukcje SQL są zastępowane przez preprocesor wywołaniami funkcji bibliotecznych i w stosownej chwili są one wykonywane przez system SQL w trakcie przetwarzania programu podstawowego.

3. Prawdziwe moduly. Najczęściej w języku SQL stosuje się moduły, które stanowią zbiory funkcji lub procedur, część z nich jest zapisana w języku podstawowym, część w SQL. Komunikują się one ze sobą za pośrednictwem parametrów lub zmiennych dzielonych.

Wykonanie modulu nazywa się agentem SQL. Na rysunku 7.13 przed­stawiono moduł i agenta jako jeden element, uruchamiający klienta SQL po to, by utworzyć połączenie. Należy pamiętać jednak o tym, że różnica między modulem a agentem jest analogiczna do różnicy między programem a proce­sem, pierwszy z nich jest kodem, a drugi wykonaniem tego kodu.

4S4 7. SYSTEMOWE ASPEKTY JĘZYKA SQL

7.4. Bezpieczeństwo i autoryzacja użytkownika w języku SQL2

Wskazania SQL2 dotyczące bezpieczeństwa zawierają między innymi zalecenie, aby użytkownicy mieli identyfikatory (ID) autoryzujc~ce, najczę­ściej jest to po prostu nazwisko. Istnieje także wyróżniony identyfikator PU­BLIC, z którego może korzystać dowolny użytkownik. Identyfikatorom przy­pisuje się prawa, których struktura pokrywa się z prawami systemu plików i systemu operacyjnego. Na przykład w systemie UNIX w zasadzie określa się trzy rodzaje praw: czytania odczytu, pisania i wykonywania. Taka lista praw ma sens, ponieważ w systemie UNIX chroni się pliki, a wymienione trzy prawa dobrze określają działania, które można wykonywać na plikach. Jed­nakże bazy danych są bardziej złożone niż system plików, a więc struktura praw w języku SQL2 jest proporcjonalnie bardziej złożona.

Najpierw dowiemy się, jakie prawa można w języku SQL2 określać do poszczególnych elementów baz danych. Potem opiszemy, w jaki sposób przypisuje się je użytkownikom (identyfikowanym przez ID). W końcu do­wiemy się, jak skasować pewne prawa.

7.4.1. Prawa

SQL2 określa następujące prawa:

1. SELECT (wybór)

2. INSERT (wstawianie) 3. DELETE (USUwanle) 4. UPDATE (aktualizacja)

5. REFERENCES (odwołanie się) 6. USAGE (stosowanie)

Pierwsze cztery prawa są określane dla relacji, czyli albo dla tabeli pod­stawowej, albo dla perspektywy. Zgodnie z nazwami zapewniają one możli­wość wykonywania kolejno: zapytań o krotki relacji (select from), wstawiania nowych krotek, usuwania krotek oraz zmiany wartości w krotkach danej rela­cji. Nie można wykonywać modułu zawierającego instrukcje SQL, jeśli nie określi się praw wykonywania tych instrukcji na relacjach, których mają do­tyczyć. Wkrótce dowiemy się, w jaki sposób określać prawa dla moduków.

Z kolei prawo REFERENCES dotyczy możliwości odwołania się do danej struktury w więzach integralności. Więzy można zadawać w dowolny sposób opisany w rozdziale 6, czyli mogą to być asercje, więzy atrybutowe lub krot­kowe, lub też więzy integralności referencyjnej. Więzów nie sprawdza się, jeśli nie nada się praw REFERENCES na schematy, z których pobiera się dane sprawdzane w więzach.

7.4. BEZPIECZEŃSTWO I AUTORYZACJA UŻYTKOWNIKA W ,lĘZYKLJ SQL2 4SS

Prawo usAGE określa się dla dziedzin i elementów schematu innych niż relacje i asercje (p. 7.3.2) i umożliwia ono korzystanie z tych elementów w deklaracjach.

Dla trzech praw: INSERT, UPDATE i REFERENCES argumentem może być pojedynczy atrybut. Wówczas prawo dotyczy tylko tego jednego atrybu­tu. Można określić kilka praw na pojedynczych atrybutach, w ten sposób można autoryzować dostęp do pewnych podzbiorów kolumn tabeli.

PRZYKŁAD 7.20

Zastanówmy się, jakie prawa są potrzebne, aby wykonać instrukcję wstawia­nia z rys. 5.12; została ona powtórzona na rys. 7.14. Po pierwsze jest to wsta­wienie do relacji studio, a zatem trzeba mieć prawo INSERT do relacji stu­dio. Ponieważ w instrukcji INSERT jest określona tylko wartość atrybutu nazwa, a więc można albo nadać prawo INSERT, albo prawo IN­SERT (nazwa) dla relacji studio. Ta druga postać umożliwia wstawianie do relacji studio tylko takich krotek, dla których określa się nazwę studia, a wartości pozostałych atrybutów są albo standardowe, albo NULL, a właśnie tak działa instrukcja przedstawiona na rys. 7.14.

1) INSERT INTO Studio (nazwa)

2) SELECT DISTINCT nazwaStudia 3) EROM Film

4) WHERE nazwastudia NOT IN 5) (SELECT nazwa

6) EROM Studio);

RYSUNEK 7.14 Dołączanie nowego studia

Zwróćmy jednak uwagę na to, że w instrukcji INSERT na rys. 7.I4 wy­stępują również dwa podzapytania, w wierszach 2) i S). Ich wykonanie wy­maga określenia dodatkowych praw. Potrzeba prawa typu sELECT dla relacji umieszczonych w klauzulach EROM: Film oraz Studio. Zauważmy, że prawo typu INSERT dla relacji studio nie oznacza, że posiada się prawo SELECT dla tej relacji, ani też odwrotnie.

0

7.4.2. Tworzenie praw

Wiemy już, jakie prawa można określać w SQL2 i że muszą one być na­dane po to, by można było wykonać działania na relacjach. Teraz jeszcze trzeba się dowiedzieć, w jaki sposób otrzymuje się takie prawa. Są tu dwa elementy: w jaki sposób tworzyć je początkowo oraz jak przekazywać je mię­dzy użytkownikami. Inicjowanie praw będzie opisane poniżej, a przesyłanie ich między użytkownikami w p. 7.4.4.

456

7. SYSTEMOWE ASPEKTY JĘZYKA SQL

Po pierwsze należy wiedzieć, że wszystkie elementy, takie jak schematy lub moduły, w języku SQL mają swoich właścicieli. Właściciel ma z racji swojego statusu wszystkie prawa, które są związane z danym obiektem. Przy określeniu praw własności w SQL2 występujątrzy elementy:

1. Przy tworzeniu schematu zakłada się, że jego właścicielem oraz wła­ścicielem wszystkich elementów schematu, takich jak tabele, jest ten użytkownik, który utworzył schemat. Ten użytkownik posiada wów­czas wszystkie możliwe prawa potrzebne do korzystania ze schematu.

2. Przy otwieraniu sesji przez instrukcję CoNNECT istnieje możliwość wskazania użytkownika; służy do tego klauzula vSER. Na przykład następująca instrukcja:

CONNECT TO Konstelacja-sql-serwer AS connl vSER karol;

spowoduje utworzenie połączenia o nazwie connl z serwerem o na­zwie Konstelacj a-sql-serwer i odpowiedzialny za tę sesję jest użytkownik identyfikowany jako Karol. Najczęściej implementacja SQL sprawdza autentyczność użytkownika, pytając na przykład o hasło.

3. Przy tworzeniu modułu można określać jego właściciela, stosując klauzulę AvTHORIZATION. Nie będziemy się zagłębiać w szczegóły dotyczące modułów, ponieważ jest to fragment SQL2, który pozosta­wia sporo swobody, jeśli chodzi o implementacje. Można jednak wy­obrazić sobie pewien schemat, gdzie klauzula

AUTHORIZATION Piotr;

występująca w instrukcji definicji modułu powoduje, że użytkownik o ID pi.otr staje się właścicielem tego modułu. Jeśli nie określi się właściciela modułu, to może go wykonywać każdy, ale prawa do wy­konywania poszczególnych działań na poszczególnych tabelach mu­szą być nadane użytkownikowi, który ten moduł uruchamia w danym połączeniu i danej sesji.

7.4.3. Procedura sprawdzania praw dostępu

Jak już wiemy, każdy moduł, schemat i sesja są powiązane z określonym użytkownikiem; w nomenklaturze SQL mówi się, że dla każdego elementu zo­staje określona autoryzacja. Każde działanie w systemie SQL ma dwie części:

1. Elementy bazy danych, na których działania są wykonywane. 2. Agent, który te działania wykonuje.

7.4. BEZPIECZEŃSTWO I AUTORYZACJA UŻYTKOWNIKA W JĘZYKU SQL2 4S%

Prawa agenta są określane dynamicznie na podstawie bieżącej identyfikacji. Jest to albo:

a) ID wynikające z autoryzacji modułu, jeśli moduł uruchamiany jako agent ma określone ID autoryzacji, albo

b) ID wynikające z autoryzacji sesji.

W systemie SQL operacja może zostać wykonana wyłącznie wtedy, kiedy bieżąca autoryzacja ma wszystkie niezbędne w tym celu prawa dostępu.

PRZYKŁAD 7.21

Mechanizmy egzekwowania praw dostępu prześledzimy na działaniach z przykładu 7.20. Można założyć, że tabele używane w tym przykładzie: Film i Studio są elementami schematu o nazwie SchematFilm, którego właścicielem jest użytkownik j areka. Użytkownik j areka ma wszystkie pra­wa do tabel i innych elementów schematu schematFilm. Może ona nadawać prawa do tych elementów innym użytkownikom dzięki mechanizmom, które zostaną przedstawione w p. 7.4.4, ale na razie zakładamy, że żadne prawa nie zostały jeszcze nadane. Wstawienie z przykładu 7.20 może zostać wykonane na kilka różnych sposobów.

1. Można je wykonać jako fragment modułu utworzonego przez użyt­kownika Janka z zastosowaniem klauzuli AUTHORIZATION Janka. Jeśli ID autoryzujące moduł zostało określone, to pokrywa się ono z autoryzacją bieżącą. Wówczas i moduł i instrukcja INSERT w nim zawarta mają takie same prawa jak użytkownik j areka, a więc wszystkie prawa do tabel Film i studio.

2. Wstawienie może być także fragmentem modułu, dla którego nie określono właściciela. Użytkownik j areka otwiera połączenie, uży­wając w instrukcji CONNECT TO klauzuli USER j areka. Wówczas j areka jest identyfikatorem bieżącym autoryzującym dostęp, co gwa­rantuje wszystkie niezbędne prawa dostępu.

3. Użytkownik Janka nadaje wszystkie prawa dostępu do tabel Film i studio użytkownikowi stefan albo użytkownikowi PUBLIC, któ­rym może być każdy. Instrukcja wstawiania występuje teraz w modu­le, który ma klauzulę

AUTHORIZATION stefan

Ponieważ stefan posiada autoryzację bieżącą i ma wszystkie po­trzebne prawa dostępu, więc wstawienie jest możliwe.

4. Podobnie jak w punkcie 3 użytkownik Stefan otrzymał prawa od użytkownika j areka. Instrukcja wstawiania znajduje się w module, dla którego nie został określony właściciel, a jest on uruchamiany podczas

4SÓ 7. SYSTEMOWE ASPEKTY JĘZYKA SQL

sesji, którą autoryzuje użytkownik Stefan. A więc autoryzacja bieżą­ca ma ID Stefan, a ten identyfikator ma potrzebne prawa.

0

W przykładzie 7.21 zilustrowano kilka zasad. Poniżej przedstawiamy ich podsumowanie.

• Potrzebne prawa są dostępne zawsze, jeśli właścicielem danych jest ten sam użytkownik, którego ID stanowi autoryzację bieżącą. Tę re­gułę ilustrują punkty I i 2 przykładu.

• Prawa sądostępne, jeśli użytkownik identyfikujący bieżącąautoryzację otrzymał je od właściciela danych lub jeśli zostały one nadane użyt­kownikowi PuBZIC. Ta zasada została zilustrowana w punktach 3 i 4.

• Jeśli właścicielem uruchamianego modułu jest właściciel danych lub ktoś, kto ma prawa dostępu do tych danych, to prawa obowiązują. Ta reguła została zilustrowana scenariuszami 1 i 3.

• Wykonanie modułu udostępnionego dla wszystkich użytkowników podczas sesji autoryzowanej przez użytkownika z ID udostępniającym dane jest także możliwe. Taki przypadek został uwzględniony w punktach 2 i 4.

7.4.4. Nadawanie praw

Na podstawie przykładu 7.21 widać, jak ważne są właściwe prawa użyt­kownika (widzianego przez autoryzujące go ID). Ale dotychczas jedyny zna­ny sposób uzyskania tych praw do elementów bazy danych sprowadzał się do bycia właścicielem lub autorem tych elementów. W języku SQL2 można jed­nak także korzystać z instrukcji GRANT, którą stosuje się do nadawania praw innym użytkownikom. Użytkownik nadający prawa nie traci ich, można o tym mechanizmie myśleć zatem jako o prawie do kopiowania praw.

Jednakże między prawem do kopiowaniem praw a ich zwykłym nada­niem istnieje różnica. Otóż każde prawo jest powiązane z prawem nadawania (opcja gram). A więc użytkownik może mieć nadane prawo typu SELECT do tabeli Film z „opcjągrant", a inny użytkownik może mieć to samo prawo, ale bez tej opcji. Wówczas pierwszy z nich może nadawać prawo SELECT do tabeli Film trzeciemu użytkownikowi, nawet razem z opcją gram lub bez niej. A drugi użytkownik, który otrzymał prawo SELECT bez opcji gram, nie może nikomu nadać tego prawa do tabeli Film. Jeśli trzeci użytkownik otrzyma prawo z opcją gram, to wówczas i on może nadać te same prawa czwartemu użytkownikowi i znowu może to zrobić z opcją gram lub bez niej. Instrukcja gram ma następujące elementy:

1. Słowo kluczowe GRANT.

7.4. BEZPIECZEŃSTWO I AUTORYZACJA UŻYTKOWNIKA W JĘZYKU SQL2 4S9

2. Lista, zlożona z jednego lub wielu praw, np. SELECT lub IN­SERT (nazwa) . Może tu także wystąpić slowo kluczowe ALL PRIVILEGES, jako skrótowe określenie przekazania tych wszystkich praw, które posiada użytkownik wykonujący instrukcje gram do ele­mentów bazy danych (opisanych w punkcie 4).

3. Slowo kluczowe ON.

4. Element bazy danych. Najczęściej jest to relacja, tabela lub perspektywa. Może to także być dziedzina lub iru~y element (np. jeden z tych, które opisaliśmy w ramce „Co jeszcze należy do schematu?" w p. 7.3.2), jed­nakże wówczas trzeba nazwę tego elementu poprzedzić odpowiednim slowem kluczowym, np. DOMAIN.

5. Słowo kluczowe To.

6. Lista identyfikatorów użytkowników (ID autoryzujących dostęp). 7. Jako opcja slowo kluczowe WITH GRANT oPTION.

Schemat instrukcji gram jest zatem następujący:

GRANT <lista praw> oN <element bazy danych> To <lista użytkowa i ków>

Na końcu może wystąpić fraza WITH GRANT oPTION.

Aby taką instrukcję wykonać, użytkownik sam musi mieć te prawa, któ­rych udziela innym, a dodatkowo musi je mieć z opcją gram. Użytkownik udzielający prawa może mieć je w szerszym zakresie niż te, które nadaje. Na przykład użytkownik, który ma prawo INSEKT do tabeli studio z opcją gram, może komu innemu nadać prawo INSEKT (nazwa) do tej tabeli.

PRZYKŁAD 7.22

Użytkownik j areka jest właścicielem schematu SchematFilm, który obej­muje relacje:

Film (tytuł, rok, długość, czyKolor. Nazwastudia, producentC#)

Studio (nazwa, adres, prezC#)

nadaje użytkownikom karot i Piotr prawa INSEKT oraz SELECT do tabe­li studio oraz prawo sELECT do tabeli Film. Ponadto nadaje te prawa z opcją gram. Poniżej przedstawiamy kod uruchamianych w tym celu in­strukcji.

GRANT SELECT, INSEKT ON Studio TO karot, Piotr WITH GRANT OPTION;

GRANT SELECT ON Film TO karot, Piotr WITH GRANT OPTION;

4C)O 7. SYSTEMOWE ASPEKTY JĘZYKA SQL

Następnie Piotr udziela tych praw użytkownikowi stefan, ale już bez opcji gram.

GRANT SELECT, INSERT ON Studio TO stefan; GRANT SELECT ON Film TO stefan;

Także karol nadaje Stefanowi minimalne prawa, które są niezbędne do uruchomienia funkcji z rys. 7.14, a nominalnie prawa sELECT i IN­SERT (nazwa) do tabeli Studio oraz SELECT do tabeli Film. W tym celu wykonuje następujące instrukcje.

GRANT SELECT, INSERT(nazwa) ON Studio TO stefan; GRANT SELECT ON Film TO Stefan;

A więc Stefan otrzymał prawo do wykonania sELECT do tabel Film i Stu­dio od dwóch różnych użytkowników. Poza tym dostał dwukrotnie prawo do wykonywania INSEKT (nazwa) dla tabeli studio: bezpośrednio od karota i pośrednio przez prawo do INSEKT od Piotra.

o

7.4.5. Diagram GRANT

Ze względu na to, że prawa nadawania praw tworzą złożoną sieć, a po­nadto końcowe prawa mogą powstawać w wyniku nakładania się różnych nadam, jest wygodnie przedstawiać te zależności w postaci graficznej tzw. diagramu g~ant. Jest on implementowany w systemie SQL i w ten sposób zawsze wiadomo, jakie są prawa i skąd się wzięły (co staje się ważne w przypadku ich odbierania, p. 7.4.6). Wierzchołki w tym diagramie repre­zentują użytkowników i prawa. Jeśli użytkownik U nadaje prawo P użyt­kownikowi U, a jest to możliwe dlatego, że U ma prawa Q (gdzie Q może być takie samo jak P z opcją gram lub pewnym rozszerzeniem P, także z opcją gram), wówczas powstaje krawędź skierowana od wierzchołka U/Q do wierzchołka T~/P.

PRZYKŁAD 7.23

Na rysunku 7.15 przedstawiono diagram gram, który powstał w wyniku wy­konania ciągu instrukcji gram z przykładu 7.22. Stosujemy konwencję pole­gającą na tym, że gwiazdka * umieszczona przy prawach oznacza, że prawo zawiera opcję gram. Z kolei dwie gwiazdki ** oznaczają, że prawa wynikają z prawa własności elementu bazy danych, a więc nie są poprzedzone żadnym nadaniem. Ta różnica okaże się istotna, gdy będziemy omawiać odbieranie praw w p. 7.4.6. Prawa opatrzone podwójną gwiazdką z natury zawierają opcję gram.

a

7.4. BEZPIECZEŃSTWO I AUTORYZACJA UŻYTKOWNIKA W JĘZYKU SQL2 461

Janka Janka Janka Janka

SELECT INSERT SELECT INSERT

z Film do Film ze Studio do Studio

** ** ** **

Karol Piotr \

SELECT SELECT

z Film z Film

*

Karol Piotr \

SELECT SELECT

ze Studio ze Studio

* i

' Karol Piotr INSERT INSERT do Studio do Studio

Stefan Stefan Stefan Stefan INSERT (nazwa) SELECT SELECT INSERT

do Studio z Film ze Studio do Studio

RYSUNEK 7.15 Diagram gram

7.4.6. Odbieranie praw

Prawa nadane można w każdej chwili odebrać. Procedura odbierania praw może tworzyć kaskadę, w tym znaczeniu, że odebranie praw udzielo­nych z opcją gram może wymagać odebrania także praw, które powstały w wyniku korzystania z tej opcji. Poniżej przedstawiamy prostą postać in­strukcji revoke.

1. Słowo kluczowe REVOKE. 2. Lista praw.

462 7. SYSTEMOWE ASPEKTY JĘZYKA SQL

3. Słowo kluczowe ON.

4. Element bazy danych, zgodny z opisem z punktu 4 w opisie instrukcji gram.

5. Słowo kluczowe EROM.

6. Lista użytkowników (czyli identyfikatory autoryzacji).

A więc można podać następujący schemat dla instrukcji revoke:

REVOKE <lista praw> oN <element bazy danych> FROM <lista użytkowników>

Można do tej instrukcji dołączyć jeszcze inne elementy:

• Instrukcja może zostać zakończona słowem kluczowym CASCADE. Wówczas odbierając wyspecyfikowane prawa, odbiera się również te prawa, które zostały nadane w wyniku ich przekazania. A dokładniej: jeśli użytkownik U odbiera prawa P użytkownikowi V, wynikające z praw Q użytkownika U, to zostaje usunięta krawędź diagramu gram prowadząca od wierzchołka UlQ do V/P. Wówczas usuwa się z tego diagramu wszystkie te wierzchołki, dla których nie można znaleźć wierzchołka poprzedzającego z dwiema gwiazdkami (właściciela praw).

• Można tę instrukcję zastąpić słowem RESTRICT, co oznacza że nie należy wykonać instrukcji revoke, jeśli w wyniku stosowania kaskady zostałyby usunięte jeszcze jakieś inne prawa niż te, które są jawnie wyspecyfikowane.

• Można zastąpić REVOKE przez REVOKE GRANT OPTION FOR, a wte­dy nie odbiera się praw, a tylko prawo do ich udzielania. Można tę opcję łączyć zarówno z CASCADE, jak i z RESTRICT, co spowoduje analizę i ewentualnąmodyfikację diagramu grunt.

PRZYKŁAD 7.24

Posługujemy się znowu danymi z przykładu 7.22 i załóżmy teraz, że j anka chce odebrać prawa, które udzieliła Piotrowi i w tym celu uruchamia in­strukcję

REVOKE SELECT, INSERT ON Studio EROM Piotr CASCADE; REVOKE SELECT ON Film EROM Piotr CASCADE;

Na rysunku 7.15 zostaje usunięta krawędź od praw j anki do praw Piotr. Ponieważ korzysta się z opcji CASCADE, więc należy sprawdzić, czy w diagramie pozostały wierzchołki, w których nie moż.~~a sprawdzić, kto jest właścicielem praw. Na rysunku 7.15 widać, że prawa Piotra nie są już do­stępne z żadnego wierzchołka z dwiema gwiazdkami (mogłyby być, jeśli ist­

7.4. BEZPIECZEŃSTWO 1 AU'CORYZACJA U7YTKOWNIKA W JĘZYKU SQL2

463

niałby inny, oprócz Janki, właściciel, który te prawa nadał piotrowi). W podobny sposób są również niedostępne prawa stefana do INSERT do relacji studio. A zatem z diagramu gram usuwamy nie tylko prawa piotra, ale także prawo Stefana do zNSERT.

Zauważmy, że nie usuwa się prawa Stefana do sELECT do relacji Film i studio, ani jego prawa do TNSERT (nazwa) do studio, ponieważ są one dostępne z wierzchołka Janki pośrednio przez prawa karota. Diagram gram, który powstał w wyniku tych przekształceń, jest przedstawiony na rys. 7.16.

0

Janka Janka Janka SELECT INSERT SELECT

z Film do Film ze Studio ** ** **

Karol SELECT

z Film

Karol SELECT ze Studio

" Karol INSEKT do Studio

Stefan Stefan Stefan INSEKT (nazwa) SELECT SELECT

do Studio z Film ze Studio

" Janka INSERT do Studio

**

RYSUNEK 7.16

Diagram GRANT po odebraniu praw Piotra

464 7. SYSTEMOWE ASPEKTY JĘZYKA SQL

PRZYKŁAD 7.25

Przedstawimy teraz za pomocą abstrakcyjnych przykładów kilka problemów bardziej subtelnych. Po pierwsze, jeśli odbiera się pewne ogólne prawa p, to nie oznacza, że odbiera się jakiś ich podzbiór, nadany osobno. Rozważmy następujący ciąg działań, gdzie użytkownik U- właściciel relacji R - nadaje prawo INSEKT do R użytkownikowi V, a poza tym nadaje dodatkowo prawo do INSEKT (A) do tej samej relacji.

Nr czynności I Kto I Czynność

1 U GRANT INSEKT ON R TO h

U GRANT INSERT(A) ON R TO V

3 U REVOKE INSEKT ON R EROM V RESTRICT

Po odebraniu prawa INSEKT od V ma on nadal prawo INSEKT (A) . Na rysunku 7.17 przedstawiono diagram gram powstały kolejno w czynno­ściach 2 i 3.

U V INSEKT INSEKT

do R do R **

' V INSEKT (A)

do R ,

(a) Po czynności 2 (b) Po czynności 3

RYSUNEK 7.17

Po odebraniu praw ogólnych prawa szczegółowe obowiązują nadal

Zauważmy, że po czynności 2 istnieją dwa oddzielne wierzchołki z po­dobnymi, ale nieidentycznymi prawami użytkownika V. Zauważmy także, że opcja RESTRICT w czynności 3 nie zapobiegnie odebraniu praw, ponieważ użytkownik V nie udzielał praw innym użytkownikom. A w ogóle nie mógł ich nadawać, ponieważ otrzymał je bez opcji gram.

0

PRZYKŁAD 7.26

Rozważmy teraz podobny przykład, w którym U nadaje użytkownikowi V prawo p z opcją gram, a potem odbiera tylko tę opcję. W tym przypadku trze­ba zmienić wierzchołek odpowiadający V po to, by widać było zmianę ro­

7.4. BEZPIECZEŃSTWO 1 AUTORYZACJA UŻYTKOWNIKA W JĘZYKU SQL2 ~1GS

dzaju praw posiadanych przez użytkownika V, oraz trzeba usunąć wszystkie krawędzie ilustrujące nadanie prawa p przez użytkownika V. Zostanie wyko­nany następujący ciąg instrukcji:

Nr czynności Kto Czynność

1 U GRANT TO V GVITH GRANT OPTION 2 V GRANT TO W

3 U REVOKE GRANT OPTION FOR p EROM V CASCADE

W pierwszej instrukcji U nadaje prawa p użytkownikowi V z opcją gram. W czynności 2 V korzysta z opcj i gram i udziela praw p do W. Diagram został przedstawiony na rys. 7.18(a).

U V W U V P

(a) Po kroku 2 (b) Po kroku 3

RYSUNEK 7.18

Przy odebraniu prawa do nadawania praw, prawa uprzednio nadane obowiązują nadal

Następnie w czynności 3 użytkownik U odbiera użytkownikowi V opcję gram do praw p, ale nie odbiera samych praw. A więc znika gwiazdka z wierzchołka Vlp. Ale z wierzchołka pozbawionego * nie może wychodzić żadna krawędź, ponieważ taki wierzchołek nie może być źródłem praw. A więc trzeba usunąć także krawędź wychodzącą z wierzchołka Vlp, która prowadzi do wierzchołka Wlp.

Teraz z kolei do wierzchołka Wlp nie dochodzi żadna ścieżka rozpoczy­nająca się w wierzchołku z dwiema gwiazdkami, który jest źródłem praw p, a zatem wierzchołek Wlp zostaje usunięty z diagramu. Ale wierzchołek Vlp pozostaje. Zmienił się tylko typ tego wierzchołka, znikła gwiazdka, oznaczająca opcję gram. Wynikowy diagram gram został przedstawiony na rys. 7.18(b).

0

7.4.7. Ćwiczenia do podrozdzia~u 7.4

Ćwiczenie 7.4.1. Należy podać, jakie są niezbędne prawa do uruchomienia następują­cych zapytań. W każdym przypadku należy podać prawa minimalne oraz ogólne, które wystarczają do uruchomienia zapytania.

a) Zapytanie z rys. 5.3. b) Zapytanie z rys. 5.5. *c) Wstawienie z rys. 5.12.

466

d) Usuwanie z przykładu 5.29.

e) Aktualizacja z przykładu 5.31. Więzy krotkowe z rys. 6.4.

g) Asercja z przykładu 6.10.

7. SYSTEMOWE ASPEKTY J~ZYKA SQL

*Ćwiczenie 7.4.2. Utworzyć diagram gram po wykonaniu czynności 4, 5 i 6 ciągu, który został przedstawiony na rys. 7.19. Należy założyć, że właścicielem relacji z prawami p jest użytkownik A.

Numer Kto Czynność czynności

1 A GRANT p TO B WITH GRANT OPTION

2 A GRANT p TO C

3 B GRANT p TO D WITH GRANT OPTION

4 D GRANT p TO B, C, E WITH GRANT OPTION

S B REVOKE p EROM D CASCADE

6 A REVOKE p EROM C CASCADE

RYSUNEK 7.19

Ciąg czynności do ćwiczenia 7.4.2

Ćwiczenie 7.4.3. Utworzyć diagram gram po wykonaniu czynności 5 i 6 ciągu, który został przedstawiony na rys. 7.20. Należy założyć, że właścicielem relacji z prawami p jest użytkownik A.

Numer czynności

1 2 3 4 5 6

Kto ~ Czynność

A GRANT p TO B, E WITH GRANT OPTION B GRANT p TO C WITH GRANT OPTION

C GRANT p TO D WITH GRANT OPTION E GRANT p To C

E GRANT p TO D WITH GRANT OPTION

A REVOKE GRANT OPTION FOR p EROM B CASCADE

RYSUNEK 7.20

Ciąg czynności do ćwiczenia 7.4.3

'Ćwiczenie 7.4.4. Należy utworzyć diagram gram powstały w wyniku przetworzenia następującego ciągu instrukcji, przy założeniu, że właścicielem relacji z prawami p jest użytkownik A.

Nr czynności Kto Czynność

1 A GRANT p TO B WITH GRANT OPTION 2 B GRANT p TO B WITH GRANT OPTION 3 ( A REVOKE p FOR EROM B CASCADE

7.5. PODSUMOWANIE

7.5. Podsumowanie

467

• Osadzanie SQL (embedded SQL): Zamiast korzystać z interfejsu za­pytań do uruchamiania zapytań i wprowadzania zmian w języku SQL, często jest efektywniej napisać program w standardowym języku pro­gramowania i wstawić do niego instrukcje SQL.

• Niedopasowanie falowe (impedance mismatch): Model danych SQL rożni się zasadniczo od modeli danych w zwykłych językach progra­mowania. Dlatego do komunikacji między instrukcjami SQL a pro­gramem zewnętrznym trzeba korzystać z tzw. zmiennych dzielonych, w których można przekazywać wartości skladowych krotek.

• Kursory (cursors): Kursor jest zmienną SQL, która wskazuje krotkę w relacji. Kursory są dodatkowym mechanizmem SQL, który umoż­liwia polączenie języka podstawowego i SQL, a stosuje się je w połą­czeniu ze zmiennymi dzielonymi, do których zapisuje się wartości z krotki, wskazywanej w danej chwili przez kursor .

• Dynamiczny SQL (dynamit SQL): Zamiast wstawiać fragmenty SQL do programu podstawowego może on generować teksty, które są in­terpretowane jako instrukcje SQL i wykonywane przez system SQL.

• Sterowanie wspólbieżnościci (concurrency control): W systemie SQL istnieją dwa mechanizmy, które pozwalają unikać konfliktów związa­nych z jednoczesnym przetwarzaniem: transakcje oraz ograniczenia w stosowaniu kursorów. Ograniczenia kursorów polegają na deklaro­waniu kursora jako „niewrażliwego", co oznacza, że zmiany dokony­wane w relacji nie są widoczne.

• Transakcje (transactions): Programista może grupować instrukcje w jednostki zwane transakcjami, które się zatwierdza lub cofa (unie­ważnia). W tym drugim przypadku cofa się wszystkie zmiany po­wstałe w bazie danych.

• Poziomy izolacji (isolation levels): Transakcje w systemie SQL można określać na jednym z czterech poziomów izolacji, które w kolejności od najbardziej do najmniej restrykcyjnego określa się jako: „sekwen­cyjny" (transakcja musi się wykonać zawsze w całości, zanim inna transakcja się zacznie lub po kompletnym zakończeniu innej transak­cji), „odczyt powtarzalny" (każda krotka, która pojawila się w wyniku zapytania, będzie pojawiali się w kolejnych odpowiedziach), „odczyt zatwierdzony" (tylko krotki powstałe w wyniku zatwierdzenia trans­akcji są dostępne dla innych transakcji) oraz „odczyt niezatwierdzo­ny" (nie ma żadnych ograniczeń na dostęp do danych).

• Kursory i transakcje tylko do odczytu (read-only cursors and transac­tions): Zarówno kursory, jak i transakcje można zadeklarować jako tylko do odczytu. Dzięki temu można uzyskać pewność, że kursor lub transakcja nie zmienią stanu bazy danych, a jednocześnie stanowi to informację dla systemu SQL o tym, że ten obiekt nie spowoduje naru­

468

7. SYSTEMOWE ASPEKTY JĘZYKA SQL

szenia niewrażliwości, sekwencyjności ani innych metod ochrony da­nych.

• Organizacja bazy danych (organization of a database): Instalacja SQL2 za pośrednictwem systemu DBMS tworzy środowisko działania SQL2. W tym środowisku elementy bazy danych, takie jak relacje, są grupowane w schematy, katalogi i klastry. Katalog stanowi zestaw schematów, a klaster jest jeszcze większą jednostką danych dostępną dla użytkownika.

• Systemy klient-serwer (client/server systems): Klient SQL łączy się z serwerem SQL2 i w ten sposób powstają: połączenie (między dwo­ma procesami) oraz sesja (ciąg działań). Kod, który wykonuje się podczas sesji, pochodzi z modułu, a wykonanie nazywa się agentem.

• Prawa (privileges): Dla zapewnienia ochrony danych przed niepowo­łanym dostępem w systemie SQL2 powstały różne typy praw dostępu do elementów bazy danych. Prawa te są następujące: select (odczyt), inser-i (wstawianie), delete (usuwanie), update (aktualizacja relacji) oraz prawa reference (odwoływania się do relacji w więzach). Prawa insert, update i references można otrzymać także na poszczególne kolumny relacji, a nie tylko na całą relację.

• Diagramy gram (gram diagrams): Prawa mogą nadawać ich właści­ciele innym użytkownikom lub użytkownikowi PUBLIC. Po określa­niu praw z opcją gram ich nabywca może stać się źródłem tych praw dla innych użytkowników. Prawa można także odbierać. Diagram gram stanowi mechanizm pamiętania, kto komu udzielił jakich praw.

7.6. Literatura do rozdziaw 7

Informacje dotyczące bibliografii standardu SQL zostały podane w nocie po rozdziale 5. Dokładniejsze omówienie standaryzacji zagadnień transakcji i kursorów znajduje się w [Ij.

Najważniejsza koncepcja dotycząca sposobu implementowania transakcji, nazywana „blokowaniem dwufazowym", została zaproponowana w [3]. Więcej informacji na temat za­rządzania transakcjami i ich implementacji znajduje się w [2) i [5]. Pierwsze pomysły związane z autoryzacją dostępu w języku SQL2 zostały opisane w [6] oraz [4].

1. Berenson H., Bernstein P.A., Gray J.N., Melton J., O'Neil E., O'Neil P.: A critique of ANSI SQL isolation levels. Proceedings ofACM SIGMOD INTG. Conf Of Management of Data, s. 1-10, 1995.

2. Bernstein I'.A., Hadzilacos V., Goodman N.: Concurrency Control ancl Recovery in Data­base Systems. Addison-Wesley, Reading, MA, 1987.

3. Eswaran K.P, Gray J.N., Lorie A., Traiger I.L.: The notions of consistency and predicate locks in a database system. Communication of the ACM 19:1 I s. 624-633, 1976.

4. Fagin R.: On the authorization mechanism. ACM Transaction on Database Systems 3:3 s. 310-319, 1978.

5. Gray J.N., Reuter A.: Transaction Processing: Concepts and Technigues. Morgan­-Kauf~rrmann, San Prancisco, 1993.

6. Griffiths P.P., Wade B.W.: An authorization mechanism for a relational database system. fł CM Transaction on Database Systenas 1:3 s. 242-255, 1976.

---