Aby prawidłowo utworzyć relację typu m…n nienarażoną na redundancję danych, należy
A. połączyć bezpośrednio klucze podstawowe obu tabel.
B. posortować przynajmniej jedną z tabel.
C. połączyć bezpośrednio klucze obce obu tabel.
D. stworzyć tabelę pomocniczą.
Pytanie z egzaminu CKE, czerwiec 2022 (arkusz E.14-SG-22.06).
Relację typu m:n, czyli wiele do wielu, modeluje się przez utworzenie tabeli pomocniczej, często nazywanej tabelą łączącą albo asocjacyjną. To jest dobra praktyka w relacyjnych bazach danych, bo sama relacja m:n nie powinna być zapisywana bezpośrednio między dwiema tabelami. Przykład: jeden uczeń może chodzić na wiele kursów, a jeden kurs może mieć wielu uczniów. Zamiast dopisywać listę kursów w tabeli uczniowie albo listę uczniów w tabeli kursy, tworzy się tabelę np. uczniowie_kursy, w której są klucze obce: id_ucznia i id_kursu. Zwykle te dwie kolumny razem tworzą klucz podstawowy złożony, ewentualnie dodaje się osobne id i unikalność na parze kluczy. Dzięki temu nie powielamy danych, łatwo dodajemy nowe powiązania i możemy dopisać informacje o samej relacji, np. data_zapisu, ocena, status. Moim zdaniem to jeden z tych tematów, który na początku wygląda teoretycznie, ale w praktyce wychodzi przy prawie każdym sensownym projekcie bazy. Takie rozwiązanie jest zgodne z normalizacją danych, szczególnie z zasadą unikania pól wielowartościowych i redundancji, co pomaga utrzymać spójność oraz ułatwia późniejsze zapytania SQL.
W relacyjnych bazach danych nie wystarczy po prostu połączyć tabel byle jak, nawet jeśli na diagramie wygląda to kusząco prosto. Bezpośrednie łączenie kluczy obcych obu tabel nie rozwiązuje relacji wiele do wielu w poprawny sposób. Gdyby próbować trzymać wiele identyfikatorów w jednej kolumnie, np. jako tekst 3,5,8, to łamie się zasady normalizacji i bardzo utrudnia zapytania SQL, filtrowanie, indeksowanie oraz kontrolę spójności referencyjnej. Z kolei dodawanie wielu kolumn typu id_produktu1, id_produktu2, id_produktu3 prowadzi do sztywnej struktury i szybko robi się bałagan. To taki typowy błąd myślowy: skoro jeden klucz obcy działa dla relacji 1:n, to dwa klucze obce bezpośrednio w tabelach powinny zadziałać dla m:n. No właśnie nie do końca. Sortowanie tabel także nie ma żadnego wpływu na model relacyjny. Kolejność rekordów w tabeli nie definiuje relacji ani nie usuwa redundancji, jest tylko sposobem prezentacji wyników zapytania, np. przez ORDER BY. Bezpośrednie łączenie kluczy podstawowych obu tabel zwykle oznacza relację 1:1 albo błędne utożsamienie dwóch różnych encji. Klucz podstawowy identyfikuje rekord w swojej tabeli, a nie listę powiązań z rekordami z innej tabeli. W praktyce poprawny model wymaga osobnej tabeli pośredniej, która przechowuje pary identyfikatorów i pilnuje powiązań przez klucze obce. Z mojego doświadczenia wynika, że jak raz dobrze zrozumie się tabelę pomocniczą, to projektowanie koszyków zamówień, tagów artykułów czy zapisów użytkowników na wydarzenia staje się dużo prostsze.