458 7. SYSTEMOWE ASPEKTY JĘZYKA SQI.
sesji, którą autoryzuje użytkownik stefan. A więc autoryzacja bieżąca ma ID stefan, a ten identyfikator ma potrzebne prawa.
□
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ę regułę ilustrują punkty 1 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żytkownikowi PU3LIC. 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.
Na podstawce przykładu 7.21 widać, jak ważne są właściwe prawa użytkownika (widzianego przez autoryzujące go ID). Ale dotychczas jedyny znany 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 jednak także korzystać z instrukcji GRANT, którą stosuje się do nadawania praw innym użytkownikom. Użytkow nik nadający prawa nic traci ich, można o tym mechanizmie my śleć zatem jako o praw ie do kopiow ania praw-.
Jednakże między prawem do kopiowaniem praw' a ich zwykłym nadaniem istnieje różnica. Otóż każde praw o jest powiązane z prawem nadawania {opcja grant). 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 rilm trzeciemu użytkownikowi, nawet razem z opcją grant lub bez niej. A drugi użytkownik, który otrzymał prawo select bez opcji grant, nie może nikomu nadać tego prawa do tabeli film. Jeśli trzeci użytkownik otrzyma prawo z opcją grant, to wówczas i on może nadać te same prawa czwartemu użytkownikowi i znowu może to zrobić z. opcją grant lub bez niej. Instrukcja grant ma następujące elementy:
1. Słowo kluczowe grant.
2. Lista, złożona z jednego lub wielu praw, np. SELECT lub INSERT (nazwa). Może tu także wystąpić słowo kluczowe ALT. PRIYILEGES, jako skrótowe określenie przekazania tych wszystkich praw, które posiada użytkownik wykonujący instrukcje grant do elementów bazy danych (opisanych w punkcie 4).
3. Słowo kluczowe ON.
4. Element bazy danych. Najczęściej jest to relacja, tabela lub perspektywa. Może to także być dziedzina lub inny element (np. jeden z tych, które opisaliśmy w ramce „Co jeszcze należy do schematu?" w p. 7.3.2), jednakże wówczas trzeba nazwę tego elementu poprzedzić odpowiednim słowem kluczowym, np. DOMAIN.
5. Słowo kluczowe to.
6. Lista identyfikatorów użytkowników (ID autoryzujących dostęp).
7. Jako opcja słowo kluczowe wiTH GRANT OPTTON.
Schemat, instrukcji grant jest zatem następujący:
GRANT <lista praw> ON <clement bazy danych> TO <lista użytkownikowi
Na końcu może wystąpić fraza WITH GRANT OPTlON.
Aby taką instrukcję wykonać, użytkownik sam musi mieć te prawa, których udziela innym, a dodatkowo musi je mieć z opcją grant. 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 _NSER? do tabeli Studio z opcją grant, może komu innemu nadać prawo INSERT (nazwa) do tej tabeli.
PRZYKŁAD 7.22
Użytkownik janka jest właścicielem schematu Schemat Fi lm, który obejmuje relacje:
Filmitytuł, rok, długość, czyKolor. NazwaStudia, producentet)
Studio(nazwa, adres, prezC-} nadaje użytkownikom karci i piotr prawa INSERT oraz SELECT do tabeli Studio oraz prawo SELECT do tabeli Film. Ponadto nadaje te prawa z opcją grant. Poniżej przedstaw iamy kod uruchamianych w tym celu instrukcji.
GRANT SELECT, INSERT ON Studio TO karol, piotr WITH GRANT OPTION;
GRANT SELECT ON Film TO karol, piotr WITH GRANT OPTION;