Czy zdarza się, że korzystanie z relacji 1: 1 bazy danych ma sens?


162

Pewnego dnia myślałem o normalizacji i przyszło mi do głowy, że nie mogę wymyślić czasu, w którym w bazie danych powinna istnieć relacja 1: 1.

  • Name:SSN? Miałbym je w tym samym stole.
  • PersonID:AddressID? Znowu ten sam stół.

Potrafię wymyślić milion przykładów 1: wiele lub wiele: wiele (z odpowiednimi tabelami pośrednimi), ale nigdy 1: 1.

Czy brakuje mi czegoś oczywistego?


Gdy baza danych jest rozdzielona w ten sposób, łatwiej jest podzielić bazę danych na wiele urządzeń fizycznych.
Pacerier,

I pytanie uzupełniające, jeśli ma to sens, jak to zrobić? Rozważane tutaj i tutaj - moje pytanie brzmi: jak wybrać, która z 2 tabel ma ograniczenie klucza obcego? Myślę, że zależy to od tego, do jakiego przypadku użycia próbujesz się zająć ...
The Red Pea,

Odpowiedzi:


161

Relacja 1: 1 zwykle wskazuje, że z jakiegoś powodu podzielono większą jednostkę. Często dzieje się tak ze względu na wydajność w schemacie fizycznym, ale może się to zdarzyć również po stronie logiki, jeśli duża część danych ma być w tym samym czasie „nieznana” (w takim przypadku mamy 1: 0 lub 1: 1, ale nie więcej).

Jako przykład partycji logicznej: masz dane o pracowniku, ale istnieje większy zestaw danych, które należy zebrać wtedy i tylko wtedy, gdy zdecyduje się na ubezpieczenie zdrowotne. Zachowałbym dane demograficzne dotyczące ubezpieczenia zdrowotnego w innej tabeli, aby zarówno ułatwić podział zabezpieczeń, jak i uniknąć przenoszenia tych danych w zapytaniach niezwiązanych z ubezpieczeniem.

Przykładem partycji fizycznej byłyby te same dane przechowywane na wielu serwerach. Mogę przechowywać dane demograficzne dotyczące ubezpieczenia zdrowotnego w innym stanie (na przykład biuro HR), a podstawowa baza danych może łączyć się z nią tylko za pośrednictwem połączonego serwera ... unikając replikowania poufnych danych do innych lokalizacji, ale udostępniając ją (zakładając tutaj rzadkie) zapytania, które tego potrzebują.

Partycjonowanie fizyczne może być przydatne, gdy masz zapytania, które wymagają spójnych podzbiorów większej jednostki.


32
Doskonałym tego przykładem może być tabela zawierająca pliki. Możesz (z oczywistych powodów) chcieć mieć jedną tabelę, która zawiera tylko metadane pliku (nazwę pliku, typ MIME itp.) I inną tabelę, mapowaną 1: 1, która zawiera rzeczywiste dane blob. W niektórych przypadkach zmniejszyłoby to obciążenie związane z przeszukiwaniem / sortowaniem plików.
Kevin Peno

2
Tak. Zależy to od bazy danych (nowoczesne projekty przechowują bloby w systemie plików tylko poprzez użycie odpowiedniego typu) i nawet przy takiej obsłudze trzeba uważać, aby wykluczyć kolumny (w SQL jawne listy kolumn są normalne, ale niektóre ORMy chcą przeciągać cały rekord). Sztuczka polega na znajomości wzorca użycia: jeśli przez większość czasu rzeczywiste dane są ignorowane, użyłbym tabeli blob 1: 1. Jeśli większość dostępów to pobieranie danych, użyłbym natywnego mechanizmu przechowywania.
Godeke

@Ochado Chociaż zgadzam się, że masz wiele naturalnie występujących (niefizycznych) powodów 1: 1, kawaler „jeśli nie masz informacji historycznych” sprawia, że ​​te przypadki, do których prawdopodobnie nie użyłbym relacji 1: 1 egzekwować.
Godeke,

1
@Ochado Myślę, że relacja IS-A jest jednak dobrym przykładem. Staram się unikać prób wymuszania koncepcji obiektowych w moich tabelach (zamiast tego używam ORM jako biblioteki danych), ale widziałem przypadki, w których byłem kuszony. Jednak działanie takich systemów na dużą skalę zabiło te eksperymenty. Jest to jednak prawdopodobnie najlepszy przykład przykładu niezwiązanego z wydajnością.
Godeke,

W rzeczywistości IS-A, a także pasujące scenariusze rezerwacji prawdopodobnie pozostaną 1: 1, nawet jeśli przechowywane są dane historyczne.
Tripartio

125

