Relacje — klucz główny i obcy

🎯 Po co Ci to?

Poznałeś chorobę (12.1); czas na lekarstwo, i to genialne w swej prostocie: rozbij dane na osobne tabele, po jednej na każdy rodzaj rzeczy, i połącz je odnośnikami. Klienci w jednej tabeli, książki w drugiej, wypożyczenia w trzeciej — a każdy fakt zapisany dokładnie raz. To pomysł, za który Edgar Codd dostał w 1981 roku Nagrodę Turinga (informatyczny odpowiednik Nobla), i który stoi pod niemal każdą bazą świata od pół wieku. Dwa proste pojęcia — klucz główny i klucz obcy — wystarczą, by zrozumieć jego istotę. To najważniejsza jednostka działu.

✅ Czego się nauczysz

Po tej jednostce potrafisz:

  • rozbić dane z jednej wielkiej tabeli na powiązane tabele (bez powtórzeń);
  • wskazać klucz główny (tożsamość rekordu) i klucz obcy (powiązanie z inną tabelą);
  • odczytać relacje między tabelami i zrozumieć, jak eliminują problemy z 12.1.

🔁 Przypomnij sobie

Z 12.1: powtórzenia i sprzeczności jednej tabeli; z 9.5: graf — tabele połączone kluczami tworzą sieć relacji.

📘 Wyjaśnienie

Rozbicie. Chore dane wypożyczalni (12.1) leczymy, dzieląc je na trzy tabele — po jednej na każdy rodzaj rzeczy:

KLIENCI                          KSIĄŻKI
id  nazwisko    telefon          id  tytuł            autor
1   Kowalska    501-234-567      1   Lalka            Prus
2   Nowak       600-111-222      2   Ferdydurke       Gombrowicz
                                 3   Zbrodnia i kara  Dostojewski

WYPOŻYCZENIA
id  klient_id  ksiazka_id  data
1   1          1           2026-01-10
2   1          2           2026-02-03
3   2          1           2026-03-01

Popatrz, co się stało: telefon Kowalskiej zapisany raz (w KLIENCI); autor „Lalki" zapisany raz (w KSIĄŻKI); tabela WYPOŻYCZENIA nie powtarza już danych — trzyma tylko odnośniki (numery) do klienta i książki. Zmiana telefonu Kowalskiej? Jedna poprawka w jednym miejscu. Sprzeczność „Prus"/„Prus B."? Niemożliwa — autor jest w jednym rekordzie. Choroba z 12.1 wyleczona u źródła.

📐 DEFINICJA — klucz główny i klucz obcy: klucz główny to pole jednoznacznie identyfikujące rekord w tabeli (np. id — unikatowy, niepusty). Klucz obcy to pole wskazujące na klucz główny rekordu w innej tabeli — tworzy powiązanie (relację).

Po ludzku: klucz główny to numer PESEL rekordu (jego tożsamość); klucz obcy to „ten wpis dotyczy klienta numer 1". Czym NIE jest: klucz główny to nie „pierwsza kolumna". To pole (lub zestaw pól) gwarantujące unikatowość — dwa rekordy nie mogą mieć tego samego klucza głównego.

W WYPOŻYCZENIA klient_id i ksiazka_id to klucze obce: klient_id = 1 znaczy „ten rekord dotyczy klienta o kluczu głównym 1 w tabeli KLIENCI" — czyli Kowalskiej. Baza wie, jak połączyć: wypożyczenie nr 1 to Kowalska (klient_id=1) wypożyczyła Lalkę (ksiazka_id=1) dziesiątego stycznia. Dane rozbite na trzy tabele, ale złączalne w każdej chwili po kluczach.

KLIENCIidnazwisko1Kowalska2NowakKSIĄŻKIidtytuł1Lalka2FerdydurkeWYPOŻYCZENIAidklient_idksiazka_iddata11101-1021202-0332103-01klient_id do KLIENCI.idksiazka_id do KSIĄŻKI.idkażdy fakt zapisany raz; klucze łączą tabele
Trzy tabele wypożyczalni: KLIENCI (klucz główny id), KSIĄŻKI (klucz główny id) i WYPOŻYCZENIA z kluczami obcymi klient_id i ksiazka_id wskazującymi strzałkami na klucze główne dwóch pozostałych tabel; każdy fakt zapisany raz. · rys. własny

