Co to jest relacja jeden-do-wielu w bazie danych? Wyjaśnienie z przykładami

Relacje jeden-do-wielu to jedne z najczęstszych relacji w bazach danych. Jeśli chcesz dowiedzieć się, kiedy i jak korzystać z relacji jeden-do-wielu, ten artykuł jest świetnym punktem wyjścia.

Z pewnością będziesz używać relacji jeden-do-wielu do przechowywania informacji w dowolnej relacyjnej bazie danych, niezależnie od tego, czy projektujesz oprogramowanie na poziomie przedsiębiorstwa, czy po prostu tworzysz prostą bazę danych, aby śledzić kolekcję znaczków wuja.

Krótkie wprowadzenie do modelu relacyjnego

Relacyjne bazy danych są podstawowym elementem każdej nowoczesnej aplikacji transakcyjnej. Model relacyjny składa się z tabel (dane zorganizowane w wiersze i kolumny), które mają co najmniej jeden unikalny klucz identyfikujący każdy wiersz. Każda tabela reprezentuje jednostkę. Pokazuje to następujący przykład, bardzo prosta wersja tabeli reprezentującej zamówienia klientów:

Powyższy diagram, który stworzyłem online za pomocą Vertabelo, ma pojedynczą tabelę. Każdy wiersz w tabeli reprezentuje jedno zamówienie, a każda kolumna (znana również jako atrybut ) reprezentuje każdą pojedynczą informację zawartą w zamówieniu.

Dla tych, którzy nie są jeszcze zaznajomieni z narzędziem do projektowania Vertabelo, artykuł Jakie są symbole używane w diagramach ER? wyjaśnia użyte symbole i konwencje. Możesz również dowiedzieć się więcej o modelach relacyjnych i bazach danych, korzystając z naszego kursu modelowania baz danych.

Czym są relacje i dlaczego ich potrzebujemy?

Jeśli przyjrzymy się dokładniej tabeli użytej w poprzednim przykładzie, zobaczymy, że tak naprawdę nie reprezentuje ona kompletnego zamówienia. Nie zawiera wszystkich informacji, których można by się spodziewać. Zauważysz, że nie zawiera żadnych danych związanych z klientem, który złożył zamówienie, ani nie zawiera żadnych informacji o zamówionych produktach lub usługach.

Co powinniśmy zrobić, aby ukończyć ten projekt, aby przechowywać dane o zamówieniach? Czy powinniśmy dodać informacje o kliencie i produkcie do Zamówienia? stół? Wymagałoby to dodania nowych kolumn (atrybutów) dla nazw klientów, identyfikatorów podatkowych, adresów itp., jak pokazano poniżej:

Jeśli to zrobimy, wkrótce napotkamy problemy. Większość klientów składa więcej niż jedno zamówienie, więc ten system będzie przechowywać informacje o kliencie wiele razy, raz dla każdego zamówienia każdego klienta. Nie wydaje się to sprytnym posunięciem.

Co więcej, co się stanie, gdy klient zmieni numer telefonu? Jeśli ktoś musi zadzwonić do klienta, może znaleźć stary numer na poprzednich zamówieniach – chyba że ktoś zaktualizuje setki (a nawet tysiące) istniejących zamówień o nowe informacje. To samo dotyczy każdej innej zmiany.

Model relacyjny wymaga od nas zdefiniowania każdej encji jako osobnej tabeli i ustanowienia relacji między nimi. Przechowywanie wszystkich informacji w jednej tabeli po prostu nie działa.

Istnieje kilka typów relacji między tabelami, ale prawdopodobnie najczęstszym jest relacja jeden-do-wielu, często zapisywana jako 1:N. Ten rodzaj relacji oznacza, że ​​jeden wiersz w tabeli (zwykle nazywanej tabelą nadrzędną) może mieć relację z wieloma wierszami w innej tabeli (zwykle nazywanej tabelą podrzędną). Oto kilka typowych przykładów relacji jeden-do-wielu:

