55133

Tabela zamówienia zawiera klucz gÓÓwny id_zamowienia oraz klucz obcy id_klienta, który odwoóuje sió do

klucza gÓÓwnego id_klienta w tabeli klient.

Tabela towary zawiera klucz gÓÓwny id_towaru, który jest kluczem obcym w tabeli dostawy.

Tabela dostawy jest tutaj dosó specyficznó

tabela. Zawiera ona bowiem tylko dwie kolumny, z których każda jest kluczem obcym. Kolumna id_zamowienia odwoóuje sió do klucza gÓÓwnego w tabeli zamówienia, natomiast klumna id_towaru odwoóuje sió do klucza gÓÓwnego w tabeli towary.

ChoÓ

nie ma tu takiego przykóadu, to możliwe jest utworzenia klucza gÓÓwnego, który zóozony jest z kilku kolumn.

Wtedy unikalnosó

rekordów jest zapewniona dzięki istnieniu unikalnych par danych. Możliwe jest zatem równieó

zdefiniowanie w taki sposób klucza obcego.

Często jest tak, ze klucz gÓÓv*ny w tabeli jest jednocześnie kluczem obcym. Wtedy

klucz taki identyfikuje

unikalnie rekordy w tabeli, jak równieó

odwoóuje sió

do rekordów z innej tabeli. Zwykle wskazuje to na relacjó jeden do wielu pomiędzy wierszami dv^ich tabel.

Co to wszystko nam daje?

Jeśli w tabeli zamówienia mamy w polu id_klienta wartość, która nie odpowiada żadnej z wartości klucza

gÓÓwnego w tabeli klient to mamy problem. Oznacza to bowiem, ze mamy zamówienie i nie wiemy kto je zóozyó.

Co prawda, możemy w aplikacji, która z takiej bazy danych korzysta, wprowadzió odpowiednie sprawdzenie i reakcjó

na tego typu bóedy, to jednak dużo bezpieczniej i wygodniej jest dbaó

0    integralnosó danych w samej

bazie danych. A zatem definiowanie relacji pomiędzy danymi w różnych tabelach umożliwia nam zachowanie

logicznej integralności danych, w taki sposób aby można byóo bezpiecznie i logicznie (a jednocześnie nie powtarzając danych) wprowadzaó

1    przechowywaó dane i korzystaó z nich.

Dane w takich tabelach.

Sprawdźmy jakie kluczowe dane znajdujÓ sió

w tablicy zamówienia

mysql> SELECT id_zamowienia, id_klienta FROM zamówienia;

+...............+............+