Отношения сущностей Несколько 1: 1

Question

У меня есть приложение, в котором у меня есть универсальный объект (таблица) с именем Hull. Каждый корпус в таблице уникален.

У меня есть еще один объект, который имеет три корпуса, но это, в частности, Port_Hull, Center_Hull и Starboard_Hull.

Вместо того, чтобы создавать отношения «один ко многим», я пытался создать отношение «один к одному» для каждого, но это приводит к многочисленным ошибкам, если я не сделаю отношение «Халл» к «Судну» один ко многим (а это не так) , Любая идея, как мне поступить, или я должен отказаться от концепции и заставить судно строить отношения один ко многим и иметь дело со списками, которые всегда имеют три записи?

p.s. Используя уникальные идентификаторы, многие пользователи могут добавлять записи, когда они отключены.

Стол Халл

• Уникальный идентификатор HullID (первичный ключ)
• плюс куча полей данных корпуса

Таблица сосуда

• Уникальный идентификатор VesselID (первичный ключ)
• MainHullID уникальный идентификатор (используется как ключ и не ключ)
• уникальный идентификатор PortHullID
• уникальный идентификатор StarboardHullID
• плюс куча полей данных судна

Answer 1

Вы можете решить это 1: 1 двумя различными способами:

1. Добавьте уникальное ограничение для каждого поля invidivual Hull в Vessel, т.е. MainHull, PortHull, StarboardHull. Это гарантирует, что Корпус может использоваться только одним Судном.
2. Снимите поля Корпуса с судна и добавьте новое поле в Корпус - Сосуд. Это тогда явно называет судно, которому принадлежит этот корпус. Казалось бы, имеет смысл добавить HullType в Hull, чтобы вы знали, что это за оболочка. Уникальное ограничение на HullType + Vessel гарантирует, что каждое судно получит не более одного корпуса каждого типа (но, к сожалению, может иметь 0 данного типа.)

Я бы пошел за первым. поскольку кажется более естественным выбрать судно, а затем найти связанные с ним корпуса, а также убедиться, что у каждого судна есть 3 требуемых корпуса (с учетом ненулевого ограничения на MainHull, PortHull, StarboardHull.)

РЕДАКТИРОВАТЬ: Видя ваш комментарий, и учитывая, что судам не нужно 3 корпуса, то второе решение также стоит рассмотреть. Если вам нужно добавить дополнительные типы оболочки, вы делаете это без изменения схемы, поскольку тип оболочки не выводится из поля, на которое он ссылается, а явно указывается в предлагаемом поле 'HullType'.

Answer 2

Вы спрашиваете, возможно ли это создать или нужно ли это создавать?

Во-первых, это возможно:

Create Table Vessel
(
    VesselId uniqueidentifier not null primary key
    , MainHullId uniqueidentifier not null
    , PortHullId uniqueidentifier not null
    , StarboardHullId uniqueidentifier not null
    , ...
    , Constraint FK_Vessel_Hull_Main
        Foreign Key ( MainHullId )
        References Hull( HullId )
    , Constraint FK_Vessel_Hull_Port
        Foreign Key ( PortHullId )
        References Hull( HullId )
    , Constraint FK_Vessel_Hull_Startboard
        Foreign Key ( StarboardHullId )
        References Hull( HullId )
    , Constraint UC_Vessal_MainHullId Unique ( MainHullId )
    , Constraint UC_Vessal_PortHullId Unique ( PortHullId )
    , Constraint UC_Vessal_StarboardHullId Unique ( StarboardHullId )
)

Отношение 1: 1 создается, когда у вас есть дочерняя таблица с внешним ключом к родительской таблице, и внешний ключ должен быть уникальным.

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