Pytanie 1
Zdefiniowanie klucza obcego jest niezbędne do utworzenia
A. transakcji.
B. relacji 1..1.
C. relacji 1..n.
D. klucza podstawowego.
W tym pytaniu łatwo się pomylić, bo wszystkie odpowiedzi zahaczają o tematykę baz danych, ale tylko jedna dotyczy faktycznego zastosowania klucza obcego. Klucz obcy w relacyjnej bazie danych służy do wiązania tabel ze sobą i pilnowania integralności referencyjnej. To oznacza, że jego główna rola to powiązanie rekordów: jeden rekord w tabeli nadrzędnej może mieć wiele powiązanych rekordów w tabeli podrzędnej. To jest właśnie relacja 1..n – najczęściej spotykana w normalnych systemach (np. jeden klient, wiele zamówień; jeden autor, wiele książek).
Częsty błąd polega na kojarzeniu klucza obcego z transakcjami. Transakcje w SQL (BEGIN, COMMIT, ROLLBACK) to zupełnie inny mechanizm – służą do zapewnienia atomowości, spójności, izolacji i trwałości operacji (tzw. ACID). Można mieć transakcje w bazie nawet wtedy, gdy w ogóle nie ma żadnych kluczy obcych. Klucz obcy nie jest wymagany do rozpoczęcia czy wykonania transakcji, to po prostu inna warstwa logiki.
Zdarza się też, że ktoś myli klucz obcy z kluczem podstawowym i myśli, że klucz obcy jest potrzebny do jego utworzenia. Jest dokładnie odwrotnie: najpierw definiuje się klucz podstawowy w tabeli nadrzędnej, a dopiero potem w innej tabeli tworzy się klucz obcy, który się do tego klucza podstawowego odwołuje. Klucz podstawowy identyfikuje jednoznacznie rekord w swojej tabeli, klucz obcy tylko wskazuje na ten rekord z innej tabeli.
Jeśli chodzi o relacje 1..1, to one również mogą być realizowane za pomocą kluczy obcych, ale pytanie używa słowa „niezbędne” i w kontekście typowych zastosowań oraz nauczania relacyjnych baz danych klucz obcy kojarzymy głównie z relacją 1..n. Relacja 1..1 jest rzadziej używana i zwykle wymaga dodatkowych ograniczeń (np. klucz obcy, który jest jednocześnie unikalny), więc to już bardziej specyficzny przypadek. Typowym, podręcznikowym i praktycznym zastosowaniem klucza obcego jest właśnie relacja jeden do wielu, i na to pytanie celuje.
Z mojego doświadczenia największy problem polega na tym, że uczniowie mieszają pojęcia: transakcje, klucze, relacje, wszystko wrzucają do jednego worka. Warto je rozdzielić: klucz podstawowy – identyfikacja rekordu, klucz obcy – powiązanie między tabelami (relacje, głównie 1..n), transakcje – kontrola przebiegu operacji w bazie. Jak się to poukłada w głowie, projektowanie schematu bazy danych staje się dużo prostsze i bardziej logiczne.
Częsty błąd polega na kojarzeniu klucza obcego z transakcjami. Transakcje w SQL (BEGIN, COMMIT, ROLLBACK) to zupełnie inny mechanizm – służą do zapewnienia atomowości, spójności, izolacji i trwałości operacji (tzw. ACID). Można mieć transakcje w bazie nawet wtedy, gdy w ogóle nie ma żadnych kluczy obcych. Klucz obcy nie jest wymagany do rozpoczęcia czy wykonania transakcji, to po prostu inna warstwa logiki.
Zdarza się też, że ktoś myli klucz obcy z kluczem podstawowym i myśli, że klucz obcy jest potrzebny do jego utworzenia. Jest dokładnie odwrotnie: najpierw definiuje się klucz podstawowy w tabeli nadrzędnej, a dopiero potem w innej tabeli tworzy się klucz obcy, który się do tego klucza podstawowego odwołuje. Klucz podstawowy identyfikuje jednoznacznie rekord w swojej tabeli, klucz obcy tylko wskazuje na ten rekord z innej tabeli.
Jeśli chodzi o relacje 1..1, to one również mogą być realizowane za pomocą kluczy obcych, ale pytanie używa słowa „niezbędne” i w kontekście typowych zastosowań oraz nauczania relacyjnych baz danych klucz obcy kojarzymy głównie z relacją 1..n. Relacja 1..1 jest rzadziej używana i zwykle wymaga dodatkowych ograniczeń (np. klucz obcy, który jest jednocześnie unikalny), więc to już bardziej specyficzny przypadek. Typowym, podręcznikowym i praktycznym zastosowaniem klucza obcego jest właśnie relacja jeden do wielu, i na to pytanie celuje.
Z mojego doświadczenia największy problem polega na tym, że uczniowie mieszają pojęcia: transakcje, klucze, relacje, wszystko wrzucają do jednego worka. Warto je rozdzielić: klucz podstawowy – identyfikacja rekordu, klucz obcy – powiązanie między tabelami (relacje, głównie 1..n), transakcje – kontrola przebiegu operacji w bazie. Jak się to poukłada w głowie, projektowanie schematu bazy danych staje się dużo prostsze i bardziej logiczne.