Jednym z powodów jest wydajność bazy danych. Relacja 1: 1 pozwala podzielić pola, na które wpłynie blokada wiersza / tabeli. Jeśli tabela A ma mnóstwo aktualizacji, a tabela b ma mnóstwo odczytów (lub mnóstwo aktualizacji z innej aplikacji), to blokowanie tabeli A nie wpłynie na to, co dzieje się w tabeli B.

Inni podnoszą dobry punkt widzenia. Bezpieczeństwo może być również dobrym powodem, w zależności od tego, jak aplikacje itp. Wpływają na system. Chciałbym przyjąć inne podejście, ale może to być łatwy sposób na ograniczenie dostępu do niektórych danych. Naprawdę łatwo jest po prostu odmówić dostępu do określonego stołu w mgnieniu oka.

Mój wpis na blogu o tym.


47

Rzadkość. Relacja danych może być technicznie 1: 1, ale odpowiednie wiersze nie muszą istnieć dla każdego wiersza. Więc jeśli masz dwadzieścia milionów wierszy i istnieje pewien zestaw wartości, który istnieje tylko dla 0,5% z nich, oszczędności miejsca są ogromne, jeśli wypchniesz te kolumny do tabeli, która może być rzadko zapełniona.


8
"ale odpowiadające sobie wiersze nie muszą istnieć w każdym wierszu" To nie jest 1: 1. Mówisz o 1: 0,1.

1
Tak. Nie wiem, czy PO dokonuje rozróżnienia.
chaos

2
Cóż, przypuszczam, że tak, ponieważ 1: 0,1 ma wiele zastosowań, w tym twoje, ale 1: 1 ma znacznie mniej. Walczyli ze znalezieniem zastosowań, więc powiedziałbym, że OP dokonał rozróżnienia.

12
Moje robocze założenie było odwrotne, ponieważ wyliczył 1: 1, 1: wiele i wiele: wiele, nie wspominając o 1: 0,1.
chaos

26

Większość wysoko ocenianych odpowiedzi podaje bardzo przydatne powody do strojenia i optymalizacji bazy danych dla relacji 1: 1, ale chcę się skupić wyłącznie na przykładach „na wolności”, w których relacje 1: 1 występują naturalnie.

Proszę zwrócić uwagę na jedną ważną cechę implementacji bazy danych większości z tych przykładów: żadne historyczne informacje nie są zachowywane na temat relacji 1: 1. Oznacza to, że w dowolnym momencie te relacje są 1: 1. Jeśli projektant bazy danych chce rejestrować zmiany w uczestnikach relacji w czasie, wówczas relacje przybierają postać 1: M lub M: M; tracą swoją naturę 1: 1. Po zrozumieniu tego, oto idzie:

  • „Is-A” lub relacje nadtyp / podtyp lub dziedziczenie / klasyfikacja: Ta kategoria ma miejsce, gdy jedna jednostka jest określonym typem innej jednostki. Na przykład może istnieć jednostka pracownika z atrybutami, które dotyczą wszystkich pracowników, a następnie różne jednostki wskazujące określone typy pracowników z atrybutami unikalnymi dla tego typu pracownika, np. Lekarz, księgowy, pilot itp. Ten projekt pozwala uniknąć wielu zer, ponieważ wielu pracowników nie miałoby wyspecjalizowanych atrybutów określonego podtypu. Innymi przykładami w tej kategorii mogą być Produkt jako nadrzędny oraz Podtypy Produktu produkcyjnego i Dostawy do konserwacji; Zwierzę jako nadtyp oraz Pies i kot jako podtypy; itd. Zauważ, że ilekroć próbujesz odwzorować zorientowaną obiektowo hierarchię dziedziczenia na relacyjną bazę danych (na przykład w modelu obiektowo-relacyjnym), jest to rodzaj relacji, która reprezentuje takie scenariusze.

  • Relacje „szef” , takie jak kierownik, przewodniczący, prezes itp., W których jednostka organizacyjna może mieć tylko jednego szefa, a jedna osoba może być szefem tylko jednej jednostki organizacyjnej. Jeśli te zasady mają zastosowanie, to masz relację 1: 1, na przykład jeden kierownik działu, jeden dyrektor generalny firmy itp. Relacje „szefowe” dotyczą nie tylko ludzi. Ten sam rodzaj relacji zachodzi wtedy, gdy jest tylko jeden sklep jako siedziba firmy lub np. Tylko jedno miasto jest stolicą kraju.

  • Niektóre rodzaje alokacji rzadkich zasobów , np. Jednemu pracownikowi można w danym momencie przydzielić tylko jeden samochód służbowy (np. Jedna ciężarówka na kierowcę ciężarówki, jedna taksówka na taksówkarza itp.). Kolega podał mi ostatnio ten przykład.

  • Małżeństwo (przynajmniej w jurysdykcjach, w których poligamia jest nielegalna): jedna osoba może być w związku małżeńskim tylko z jedną osobą naraz. Ten przykład pochodzi z podręcznika, w którym wykorzystano go jako przykład jednoargumentowego związku 1: 1, gdy firma rejestruje małżeństwa między pracownikami.

  • Dopasowane rezerwacje : gdy dokonywana jest unikalna rezerwacja, a następnie realizowana jako dwa oddzielne podmioty. Na przykład system wynajmu samochodów może rejestrować rezerwację w jednej jednostce, a następnie faktyczny wynajem w oddzielnej jednostce. Chociaż taką sytuację można alternatywnie zaprojektować jako jeden podmiot, rozsądne może być rozdzielenie podmiotów, ponieważ nie wszystkie rezerwacje są spełnione i nie wszystkie wypożyczenia wymagają rezerwacji, a obie sytuacje są bardzo częste.

