Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Na ilustracji widoczne są dwie tabele. Aby stworzyć relację jeden do wielu, gdzie jeden jest po stronie Klienci, a wiele po stronie Zamowienia, należy

Odpowiedzi
Informacja zwrotna
Relacja jeden do wielu polega na tym że jedna wartość z jednej tabeli może być związana z wieloma wartościami w innej tabeli W tym przypadku jeden klient może mieć wiele zamówień co oznacza że musimy dodać pole klucza obcego w tabeli Zamowienia które będzie odnosiło się do Klientów Klucz obcy w bazach danych to pole które odwołuje się do klucza głównego w innej tabeli Dobre praktyki projektowania baz danych sugerują aby takie połączenia realizować za pomocą kluczy obcych co pozwala na utrzymanie integralności danych oraz łatwiejsze ich przetwarzanie W praktyce oznacza to że w tabeli Zamowienia dodajemy pole które przechowuje ID z tabeli Klienci Standardy branżowe jak SQL ANSI określają sposób tworzenia takich relacji co zapewnia kompatybilność z większością systemów zarządzania bazami danych Dzięki temu możemy łatwo uzyskać wszystkie zamówienia przypisane do konkretnego klienta co jest funkcjonalnością często wymaganą w aplikacjach biznesowych
Dodanie pola klucza obcego do tabeli Klienci i połączenie go z ID tabeli Zamowienia nie jest poprawne ponieważ relacja jeden do wielu wymaga aby klucz obcy znajdował się po stronie tabeli która reprezentuje wiele elementów czyli w tym przypadku Zamowienia Jeśli połączymy relacją pola ID z obu tabel nie uzyskamy semantyki relacji jeden do wielu a jedynie relację równoważności co nie odzwierciedla rzeczywistego scenariusza w którym jeden klient może posiadać wiele zamówień Zdefiniowanie trzeciej tabeli z dwoma kluczami obcymi przypomina projektowanie tabeli asocjacyjnej stosowanej raczej w relacjach wiele do wielu niż jeden do wielu Taka konstrukcja jest bardziej skomplikowana i niepotrzebna w tym konkretnym przypadku wprowadza nadmiarowość oraz dodatkowe obciążenie operacyjne Takie błędne podejścia mogą wynikać z niezrozumienia podstawowych zasad modelowania danych oraz zaniedbania w stosowaniu dobrych praktyk projektowych takich jak normalizacja baz danych i optymalizacja struktury relacyjnej Prowadzą one do nieefektywnego przetwarzania danych i trudności w ich późniejszym zarządzaniu