• Producent samochodów produkuje wiele różnych modeli, ale konkretny model samochodu jest budowany tylko przez jednego producenta samochodów.
• Jeden klient może dokonać kilku zakupów, ale każdy zakup jest dokonywany przez jednego klienta.
• Jedna firma może mieć wiele numerów telefonów, ale numer telefonu należy do jednej firmy.

Istnieją również inne rodzaje relacji między tabelami; jeśli chcesz dowiedzieć się o nich więcej, zapoznaj się z tym artykułem o związkach wiele-do-wielu.

Wracając do naszego początkowego przykładu zamówienia, Customer tabela byłaby tabelą nadrzędną, a Order nałóż dziecko; klient może mieć wiele zamówień, podczas gdy zamówienie może należeć do jednego klienta.

Należy zauważyć, że definicja jeden-do-wielu umożliwia powiązanie wiersza w tabeli nadrzędnej z wieloma wierszami w każdej tabeli podrzędnej, ale tego nie wymaga. Właściwie projekt pozwala klientowi mieć zero zamówień (tj. nowy klient, który nie dokonał jeszcze pierwszego zakupu), jedno zamówienie (stosunkowo nowy klient, który dokonał pojedynczego zakupu) lub wiele zamówień (częsty klient).

Pokazywanie relacji jeden-do-wielu na diagramie ER

Rzućmy okiem na pełniejszy przykład prostego systemu zamawiania klientów przy użyciu diagramu ER (lub relacji encji). (Jeśli chcesz dowiedzieć się więcej o tych diagramach, funkcje Vertabelo:Diagramy logiczne to świetny punkt wyjścia.) Oto model:

To jest bardziej realistyczny projekt. Zauważysz, że na diagramie pojawiły się nowe encje (tabele), które teraz zawierają tabele Customer , Order , Order Detail i Product . Jednak najważniejszą rzeczą, którą zauważysz, jest to, że istnieją teraz związki między stołami .

W modelu bazy danych relacje są reprezentowane przez linie łączące dwie jednostki. Cechy tych relacji są reprezentowane przez różne złącza:

• Gdy istnieje pojedyncza linia pionowa, encja najbliżej tego łącznika ma tylko jeden wiersz, na który ma wpływ relacja. To „jeden” w jeden do wielu.
• Gdy istnieje łącznik wielowierszowy, który wygląda jak kurza łapka, encja najbliżej tego łącznika ma wiele wierszy, na które ma wpływ relacja; to „wiele”.

Patrząc na obraz i znając notację, łatwo jest zrozumieć, że diagram definiuje, że każde Order może mieć wiele Order Details i że każdy Order Detail należy do jednego Order .

Implementacja relacji jeden-do-wielu między tabelami

Aby zdefiniować relację jeden-do-wielu między dwiema tabelami, tabela podrzędna musi odwoływać się do wiersza w tabeli nadrzędnej. Kroki wymagane do jej zdefiniowania to:

1. Dodaj kolumnę do tabeli podrzędnej, która będzie przechowywać wartość identyfikatora podstawowego. (W rzeczywistości większość aparatów baz danych pozwala, aby był to dowolny unikalny klucz z tabeli nadrzędnej, a nie tylko klucz podstawowy). Kolumnę można zdefiniować jako obowiązkową w zależności od potrzeb biznesowych; mimo to zwykle tworzone są kolumny kluczy obcych

Uwaga: Dobrą praktyką jest utrzymywanie nazw kolumn odniesienia takich samych jak w tabeli odniesienia (nadrzędnej). Dzięki temu zrozumienie relacji jest jeszcze prostsze.

2. Dodaj klucz obcy ograniczenie w tabeli podrzędnej. Wskazuje to, że każda wartość przechowywana w tej nowej kolumnie odwołuje się do wiersza w tabeli nadrzędnej.

Ograniczenia klucza obcego to funkcja dostępna w relacyjnej bazie danych, która wymusza to:

1. Gdy dodajesz wiersz do tabeli podrzędnej, wartość kolumny odniesienia musi odpowiadać jednej (i tylko jednej) wartości w tabeli nadrzędnej. (Dlatego należy odwoływać się do kolumny lub zestawu kolumn, które składają się na klucz podstawowy lub klucz unikalny).
2. Jeśli ktoś próbuje usunąć wiersz z tabeli nadrzędnej lub próbuje zmodyfikować wartości klucza unikalnego/podstawowego używanego jako odwołanie i istnieje tabela podrzędna, która odwołuje się do tego wiersza, operacja się nie powiedzie.

