6 WII-/.Y ] WYZ WALACZ-I•• W ję&YKO syt.
kiedy następuje próba zmiany zawartości bazy danych. Oczywiście jednak naruszenie więzów klucza relacji R może zaistnieć wyłącznic wówczas, gdy ma nastąpić modyfikacja danych właśnie tej relacji. A poza tym usunięcie danych nie może powodować naruszenia więzów klucza relacji R. niebezpieczne mogą być tylko operacje wstawiania danych lub ich modyfikacji. Dlatego standardowa praktyka w systemie SQL polega na sprawdzaniu więzów^ klucza tylko podczas operacji wstawiania i modyfikacji danych w relacji.
Indeksy dla atrybutów kluczowych są potrzebne po to, by system SQL korzystał efektywnie z więzów klucza. Jeśli indeks jest dostępny, to zawrze gdy dołączamy do relacji nową krotkę albo modyfikujemy klucz istniejącej, korzystamy z indeksu, aby sprawdzić, czy przypadkiem nie ma już innej krotki o danej wartości atrybutu deklarowanego jako klucz. Jeśli taka krotka występuje, to system nie może dopuścić do wykonania działań.
Jednak nawet jeśli na atrybucie klucza nie założono indeksu, to i tak można przestrzegać ograniczeń wynikających z więzów klucza. Trzeba wówczas sprawdzać całą relację w poszukiwaniu krotki o określonej wartości klucza. Taki proces jest nadzwyczaj czasochłonny i w przypadku dużych baz danych modyfikacja może się okazać niewykonalna.
Ćwiczenie 6.1.1. W naszej przykładowej bazie danych filmów z podrozdziału 3.9 zdefiniowano klucze dla wszystkich relacji. Należy tak zmodyfikować deklaracje z ćwiczenia 5.7.1, aby włączyć deklaracje kluczy dla wszystkich tych relacji. Przypomnijmy, że wszystkie trzy atrybuty są kluczem relacji GwiazdyW.
Ćwiczenie 6.1.2. Zaproponuj właściwe klucze relacji w bazie danych komputerów' osobistych PC z ćwiczenia 4.1.1. Włącz deklaracje tych kluczy' do zapisanego w- SQL schematu z ćwiczenia 5.7.2.
Ćwiczenie 6.1.3. Zaproponuj właściwe klucze relacji w bazie danych bitew morskich z ćwiczenia 4.1.3. Włącz deklaracje tych kluczy do zapisanego w' SQL schematu z ćwiczenia 5.7.3.
Inny ważny rodzaj więzów w schemacie bazy danych wynika stąd, że wartości poszczególnych atrybutów muszą zachowywać pewne właściwości. Na przykład taki atrybut jak prezCf relacji Studio musi wskazywać na właściwego dyrektora produkcji. Wynika stąd warunek integralności referencyjnej polegający na tym, że jeśli w krotce studia występuje określona wartość atrybutu prezC=, to nie wzięła się ona z powietrza, a stanowi ona numer certyfikatu rzeczywistego dyrektora produkcji. W sensie bazy danych „rzeczywisty” dyrektor to taki, który występuje w relacji FilmDyr. Oznacza to, że w relacji FilmDyr występuje krotka z wartością c w polu cert *.
W języku SQL można zadeklarować, że atrybut lub atrybuty z jednej relacji stanowią klucz obcy, odpowiadający pewnym atrybutom z innej relacji (a czasem tej samej relacji). Wynikają stąd dwa wnioski:
1. Atrybuty' klucza obcego muszą być zadeklarowane jako klucz głów ny w oryginalnej relacji.
2. Każda wartość występująca jako atry but klucza obcego musi wystąpić również jako wartość odpowiedniego atry butu w oryginalnej relacji. Oznacza to istnienie więzów integralności referencyjnej łączących dwa atrybuty lub ich zbiory.
Tak samo jak w przypadku klucza głównego, klucz obcy można deklarować na dwa sposoby:
a) Jeśli klucz obcy jest pojedynczym atrybutem, to możemy określić jego nazwę i typ, deklarując go przez odwołanie do innego atrybutu (klucza głównego), w' pewnej tabeli. Postać deklaracji jest następująca:
REFERENCF.S <tabela> (<atrybut>)
b) Alternatywnie można do listy' atrybutów' w instrukcji CREATE TA3LE dołączyć jedną lub więcej deklaracji określające, że atrybut, lub ich zbiór, jest kluczem obcym. Potem należy wymienić nazwy tabeli oraz atrybutów' (muszą one stanowić klucz, główny), do których odwołuje się klucz obcy. Oto postać takiej deklaracji:
FORSIGN KEY <atrybuty> REFERENCES <tabela>
(<atrybuty>)
PRZYKŁAD 6.3
Załóżmy, że deklarowana relacja
Studio (nazwa, adres, prezC#)
zaw iera klucz główny nazwa oraz klucz obcy prezC-, określający odwołanie do atrybutu cert.# w relacji
FilmDyr (nazwisko, adres, cert#, cenaSieci)