ullman187 (2)

6. Wlł-ZY 1 WYZWALAC7.F. W Jiy.YK-U iWL

zdefiniować w wierszu deklaracji atrybutu nazwisko. Rysunek 6.1 zawiera obraz z rys. 5.13 z uwzględnieniem opisanej zmiany. Można skorzystać jednak z drugiego sposobu - odrębnego definiowania klucza głównego. Wówczas w tekście z rys. 5.13 po wierszu 5) pojawi się deklaracja klucza głównego i nie ma potrzeby definiowania tej cechy w wierszu 2). Wynikowy obraz deklaracji schematu relacji zawiera rys. 6.2.

1)    CREATE 7A5LE GwiazdaFilmowa (

2)    nazwisko CHAR(30) PRIMARY KEY,

3)    adres VARCHAR(255),

4)    płeć CHARCI),

5)    dataUrodzenia DATĘ ) ;

RYSUNEK 6.1

Zdefiniowanie nazwiska jako klucza głównego

1)    CREATE TABLE GwiazdaFilmowa (

2)    nazwisko CHAR(30),

3)    adres VARCHAR(255),

4)    płeć CHAR(1),

5)    datauroćzenia DATĘ,

6)    PRIMARY KEY(nazwisko)

>;

RYSUNEK 6.2

Oddzielna deklaracja klucza głównego

□

Zauważmy, że w przykładzie 6.1 obie postaci, ta z rys. 6.1 i ta z rys. 6.2, są jednakowo poprawne, ponieważ klucz główny składa się z jednego atrybutu. Jednak w sytuacji, gdy klucz główny składa się z więcej niż jednego atrybutu, należy korzystać ze stylu z rys. 6.2. Na przykład w deklaracji schematu relacji Film, której kluczem jest para atrybutów tytuł oraz rok, trzeba na końcu listy atrybutów dopisać wiersz:

PRIMARY KEY (tytuł, rok)

Jeszcze inaczej można określać klucz, korzystając ze słowa kluczowego UNiguE. Ten wyraz może pojawić się w takich samych kontekstach jak określenie PRIMARY KEY: albo po zdefiniowaniu atrybutu i jego typu, albo jako oddzielny element instrukcji CREATE TABLE. Ma on takie same znaczenie jak określenie PRIMARY key. Jednak w instrukcji CREATE TABLE może wystąpić wiele specyfikacji UNTQUE, natomiast tylko jedna PRIMARY KEY.

Wiersz 2) z rys. 6.1 mógłby zostać zapisany następująco:

2)    nazwisko CHAR(30) UNIQUE,

Można również zmienić wiersz 3):

3)    adres VARCHAR{255) UNIQUE,

jeśli mamy przeświadczenie, że dwie gwiazdy filmowe nie mogą mieć takiego samego adresu (założenie budzące wątpliwości). Podobnie można zmodyfikować wiersz 6) z rys. 6.2, nadając mu postać:

6) UNIQCJE (nazwisko)

□

Wiązy klucza są to więzy deklarowane albo jako PRIMARY KEY, albo jako UNIQUE. Formalna różnica między tymi dwoma typami deklaracji została opisana w ramce w p. 6.2.2.

6.1.2. Wymuszanie więzów klucza

Przypomnijmy rozważania z p. 5.7.7, z których wynika, że każda implementacja języka SQL zawiera mechanizmy definiowania indeksów w schemacie bazy danych, mimo że nie są one elementem standardu SQL. W naturalny sposób buduje się indeks na polach kluczy po to, by ułatwić typowe zapytania korzystające z ich wartości. Można także określać indeksy na innych atrybutach, specyfikow^ranych jako UNIQUE.

Stąd też, jeśli w zapytaniu klauzula WHERE zawiera porównanie klucza z konkretną wartością, np. w relacji GwiazdaFi lmowa z przykładu 6.1: nazwisko = ' Audrey Hepburn', to właściwe krotki zostaną bardzo szybko wybrane, bowiem nie trzeba będzie przeglądać wszystkich krotek relacji.

W wielu implementacjach języka SQL instrukcja, która jest przeznaczona do tworzenia indeksu, może być użyta również do określenia klucza przez dopisanie słowa kluczowego UNIQUE. Na przykład użycie instrukcji

CREATE UNIQUE INDEX Roklndeks On Film(rok);

dałoby ten sam wynik, co wykonanie instrukcji zakładania indeksu z przy kładu 5.7.7, a ponadto spowodowałoby określenie więzów'jednoznaczności atrybutu rok w' relacji Film (niezbyt rozsądne założenie).

Rozważmy przez chwilę, w jaki sposób w^rięzy klucza są wymuszane przez system SQL. W zasadzie w ięzy muszą być sprawdzane zawsze wtedy,