Klucze są podstawową koncepcją w teorii relacyjnych baz danych. Zapewniają tabelom możliwość skorelowania ze sobą dwóch lub więcej tabel. Nawigacja w relacyjnej bazie danych zależy od możliwości identyfikacji określonego wiersza w tabeli za pomocą klucza głównego. Artykuł ten poświęcony będzie poświęcony teorii kluczy głównych i obcych oraz zasadom ich działania.

Związek pomiędzy dwoma lub większą ilością tabel to asocjacja (w potocznym bazodanowym języku znana również jako relacja). Asocjacja jest wyrażona za pomocą wartości klucza głównego i kluczy obcych.

Klucz główny - Primary Key, to kolumna lub zbiór kolumn, które w sposób unikalny definiują wiersz w danej tabeli. Klucz obcy jest kolumną lub zbiorem kolumn, który jest kluczem głównym w innej tabeli. Można powiedzieć, że klucz obcy jest kopią klucza głównego z innej tabeli. Asocjacja jest utworzona pomiędzy tabelami poprzez zaznaczenie, iż wartość z jednej tabeli, w której jest kluczem obcym, jest powiązana z wartością z innej tabeli, gdzie jest kluczem głównym. Ważne jest to, iż wartość klucza obcego nie może istnieć bez powiązania z kluczem głównym. Jeśli w tabeli pracowników mamy pole, które jest kluczem głównym w tabeli z państwami, to nie możemy wpisać w nie wartości, która nie istnieje w tabeli państw. Silnik bazy danych nie zezwoli, aby wstawić wartość klucza obcego, który nie posiada odnośnika na klucz obcy.

Teraz, kiedy mamy na czym skupić naszą uwagę, możemy przejść do opisywania krok po kroku poszczególnych struktur i technik pracy z kluczami. Powiemy, co określa klucz główny, co za tym idzie - w jaki sposób odnaleźć pole, które aplikuje do bycia kluczem. Aby utworzyć taki podstawowy model danych możemy posłużyć się następującym algorytmem:

• identyfikacja pól, które mogłyby się stać kluczami głównymi
• sprawdzenie poprawności kluczy i związków pomiędzy tabelami
• przeniesienie kluczy głównych do innych tabel jako klucze obce.

Określenie kluczy głównych

Klucz główny musi unikalnie identyfikować wiersz. Każdy wiersz w naszej tabeli musi mieć wartość która unikalnie go identyfikuje.

Aby zakwalifikować dany atrybut jako klucz główny, musimy sprawdzić, czy posiada następujące własności:

• musi posiadać wartość dla każdego z wierszy
• dla każdego z tych wierszy wartość musi być unikalna
• wartość ta nie może się zmienić, ani nie może zostać usunięta podczas całego funkcjonowania wiersza w tabeli

Jeśli mielibyśmy tabelę z użytkownikami zarejestrowanymi w portalu internetowym, kluczem głównym mógłby być login. Jest unikalny w ramach całej tabeli, a po usunięciu logina użytkownik ulega usunięciu. Kluczem głównym nie mogłoby być nazwisko, gdyż może być wiele osób, które nazywają się Kowalski. A to łamie drugą zasadę, która mówi, iż wartość musi być unikalna.
W niektórych przypadkach możemy mieć kilku kandydatów do klucza głównego. Rozważmy ponownie ten sam przypadek. Przypuśćmy, że mamy dodatkowe informacje o użytkowniku: datę urodzenia, PESEL, email. Wiemy, że unikalne są dwie wartości: PESEL i email. Zatem zarówno jedną i drugą możemy zaproponować na klucz główny w tabeli User. Teraz od nas tylko zależy czy wybierzemy email czy PESEL. Ja osobiście wybrałbym PESEL ponieważ wyszukiwanie w bazach po wartości typu INT (czyli typu całkowitoliczbowego) jest znacznie szybsze, niż po łańcuchu znaków. Jeśli jednak byłby to portal możliwością logowania, trzeba wziąć pod uwagę, że zmuszenie użytkownika, aby przy logowaniu wpisywał PESEL jest trudniejsze niż skłonienie go do wpasania adresu email.

Klucze złożone

Czasem pojedyncza wartość nie wystarczy na jednoznaczne określenie wiersza.

Jeśli chcielibyśmy zapisać oceny z przedmiotów dla danego studenta musielibyśmy zapisać następujące informacje: przedmiot, z którego ocena została wystawiona, studenta któremu ją wystawiamy i samą ocenę. W tym celu należało by stworzyć następującą tabelę.

Przyporządkowujemy zajęciom o kluczu głównym 01 i studentowi o kluczu głównym 01 ocenę pięć. Zaś temu samemu studentowi tylko dla innego przedmiotu o kluczu głównym 02 już ocenę trzy. W tym wypadku mamy złożony klucz główny. Ponieważ ani LessonID ani też StudentID pojedynczo nie spełnia wymagań unikalności klucza głównego, musimy zastosować klucz złożony. W tym wypadku kluczem będzie powiązanie LessonID i StudentID. Pojedynczo żaden z nich nie może spełnić tego zadania, ale w sumie unikalnie określają każdy wiersz.

Sprawdzenie poprawności kluczy

Podstawowe zasady zarządzania i identyfikacji kluczy głównych:

• każda tabela w bazie danych powinna posiadać klucz główny unikalnie identyfikujący wiersz.
• klucz główny nie może być opcjonalny. Czyli nie może posiadać wartości nieokreślonej.
• klucz główny nie może się powtarzać. Może być co najwyżej jedna wartość atrybutu klucza głównego w danej tabeli.

Sprawdzenie poprawności kluczy

Klucze obce są polami, które umożliwiają zachowanie związku pomiędzy identyfikatorem w tabeli, a tabelą, z której wartość ta się wywodzi. Klucze obce umożliwiają zarządzanie integralnością i spójnością danych. Każda asocjacja w bazie powinna być opatrzona kluczem obcym.

W przykładzie ze złożonym kluczem głównym mieliśmy do czynienia z dwoma kolumnami LessonID oraz StudentID. Jeśli zobaczylibyśmy, jak to wygląda w szerszym kontekście, moglibyśmy wyciągnąć bardzo ciekawy wniosek. LessonID i StudentID są kluczami obcymi z tabel Lesson i Student. Ponieważ za pomocą LessonID możemy pobrać informacje o tym, jakiej lekcji dotyczy LessonID 01, zaś z tabeli Student możemy wybrać informacje o osobie, do której StudentID jest przyporządkowane.
To jest właśnie istota kluczy. Nie musimy przechowywać wartości pola, wystarczy nam sam klucz. Za pomocą jego unikalnej wartości możemy bez problemu wyciągnąć interesującą nas wartość.

Podsumowanie

Klucze główne i klucze obce są podstawą teorii relacyjnych baz danych. Każda z tabel powinna mieć kolumnę lub kolumny, na które można nałożyć klucz główny jednoznacznie określający każdy z wierszy. Każda tabela wykorzystująca w jakiś sposób dane z innych tabel powinna być powiązana z nią za pomocą klucza obcego