1 Wykład 22.04.2004 Asercje, wyzwalacze i prawa. 2 Elementy aktywne bazy Chcielibyśmy, aby baza danych zapewniała nam pewne własności lub niezmienniki.

Prezentacja na temat: "1 Wykład 22.04.2004 Asercje, wyzwalacze i prawa. 2 Elementy aktywne bazy Chcielibyśmy, aby baza danych zapewniała nam pewne własności lub niezmienniki."— Zapis prezentacji:

1 1 Wykład 22.04.2004 Asercje, wyzwalacze i prawa

2 2 Elementy aktywne bazy Chcielibyśmy, aby baza danych zapewniała nam pewne własności lub niezmienniki. Chcielibyśmy mieć możliwość zapisania tych własności do schematu bazy a baza powinna sama zapewniać, że cały czas będą spełnione. Te elementy schematu, które nam te własności zapewniają można określić jako elementy aktywne. Do elementów aktywnych zaliczamy:

3 3 Elementy aktywne bazy cd. 1 Klucze (primery key,unique) Integralność referencyjną i klucze obce (foreign key) Więzy wartości atrybutów –Więzy NOT-NULL –Więzy check –Więzy dziedziny

4 4 Elementy aktywne bazy cd. 2 Więzy globalne –Więzy check deklarowanie więzów dla pojedynczej relacji check ( ) –Asercje (assertion) –Wyzwalacze (triggers)

5 5 Asercje Po co nam asercje? Wszystkie dotychczasowe więzy dotyczyły pojedynczej krotki (więzy wartości atrybutów), ewentualnie prostych związków między krotkami z różnych relacji (więzy integralności) a my czasami chcielibyśmy napisać warunek, który dotyczy całej relacji lub paru relacji.Czasami taki warunek dałoby się napisać używając więzów check dotyczących relacji zapisanych w schematach relacji, których ten warunek dotyczy, jednak przy bardziej

6 6 Asercje skomplikowanych warunkach zapisanie takiego samego warunku używając samych więzów check może być bardziej pracochłonne oraz znacznie łatwiej popełnić błąd w wyniku którego baza nie będzie spełniała warunków, które wg. nas powinna spełniać. Co więcej niektórych warunków nie da się w ten sposób zapisać. Wynika to np. z różnic między asercjami a więzami krotkowymi dotyczącymi sprawdzania, kiedy są spełnione warunki których dotycza.

7 7 Składnia asercji CREATE ASSERTION CHECK ( ) Gdzie musi być typu logicznego Przykład Przyjmijmy, że mamy w bazie następujące relacje: Dyrektor(nazwisko:varchar(10),adres:varchar(10),cert:varcha r(10),cenaSieci:int) Studio(nazwa:varchar(10),adres:varchar(10),prezC:varchar (10) references Dyrektor(cert)) I chcielibyśmy, aby szefem studia była osoba, której sieć ma wartość co najmniej 10 mln $

8 8 Asercje Asercja opisująca ten warunek może wyglądać następująco: 1.CREATE ASSERTION BogatyPrez CHECK 2.(NOT EXISTS 3.(SELECT * 4.FROM Studio,Dyrektor 5.WHERE prezC=cert AND cenaSieci<10000000 6.));

9 9 Asercje Zauważmy, że gdybyśmy chcieli zdefiniować to samo używając tylko więzów krotkowych i napisalibyśmy następująco definicję tabeli Studio: 1.CREATE TABLE Studio ( 2.nazwa CHAR(30) PRIMARY KEY, 3.adres VARCHAR(255), 4.prezC INT REFERENCES Dyrektor(cert), 5. CHECK (prezC NOT IN 6.(SELECT cert FROM Dyrektor 7.WHERE cenaSieci<10000000) 8.));

10 10 Asercje to (co na początku może budzić duże zdziwienie) nie uzyskamy tego samego efektu co przy pomocy asercji.Dzieje się tak ponieważ warunek, który jest opisany w więzie krotkowym, będzie sprawdzany przy wstawianiu i modyfikacji krotki tylko z relacji Studio. Przy zmianach w relacji Dyrektor więzy krotkowe w relacji Studio nie będą sprawdzane.

11 11 Porównanie krotkowych check i asercji Typ więzówKiedy uruchamiane Krotkowe check Przy wstawianiu lub zmianie wartości w krotce (NIE przy usuwaniu krotki z relacji) tylko z tej relacji Asercje Przy dowolnej modyfikacji relacji (wstawianie, modyfikacja lub usuwanie dowolnej krotki) której dotyczy ta asercja

