Я много слышал о подтипировании таблиц при разработке базы данных, и я полностью осознаю теорию, лежащую в их основе. Тем не менее, я никогда не видел табличного подтипирования в действии. Как вы можете создавать подтипы таблиц? Я использую MS Access, и я ищу способ сделать это в SQL, а также через GUI (Access 2003).Таблицы базы подтипов
Cheers!
Простым примером может быть таблица Person с первичным ключом и некоторыми столбцами в этой таблице. Теперь вы можете создать другую таблицу с именем «Студент», которая имеет внешний ключ для таблицы лиц (ее супертип). Теперь в таблице ученика есть несколько столбцов, у которых супертип не имеет GPA, Major и т. Д. Но имя, фамилия и т. Д. Будут в родительской таблице. Вы всегда можете получить доступ к имени ученика в таблице Person через внешний ключ в таблице Student.
В любом случае, помните следующее:
Подтипы таблиц являются концептуальными в диаграммах EER. Я не видел RDBMS (за исключением объектно-реляционных СУБД), который поддерживает его напрямую. Они, как правило, осуществляется в любом
Понятие подтипов таблицы полезно при использовании ORM-mapper для создания иерархии подтипов класса, которая точно моделирует домен.
Таблица подтипов будет иметь и внешний ключ обратно к его родительскому элементу, который также является основным ключом таблицы подтипов.
Если записи таблицы подтипов имеют отношение 1: 1 к родительской таблице, почему бы им не просто использовать FK как ПК? –
Имейте в виде, что в проектирование связанного приложения, как и в приложении Access, подтипы налагают значительную стоимость с точки зрения объединения.
Например, если у вас есть таблица супертипов с тремя таблицами подтипов, и вам нужно отобразить все три в одной форме сразу (и вам нужно показать не только дату супертипа), вы получите выбор используя три внешних объединения и Nz(), или вам нужен UNION ALL из трех взаимоисключающих операторов SELECT (по одному для каждого подтипа). Ни один из них не будет доступен для редактирования.
Я собирался вставить некоторый SQL из первого основного приложения, где я работал с супер/подтипами, но, глядя на него, SQL настолько сложный, что это просто смущает людей. Это не так, потому что мое приложение было сложным, но это связано с тем, что характер проблемы сложный - представление полного набора данных пользователю, как супер-, так и подтипы, по своей природе является сложным. Мой вывод от работы с ним состоял в том, что мне было бы лучше с одной таблицей подтипа.
Это не значит, что в некоторых случаях это не полезно, только связанные формы доступа не обязательно облегчают представление этих данных пользователю.
У меня есть аналогичная проблема, над которой я работаю.
При поиске повторяемого шаблона я хотел убедиться, что я не отказался от ссылочной целостности, а это значит, что я не буду использовать решение (TABLE_NAME, PK_ID).
я, наконец, остановились на:
базы Тип таблицы: КЛИЕНТ
Sub Тип Таблицы: ПЕРСОНА, БИЗНЕС, GOVT_ENTITY
Я поставил NULLABLE PRERSON_ID, BUSINESS_ID и GOVT_ENTITY_ID полей ЗАКАЗЧИКА с внешними ключами на каждом и контрольное ограничение, что только один не является нулевым. Легко добавлять новые подтипы, просто нужно добавить нулевой внешний ключ и изменить ограничение проверки.
Извините, но я думаю, что вы просто описываете ССЫЛКУ. В вашей так называемой таблице супертипов отсутствует атрибут типа! Для лучшего примера IMO см. Сообщение CREATE TABLE Transport в этой теме: http://bytes.com/groups/ms-sql/808389-design-question-type-heirarchy-supertype-queries – onedaywhen
Да, вы говорите о дискриминатора, что является другим подходом к решению одной и той же проблемы. Я хорошо знал об этом. Это не значит, что мое решение неверно. Я просто хотел дать короткий простой пример. В опубликованной вами ссылке сообщение четко указывает, что существует множество способов моделирования таких структур. Пример, аналогичный тому, который я опубликовал, упоминается в книге «Системы баз данных: проектирование, внедрение и управление 6-го издания». п. 150, 151 и 159. – jasonco
. Мой вопрос с вышеизложенным заключается в том, что вы должны были сделать более явным, что PK таблицы Student имеет ограничение внешнего ключа для ключа Surrogate Key Person. Импорт этого состоит в том, что кортежи отношения Student не имеют идентичности, не зависящей от соответствующих кортежей в таблице Person; следовательно, это истинное отношение подтипа. Это не упоминание, как было сказано после заявлений. – Recurse