Rodzaje relacji. Powiązania mają „liczebność": jeden klient ma wiele wypożyczeń (relacja jeden-do-wielu — najczęstsza); jedno wypożyczenie dotyczy jednego klienta i jednej książki. Relacja wiele-do-wielu (uczeń chodzi na wiele kółek, kółko ma wielu uczniów) rozwiązuje się przez tabelę pośrednią (jak WYPOŻYCZENIA łączy klientów z książkami — to też wiele-do-wielu: klient wypożyczał wiele książek, książkę wypożyczało wielu klientów). Ten wzorzec — tabela pośrednia dla relacji wiele-do-wielu — jest w projektowaniu baz wszechobecny (spotkałeś go w tej książce: grupa_uczen, lekcja_jednostka w opisach systemu... a teraz wiesz, czemu tak wyglądają).

💭 Pomyśl: Dlaczego w tabeli WYPOŻYCZENIA lepiej trzymać klient_id = 1 niż wprost nazwisko = "Kowalska"? Co daje odnośnik przez klucz?

Sprawdź odpowiedź

Trzy zyski. (1) Jednoznaczność: dwie różne Kowalskie mają różne id, a to samo nazwisko by je zlało. (2) Odporność na zmiany: Kowalska wyjdzie za mąż i zmieni nazwisko — poprawiasz JEDEN rekord w KLIENCI, a wszystkie jej wypożyczenia (wskazujące przez id) automatycznie „widzą" nowe nazwisko; gdyby trzymały tekst „Kowalska", trzeba by je wszystkie poprawiać (powrót choroby z 12.1!). (3) Oszczędność: liczba 1 waży mniej niż powtarzany tekst. Klucz obcy wskazuje na tożsamość, nie na kopię danych — i dlatego zmiana danych nie rozjeżdża powiązań. To sedno mocy modelu relacyjnego.

🐞 Znajdź błąd