Powtarzam zastrzeżenie, które zrobiłem wcześniej, że większość z nich to relacje 1: 1 tylko wtedy, gdy nie są zapisane żadne informacje historyczne. Tak więc, jeśli pracownik zmieni swoją rolę w organizacji, kierownik przejmuje odpowiedzialność za inny dział, pracownikowi zostaje przydzielony pojazd, albo ktoś owdowiał i ponownie się ożenił, wówczas uczestnicy relacji mogą się zmienić. Jeśli baza danych nie przechowuje żadnej wcześniejszej historii dotyczącej tych relacji 1: 1, pozostają one poprawnymi relacjami 1: 1. Ale jeśli baza danych rejestruje informacje historyczne (takie jak dodawanie dat rozpoczęcia i zakończenia dla każdej relacji), to prawie wszystkie zmieniają się w relacje M: M.

Istnieją dwa godne uwagi wyjątki od notatki historycznej: po pierwsze, niektóre relacje zmieniają się tak rzadko, że informacje historyczne normalnie nie byłyby przechowywane. Na przykład większość relacji IS-A (np. Typ produktu) jest niezmienna; to znaczy, nigdy nie mogą się zmienić. Zatem historyczny punkt rekordu jest dyskusyjny; byłyby one zawsze realizowane jako naturalne relacje 1: 1. Po drugie, relacja rezerwacja-wynajem zapisuje się osobno, ponieważ rezerwacja i wynajem są niezależnymi wydarzeniami, każde z własnymi datami. Ponieważ jednostki mają własne daty, a nie sam związek 1: 1 mający datę początkową, pozostaną one jako relacje 1: 1, nawet jeśli przechowywane są informacje historyczne.


2
Naprawdę podoba mi się, jak trzymałeś się pierwotnego ducha pytań o to, kiedy taka relacja jest poprawna, a nie kiedy jest użyteczna z ziemskich powodów, takich jak fizyczna natura komputerów.
user1852503

21

Twoje pytanie można zinterpretować na kilka sposobów, ze względu na sposób, w jaki je sformułowałeś. Odpowiedzi to pokazują.

Z pewnością mogą istnieć relacje 1: 1 między elementami danych w świecie rzeczywistym. Bez wątpienia. Relacja „jest” to na ogół jeden do jednego. Samochód to pojazd. Jeden samochód to jeden pojazd. Jeden pojazd może być jednym samochodem. Niektóre pojazdy to ciężarówki, w którym to przypadku jeden pojazd nie jest samochodem. Kilka odpowiedzi dotyczy tej interpretacji.

Ale myślę, że tak naprawdę pytasz ... czy kiedy istnieją relacje 1: 1, czy tabele powinny być kiedykolwiek dzielone? Innymi słowy, czy kiedykolwiek powinieneś mieć dwie tabele zawierające dokładnie te same klucze? W praktyce większość z nas analizuje tylko klucze podstawowe, a nie inne klucze kandydujące, ale to pytanie jest nieco inne.

Reguły normalizacji dla 1NF, 2NF i 3NF nigdy nie wymagają dekomponowania (dzielenia) tabeli na dwie tabele z tym samym kluczem podstawowym. Nie zastanawiałem się, czy umieszczenie schematu w BCNF, 4NF lub 5NF może kiedykolwiek spowodować powstanie dwóch tabel z tymi samymi kluczami. Z góry myślę, że zgaduję, że nie.

Istnieje poziom normalizacji zwany 6NF. Reguła normalizacji dla 6NF może zdecydowanie skutkować dwiema tabelami z tym samym kluczem podstawowym. 6NF ma tę przewagę nad 5NF, że można całkowicie uniknąć NULLS. Jest to ważne dla niektórych, ale nie dla wszystkich projektantów baz danych. Nigdy nie zadałem sobie trudu, aby umieścić schemat w 6NF.

