11038 ullman189 (2)

384 6. WIĘZY IWYZWALACZE W JĘZYKU SQL ¹

Odpowiedniość między atrybutami prezC# i cert# można deklarować bezpośrednio w sposób następujący:

CREATE TA3LE Studio {

nazwa CHAR(30) PR1MARY KEY, adres VARCHAR(255),

prezC- INT REFERENCES FiimDyr(cert#)

);

Alternatywny sposób deklarowania klucza polega na włączeniu oddzielnej deklaracji klucza do instrukcji:

CREATE TA3LE Studio {

nazwa CHAR(30) PRIMARY KEY, adres VARCHAR(255), prezC# INT,

FOREIGN KEY prezC# REFERENCES FiimDyr(cert#)

) ;

Należy zauważyć, że klucz obcy cert#, do którego wystąpiło odwołanie, jest w rzeczywistości kluczem głównym relacji FiimDyr. To, żc atrybut cert# jest kluczem głównym relacji F^:. lmDyr, gwarantuje poprawność określenia atrybutu prezC, który się do niego odwołuje jako do klucza obcego.

Klucze główne i atrybuty różnowartościowe

Deklaracja PRIMARY KEY jest nieomal synonimem deklaracji UNIQUE. Najważniejsza różnica polega na tym, żc jest jeden tylko klucz główny dla całej tabeli, a atrybutów różnowartościowych typu UNIQUF. może być wiele. Jednak istnieją również subtelniejsze różnice:

1.    Klucz obcy może wskazywać wyłącznie klucz główny relacji.

2.    Do implementacji systemu zarządzania bazami danych można dołączyć szereg mechanizmów, które rozszerzają zestaw właściwości klucza głównego. Nadają one temu pojęciu nowe znaczenie, które nie jest zawarte w standardzie SQL2. Na przykład, jak już wspomniano w p. 6.1.2, producent systemu baz danych może zawsze dla klucza głównego konstruować indeks (nawet jeśli jest to klucz złożony), a w przypadku innych atrybutów pozostawić użytkownikowi decyzję o założeniu indeksu. Inny sposób polega na tym, że tabela może być utrzy mana w postaci posortowanej według klucza głównego, o ile taki istnieje.

Każda z tych dwóch deklaracji klucza obcego o/.nacza, że dowolna wartość występująca w polu prezC# pewnej krotki relacji Studio występuje także w jakiejś krotce relacji FiimDyr w polu cert#. Jedyny wyjątek stanowi wartość NULŁ, której wystąpienie w relacji Studio nie wymusza istnienia odpowiednika w polu cert# relacji FiimDyr (w praktyce nie dopuszcza się bowiem wartości NULI jako wartości klucza głównego, zob. rozdz. 6.3.1).

6.2.2. Przestrzeganie zasad wiązów integralności referencyjnej

Wiadomo już. w jaki sposób deklarować klucz obcy, a także to, że w wyniku jego użycia każda wartość klucza obcego różna od null musi mieć swój odpowiednik wc wskazywanej relacji. Ale w jak i sposób przestrzegać tej zasady w obliczu konieczności wprowadzania zmian do bazy danych? Można tu wyróżnić trzy rodzaje postępowania:

Postępowanie standardowe: odrzucanie zmian naruszających więzy

W języku SQL przyjmuje się przez domniemanie, że o ile nie zostanie wybrana inna strategia, to każda próba naruszenia więzów integralności referencyjnej będzie powodowała automatyczne odrzucenie polecenia przez system. Rozważmy ponownie przykład 6.3, w którym wartość prezC# relacji Studio musi wystąpić również w polu cert# relacji FiimDyr. Zatem przy stosowaniu standardowej procedury nic powiedzie się wykonanie następujących działań (tzn. zostanie wygenerowany błąd wykonania):

1.    Próbujemy wstawić now'ą krotkę do relacji Studio, której wartość prezC# jest różna od NULL i która nie występuje w polu cert# relacji FiimDyr. Próba wstawienia nie powiedzie się, krotka nic zostanie wstawiona.

2.    Próbujemy zmienić określoną krotkę relacji Studio, tak aby wartość w polu prezC# była różna od null. Wstawiana wartość nie występuje w' polu cert# żadnej istniejącej krotki relacji FiimDyr. Modyfikacja zostaje odrzucona i krotka pozostaje bez zmian.

3.    Próbujemy usunąć krotkę z relacji FiimDyr, ale wartość w polu cert# występuje również w- polu prezC# pewnej krotki relacji Studio. Ta próba również nie powiedzie się i krotka pozostanie w relacji FiimDyr.

4.    Próbujemy zmienić wartość atrybutu cert# w relacji FiimDyr, ale stara wartość cert# występuje w polu prezC# relacji Studio. Tak samo jak poprzednio próba nic powiedzie się. a krotka pozostanie taka, jaka była.