Klucze

Omawiając tabelę podczas poprzednich zajęć, powiedzieliśmy, że musimy wskazać jedną lub więcej kolumn, które w sposób jednoznaczny zidentyfikują każdego ucznia. Kolumna Nazwisko_imie na pewno nie może być kluczem, ponieważ może istnieć kilku uczniów, którzy tak samo się nazywają. Jak więc zidentywikować na przykład Nowaka Euzebiusza? Zapewne istnieje tylko jeden uczeń o tym nazwisku i imieniu, mieszkający na ulicy Lipowej 1/47 w Pułtusku. Tak więc klucz, mamy już zdefiniowany. Czy na pewno?

1. Jeżeli istnieje kilka poprawnych rozwiązań danego problemu, to najlepsze jest rozwiązanie naprostsze - tę zasadę, stosuj zawsze w informatyce (i chyba nie tylko), szczególnie w programowaniu.
2. Czy biorąc pod uwagę powyższą zasadę, możemy przyjąć za klucz tej tabeli aż trzy jej kolumny? Na pewno nie - należy zastanowić się nad prostszym rozwiazaniem.

Powszechnie stosowaną metodą jest umieszczanie w tabeli kolumny identyfikatorów, zawierającej kolejne liczby całkowite. W naszej tabeli mamy więc UczniowieID. Końcówka ID informuje, że jest to kolumna z numerami identyfikacyjnymi. Co prawda, numery te są sztuczne i nie wynikają z danych ucznia, ale taka metoda jest bardzo korzystna ponieważ:

1. Upraszcza identyfikację poszczególnych rekordów.
2. Sztucznie nadawany numer gwarantuje unikalność poszczególnych rekordów, w przypadku danych realnych, zawsze istnieje ryzyko powtórzenia wartości.

Zwróć uwagę, że w codziennym życiu, często Twojej osobie przypisany jest jakiś unikatowy numer. Na przykład każdy ma swój numer PESEL, w szkolnej księdze uczniów również masz swój numer, jeżeli posiadasz konto w banku, to ma ono swój numer, itp., itd.

Pole tabeli, identyfikujące poszczególne rekordy nazywamy kluczem podstawowym.

Teraz wykonamy następny krok w poznaniu podstaw budowy i działania relacyjnych baz danych. Bazy danych składają się z wielu tabel. W naszym przykładzie, jest wiele danych dotyczących ucznia, choćby dane zapisywane w dziennikach lekcyjnych tradycyjnych lub elektronicznych. Weźmy dla przykładu ocenianie uczniów. Poniższe tabele mogłyby być fragmentem bazy danych o nazwie DziennikElektroniczny:

Chcemy analizować oceny w szkole, więc przyjrzyjmy się tabeli Oceny. Klucz podstawowy (główny) tej tabeli, to OcenaID. Zwróć uwagę na cztery następne kolumny - nie posiadają wartości tylko klucze innych tabel. Na przykład w kolumnie UczenID tabeli Oceny znajdują się klucze główne tabeli Uczniowie, które w tabeli Oceny uzyskują status kluczy obcych. Przeanalizujmy całą tabelę Oceny w powiązaniu z pozostałymy tabelami, albo mówiąc inaczej w relacji do innych tabel:

• Kolumna OcenaID jest kluczem podstawowym tabeli Oceny.
• Kolumna UczenID jest kluczem obcym tabeli Oceny i kluczem podstawowym tabeli Uczniowie.
• Kolumna PrzedmiotID jest kluczem obcym tabeli Oceny i kluczem podstawowym tabeli Przedmioty.
• Kolumna NauczycielID jest kluczem obcym tabeli Oceny i kluczem podstawowym tabeli Nauczyciele.
• Kolumna OcenaDefID jest kluczem obcym tabeli Oceny i kluczem podstawowym tabeli OcenyDefinicje.

Jak więc należy odczytywać wartości w tabeli Oceny? To proste, weźmy dla przykładu drugi rekord tabeli:

• Widzimy, że UczenID=1, a więc z tabeli Uczniowie, która posiada ten klucz jako podstawowy, bierzemy ucznia o tym numerze - będzie to Kowalski Zenon (tę relację zanaczono w kolorze czerwonym).
• Widzimy, że PrzedmiotID=2, a więc z tabeli Przedmioty, która posiada ten klucz jako podstawowy, bierzemy przedmiot o tym numerze - będzie to język polski (tę relację zanaczono w kolorze czarnym).
• Widzimy, że NauczycielID=3, a więc z tabeli Nauczyciele, która posiada ten klucz jako podstawowy, bierzemy nauczyciela o tym numerze - będzie to Kargul Jadwiga (tę relację zanaczono w kolorze zielonym).
• Widzimy, że OcenaDefID=5, a więc z tabeli OcenyDefinicje, która posiada ten klucz jako podstawowy, bierzemy ocenę o tym numerze - będzie to niedostateczny (tę relację zanaczono w kolorze niebieskim).

Podsumujmy omówiony przykład zastanawiając się jakie korzyści płyną z takiego releacyjnego układu danych:

• Tabela Oceny jest bardzo prosta, mamy, oprócz dwóch ostatnich kolumn tylko liczy całkowite - przyspiesza to wyszukiwanie danych.
• Co by było, gdyby w tabeli Oceny znajdowały się pełne dane - w tym np. nazwiska uczniów? Załóżmy, że po pewnym czasie administrator bazy zorientował się, że błędnie wpisał jedno z nazwisk. I co teraz? Jeżeli mamy układ relacji, tak jak w przykładzie, to wystarczy poprawić to nazwisko w tabeli Uczniowie. W przeciwnym razie należałoby poprawiać to nazwisko we szystkich tabelach w których ono występuje. Jak wiadomo człowiek jest istotą omylną - co będzie jeżeli w któymś z "poprawień", administrator się pomyli? Doprowadzi to do sprzeczności w danych i w konsekwencji do błędów podczas np. wyszukiwania danych.
• Z punktu poprzedniego wynika oczywisty wniosek - w poprawnie zaprojektowanej bazie danych, dane występują tylko raz, nie powtarzają się w różnych tabelach.
• Kolejny wniosek wynikający z poprzedniego brzmi - podstawą projektowania bazy danych jest poprawne zdefiniowanie tabel a w nich kluczy.
• Umieszczając klucz główny jednej tabeli w innej tabeli jako klucz obcy, definiujemy tym samym relację między tymi tabelami.