Projektant dał w tabeli KSIĄŻKI klucz główny = tytuł („przecież tytuł jednoznacznie wskazuje książkę"). Gdzie i kiedy to wybuchnie?

Sprawdź odpowiedź

Tytuł nie jest unikatowy: dwie różne książki mogą mieć ten sam tytuł („Zemsta" Fredry i czyjś kryminał „Zemsta"), a biblioteka może mieć dwa egzemplarze tej samej książki — oba „Lalka", a to fizycznie różne obiekty do wypożyczenia! Klucz główny musi gwarantować unikatowość, a tytuł jej nie gwarantuje — pierwszy duplikat tytułu wysadzi bazę (albo zablokuje dodanie drugiego egzemplarza). Dlatego kluczem głównym robi się zwykle sztuczny, gwarantowanie unikatowy id (liczba nadawana automatycznie), a nie „naturalne" pole jak tytuł czy nazwisko — te bywają zwodniczo niejednoznaczne. To klasyczny błąd początkujących projektantów baz.

🌍 Powiązania

Model relacyjny to jeden z najbardziej udanych pomysłów w historii informatyki — pół wieku dominacji, biliony rekordów, fundament bankowości, administracji, handlu i nauki. Struktura, którą właśnie poznałeś, stoi pod systemem, z którego korzystasz czytając te słowa (uczniowie, lekcje, oceny — osobne tabele połączone kluczami). Umiejętność „widzenia tabel" w danych — rozpoznania, co jest osobnym rodzajem rzeczy, a co powiązaniem — to fundament projektowania systemów informatycznych, którą docenisz w każdym większym projekcie.

🛠️ Teraz Ty

Weź „chorą" tabelę z 12.1 (własną z 🛠️ tamtej jednostki) i rozbij ją na relacyjne tabele: wypisz, jakie są rodzaje rzeczy (to osobne tabele), nadaj każdej klucz główny id, a powiązania wyraź kluczami obcymi. Narysuj strzałki klucz obcy → klucz główny. Sprawdź: czy każdy fakt jest teraz zapisany dokładnie raz? Czy zmiana dowolnej danej to jedna poprawka?

📐 Definicje tej lekcji

  • Klucz główny — pole jednoznacznie identyfikujące rekord (unikatowe, niepuste); zwykle sztuczny id.
  • Klucz obcy — pole wskazujące na klucz główny rekordu w innej tabeli; tworzy relację.
  • Relacja wiele-do-wielu — rozwiązywana tabelą pośrednią z dwoma kluczami obcymi.

📌 Najważniejsze w pigułce

  • Lekarstwo na chorobę z 12.1: rozbij na tabele wg rodzajów rzeczy, każdy fakt zapisz raz.
  • Klucz główny = tożsamość rekordu (unikatowa!); klucz obcy = odnośnik do niej z innej tabeli.
  • Klucz obcy wskazuje tożsamość, nie kopię — dlatego zmiana danych nie rozjeżdża powiązań; wiele-do-wielu przez tabelę pośrednią.

🎒 Zadania

  1. Sklep internetowy: klienci, produkty, zamówienia (klient zamawia wiele produktów, produkt bywa w wielu zamówieniach). Zaprojektuj tabele z kluczami. Ile tabel i gdzie klucze obce?
Wskazówka i odpowiedź

Cztery tabele: KLIENCI (id), PRODUKTY (id), ZAMÓWIENIA (id, klient_id→KLIENCI, data), oraz tabela pośrednia POZYCJE_ZAMÓWIENIA (zamowienie_id→ZAMÓWIENIA, produkt_id→PRODUKTY, ilość) — bo jedno zamówienie ma wiele produktów, a produkt jest w wielu zamówieniach (wiele-do-wielu!). Klucze obce: klient_id w ZAMÓWIENIA, oraz dwa w tabeli pośredniej. To kanoniczny schemat sklepu — rozpoznasz go w każdym systemie e-commerce.

  1. W tabeli WYPOŻYCZENIA jest klient_id = 7, ale w KLIENCI nie ma klienta o id 7. Jak nazywa się ten problem i czemu dobra baza go nie dopuści?
Wskazówka i odpowiedź

To naruszenie integralności referencyjnej: klucz obcy wskazuje na nieistniejący rekord („wypożyczenie widmo" bez klienta). Dobra baza tego pilnuje — przy próbie wstawienia wypożyczenia z klient_id=7, którego nie ma, odmówi (albo przy usuwaniu klienta zablokuje/skaskaduje jego wypożyczenia). To jedna z obietnic bazy, której arkusz nigdy nie da: nie pozwoli na stan sprzeczny (rozwiniemy to w 12.5). Klucz obcy to nie tylko odnośnik — to pilnowana obietnica, że odnośnik prowadzi do czegoś realnego.

  1. Wyjaśnij, czemu sztuczny klucz id (liczba nadawana automatycznie) jest zwykle lepszym kluczem głównym niż „naturalne" pole (nazwisko, tytuł, PESEL). Podaj po jednym powodzie za każdym z trzech naturalnych kandydatów.
Wskazówka i odpowiedź

Nazwisko: nie jest unikatowe (wielu Kowalskich) i bywa zmieniane. Tytuł: nie jest unikatowy (różne książki, wiele egzemplarzy). PESEL: unikatowy i stały, ale to dane osobowe wrażliwe — używanie go jako klucza rozsiewa go po wszystkich powiązanych tabelach (RODO!), a poza tym cudzoziemcy go nie mają, więc nie każdy rekord da się utworzyć. Sztuczny id jest gwarantowanie unikatowy, niezmienny, neutralny i nie niesie znaczenia, które mogłoby się zdezaktualizować. Dlatego „naturalne klucze" to pułapka na początkujących — kuszą sensownością, a zdradzają w szczegółach.

🔍 Sprawdź, czy umiesz

  • Rozbić płaską tabelę na relacyjne tabele wg rodzajów rzeczy.
  • Wskazać klucz główny i klucz obcy oraz odczytać relację między tabelami.
  • Uzasadnić sztuczny klucz id i rozpoznać relację wiele-do-wielu.

Ucz się tej jednostki z asystentem