W 6NF brakujące dane mogą być reprezentowane przez pominięty wiersz zamiast wiersza z wartością NULL w jakiejś kolumnie.

Istnieją inne powody niż normalizacja podziału tabel. Czasami podzielone tabele dają lepszą wydajność. W przypadku niektórych silników baz danych można uzyskać takie same korzyści w zakresie wydajności, dzieląc tabelę na partycje zamiast jej faktycznego dzielenia. Może to mieć tę zaletę, że logiczny projekt jest łatwy do zrozumienia, jednocześnie dając silnikowi bazy danych narzędzia potrzebne do przyspieszenia działania.


19

Używam ich przede wszystkim z kilku powodów. Jedną z nich jest znacząca różnica w szybkości zmian danych. Niektóre z moich tabel mogą mieć ślady audytu, w których śledzę poprzednie wersje rekordów, jeśli zależy mi tylko na śledzeniu poprzednich wersji 5 z 10 kolumn, dzielenie tych 5 kolumn na osobną tabelę z mechanizmem ścieżki audytu jest bardziej wydajne. Ponadto mogę mieć rekordy (na przykład dotyczące aplikacji księgowej), które są tylko do zapisu. Nie możesz zmienić kwot w dolarach ani konta, na które były przeznaczone, jeśli popełniłeś błąd to musisz zrobić odpowiedni rekord, aby odpisać, skorygować nieprawidłowy rekord, a następnie utworzyć wpis korygujący. Mam ograniczenia w tabeli wymuszające fakt, że nie można ich zaktualizować ani usunąć, ale mogę mieć kilka atrybutów tego obiektu, które są plastyczne, są one przechowywane w osobnej tabeli bez ograniczeń dotyczących modyfikacji. Innym razem robię to w przypadku wniosków dotyczących dokumentacji medycznej. Istnieją dane związane z wizytą, których nie można zmienić po jej wylogowaniu, oraz inne dane dotyczące wizyty, które można zmienić po jej wylogowaniu. W takim przypadku podzielę dane i ustawię wyzwalacz na zablokowanej tabeli, odrzucając aktualizacje zablokowanej tabeli po wylogowaniu, ale zezwalając na aktualizacje danych, których lekarz się nie wylogowuje.

Inny plakat komentował, że 1: 1 nie jest normalizowany, nie zgadzam się z tym w niektórych sytuacjach, zwłaszcza w przypadku podtypów. Powiedzmy, że mam tabelę pracowników, a kluczem podstawowym jest ich numer SSN (to przykład, zachowajmy debatę, czy to dobry klucz, czy nie dla innego wątku). Pracownicy mogą być różnego rodzaju, powiedzmy, że są tymczasowi lub stali, a jeśli są zatrudnieni na stałe, mają do wypełnienia więcej pól, takich jak numer telefonu do biura, który nie powinien być pusty, jeśli typ = „Stały”. W bazie danych trzeciej postaci normalnej kolumna powinna zależeć tylko od klucza, czyli pracownika, ale w rzeczywistości zależy to od pracownika i typu, więc relacja 1: 1 jest całkowicie normalna i pożądana w tym przypadku. Zapobiega również zbyt rzadkim tabelom, jeśli mam 10 kolumn, które normalnie są wypełnione,


1
@ShaneD +1 dla prawdziwego przykładu słowa. Podoba mi się również wyróżnienie „Tylko do odczytu”.
Michael Riley - AKA Gunny

13

Najczęstszym scenariuszem, jaki przychodzi mi do głowy, jest sytuacja, gdy masz BLOB-y. Powiedzmy, że chcesz przechowywać duże obrazy w bazie danych (zazwyczaj nie jest to najlepszy sposób ich przechowywania, ale czasami ograniczenia sprawiają, że jest to wygodniejsze). Zazwyczaj obiekt BLOB powinien znajdować się w oddzielnej tabeli, aby poprawić wyszukiwanie danych innych niż BLOB.


Poważnie? Zazwyczaj nie jest to najlepszy sposób? Największy internetowy dostawca muzyki przechowuje to, ahem, pliki MP3 w bazie danych.

1
@Mark, jest kilka pytań dotyczących najlepszego sposobu przechowywania obrazów, w bazie danych lub poza nią, i wydaje się, że konsensus jest taki, że w większości system plików jest szybszy. Wyobrażam sobie, że jeśli to prawda, to samo byłoby prawdą w przypadku plików MP3.
James McMahon

1
„Zwykle chciałbyś, aby BLOB znajdował się w oddzielnej tabeli” - zwykle BLOB nie są przechowywane w wierszu (jeśli przekraczają określoną długość wiersza specyficzną dla db). Jeśli nie są one wbudowane, to są zwykle przechowywane jako „wskaźnik” do ich fizycznej lokalizacji na stronach DB.
bliski