12 12 Asercje Tak więc jeśli uczynimy kogoś prezesem studia a potem będziemy chcieli obniżyć wartość jego sieci to asercja na to nie pozwoli natomiast więz krotkowy tak, ponieważ on jest sprawdzany przy modyfikacji krotki z relacji Studio a nie krotki z relacji Prezes. DLACZEGO: ponieważ więzy krotkowe powinny dotyczyć krotek z danej relacji a w tej relacji nic się nie zmieniło. Ten sposób traktowania więzów krotkowych wynika głównie z wymogów wydajnościowych! Wyobraźmy sobie, jaką pracę musiałaby wykonać baza, gdyby musiała zapewnić wiele więzów krotkowych podobnych temu.

13 13 Asercje UWAGA NA MARGINESIE: można w bazie wymusić spełnienie warunku opisanego w asercji używając tylko więzów krotkowych. Trzeba po prostu dodać odpowiedni więz do relacji Prezes (łatwe ćwiczenie ). INNY PRZYKŁAD. Mamy relację: Film(tytuł:varchar(10),rok:date,długość:int,czyKolor:boolean, nazwaStudia:varchar(10),producentC:varchar(10)); I chcielibyśmy, aby długość wszystkich filmów w danym studiu miała co najmniej 10000 minut.

14 14 Asercje Asercja wygląda następująco: 1.CREATE ASSERTION SumDlugość 2. CHECK (10000 <= ALL 3. (SELECT SUM(długość) FROM Film 4. GROUP BY nazwaStudia)); W tym przypadku istnieje silna pokusa, aby zamiast tworzyć asercję dodać linijki 2-4 jako więz krotkowy do relacji Film.Wydaje się,że również zadziałałoby. Jednak również w tym wypadku zostalibyśmy niemile zaskoczeni.Zauważmy bowiem, co mogłoby się zdarzyć przy usuwaniu filmów!!

15 15 Po co wyzwalacze? Czasami chcielibyśmy reagować w bardziej aktywny sposób na sytuacje, gdy dochodzi do naruszenia jakiegoś warunku lub niezmiennika niż tylko nie dopuszczając do tych modyfikacji bazy danych, która ten warunek narusza (być może dla pewnych sytuacji umiemy temu zaradzić). Poza tym czasami to my chcielibyśmy decydować, kiedy warunek ma być sprawdzany (choćby ze względu na wydajność), a w przypadku np. asercji to system o tym decyduje. Poza tym asercje są „drogie”. Dlatego chcielibyśmy mieć coś „tańszego” od asercji, co pozwala nam na nakładanie pewnych więzów na bazę.

16 16 Cechy wyzwalaczy Wyzwalacze są testowane tylko przy zajściu określonego zdarzenia (dołączanie, usuwanie, modyfikacja krotki) określonego przez programistę (projektanta bazy) (w przypadku asercji i więzów krotkowych decyduje o tym SZBD) Testują warunek w chwili zajścia zdarzenia (a nie uprzedzają go) Jeśli warunek zostanie spełniony to przetwarzana jest akcja związania z wyzwalaczem

17 17 Składnia wyzwalaczy CREATE TRIGGER {BEFORE|INSTEAD OF |AFTER} [OF ] ON REFERENCING {OLD|OLD_TABLE} AS nazwa_zmiennej1 {NEW|NEW_TABLE} AS nazwa_zmiennej2 WHEN ( ) //akcja [FOR EACH ROW]

18 18 Cechy wyzwalaczy Akcja może być wykonana przed (BEFORE), po (AFTER) lub zamiast (INSTEAD OF) zdarzenia W akcji dostępne są wartości sprzed (OLD, OLD_TABLE) zajścia zdarzenia jak i nowe (NEW,NEW_TABLE) wartości Można określać czy akcja ma być wykonywana dla każdej modyfikowanej krotki (FOR EACH ROW) czy tylko raz dla wszystkich krotek zmodyfikowanych w pojedynczej operacji

19 19 Przykład wyzwalacza Uniemożliwienie obniżenie ceny sieci: 1.CREATE TRIGGER CenaSieciWyzw 2.AFTER UPDATE OF cenaSieci ON Dyrektor 3.REFERENCING 4.OLD AS Stara 5.NEW AS Nowa 6.WHEN (Stara.cenaSieci > Nowa.cenaSieci) 7.UPDATE Dyrektor SET cenaSieci= Stara.cenaSieci 8. WHERE cert = Nowa.cert 9.FOR EACH ROW

