ullman193 (2)

6. WIEŻY I w Y Z W Al. ACZ E W JĘZYKU SQl.

A więc usunięcie zostanie wykonane, nawet jeśli w jego wyniku więzy CHECK zostaną naruszone.

W punkcie 6.4.2 opiszemy, w jaki sposób można poprawnie wyrazić stawiane warunki.

□

6.3.3. Więzy dziedziny

Inny sposób narzucenia ograniczeń na wartości atrybutu polega na zadeklarowaniu tych ograniczeń dla dziedziny atrybutu (o dziedzinach była już mowa w p. 5.7.6), a następnie przypisaniu tej dziedziny typow^ri atrybutu. Różnica ujawnia się tylko wówczas, gdy ograniczenie dziedziny polega na wypisaniu dopuszczalnych wartości, ale nie ma się jak do nich odwoływać. Dla porównania: jeśli więzy są przypisane bezpośrednio do atrybutu, to wówczas możemy dowiedzieć się, jaka jest w-artość poprzez atrybut, któremu ją przypisano. W SQL2 ten problem rozwiązano, wprowadzając specjalne słowo kluczowe VALUE, dzięki któremu można odwoływać się do wartości przypisanych do dziedziny.

PRZYKŁAD 6.8

Następująca deklaracja może posłużyć do określenia, że w dziedzinie Dzie-dzinaPłci wartościami mogą być tylko dwa pojedyncze znaki' K' oraz ' M':

CREATE DOMATN DziedzinaPici CHAR{1)

CHECK (VALUE IN t'K', 'M' ));

Po zapisaniu takiej deklaracji wiersz 4) z ry s. 5.13 może przybrać następującą postać:

4) płeć DziedzinaPici,

Analogiczny efekt uzyskuje się dla przykładu 6.6, gdzie jest stawiany wymóg sześciocyfrowego numeru certyfikatu dla atrybutu prezC#, jeśli utworzy' się dziedzinę:

CREATE DOMATN DziedzinaCert INT CHECK (VAL^rJE >= 100000);

a z kolei deklaracja atrybutu prezC# zostanie zapisana następująco:

4) prezC# DziedzinaCert REFERENCES FilmDyr (cert#)

□

Kiedy należy sprawdzać więzy

W normalnych okolicznościach system SQL nie dopuszeza do takich modyfikacji danych w bazie danych, które prowadzą do naruszenia więzów. Może się jednak zdarzyć, że trzeba wykonać działania na danych i któreś z nich prowadzi do naruszenia więzów, ale kolejne poprawia ten stan. Rozważmy przykład 6.3, w którym ustaliliśmy, że atrybut prezC# jest kluczem obcym w relacji Studio, dziedziczonym z atrybutu cert# z relacji FiinDyr. Jeśli do bazy zamierzamy dołączyć nowe studio oraz jego prezesa, to rozpoczynając od wpisywania studia, zostaną naruszone więzy klucza obcego.

Wydaje się, że sytuację można uzdrowić, jeśli w pierwszej kolejności wprowadzi się dane prezesa do relacji FilmDyr. Ale jeśli dołączymy wymaganie, żeby prezes, identyfikowany w relacji FilmDyr poprzez cert#, miał wpisany ten numer certyfikatu w relacji film albo Studio, to ju2 żadna kolejność nie będzie właściwa.

Na szczęście w SQL2 można określać więzy typu deferred. Takie więzy są sprawdzane dopiero po zakończeniu wykonywania całej „transakcji” (podstawowej jednostki działania na bazach danych - transakcje opisano w podrozdziale 7.2). Dzięki temu studio i jego prezydenta możemy dopisać do bazy danych, nie powodując przy tym naruszenia więzów-.

6.3.4. Ćwiczenia do podrozdziału 6.3

Ćwiczenie 6.3.1. Dla relacji:

Film(tytuł, rok, długość, czyKoior, nazwaStućia, proćucer.tC#)

Zadeklarować następujące więzy:

*a) Rok nie może być wcześniejszy niż 1895. b) Długość nie może wynosić mniej niż 60 ani więcej niż 250.

*c) Nazwą studia musi być Disney, Fox, MGM albo Paramount.

Ćw iczenie 6.3.2. Dla przykładow-ego schematu bazy danych z ćwiczenia 4.1.1:

Produkt(producent, model, typ)

PC{model, szybkość, ram, ha, cd, cena)

Laptop(model, szybkość, ram, hd, ekran, cena)

Drukarkę{model, kolor, typ, eona)

Należ>^r zadeklarować następujące więzy atrybutów:

a)    Częstotliwość zegara laptopa nie może być mniejsza niż. 100.

b)    Szybkość CD może być równa wyłącznie: 4x, 6x, 8x lub 12x.