1
Można spierać się, czy przechowywanie dużych danych (plików) w bazie danych ma sens, niektóre są dla niektórych przeciwne, wszystkie mają ważne powody, ale +1 na przykład 1: 1.
Kevin Peno

To naprawdę powinno być własne pytanie, które chciałbym zobaczyć. Z wkładem inteligentnych ludzi, którzy mierzą czas / prestanda dla różnych dysków twardych / OS / RDBMS. POWINNA istnieć ostateczna odpowiedź na to pytanie, nie powinna być kwestionowana, jeśli jest prawidłowo zmierzona. Czy ktoś już tego nie zrobił?
Stefan,

9

Jeśli chodzi o czystą naukę, tak, są bezużyteczne.

W prawdziwych bazach danych czasami przydatne jest trzymanie rzadko używanego pola w oddzielnej tabeli: aby przyspieszyć zapytania używające tego i tylko tego pola; aby uniknąć blokad itp.


3
@Mark Brady: nie, nie ma, ponieważ są Na2SO4 i KCl. Tworząc bazę danych wszechświata, należy utworzyć t_atom (id INT, protony INT, neutrony INT), t_molecule (id INT, atom_id INT) i wykonać łączenia. To relacja jeden do wielu.
Quassnoi

2
Po drugie, INT może nie wystarczyć, ponieważ we wszechświecie jest 10 ^ 78 atomów. Nawet dwa sklejone ze sobą GUID mogą pomieścić tylko 1/10 atomu. Będziemy potrzebować klucza podstawowego RAW (40) - na wypadek, gdyby nasza baza danych rozrosła się zbyt szybko. Wiesz, ciemna materia czegoś.
Quassnoi

1
Och, więc tylko teoria relacji to czysta nauka. Nie zdawałem sobie sprawy, że chemia nie jest czystą nauką, dopóki nie zbudujemy dla niej bazy danych.

1
@Mark Brady: czy nie mógłbyś po prostu powiedzieć, z czym się nie zgadzasz? Nie rozumiem twojego sarkazmu, naprawdę :)
Quassnoi,

Quassnoi (i Mark Brady) Otrzymujesz głos za LOL, który właśnie mi dałeś.
Pulsehead

8

Zamiast używać widoków do ograniczania dostępu do pól, czasami warto przechowywać ograniczone pola w oddzielnej tabeli, do której mają dostęp tylko niektórzy użytkownicy.


8

Mogę również pomyśleć o sytuacjach, w których masz model OO, w którym używasz dziedziczenia, a drzewo dziedziczenia musi zostać utrwalone w bazie danych.

Na przykład, masz klasę Bird i Fish, które dziedziczą po Animal. W swojej bazie danych możesz mieć tabelę `` Animal '', która zawiera wspólne pola klasy Animal, a tabela Animal ma relację jeden do jednego z tabelą Bird i relację jeden do jednego z tabelą Fish stół.

W takim przypadku nie musisz mieć jednej tabeli Animal, która zawiera wiele kolumn dopuszczających wartość null, aby przechowywać właściwości Bird i Fish, gdzie wszystkie kolumny zawierające dane Fish mają ustawioną wartość NULL, gdy rekord reprezentuje ptaka.

Zamiast tego masz rekord w tabeli Birds, który ma relację jeden do jednego z rekordem w tabeli Animal.


Z tą odpowiedzią związane jest inne pytanie: relacja 1 do 0‑1.
Hibou57,

8

Relacje 1-1 są również konieczne, jeśli masz zbyt dużo informacji. Dla każdego rekordu w tabeli istnieje ograniczenie rozmiaru rekordu. Czasami tabele są dzielone na dwie części (z najczęściej przywoływanymi informacjami w tabeli głównej), aby rozmiar rekordu nie był zbyt duży. Bazy danych są również wydajniejsze w wykonywaniu zapytań, jeśli tabele są wąskie.


6

Jest to również sposób na rozszerzenie tabeli, która jest już produkowana, przy mniejszym (postrzeganym) ryzyku niż „rzeczywista” zmiana bazy danych. Widzenie relacji 1: 1 w starszym systemie jest często dobrym wskaźnikiem, że pola zostały dodane po początkowym projekcie.


Dlaczego dwuznaczne? Czy uważasz, że marka spankin w nowym stole wiąże się z takim samym ryzykiem, jak zmiana istniejącego stołu? Wymień rzeczy, które psują się po dodaniu nowych tabel. Jedyne, co przychodzi mi do głowy, to kod, który działa na metadanych, tj. SELECT * From USER_TABLES loop <coś> pętla końcowa.