20 20 Inny przykład wyzwalacza Zabronienie spadku średniej ceny sieci poniżej 500000 1.CREATE TRIGGER WyzwalaczSrCenySieci 2.INSTEAD OF UPDATE OF cena sieci ON Dyrektor 3.REFERENCING 4.OLD_TABLE AS Stara 5.NEW_TABLE AS Nowa 6.WHEN (500000 <= (SELECT AVG(cenaSieci) FROM 7.((Dyrektor EXCEPT Stare) UNION Nowe)) 8.DELETE FROM Dyrektor WHERE (nazwisko,adres,cert,cenaSieci) IN Stare; 9.INSERT INTO Dyrektor (SELECT * FROM Nowe);

21 21 Prawa Dowolny SZBD powinien zapewniać również poufność naszych danych oraz możliwość regulowania oraz limitowania dostępu do danych. Dlatego w SQL-u zdefiniowano tzw. prawa, które właściciel obiektu może dać (GRANT) lub odebrać (REVOKE) innym użytkownikom. Istnieje też możliwość przekazania otrzymanych wcześniej praw. UWAGA: użytkownicy, są tworzeniu przed DBA i są oni właścicielami obiektów które stworzyli (czyli podobnie jak np. w unix-owym systemie plików).

22 22 Składnia do nadawania praw GRANT ON TO [WITH GRANT OPTION] Prawa, które można nadać to: SELECT, INSERT, DELETE, UPDATE, REFERENCES,USAGE (można też ALL PRIVILEGES) REFERENCES dotyczy możliwości odwołania się do danej struktury w więzach integralności (np. asercje,więzy integralności referencyjnej). USAGE nadaje się dla dziedzin i innych elementów schematu innych niż relacje i asercje.

23 23 Składnia GRANT ALL PRIVILEGES – skrót, dzięki któremu można przekazać wszystkie prawa, które posiada się względem danego obiektu. W miejsce nazwy użytkownik można również użyć słowa PUBLIC. Wtedy przekaże się prawa wszystkim użytkownikom w bazie danych (obecnym w chwili nadawania praw jak i tym, którzy zostaną stworzeni późnej).

24 24 Przykłady nadawania praw GRANT SELECT,INSERT ON Studio TO mariusz WITH GRANT OPTION; GRANT REFERENCES(nazwa), DELETE ON Studio TO mariusz; GRANT USAGE ON DOMAIN Imiona TO jacek,placek WITH GRANT OPTION;

25 25 Składnia REVOKE Odbieranie nadanych wcześniej praw (innych niż GRANT) REVOKE ON FROM [CASCADE|RESTRICT]; Odbieranie prawa GRANT REVOKE GRANT OPTION FOR ON FROM [CASCADE|RESTRICT]

26 26 Prawa Semantyka CASCADE i RESTRICT w zdaniu REVOKE jest identyczna jak ich semantyka w zdaniu DROP TABLE. PRZYKŁADY: REVOKE SELECT, INSERT ON Studio FROM mariusz CASCADE; REVOKE GRANT OPTION FOR DELETE ON Studio FROM mariusz RESTRICT;

27 27 REVOKE Podobne jak w przypadku GRANT w zdaniu REVOKE mogą wystąpić ALL PRIVILEGES oraz PUBLIC Jeśli ktoś otrzymał takie samo prawo od wielu użytkowników to odebranie praw przez jednego użytkownika nie powoduje odebrania tego prawa przyznanego przez innych użytkowników (czyli dopiero, gdy wszystkie osoby odbiorą to prawo zostanie ono utracone)

28 28 REVOKE Po wykonaniu następującego ciągu instrukcji: GRANT INSERT ON Film TO mariusz; GRANT INSERT(tytul) ON Film TO mariusz; REVOKE INSERT ON Film FROM mariusz; użytkownik mariusz nadal posiada prawo INSERT(tytul) ON Film, ponieważ odebranie praw ogólniejszych nie zabiera podzbioru tych praw nadanego osobnym poleceniem.

29 29 Diagram GRANT Root INSERT ON Film ** Mariusz INSERT ON Film Mariusz INSERT ON Film(Tytuł)

30 30 REVOKE Po wykonaniu następującego ciągu instrukcji: Root: GRANT INSERT ON Film TO mariusz WITH GRANT OPTION; Mariusz: GRANT INSERT ON Film TO jacek; Root:REVOKE GRANT OPTION FOR INSERT ON Film FROM mariusz CASCADE; użytkownik mariusz nadal posiada prawo INSERT ON Film, nie posiada już jednak prawa GRANT. Użytkownik jacek nie posiada już natomiast prawa INSERT ON Film (ponieważ zostało mu one nadane przez mariusz dzięki prawu GRANT, którego został on potem pozbawiony).

31 31 Diagramy GRANT Root INSERT ON Film ** Jacek INSERT ON Film Mariusz INSERT ON Film * Mariusz INSERT ON Film