Lekcje >> Podstawy MySQL
Polimax

Drukarnia w Warszawie realizująca druk wizytówek, plakatów jak również fotoksiążki, fotoobrazy i fotokalendarze - z wysyłką na terenie całego kraju.

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:

Tabele bazy danych
Rysunek 2_2_2_1. Kilka przykładowych tabel bazy dziennik_elektroniczny pokazujących oceny uczniów

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.

Ćwiczenie 2_2_2_1

Utwórz w zeszycie kilka tabel bazy danych o nazwie SamochodyDostawcze. Pokaż klucze główne i klucze obce. Zaznacz liniami relacje. Każda tabela powinna mieć przynajmniej 3 rekordy. Tabele:

  • Tabela Samochody posiada pola: SamochodID, MarkaID, ProducentID, KolorID, RokProdukcji.
  • Tabela Marki posiada pola: MarkaID, Nazwa, Opis, RokPowstania.
  • Tabela Producenci posiada pola: ProducentID, Nazwa, Siedziba, RoczneObroty.
  • Tabela Kolory posiada pola: KolorID, Nazwa, RGB.