1
Nie chodzi o to, że coś się zepsuje, niż o to, że poprawne dodanie tabeli 1: 1 często wymaga więcej pracy niż dodanie dodatkowego pola. Teraz nowy rekord oznacza aktualizację dwóch tabel zamiast tylko jednej. Usuwanie rekordu? Dwa zapytania również. Teraz utrzymujemy więcej kodu zamiast zmieniać go raz.
JT Grimes

@Mark Brady, silnie wpisane zbiory danych mogą być piekłem w zarządzaniu po dodaniu kilku plików do bazy danych. Jeśli adapter tabeli w zestawie danych zawiera wiele zapytań i tak dalej, znacznie łatwiej jest po prostu przeciągnąć nową tabelę, a następnie zrobić.
Stefan,

@Stefan: Nie ma wstawki Cascade.
JT Grimes,

@Boofus, no cóż… czasami musimy użyć klawiatury i trochę zaprogramować za zarobione pieniądze. ;)
Stefan

5

W SQL nie można wymusić relacji 1: 1 między dwiema tabelami, która jest obowiązkowa po obu stronach (chyba że tabele są tylko do odczytu). Z praktycznego punktu widzenia relacja „1: 1” w języku SQL tak naprawdę oznacza 1: 0 | 1.

Brak możliwości obsługi obowiązkowej liczności w ograniczeniach referencyjnych jest jednym z poważnych ograniczeń SQL. Ograniczenia „odroczone” tak naprawdę nie liczą się, ponieważ są po prostu sposobem na powiedzenie, że ograniczenie nie jest egzekwowane przez pewien czas.


4

Jeśli korzystasz z danych z jednym z popularnych ORMów, możesz podzielić tabelę na wiele tabel, aby dopasować ją do hierarchii obiektów.


3
Smutny, smutny powód. Jeśli ORM nie poradzi sobie z rozbieżnością między modelem obiektowym a fizycznym magazynem, to ... po prostu smutne.

Właściwie, jeśli dobrze rozumiem, oznacza to implementację hierarchii klasyfikacyjnych w relacyjnej bazie danych. Jest to całkowicie uzasadniony i naturalny przypadek relacji 1: 1; nie ma w tym nic „smutnego”.
Tripartio

4

Zauważyłem, że kiedy tworzę relację 1: 1, jest to całkowicie z powodów systemowych, a nie relacyjnych.

Na przykład odkryłem, że umieszczenie zarezerwowanych aspektów użytkownika w jednej tabeli i umieszczenie edytowalnych przez użytkownika pól użytkownika w innej tabeli znacznie ułatwia logiczne zapisywanie reguł dotyczących uprawnień do tych pól.

Ale masz rację, w teorii relacje 1: 1 są całkowicie wymyślone i są prawie fenomenem. Jednak logicznie pozwala programom i optymalizacjom na łatwiejsze wyodrębnienie bazy danych.


zjawisko: to każdy fakt lub zdarzenie o znaczeniu naukowym, które może zostać naukowo opisane i / lub wyjaśnione. Nie sądzę, żebyś chciał użyć tego słowa.

1
Chciałem go użyć w konotacji bycia rzadką rzeczą. Zwykle do opisywania wartości odstających używa się zjawiska, mimo że jego definicja określa Twoją potrzebę poprawienia każdego słowa w moim poście.
DevelopingChris

@DevelopingChris Zgadzam się, że 1: 1 to fenomen. Z wyjątkiem teorii szkolnej istnieje bardzo niewiele sytuacji w świecie rzeczywistym.
Michael Riley - AKA Gunny

4

W większości przypadków uważa się, że projekty są 1: 1, dopóki ktoś nie zapyta „cóż, dlaczego nie może to być 1: wiele”? Przedwczesne rozdzielanie pojęć od siebie odbywa się w oczekiwaniu na ten powszechny scenariusz. Osoba i adres nie są tak mocno powiązane. Wiele osób ma wiele adresów. I tak dalej...

Zwykle dwie oddzielne przestrzenie obiektów oznaczają, że jedną lub obie można pomnożyć (x: wiele). Gdyby dwa obiekty były naprawdę, naprawdę 1: 1, nawet filozoficznie, to bardziej byłby to związek. Te dwa „obiekty” są w rzeczywistości częściami jednego całego obiektu.


3

rozszerzone informacje, które są potrzebne tylko w niektórych scenariuszach. w starszych aplikacjach i językach programowania (takich jak RPG), w których programy są kompilowane w tabelach (więc jeśli tabela się zmieni, musisz ponownie skompilować program (y)). Oznaczanie plików może być również przydatne w przypadkach, gdy musisz się martwić o rozmiar tabeli.


2

