Lekcja 5. Klucz główny i klucz obcy. Relacje w tabelach.

Model bazy danych to zbiór zasad (specyfikacji), opisujących strukturę danych w bazie danych. Dziś najczęściej wykorzystuje się model relacyjny bazy danych. W modelu tym dzielimy dane w bazie na tabele i definiujemy w tabelach pola będące tzw. kluczami. Następnie określa się relacje istniejące pomiędzy tabelami, które łączą dane w logiczną całość.

Klucz główny

Klucz główny (ang. primary key) to jedno lub więcej pól, których wartość jednoznacznie identyfikuje każdy rekord w tabeli. To oznacza, że taki klucz musi przyjmować wyłącznie wartości niepowtarzalne i nie może być wartością pustą (null*). Każda tabela może mieć najwyżej jeden klucz główny.

*null – specjalny znacznik w języku SQL, wskazujący, że dana nie istnieje w bazie danych

Klucz obcy

Klucz obcy (ang. foreign key)  to kombinacja jednego lub więcej pól w danej tabeli z wartościami, stanowiącymi klucz główny w innej. Wykorzystuje się go do tworzenia relacji pomiędzy parą tabel, gdzie w jednej tabeli ten zbiór atrybutów jest kluczem obcym, a w drugiej kluczem głównym.

Przykład

Załóżmy, że projektujemy prostą bazę danych sklepu, w której będą znajdować się informacje, jakie produkty zakupił dany klient. W tym celu musimy zaprojektować trzy tabele: „Klient”, „Produkt”, „Zakupy”.

Tabela "Klient"

 Tabela "Produkt"

Tabela "Zakupy" musi dostarczyć informacji, który klient zakupił który konkretny produkt. Jeśli ustalimy, że osobę będziemy rozpoznawać na podstawie imienia i nazwiska, wtedy tabela „Zakupy” będzie wyglądała następująco:

Tabela "Zakupy"

Należy sobie jednak zadać pytanie, co zrobić w przypadku, gdy tabela będzie posiadała informacje o dwóch osobach posiadających identyczne dane personalne? Nie można wykluczyć, iż dwie osoby o takich samych nazwiskach zamieszkują pod tym samym adresem. W jaki sposób identyfikować takie osoby? Inną kwestią jest zawartość tabeli „Zakupy”, w której rekordy się powtarzają i zaburzają atomowość rekordów (tematem normalizacji bazy danych, czyli procesu mającego na celu eliminację powtarzających się danych w relacyjnej bazie danych, zajmiemy się w jednej z kolejnych lekcji).

W codziennej pracy z bazami danych najczęściej wykorzystuje się informacje składowane w wielu tabelach, połączonych ze sobą za pomocą relacji FOREIGN KEY – PRIMARY KEY. Jednakże nawet w przypadku prostej bazy danych należy używać mechanizmu łączenia tabel w relacyjnej bazie danych za pomocą kluczy: głównego i obcego.

W naszym przypadku jedynym sensownym rozwiązaniem jest dodanie klucza głównego (osobnej kolumny która będzie stanowić unikatowy identyfikator) do tabeli „Klient” oraz do tabeli „Produkt”.

Tabela "Klient"

Tabela "Produkt" 

Pozostaje kwestia tabeli „Zakupy”. Bazując na już zaprojektowanych tabelach możemy zauważyć, że tabela „Zakupy” będzie wymagać jedynie kompletacji identyfikatorów z tabeli „Klient” i tabeli „Produkt”.

Tabela „Zakupy” łączy w sobie dwa klucze obce: ID Klienta oraz ID Produktu, które w tabelach „Klient” oraz „Produkt” figurowały jako klucze główne. Na tej podstawie łatwo można rozróżnić, który rekord, określający sprzedaż danego produktu, należał do Jana Kowalskiego, a który do Krzysztofa Nowaka.

Tabela "Zakupy"

I tak dla przykładu trzeci rekord z tabeli „Zakupy” informuje nas o tym, że Jan Kowalski kupił Encyklopedię .NET.

Relacje w tabelach

Relacja pomiędzy tabelami działa przez dopasowywanie danych w polach kluczy — często są to pola o tej samej nazwie w obu tabelach. W większości przypadków te pasujące pola to klucz podstawowy z jednej tabeli, dostarczający unikatowego identyfikatora każdego rekordu, oraz klucz obcy w drugiej tabeli. 

W tabelach mogą obowiązywać następujące 3 typy relacji :

1:1, czyli jeden do jednego, tzn., że dokładnie jednemu rekordowi z jednej tabeli odpowiada dokładnie jeden rekord z drugiej tabeli

Rozważmy przykład bazy danych do śledzenia zamówień, która zawiera tabelę "Klienci" i tabelę "Zamówienia". Klient może złożyć dowolną liczbę zamówień. W związku z tym każdemu klientowi reprezentowanemu w tabeli "Klienci" może odpowiadać wiele zamówień reprezentowanych w tabeli "Zamówienia". Dlatego relacja pomiędzy tabelą "Klienci", a tabelą "Zamówienia" to relacja jeden-do-wielu.

1:M, czyli jeden do wielu, tzn., że dokładnie jeden rekord z jednej tabeli może mieć przypisane więcej rekordów z innej tabeli

Rozważmy przykład relacji pomiędzy tabelą "Produkty", a tabelą "Zamówienia". Jedno zamówienie może obejmować wiele produktów. Z drugiej strony jeden produkt może się znaleźć w wielu zamówieniach. Dlatego każdemu rekordowi z tabeli "Zamówienia" może odpowiadać wiele rekordów z tabeli "Produkty". Ponadto każdemu rekordowi z tabeli "Produkty" może odpowiadać wiele rekordów z tabeli "Zamówienia". Jest to relacja typu wiele-do-wielu, ponieważ każdemu produktowi może odpowiadać wiele zamówień, a każdemu zamówieniu — wiele produktów. Należy zauważyć, że aby wykryć istniejące relacje wiele-do-wielu pomiędzy tabelami, trzeba się przyjrzeć obu stronom relacji.

M:M, czyli wiele do wielu, tzn., że wiele rekordów z jednej tabeli może mieć przypisane wiele rekordów z drugiej tabeli

W relacji jeden-do-jednego z każdym rekordem w pierwszej tabeli może być związany tylko jeden pasujący rekord w drugiej tabeli, a z każdym rekordem w drugiej tabeli może być związany tylko jeden pasujący rekord w pierwszej tabeli. Ten typ relacji jest nietypowy, ponieważ najczęściej informacje powiązane w ten sposób są przechowywane w jednej tabeli. Za pomocą relacji jeden-do-jednego można podzielić tabelę z wieloma polami, odizolować fragment tabeli ze względów bezpieczeństwa lub przechowywać informacje odnoszące się tylko do podzbioru tabeli głównej. Określenie takiej relacji wymaga, aby obie tabele używały wspólnego pola.