Te dwie cechy zapewniają, że baza danych zachowuje swoją integralność. Nie ma możliwości tworzenia zamówień odwołujących się do nieistniejącego klienta ani usuwania klienta, który już ma zamówienia.

Tworzenie klucza obcego

Składnia klucza obcego zwykle zależy od docelowego aparatu bazy danych. Po zdefiniowaniu modelu logicznego można użyć funkcji „Generuj model fizyczny…” na diagramach logicznych Vertabelo, aby przekształcić model (niezależny od bazy danych) w model fizyczny zgodny z dostawcą bazy danych. Vertabelo wygeneruje również wymagany skrypt SQL, który umożliwi tworzenie tabel i relacji w docelowej bazie danych.

Kilka praktycznych przykładów relacji 1:N

Przyjrzyjmy się teraz kilku przykładom rzeczywistych relacji jeden-do-wielu.

Relacja jeden-do-wielu przy użyciu kluczy podstawowych

Jest to prawdopodobnie najczęstszy scenariusz podczas definiowania relacji jeden-do-wielu. Tabela podrzędna używa wartości klucza głównego tabeli nadrzędnej do ustanowienia relacji.

Ten przykład opisuje podstawową usługę przesyłania strumieniowego online. Przyjrzyjmy się, co jest przechowywane w każdej z tabel i jak odnoszą się one do innych tabel w naszym modelu:

1. Każdy ServiceType określa, w jaki sposób konto „zachowuje się” (np. ilu użytkowników może jednocześnie połączyć się z systemem, czy konto ma włączoną funkcję Full HD itp.). Ma jedną relację z innymi bytami:
   • Relacja jeden-do-wielu z Account , co oznacza, że ​​każdy typ usługi może mieć wiele kont tego typu.
2. Każde Account przechowuje informacje o jednym kliencie. Ma dwa bezpośrednie relacje z innymi bytami:
   • Każde konto należy do jednego ServiceType , jak wyjaśniono powyżej.
   • Ta tabela ma związek jeden-do-wielu z Profile tabeli, co oznacza, że ​​więcej niż jeden użytkownik może połączyć się z naszym systemem przy użyciu tego samego konta.
3. Każdy Profile reprezentuje użytkownika w naszym systemie. Ma dwa relacje z innymi bytami:
   • Każdy profil należy do jednego Account . Dzięki temu wszyscy członkowie rodziny (a może grupa przyjaciół) mogą dzielić to samo konto, podczas gdy każdy z nich ma swoje osobiste atrybuty (np. nazwę profilu).
   • Każdy profil ma unikalny Avatar .
4. Każdy Avatar to obraz, który pozwala nam szybko zidentyfikować każdego użytkownika konta. Ma jeden związek z inną istotą:
   • Relacja jeden-do-wielu z Profile , co oznacza, że ​​jeden awatar może być przypisany do profili na różnych kontach.

Relacje jeden-do-wielu z naturalnymi lub zastępczymi unikalnymi kluczami

Użycie zastępczych kluczy podstawowych jest powszechnie akceptowanym sposobem modelowania tabel. (Zastępcze klucze podstawowe są generowane przez bazę danych i nie mają rzeczywistej wartości biznesowej). Ta metoda tworzy klucze, które są prostsze w użyciu i zapewniają pewną elastyczność, gdy wymagane są zmiany.

Zdarzają się jednak sytuacje – m.in. kiedy musimy wejść w interakcję z systemami zewnętrznymi – gdzie użycie klucza wygenerowanego w naszej bazie danych jest złym podejściem. W takich scenariuszach zwykle lepiej jest używać kluczy naturalnych, które są unikalnymi wartościami, które są częścią przechowywanej encji i nie są automatycznie generowane przez naszą bazę danych.

