Co to jest relacja jeden-do-jednego w modelowaniu danych? Jak zaimplementować tę relację w bazie danych? Przykłady w tym artykule odpowiedzą na te pytania.
Istnieją trzy rodzaje relacji między jednostkami (tabelami) w modelowaniu danych:
- Relacje jeden-do-wielu (oznaczane również jako 1:M).
- Relacje wiele-do-wielu (M:N).
- Relacje jeden-do-jednego (1:1).
Najpopularniejszym typem relacji jest relacja jeden-do-wielu, w której do rekordu w jednej encji może odwoływać się wiele rekordów w innej encji. Innym powszechnym typem jest relacja wiele-do-wielu. Ten typ relacji jest używany tylko w logicznych modelach danych. W fizycznej bazie danych musi być zaimplementowana przy użyciu relacji jeden-do-wielu i tabeli połączeń.
W tym artykule omówimy trzeci typ relacji:relacja jeden-do-jednego . Jest to najrzadziej spotykany typ relacji w modelu danych. Podamy przykłady relacji jeden-do-jednego, pokażemy notację relacji jeden-do-jednego na diagramie ER i omówimy relacje jeden-do-jednego w praktyce.
Przykłady relacji jeden-do-jednego
Po pierwsze, czym jest relacja jeden-do-jednego? Jest to relacja, w której rekord w jednej encji (tabeli) jest powiązany z dokładnie jednym rekordem w innej encji (tabeli).
Zobaczmy kilka rzeczywistych przykładów relacji jeden-do-jednego:
- Kraj - stolica :Każdy kraj ma dokładnie jedną stolicę. Każda stolica jest stolicą dokładnie jednego kraju.
- Osoba – jej odciski palców . Każda osoba ma unikalny zestaw odcisków palców. Każdy zestaw odcisków palców identyfikuje dokładnie jedną osobę.
- E-mail — konto użytkownika . W wielu witrynach jeden adres e-mail jest powiązany z dokładnie jednym kontem użytkownika, a każde konto użytkownika jest identyfikowane przez jego adres e-mail.
- Małżonek - małżonek :W monogamicznym małżeństwie każda osoba ma dokładnie jednego małżonka.
- Profil użytkownika — ustawienia użytkownika . Jeden użytkownik ma jeden zestaw ustawień użytkownika. Jeden zestaw ustawień użytkownika jest powiązany z dokładnie jednym użytkownikiem.
Dla jasności porównajmy te przykłady z relacjami, które nie są jeden do jednego:
- Kraj - miasto: Każde miasto znajduje się dokładnie w jednym kraju, ale większość krajów ma wiele miast.
- Rodzic - dziecko :Każde dziecko ma dwoje rodziców, ale każdy rodzic może mieć wiele dzieci.
- Pracownik - kierownik :Każdy pracownik ma dokładnie jednego bezpośredniego przełożonego lub kierownika, ale każdy kierownik zwykle nadzoruje wielu pracowników.
Oznaczanie relacji jeden-do-jednego na diagramie ER
Relacja jeden-do-jednego na diagramie ER jest oznaczona, podobnie jak wszystkie relacje, linią łączącą te dwie jednostki. Kardynalność „jeden” oznaczona jest pojedynczą linią prostą. (Kardynalność „wiele” jest oznaczona symbolem kurzej łapki).
Relację jeden do jednego między krajem a kapitałem można opisać w następujący sposób:
Prostopadłe linie proste oznaczają „obowiązkowe ”. Ten diagram pokazuje, że stolica musi mieć kraj i kraj musi mieć stolicę.
Inną możliwością jest, aby jedna lub obie strony relacji były opcjonalne . Opcjonalna strona jest oznaczona otwartym kółkiem. Ten diagram mówi, że istnieje relacja jeden do jednego między osobą a jej odciskami palców. Osoba jest obowiązkowa (odciski palców muszą być przypisane do osoby), ale odciski palców są opcjonalne (osoba może nie mieć przypisanych odcisków palców w bazie danych).
Relacje jeden-do-jednego w fizycznej bazie danych
Istnieje kilka sposobów na zaimplementowanie relacji jeden-do-jednego w fizycznej bazie danych.
Klucz podstawowy jako klucz obcy
Jednym ze sposobów zaimplementowania relacji jeden-do-jednego w bazie danych jest użycie tego samego klucza podstawowego w obu tabelach. Wiersze o tej samej wartości w kluczu podstawowym są powiązane. W tym przykładzie Francja to country z id 1 i jego stolica znajduje się w tabeli capital pod id 1.
country
| id | nazwa |
|---|---|
| 1 | Francja |
| 2 | Niemcy |
| 3 | Hiszpania |
capital
Technicznie jeden z kluczy podstawowych musi być oznaczony jako klucz obcy, tak jak w tym modelu danych:
Klucz podstawowy w tabeli capital jest również kluczem obcym, który odwołuje się do kolumny id w tabeli kraj . Od capital.id jest kluczem podstawowym, każda wartość w kolumnie jest unikalna, więc kapitał może odnosić się co najwyżej do jednego kraju. To także musi odwołuje się do kraju – jest to klucz podstawowy, więc nie może być pusty.
Dodatkowy klucz obcy z unikalnym ograniczeniem
Innym sposobem na zaimplementowanie relacji jeden do jednego w bazie danych jest dodanie nowej kolumny i uczynienie jej kluczem obcym.
W tym przykładzie dodajemy kolumnę country_id w tabeli capital . Kapitał z id 1, Madryt, jest powiązany z krajem 3, Hiszpanią.
country
| id | nazwa |
|---|---|
| 1 | Francja |
| 2 | Niemcy |
| 3 | Hiszpania |
capital
| id | nazwa | identyfikator kraju |
|---|---|---|
| 1 | Madryt | 3 |
| 2 | Berlin | 2 |
| 3 | Paryż | 1 |
Technicznie rzecz biorąc, kolumna country_id powinien być kluczem obcym odwołującym się do id kolumna w tabeli country . Ponieważ chcesz, aby każdy kapitał był powiązany dokładnie z jednym krajem, powinieneś utworzyć kolumnę klucza obcego country_id wyjątkowy.
Relacje jeden-do-jednego w praktyce
Kilka relacji jeden-do-jednego trwa
Relacje jeden-do-jednego są najrzadziej występującym typem relacji. Jednym z powodów jest to, że w prawdziwym życiu istnieje bardzo niewiele relacji jeden-do-jednego. Ponadto większość relacji jeden-do-jednego to relacje jeden-do-jednego tylko przez pewien okres czasu. Jeśli Twój model zawiera składnik czasu i rejestruje historię zmian, jak to często bywa, będziesz mieć bardzo niewiele relacji jeden-do-jednego.
Związek monogamiczny może się rozpaść lub jeden z partnerów może umrzeć. Jeśli będziesz modelować rzeczywistość związków monogamicznych (takich jak małżeństwa lub związki cywilne) w czasie, prawdopodobnie będziesz musiał modelować fakt, że trwają one tylko przez pewien okres.
Można by pomyśleć, że osoba i jej odciski palców nigdy się nie zmieniają. Ale co, jeśli osoba straci palec lub palec zostanie mocno spalony? Ich odciski palców mogą się zmienić. To niezbyt częsty scenariusz; jednak w niektórych modelach może być konieczne wzięcie tego pod uwagę.
Nawet coś pozornie tak stabilnego jak kraje i ich stolice zmieniają się w czasie. Na przykład Bonn było stolicą Niemiec Zachodnich (Bundesrepublik Deutschland) po II wojnie światowej, kiedy Berlin był częścią Niemiec Wschodnich. Zmieniło się to po zjednoczeniu Niemiec; stolicą Niemiec (Bundesrepublik Deutschland) jest teraz Berlin. To, czy powinieneś brać to pod uwagę, czy nie, zależy od Twojej rzeczywistości biznesowej i aplikacji, nad którą pracujesz.
Wykonalny scenariusz 1:1:opcjonalne części tabeli
Przychodzi mi do głowy jeden możliwy scenariusz prawdziwej relacji jeden-do-jednego:opcjonalne części tabeli. Wyobraź sobie, że masz stół użytkownik z danymi użytkownika. Tabela zawiera ogólne informacje o użytkownikach, takie jak nazwy użytkowników, adresy e-mail i daty rejestracji. Zawiera również ustawienia użytkownika, takie jak motyw kolorystyczny lub automatyczne logowanie do tej aplikacji. Jednak większość użytkowników nie ma żadnych ustawień użytkownika; używają ustawień domyślnych.
user
| id | nazwa | data rejestracji | motyw | automatyczne logowanie | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | ciemny | prawda |
| 2 | Talitha Yates | [email protected] | 2014-12-14 | ||
| 3 | Jaz Markusa | [email protected] | 2020-12-15 | lekkie | fałsz |
| 4 | Nathalie Hays | [email protected] | 2018-12-18 | ||
| 5 | Kościół Maurycego | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 21.12.2020 |
W tej tabeli jest dużo pustych pól. Możesz podzielić user tabela na dwie tabele:user i user_settings , który zawiera informacje o ustawieniach użytkowników dla tych, którzy je wybrali.
user
| id | nazwa | data rejestracji | motyw | automatyczne logowanie | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | ciemny | prawda |
| 2 | Talitha Yates | [email protected] | 2014-12-14 | ||
| 3 | Jaz Markusa | [email protected] | 2020-12-15 | lekkie | fałsz |
| 4 | Nathalie Hays | [email protected] | 2018-12-18 | ||
| 5 | Kościół Maurycego | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 21.12.2020 |
user_settings
| user_id | motyw | automatyczne logowanie |
|---|---|---|
| 1 | ciemny | prawda |
| 3 | lekkie | fałsz |
Podział danych na dwie tabele sprawia, że zapytania dotyczące tabel są bardziej złożone:musisz połączyć dane z obu tabel. Z drugiej strony główny użytkownik tabela jest prostsza w zarządzaniu.
Dowiedz się więcej o relacjach z bazami danych
Relacja jeden-do-jednego to relacja, w której rekord w jednej tabeli jest skojarzony z dokładnie jednym rekordem w innej tabeli. Ten rodzaj relacji jest rzadki w prawdziwym życiu. Jeśli w modelu danych uwzględnisz czas, wiele relacji jeden-do-jednego stanie się relacjami jeden-do-wielu lub wiele-do-wielu. Najczęstszym scenariuszem korzystania z relacji jeden-do-jednego w bazie danych jest podzielenie jednej tabeli na dwie:jedna z obowiązkowymi kolumnami, druga z opcjonalnymi.
Jeśli podobał Ci się ten artykuł, zapoznaj się z innymi artykułami na temat relacji jeden-do-wielu i wiele-do-wielu na naszym blogu.
Jeśli jesteś studentem biorącym udział w zajęciach z bazami danych, upewnij się, że utworzyłeś bezpłatne konto akademickie w Vertabelo, naszym internetowym narzędziu do rysowania diagramów ER. Vertabelo umożliwia rysowanie logicznych i fizycznych diagramów ER bezpośrednio w przeglądarce. Obsługuje PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift i inne relacyjne bazy danych. Wypróbuj i zobacz, jak łatwo zacząć!
