База данных Super-type / Sub-type Design [дубликат]

Существует не только один способ реализовать какую-либо конкретную модель данных. Часто происходит преобразование, которое происходит при переходе от логической модели к физической модели.

Стандартный SQL не имеет чистого способа принудительного ограничения ограничений подтипа.

Если ваша цель - обеспечить максимально возможное использование правил вашей модели с помощью схемы, тогда стандартным подходом к реализации вашей модели является использование таблицы для супертипа и по одному для каждого из подтипов. Это гарантирует, что для каждого объекта используются только применимые атрибуты.

Существует более или менее стандартный трюк SQL для принудительного ограничения непересекающихся ограничений. Это отводит некоторых людей, потому что это нарушает правила нормализации неважно. Тем не менее, некоторые люди находят технику эстетически оскорбительной, поскольку существует техническое нарушение 2NF.

Этот метод включает добавление атрибута секционирования к супертипу и включение этого атрибута секционирования в каждый подтип , добавив его в первичный ключ подтипа. Наряду с контрольными ограничениями, которые налагают конкретные значения атрибутов секционирования, это гарантирует, что каждый объект может иметь не более одного подтипа. Этот метод подробно описан во многих местах, например в этом блоге .

Обычно, когда вы выполняете отношения типа Super-type / Sub-type в своем проекте базы данных, вам нужно создать отдельную таблицу для вашего типа общего типа (супертип) и отдельных таблиц для вашей специализированной версии / s (Sub -Type) несвязанный или нет. В вашем случае вам нужно будет создать таблицу для VEHICLE и первичного ключа и некоторых атрибутов, которые являются общими или разделяются всеми подтипами. Затем вам нужно будет создать отдельные таблицы для 2WD и 4WD вместе с атрибутами, специфичными только для этих таблиц. Например,

[/g0]

, тогда вы можете запросить эти таблицы с помощью SQL-соединений

Другие ответчики сказали, плюс следующее, которое входит в первичные ключи для таблиц подкласса.

Ваше дело выглядит как экземпляр шаблона проектирования, известного как «Специализация обобщения», или Gen-Spec для краткости , Вопрос о том, как моделировать ген-спецификацию с использованием таблиц базы данных, появляется все время в SO.

Если вы моделировали ген-spec в OOPL, например Java, вы использовали бы средство наследования подкласса для принятия заботиться о деталях для вас. Вы бы просто определили класс, чтобы позаботиться об обобщенных объектах, а затем определите коллекцию подклассов, по одному для каждого типа специализированного объекта. Каждый подкласс расширяет обобщенный класс. Это легко и просто.

К сожалению, реляционная модель данных не имеет встроенного наследования подкласса, и, как мне известно, системы баз данных SQL не предоставляют никаких подобных средств. Но тебе не повезло. Вы можете проектировать свои таблицы для моделирования gen-spec таким образом, который параллелен кластерной структуре ООП. Затем вам необходимо организовать реализацию собственного механизма наследования при добавлении новых элементов в обобщенный класс. Подробности следуют.

Структура класса довольно проста: одна таблица для класса gen и одна таблица для каждого подкласса spec. Вот хорошая иллюстрация, с сайта Мартина Фаулера. Наследование классов. Обратите внимание, что на этой диаграмме Cricketer является как подклассом, так и суперклассом. Вы должны выбрать, какие атрибуты входят в таблицы. На диаграмме показан один пример атрибута в каждой таблице.

Трудная деталь заключается в том, как вы определяете первичные ключи для этих таблиц. Таблица gen class получает первичный ключ обычным способом (если эта таблица не является специализацией еще одного обобщения, например Cricketers). Большинство дизайнеров дают первичному ключу стандартное имя, например «Id». Они используют функцию autonumber для заполнения поля Id. Таблицы классов spec получают первичный ключ, который можно назвать «Id», но функция autonumber не используется. Вместо этого первичный ключ каждой таблицы подкласса ограничивается ссылкой на первичный ключ обобщенной таблицы. Это делает каждый из специализированных первичных ключей внешним ключом, а также первичным ключом. Обратите внимание, что в случае Cricketers поле Id будет ссылаться на поле Id в Players, но поле Id в Bowlers будет ссылаться на поле Id в Cricketers.

Теперь, когда вы добавляете новые элементы, вам необходимо поддерживать ссылочную целостность. Вот как это сделать. Сначала вы вставляете новую строку в таблицу gen, предоставляя данные для всех своих атрибутов, за исключением первичного ключа. Механизм autonumber генерирует уникальный первичный ключ. Затем вы вставляете новую строку в соответствующую таблицу спецификаций, включая данные для всех ее атрибутов, включая первичный ключ. Первичный ключ, который вы используете, это копия только что созданного первичного ключа. Это распространение первичного ключа можно назвать «наследованием бедных людей».

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