Relacja jeden do wielu (1:N) oznacza, że jeden rekord w tabeli nadrzędnej może być powiązany z wieloma rekordami w tabeli podrzędnej. W typowym przykładzie: jeden klient może złożyć wiele zamówień, ale każde pojedyncze zamówienie należy do dokładnie jednego klienta.
Aby poprawnie odwzorować to w relacyjnej bazie danych, stosuje się parę: klucz główny w tabeli po stronie "jeden" oraz klucz obcy w tabeli po stronie "wiele". Klucz obcy przechowuje wartość identyfikatora rekordu nadrzędnego, na który wskazuje. W praktyce oznacza to, że w tabeli Zamowienia powinno istnieć pole typu np. KlientID, które jest kluczem obcym wskazującym na Klienci.ID.
- Dlaczego "dodać pole klucza obcego do tabeli Zamowienia i połączyć je z ID tabeli Klienci" jest poprawne?
Bo tabela Zamowienia jest po stronie "wiele", więc to ona powinna przechowywać odwołanie do rekordu klienta. Dzięki temu każde zamówienie ma przypisanego właściciela, a system może wymuszać, by nie dało się dodać zamówienia dla nieistniejącego klienta. - Dlaczego "połączyć relacją pola ID z obu tabel" jest niepoprawne?
Łączenie ID z ID sugeruje relację 1:1 (lub sztucznie ograniczałoby 1:N), ponieważ po stronie zamówień identyfikator zamówienia nie jest identyfikatorem klienta. Te pola mają różne znaczenie biznesowe. - Dlaczego "dodać klucz obcy do tabeli Klienci i połączyć go z ID tabeli Zamowienia" jest niepoprawne?
Wtedy w rekordzie klienta trzeba byłoby przechowywać informację o zamówieniu, co nie działa dla wielu zamówień (musiałaby powstać lista/kolumny wielowartościowe) i łamie zasady poprawnego modelu relacyjnego. - Dlaczego "zdefiniować trzecią tabelę z dwoma kluczami obcymi" jest niepoprawne w 1:N?
Tabela pośrednia jest typowym rozwiązaniem dla relacji wiele do wielu (N:M). Dla 1:N jest zbędna i komplikuje model oraz zapytania.
Wskazówka egzaminacyjna: jeśli w treści widzisz "jeden klient – wiele zamówień", automatycznie szukaj klucza obcego w tabeli zamówień (po stronie "wiele").
