wykład 22.04.2004

31
1 Wykład 22.04.2004 Asercje, wyzwalacze i prawa

Upload: lars-sharp

Post on 30-Dec-2015

56 views

Category:

Documents


0 download

DESCRIPTION

Wykład 22.04.2004. Asercje, wyzwalacze i prawa. Elementy aktywne bazy. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Wykład 22.04.2004

1

Wykład 22.04.2004

Asercje, wyzwalacze i prawa

Page 2: Wykład 22.04.2004

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:

Page 3: Wykład 22.04.2004

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

Page 4: Wykład 22.04.2004

4

Elementy aktywne bazy cd. 2

• Więzy globalne– Więzy check

deklarowanie więzów dla pojedynczej relacji

check (<warunek_jak_po_where>)– Asercje (assertion)– Wyzwalacze (triggers)

Page 5: Wykład 22.04.2004

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

Page 6: Wykład 22.04.2004

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.

Page 7: Wykład 22.04.2004

7

Składnia asercji

• CREATE ASSERTION <nazwa_asercji>CHECK (<warunek>)

Gdzie <warunek> musi być typu logicznego• PrzykładPrzyjmijmy, ż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 $

Page 8: Wykład 22.04.2004

8

Asercje

Asercja opisująca ten warunek może wyglądać następująco:

1. CREATE ASSERTION BogatyPrez CHECK2. (NOT EXISTS3. (SELECT *4. FROM Studio,Dyrektor5. WHERE prezC=cert AND

cenaSieci<100000006. ));

Page 9: Wykład 22.04.2004

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 Dyrektor7. WHERE cenaSieci<10000000)8. ));

Page 10: Wykład 22.04.2004

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.

Page 11: Wykład 22.04.2004

11

Porównanie krotkowych check i asercji

Typ więzów Kiedy 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

Page 12: Wykład 22.04.2004

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.

Page 13: Wykład 22.04.2004

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.

Page 14: Wykład 22.04.2004

14

Asercje

Asercja wygląda następująco:1. CREATE ASSERTION SumDlugość2. CHECK (10000 <= ALL3. (SELECT SUM(długość) FROM Film4. 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!!

Page 15: Wykład 22.04.2004

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ę.

Page 16: Wykład 22.04.2004

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

Page 17: Wykład 22.04.2004

17

Składnia wyzwalaczy

CREATE TRIGGER <nazwa_wyzwalacza>{BEFORE|INSTEAD OF |AFTER}[OF <nazwa_kolumny>] ON <nazwa_tabeli>REFERENCING{OLD|OLD_TABLE} AS nazwa_zmiennej1{NEW|NEW_TABLE} AS nazwa_zmiennej2WHEN (<warunek>)<lista_poleceń_do_wykonania> //akcja[FOR EACH ROW]

Page 18: Wykład 22.04.2004

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

Page 19: Wykład 22.04.2004

19

Przykład wyzwalacza

Uniemożliwienie obniżenie ceny sieci:1. CREATE TRIGGER CenaSieciWyzw2. AFTER UPDATE OF cenaSieci ON Dyrektor3. REFERENCING 4. OLD AS Stara5. NEW AS Nowa6. WHEN (Stara.cenaSieci > Nowa.cenaSieci)7. UPDATE Dyrektor SET cenaSieci= Stara.cenaSieci8. WHERE cert = Nowa.cert9. FOR EACH ROW

Page 20: Wykład 22.04.2004

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);

Page 21: Wykład 22.04.2004

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).

Page 22: Wykład 22.04.2004

22

Składnia do nadawania praw

GRANT <prawa> ON <element bazy danych> TO <lista użytkowników>

[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.

Page 23: Wykład 22.04.2004

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).

Page 24: Wykład 22.04.2004

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;

Page 25: Wykład 22.04.2004

25

Składnia REVOKE

• Odbieranie nadanych wcześniej praw (innych niż GRANT)

REVOKE <prawa> ON <element bazy danych> FROM <lista użytkowników>

[CASCADE|RESTRICT];• Odbieranie prawa GRANTREVOKE GRANT OPTION FOR <prawa> ON

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

[CASCADE|RESTRICT]

Page 26: Wykład 22.04.2004

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;

Page 27: Wykład 22.04.2004

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)

Page 28: Wykład 22.04.2004

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.

Page 29: Wykład 22.04.2004

29

Diagram GRANT

RootINSERT ON

Film **

MariuszINSERT ON

Film

MariuszINSERT ONFilm(Tytuł)

Page 30: Wykład 22.04.2004

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).

Page 31: Wykład 22.04.2004

31

Diagramy GRANT

RootINSERT ON

Film **

JacekINSERT ON

Film

MariuszINSERT ON

Film *

MariuszINSERT ON

Film