Implementowanie relacji jeden do zera lub jeden w SQL

Powiedzmy, że projektuję bazę danych dla scenariusza, w którym istnieje relacja jeden do zera lub jeden (1-0..1). Na przykład:

• Istnieje zestaw Użytkowników , a niektórzy Użytkownicy mogą być również Klientami .

W ten sposób utworzyłem dwie odpowiednie tabele usersi customers, ale…

… Jaki jest najlepszy sposób na przedstawienie i wdrożenie tej sytuacji na danej platformie SQL? Rozważyłem dwa możliwe rozwiązania:

1. W userstabeli dodaj customerkolumnę, która może być odniesieniem do klucza OBCEGO customerslub NULLznakiem.

2. W customerstabeli dołącz userkolumnę (ustawioną z UNIQUEograniczeniem), która wskazuje na userstabelę.

Zadałem już podobne pytanie na niektórych forach, ale odpowiedź brzmiała „cokolwiek potrzebujesz”, „cokolwiek uznasz za wygodne”. Nie podoba mi się tego rodzaju odpowiedź. Chcę zamiast tego poważnego fragmentu teorii DB, dobrze uzasadnionej odpowiedzi. Gdzie mogę przeczytać o relacjach 1-0..1?

Chcę poważnego kawałka teorii DB

Współczesna teoria relacyjna odrzuca wartości zerowe , które wydają się natychmiastowo unieważniać twoją opcję 1. Jednak tego słomianego można wyeliminować, zastępując domyślną wartość zerową wartością domyślną, np. Klient „fikcyjny” stworzony wyłącznie w celu jawnego modelowania „nie jest klientem” korespondencja.

Myślę, że twoja opcja 2 jest najbardziej uzasadniona teoretycznie, ponieważ w przeciwieństwie do zmodyfikowanej opcji 1, relacje mogą być w szóstej postaci normalnej (6NF), będąc normalną formą łączenia projekcji i najwyższą możliwą do uzyskania formą normalną.

Słyszałem także o ogólnej zasadzie projektowej, która stwierdza, że ​​relacja powinna modelować KAŻDĄ jednostkę LUB relację między jednostkami, ale nigdy obie, co wydaje mi się rozsądne. Ponownie, sprzyjałoby to opcji 2. Jednak wiele lat temu słyszałem o tej praktycznej zasadzie, nie przypominam sobie, gdzie i nie może zaoferować żadnych poważnych podstaw teoretycznych (innych niż 6NF, jak wspomniano powyżej).

Częściowo otrzymano prawidłową odpowiedź. Prawdziwa odpowiedź pochodzi z modelu danych i tego, jak się znormalizował. Kluczem jest sposób dojścia do relacji:

• customersTabela składa się z wielu dziedzinach uznawanych za usersstołem, które należą do koncepcji klienta, i są nieważne, chyba że użytkownik jest również klientem (typu sub użytkownika). W takim przypadku customerstabela dziedziczy klucz podstawowy z userstabeli. (Możliwe jest wiele podtypów, które mogą się pokrywać lub nie.)

• customersTabela składa się z szeregu dziedzin związanych z koncepcją klienta, ale niekoniecznie pojęcie użytkownika. Klient jest silnym stołem i nie jest zależny od koncepcji użytkownika. (Usunięcie userstabeli nie wpłynęłoby znacząco na projekt tabeli klientów.) W tym przypadku tabela klientów otrzymuje swój własny klucz podstawowy.

To, co masz, to szczególny przypadek opcjonalnej relacji jeden do wielu, w której górna granica wynosi 1. Rozważ to z obu stron: czy jeden użytkownik może mieć wielu klientów, czy jeden klient może mieć wielu użytkowników? Jeśli tak, musisz przebudować swoje dane.

Dodanie user-idklucza obcego do customerstabeli może być uważane za lepszy wybór, ponieważ poprawnie odwzorowuje relację jeden do wielu (górny limit 1) i pozwala uniknąć pola zerowalnego. Aby wymusić górny limit, indeks klucza obcego musi być unikalny. Nastąpi to automatycznie, jeśli kluczem podstawowym jest user-id.

Dodanie customer-idopcjonalnego klucza obcego do userstabeli wymusza górny limit 1 w relacji, ale odwraca zależność.

Czy zastanawiałeś się nad bardziej złożonym, ale elastycznym podejściem? Tabela nadrzędna to „osoba” (lub „byt” w zależności od tego, jak bardzo chcesz być złożony). Następnie tabela klienta i tabela użytkownika mają FK do tabeli osoby. Tabela osób zawiera dane osobowe, a tabele klientów i użytkowników zawierają tylko atrybuty powiązane z użytkownikiem lub klientem. Często adresy (e-mail i ślimak), numery telefonów itp. Są również reprezentowane w osobnych tabelach z tabelami mapowania, aby umożliwić wiele do wielu sytuacji. Jest to stosunkowo popularny model, który można znaleźć w wielu witrynach referencyjnych.