Którą relację w projekcie bazy danych należy ustalić między tabelami widocznymi na ilustracji zakładając, że każdy klient sklepu internetowego dokona przynajmniej dwóch zamówień?

Poprawnie wskazana relacja 1:n (jeden do wielu), gdzie „1” jest po stronie tabeli Klient, a „n” po stronie tabeli Zamówienie, dokładnie odzwierciedla opisany przypadek biznesowy: jeden klient sklepu internetowego może złożyć wiele zamówień, a każde zamówienie należy do jednego, konkretnego klienta. W praktyce projektowania relacyjnych baz danych oznacza to, że w tabeli Zamówienie umieszczamy klucz obcy (np. kolumnę id_klienta), który wskazuje na klucz główny w tabeli Klient (np. id_klienta jako PRIMARY KEY). To jest klasyczny przykład relacji nadrzędny–podrzędny (parent–child). Z mojego doświadczenia w systemach e‑commerce taka struktura jest standardem, bo pozwala łatwo wykonywać typowe kwerendy: wyszukiwanie wszystkich zamówień danego klienta, liczenie wartości zamówień na klienta, analizę historii zakupów. Dodatkowo założenie, że każdy klient dokona co najmniej dwóch zamówień, wpływa na tzw. krotność minimalną po stronie Zamówienia (min 2), ale nie zmienia samego typu relacji – nadal jest to 1:n. W modelu logicznym i fizycznym realizujemy to przez odpowiednie więzy integralności: klucz główny w tabeli Klient i klucz obcy w tabeli Zamówienie z ON DELETE RESTRICT lub CASCADE (w zależności od polityki biznesowej). Taka relacja ułatwia normalizację danych: dane klienta trzymamy w jednym miejscu, unikamy duplikacji w wielu zamówieniach, a w razie zmiany np. adresu e‑mail aktualizujemy tylko jeden rekord. W dobrze zaprojektowanych schematach (np. zgodnych z 3NF) dokładnie tak modeluje się powiązanie Klient–Zamówienie.