Реализация отношения один к нулю или один в SQL

Допустим, я проектирую базу данных для сценария, в котором существует отношение «один к нулю или один» (1-0..1). Например:

• Существует множество пользователей , и некоторые пользователи также могут быть клиентами .

Таким образом, я создал две соответствующие таблицы, usersи customers, но ...

... Как лучше всего представить и реализовать эту ситуацию на данной платформе SQL? Я рассмотрел два возможных решения:

1. В usersтаблице добавьте customerстолбец, который может быть либо ссылкой FOREIGN KEY, customersлибо NULLзнаком.

2. В customersтаблицу включите userстолбец (заданный с UNIQUEограничением), который указывает на usersтаблицу.

Я уже задавал подобный вопрос на некоторых форумах, но ответ был в основном «все, что вам нужно», «все, что вы считаете удобным». Мне не нравится такой ответ. Вместо этого я хочу серьезную часть теории БД, обоснованный ответ. Где я могу прочитать об отношениях 1-0..1?

Я хочу серьезную часть теории БД

Современная реляционная теория отвергает нулевые значения , что, по-видимому, немедленно лишает законной силы ваш вариант 1. Однако этот соломенный человек может быть устранен путем замены нулевого значения по умолчанию значением по умолчанию, например «фиктивный» клиент, созданный исключительно для явного моделирования «не является клиентом» переписка.

Я думаю, что ваш вариант 2 является наиболее теоретически обоснованным, потому что, в отличие от измененного варианта 1, отношения могут быть в шестой нормальной форме (6NF), являющейся нормальной формой проекции-соединения и достижимой наивысшей нормальной формой.

Я также слышал об эмпирическом эмпирическом правиле, которое гласит, что отношение должно моделировать ЛЮБУЮ сущность ИЛИ отношения между сущностями, но никогда не обе, что кажется разумным для меня. Опять же, это предпочло бы вариант 2. Однако я слышал об этом практическом праве много лет назад, не помню, где и не могу предложить никаких серьезных теоретических основ (кроме 6NF, как упомянуто выше).

Вам дали правильный ответ частично. Реальный ответ исходит из вашей модели данных и того, как она нормализовалась. Ключ, как вы добираетесь до отношений:

• customersТаблица состоит из нескольких полей , рассматриваемых в usersтаблице , которые принадлежат к концепции заказчика и являются недействительными , если пользователь не является также клиентом (подтип пользователя). В этом случае customersтаблица наследует первичный ключ из usersтаблицы. (Возможно несколько подтипов, которые могут или не могут перекрываться.)

• customersТаблица состоит из нескольких полей , связанных с концепцией клиента, но не обязательно понятие пользователя. Клиент - сильная таблица и не зависит от концепции пользователя. (Удаление usersтаблицы не окажет значительного влияния на дизайн таблицы клиентов.) В этом случае таблица клиентов получает свой собственный первичный ключ.

То, что у вас есть, - это особый случай необязательного отношения один ко многим, когда верхняя граница равна 1. Рассмотрим это с обеих сторон: возможно ли, чтобы у одного пользователя было несколько клиентов, или у одного клиента было несколько пользователей? Если это так, вам нужно будет переделать ваши данные.

Добавление user-idвнешнего ключа в customersтаблицу может считаться лучшим выбором, поскольку правильно отображает отношение один ко многим (верхний предел 1) и избегает пустых полей. Для обеспечения верхнего предела индекс внешнего ключа должен быть уникальным. Это произойдет автоматически, если первичным ключом является user-id.

Добавление в таблицу customer-idнеобязательного внешнего ключа usersусиливает верхний предел 1 в отношении, но обращает зависимость.

Рассматривали ли вы немного более сложный, но гибкий подход. Родительской таблицей является «персона» (или «сущность» в зависимости от того, насколько сложным вы хотите быть). Затем таблица клиента и таблица пользователя имеют FK для таблицы персонажа. Таблица person содержит личные данные, а таблицы customer и user содержат только атрибуты, связанные с пользователем или клиентом. Часто адреса (электронная почта и обычная почта), телефонные номера и т. Д. Также представлены в отдельных таблицах с таблицами сопоставления, чтобы разрешить ситуации «многие ко многим». Это относительно распространенная модель, которую вы можете найти на ряде справочных сайтов.