Ответ механически выводится из идеи функциональной зависимости.
Чтобы значение существовало в одном отношении, подразумевается, что значение должно существовать в другом. Когда это верно, будет ограничение внешнего ключа из зависимой таблицы (первой) в независимую таблицу (последнюю).
Другой способ взглянуть на это состоит в том, что отношение «один к одному» на самом деле является частным случаем отношения «один ко многим»; только вместо многих вам разрешено только одно.
в SQL:
CREATE TABLE independent (
id INTEGER PRIMARY KEY
);
CREATE TABLE dependent (
independent_id INTEGER UNIQUE NOT NULL FOREIGN KEY REFERENCES independent(id)
);
Как и один ко многим, «многие» имеют внешний ключ к «одному», но чтобы превратить «многие» в «один», просто сделайте его unique. Обычно удобно выразить все это, сделав столбец внешнего ключа в зависимом отношении первичным ключом для этого отношения:
CREATE TABLE dependent (
independent_id INTEGER PRIMARY KEY FOREIGN KEY REFERENCES independent(id)
);
Правка: я заметил, что ваш заголовок задает вопрос, отличный от вашего основного текста. Вышеизложенное отвечает заголовку.
С точки зрения нормализации базы данных, вероятно, предпочтительнее использовать несколько таблиц, как указано выше, в пользу атрибутов, допускающих значение NULL. Пустые значения - это своего рода нестандартный способ сказать, что значение определенного атрибута является в некотором роде «особым», но на самом деле не требует какой-либо конкретной интерпретации того, что это может означать. Нулевой manager_id, вероятно, означает что-то совершенно отличное от нулевого birthdate, даже если они имеют одинаковую метку.
Добавление таблиц никоим образом не считается чем-то плохим с чисто абстрактной или академической точки зрения; ни добавление атрибутов. Выбор всегда должен основываться на том, какие данные вам действительно нужны для моделирования.
Тем не менее, есть несколько очень реальных практических причин для использования того или другого. Наиболее очевидная причина производительности связана с затратами места на использование того или другого. Когда обычно используется необязательное значение, дополнительное пространство, используемое внешним ключом и соответствующим индексом, не окупается. Точно так же, если необязательное значение используется редко; более компактно поместить эти значения в другое отношение. Наличие атрибута, допускающего значение NULL, заняло бы место в таблице, которое почти никогда не используется.
Выяснение того, что в основном требует фактических данных, и тестирование производительности этих (и, возможно, других) конфигураций, чтобы увидеть, какие из них работают лучше всего.
person
SingleNegationElimination
schedule
12.10.2011