Najczęściej jest to konstrukcja bardziej fizyczna niż logiczna. Jest powszechnie używany do partycjonowania tabeli w pionie, aby skorzystać z dzielenia we / wy na urządzenia fizyczne lub innych optymalizacji zapytań związanych z segregacją danych, do których dostęp jest rzadszy, lub danych, które muszą być bezpieczniejsze niż pozostałe atrybuty tego samego obiektu (SSN, wynagrodzenie itp.).

Jedyną logiczną kwestią, która nakazuje relację 1-1, jest sytuacja, gdy pewne atrybuty mają zastosowanie tylko do niektórych jednostek. Jednak w większości przypadków istnieje lepszy / bardziej znormalizowany sposób modelowania danych poprzez wyodrębnianie jednostek.


2

Najlepszym powodem, dla którego widzę relację 1: 1, jest podtyp projektu bazy danych SuperType. Na podstawie tego modelu stworzyłem strukturę danych Real Estate MLS. Było pięć różnych źródeł danych; Mieszkaniowe, komercyjne, wielorodzinne, hotele i grunty.

Utworzyłem SuperType o nazwie property, który zawierał dane wspólne dla każdego z pięciu oddzielnych źródeł danych. Pozwoliło to na bardzo szybkie „proste” wyszukiwanie we wszystkich typach danych.

Tworzę pięć oddzielnych podtypów, które przechowują unikalne elementy danych dla każdego z pięciu źródeł danych. Każdy rekord SuperType miał relację 1: 1 z odpowiednim rekordem podtypu.

Jeśli klient chciał szczegółowego wyszukiwania, musiał wybrać typ Super-Sub, na przykład PropertyResidential.


1

Moim zdaniem relacja 1: 1 odwzorowuje dziedziczenie klas na RDBMS. Istnieje tabela A, która zawiera wspólne atrybuty, tj. Status klasy partent. Każdy odziedziczony status klasy jest odwzorowywany w RDBMS z tabelą B w relacji 1: 1 do tabeli A zawierającej wyspecjalizowane atrybuty. Tabela nazwy A zawiera również pole „typ”, które reprezentuje funkcję „rzutowania”

Cześć Mario


1

Możesz utworzyć tabelę relacji jeden do jednego, jeśli istnieje znacząca korzyść dotycząca wydajności. Rzadko używane pola można umieścić w osobnej tabeli.


0

Relacje 1: 1 tak naprawdę nie mają sensu, jeśli interesujesz się normalizacją, ponieważ wszystko, co byłoby 1: 1, byłoby trzymane w tej samej tabeli.

Jednak w prawdziwym świecie często jest inaczej. Możesz podzielić swoje dane, aby dopasować je do interfejsu aplikacji.


Nie zgadzam się z teorią jednego stołu. Są chwile, kiedy relację SuperType z podtypem najlepiej wyrazić za pomocą relacji 1: 1.
Michael Riley - AKA Gunny

1
Właściwie, gdybyś poszedł na skrajną normalizację, miałbyś znacznie więcej relacji 1: 1. Wczesne formy normalizacji zaproponowane przez Date zawierały zasadę, że żadna kolumna nie powinna zezwalać na NULL. Oznaczało to, że jeśli kolumna może mieć wartość NULL dla tabeli, powinna znajdować się we własnej tabeli i dodać wiersz tylko wtedy, gdy została wyceniona. Ta zasada została w większości odrzucona, w tym przez Codda.
Tom H,

0

Prawdopodobnie jeśli masz jakieś obiekty wpisane w bazie danych.

Powiedzmy w tabeli T1, że masz kolumny C1, C2, C3… z relacją jeden do jednego. W porządku, jest w znormalizowanej formie. Powiedzmy teraz, że w tabeli T2 masz kolumny C1, C2, C3,… (nazwy mogą się różnić, ale powiedz, że typy i rola są takie same) z relacją jeden do jednego. Dla T2 jest OK z tych samych powodów, co w przypadku T1.

Jednak w tym przypadku widzę dopasowanie do oddzielnej tabeli T3, zawierającej C1, C2, C3… i relację jeden do jednego od T1 do T3 i od T2 do T3. Jeszcze bardziej widzę dopasowanie, jeśli istnieje inna tabela, z którą już istnieje jeden do wielu C1, C2, C3… powiedzmy od tabeli A do wielu wierszy w tabeli B. Następnie zamiast T3 używasz B i masz relacja jeden do jednego od T1 do B, taka sama od T2 do B i wciąż ta sama do relacji wielokrotnej od A do B.

Uważam, że normalizacja się z tym nie zgadza i może to być idea poza nią: identyfikowanie typów obiektów i przenoszenie obiektów tego samego typu do własnej puli pamięci, przy użyciu relacji jeden do jednego z niektórych tabel i jeden do wielu relacja z innych tabel.


0

