34361 ullman188 (2)

34361 ullman188 (2)



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.

6.1.3. Ćwiczenia do podrozdziału 6.1

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

6.2. Integralność referencyjna i klucze obce

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

6.2.1. Deklarowanie więzów klucza obcego

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)


Wyszukiwarka

Podobne podstrony:
img24601 djvu 249Kowal. 249 ki rb .*• i— 1. Je-stem so - bie ko-wał, mam za-wsze ro - bo - tę, rq::
MA1 (2) 5 —W T^Ł H. -*■ k:—u — 0Ć& /(/ /tkGMlk Z -i— i ___je. &
3 1 (4) I tkwr cl p ► «i <1 p Je li i- v. p»»i. 1mV4U)i cl p Jc la v. ailciKfllMARIKKA FEQfcfSA l
Saniawa3 i^F~- f— —TT^K. —r-—i—i---Je - J* hm /
3 1 (4) I tkwr cl p ► «i <1 p Je li i- v. p»»i. 1mV4U)i cl p Jc la v. ailciKfllMARIKKA FEQfcfSA l
muse ULUBIONY WALC 001 ✓ * c AULUBIONY WALCwalc musette —I-- —I- f J i JE: W=^ v .
plakat tertio 213x300 ii F, • II A > I I } iuH» 2g*    i»«» ję* 2010TERTIO MILLENN
PrepOrg II015 (2) : ■■ ■-X" . -‘i fetó. ■H. < bieżęcej wody, następnie 1% roz - 17 Stężony
272 Ćwiczenia laboratoryjne z fizyki lości przekształcających je w impulsy elektryczne, które następ
Wszechnica Poranna• Trzy tematy: 1.    Bazy danych - jak je ugryźć? 2.
Wszechnica Poranna• Bazy danych - jak je ugryźć?-    Wykład : •
P2025497 24 Bazy danych I w tym polu motna wpisać potrzebne hasto lub wybrać je (np. klikn
43271 ullman221 (2) 7. SYSTEMOWE ASPEKTY Jl-ZYKA SQL RYSUNHK 7.11 Organizacja elementów bazy danych
Rodza je reguł Wyróżnia się trzy podstawowe rodzaje reguł wygenerowanych z danych: - klasyfikacyjne
Bazy?nych jak je ugryźć Bazy danych - jak je ugryźć? Warszawska Wyższa Szkolą 1 N r OR M AT Y K IW
CCF20090213016 (2) Te trzy zasady, tak jak je sformułował Arystoteles, brzmią następująco: 1)  
Trening ortograficzny103 Zapamiętaj wyrazy. Potem je porozcinaj i wymieszaj sylaby. Następnie ponown

więcej podobnych podstron