Poniższy przykład przedstawia podstawowy model danych organizacji, która śledzi pojazdy (tj. markę, model, kolor i rok samochodu), ich właścicieli i wszelkie powiązane naruszenia tranzytu. Kiedy to zdefiniowaliśmy, użyliśmy zastępczych kluczy podstawowych, aby ustalić relacje między pojazdami i markami, modelami i właścicielami, ponieważ wszystkie te informacje są obsługiwane wewnętrznie przez nasz system.

W tym systemie, w jaki sposób funkcjonariusz policji w innym mieście może zgłosić nielegalnie zaparkowany samochód przy użyciu naszego klucza podstawowego pojazdu (VehicleID )? Takie informacje nie są oczywiście dostępne w zaparkowanym pojeździe, ale tablica rejestracyjna tam jest. Oznacza to, że najprostszym sposobem otrzymywania i kojarzenia informacji z zewnętrznego źródła (w tym przykładzie z dowolnego departamentu policji w kraju) jest użycie naturalnego unikalnego klucza zamiast zastępczego klucza podstawowego.

Fizyczna implementacja tego logicznego diagramu dla SQL Server jest dostępna tutaj:

Relacje jeden-do-wielu na tym samym stole

Poprzednie przykłady dotyczyły relacji między co najmniej dwiema tabelami, ale istnieją również scenariusze, w których relacja występuje między wierszami tej samej tabeli. Ten rodzaj relacji jeden-do-wielu jest również nazywany relacją hierarchiczną; jest używany w wielu systemach do przedstawiania struktur drzewiastych, tj. schematu organizacyjnego, konta księgi głównej lub produktu i jego części składowych.

Gdy po raz pierwszy będziesz musiał stworzyć tego rodzaju strukturę, będziesz kuszony, aby zdefiniować tabelę dla każdego z poziomów w swojej hierarchii, jak pokazano na poniższym diagramie:

Takie podejście wiąże się z wieloma problemami:

• Wszystkie tabele są prawie identyczne i przechowują identyczne informacje.
• Jeśli Twoja organizacja dodaje nowy poziom, będziesz musiał zmodyfikować model danych i dodać nową tabelę, nowe klucze obce itp.
• Jeśli pracownik otrzyma awans, musisz usunąć go z jednej tabeli i wstawić do innej.

Dlatego najlepszym sposobem modelowania tego rodzaju struktury jest użycie pojedynczej tabeli, która odwołuje się do siebie, jak pokazano na poniższym diagramie:

Tutaj widzimy pojedynczego Employee tabela i kolumna o nazwie EmployeeID_Manager . Ta kolumna odnosi się do innego pracownika w tej samej organizacji, który jest przełożonym/kierownikiem obecnego pracownika.

Dodałem _Manager przyrostek, aby odróżnić identyfikator bieżącego wiersza od identyfikatora kierownika. (Możemy użyć ManagerID zamiast tego wolę zachować oryginalną nazwę kolumny, do której się odwołuje, i w przypadkach, gdy obie znajdują się w tej samej tabeli, dodać przyrostek wyjaśniający rolę, jaką faktycznie pełni).

Zrozumienie relacji hierarchicznych jest bardziej złożone niż inne relacje jeden-do-wielu. Ale jeśli zapomnisz o tabeli, w której przechowywane są wszystkie informacje, i wyobrazisz sobie, że w rzeczywistości istnieją różne tabele, z których każda reprezentuje poziom w hierarchii, nieco łatwiej to zwizualizować. Wyobraź sobie, że tworzysz relację między dwoma podmiotami, a następnie łączysz je w jedną całość.

Co dalej?

Podane przykłady pomogą Ci zidentyfikować różne scenariusze, które wymagają relacji jeden-do-wielu. Możesz rozpocząć projektowanie własnej struktury bazy danych za pomocą Vertabelo Database Modeler, narzędzia internetowego, które pozwala nie tylko generować model logiczny, ale także tworzyć jego fizyczną wersję dla dostawcy bazy danych, którego potrzebujesz.

Teraz twoja kolej – skorzystaj z sekcji komentarzy, aby opowiedzieć nam o swoich przemyśleniach na temat tego artykułu, zadać dodatkowe pytania lub podzielić się swoimi doświadczeniami z modelowaniem baz danych.