Jest to niepotrzebne wielkie ze względów bezpieczeństwa, ale istnieją lepsze sposoby przeprowadzania kontroli bezpieczeństwa. Wyobraź sobie, że tworzysz klucz, który otwiera tylko jedne drzwi. Jeśli kluczem można otworzyć jakiekolwiek inne drzwi, należy zadzwonić na alarm. W istocie możesz mieć „CitizenTable” i „VotingTable”. Obywatel Jeden głos na Kandydata Jeden, który jest przechowywany w Tabeli do głosowania. Jeśli obywatel jeden ponownie pojawi się na stole do głosowania, to powinien być alarm. Radzę, jest to relacja jeden do jednego, ponieważ nie odnosimy się do pola kandydata, mamy na myśli tabelę do głosowania i tabelę obywateli.

Przykład:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Następnie, jeśli zobaczymy tabelę do głosowania jako taką:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Można powiedzieć, że obywatel numer 3 to podpalony kłamca, który oszukał Bern Nie. Tylko przykład.


0

Kiedy masz do czynienia z bazą danych z produktu innej firmy, prawdopodobnie nie chcesz zmieniać ich bazy danych, aby zapobiec ścisłemu powiązaniu. ale możesz mieć dane, które odpowiadają 1: 1 ich danym


-4

Gdziekolwiek były dwie całkowicie niezależne jednostki, które łączyła relacja jeden do jednego. Musi być wiele przykładów:

osoba <-> dentysta (to 1: N, więc to źle!)

osoba <-> lekarz (to 1: N, więc też jest źle!)

osoba <-> współmałżonek (to 1: 0 | 1, więc w większości źle!)

EDYTOWAĆ: Tak, to były bardzo złe przykłady, szczególnie jeśli zawsze szukałem 1: 1, a nie 0 lub 1 po obu stronach. Myślę, że mój mózg źle działał :-)

Więc spróbuję ponownie. Po chwili namysłu okazuje się, że jedynym sposobem, aby mieć dwa oddzielne byty, które muszą (jeśli chodzi o oprogramowanie) być razem przez cały czas, jest istnienie razem w wyższej kategoryzacji. Wtedy, wtedy i tylko wtedy, gdy wpadniesz w niższy rozkład, rzeczy są i powinny być oddzielone, ale na wyższym poziomie nie mogą żyć bez siebie. Kontekst jest więc kluczem.

W przypadku medycznej bazy danych możesz chcieć przechowywać różne informacje o określonych obszarach ciała, zachowując je jako oddzielną całość. W takim przypadku pacjent ma tylko jedną głowę i musi ją mieć, inaczej nie jest pacjentem. (Mają też jedno serce i kilka innych niezbędnych pojedynczych narządów). Jeśli na przykład interesuje Cię śledzenie operacji, każdy region powinien być odrębną jednostką.

W systemie produkcji / inwentaryzacji, jeśli śledzisz montaż pojazdów, z pewnością chcesz obserwować postęp silnika w inny sposób niż karoseria, ale istnieje relacja jeden do jednego. Opieka musi mieć silnik i tylko jeden (inaczej nie byłby to już „samochód”). Silnik należy tylko do jednego samochodu.

W każdym przypadku możesz stworzyć oddzielne jednostki jako jeden duży rekord, ale biorąc pod uwagę poziom dekompozycji, byłoby to błędne. W tych konkretnych kontekstach są one prawdziwie niezależnymi bytami, chociaż na wyższym poziomie mogą się tak nie wydawać.

Paweł.


Dentysta na ma jednego pacjenta? Lekarz ma tylko jednego pacjenta? Osoba do małżonka tylko w 1: 1, jeśli umieścisz jednego małżonka na jednym stole, a drugiego na drugim (miałem powiedzieć, że mężczyźni w jednym i kobiety w drugim. No cóż)

Zaznacz, możesz po prostu stworzyć tabelę „Pary”, w której wiersze zawsze występują w parach. Ale poza tym zgadzam się z twoim, ehm ... rantem. : P
JohannesH

Tak, zgadzam się też z Markiem. :-) (Mogę odrzucić własną głupią odpowiedź?)
Paul W Homer

Tak, przyznanie się do „głupoty” udowadnia, jak mądry jesteś. Prawdziwi tchórze usuwają swoje głupie odpowiedzi ... dobrze, że nie są lekarzami, kasują akta medyczne. Właściwie to dobrze, że my też nie jesteśmy; ponowne uruchomienie byłoby złym leczeniem.

2
Zawsze wyobrażałem sobie, że nawet najmądrzejsza osoba na świecie (kimkolwiek może być w tym czasie) wciąż ma swoje chwile głupoty wymion. To ludzka klątwa :-) Podczas gdy mój komputer ma momenty bliskiej inteligencji.
Paul W Homer
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.