Согласно моей интерпретации ваших спецификаций, вы хотите найти метод для реализации двух разных (но связанных ) структур супертип-подтип .
Чтобы раскрыть подход для достижения вышеупомянутой задачи, я собираюсь добавить к рассматриваемому сценарию два классических гипотетических типа сущностей, называемых Fooи Bar, которые я подробно опишу ниже.
Бизнес правила
Вот несколько утверждений, которые помогут мне создать логическую модель:
A Foo is either one Bar or one CA Foo is categorized by one FooTypeA Bar is either one A or one CA Bar is classified by one BarType
Логическая модель
И затем, результирующая логическая модель IDEF1X [1] показана на рисунке 1 (и вы также можете загрузить ее из Dropbox в формате PDF ):
Дополнение Foo and Bar
Я не добавлял Fooи Barчтобы модель выглядела лучше, но чтобы она была более выразительной. Я считаю, что они важны из-за следующего:
Как Aи Bразделить названный атрибут E, эта особенность предполагает, что они являются типами субъективности отдельного (но связанного) вида концепции , события , личности , измерения и т. Д., BarКоторые я представлял с помощью типа превосходства, который, в свою очередь, является тип подчиненности Foo, который содержит Dатрибут в верхней части иерархии.
Поскольку Cтолько один атрибут разделяет с остальными обсуждаемыми типами сущностей, т. Е. DЭтот аспект намекает на то, что это тип сущности другого типа концепции , события , лица , измерения и т. Д., Поэтому я изобразил это обстоятельство в силу Fooсупер тип объекта.
Тем не менее, это всего лишь предположения, и поскольку реляционная база данных предназначена для точного отражения семантики определенного бизнес-контекста , вам необходимо идентифицировать и классифицировать все вещи, представляющие интерес в вашей конкретной области, чтобы вы могли, точно, захватить больше смысла ,
Важные факторы на этапе проектирования
Весьма полезно осознавать тот факт, что, исключая всю терминологию, исключительный кластер супертип-подтип является обычным отношением. Опишем ситуацию следующим образом:
- Каждое исключительное вхождение типа суперчувствительности связано только с одним дополнением типа субэлемента .
Таким образом, в этих случаях есть соответствие (или количество элементов) один к одному (1: 1).
Как вы знаете из предыдущих постов, атрибут дискриминатора (столбец, если он реализован) играет первостепенную роль при создании ассоциации такого рода, поскольку он указывает на правильный экземпляр подтипа, с которым связан супертип . Миграция первичного ключа из (I) супертипе к (б) подтипы также имеет первостепенное значение.
Бетонная конструкция DDL
А затем я написал структуру DDL, основанную на логической модели, представленной выше:
CREATE TABLE FooType -- Look-up table.
(
FooTypeCode CHAR(2) NOT NULL,
Description CHAR(90) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_FooType PRIMARY KEY (FooTypeCode),
CONSTRAINT AK_FooType_Description UNIQUE (Description)
);
CREATE TABLE Foo -- Supertype
(
FooId INT NOT NULL, -- This PK migrates (1) to ‘Bar’ as ‘BarId’, (2) to ‘A’ as ‘AId’, (3) to ‘B’ as ‘BId’, and (4) to ‘C’ as ‘CId’.
FooTypeCode CHAR(2) NOT NULL, -- Discriminator column.
D INT NOT NULL, -- Column that applies to ‘Bar’ (and therefore to ‘A’ and ‘B’) and ‘C’.
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_Foo PRIMARY KEY (FooId),
CONSTRAINT FK_from_Foo_to_FooType FOREIGN KEY (FooTypeCode)
REFERENCES FooType (FooTypeCode)
);
CREATE TABLE BarType -- Look-up table.
(
BarTypeCode CHAR(1) NOT NULL,
Description CHAR(90) NOT NULL,
CONSTRAINT PK_BarType PRIMARY KEY (BarTypeCode),
CONSTRAINT AK_BarType_Description UNIQUE (Description)
);
CREATE TABLE Bar -- Subtype of ‘Foo’.
(
BarId INT NOT NULL, -- PK and FK.
BarTypeCode CHAR(1) NOT NULL, -- Discriminator column.
E INT NOT NULL, -- Column that applies to ‘A’ and ‘B’.
CONSTRAINT PK_Bar PRIMARY KEY (BarId),
CONSTRAINT FK_from_Bar_to_Foo FOREIGN KEY (BarId)
REFERENCES Foo (FooId),
CONSTRAINT FK_from_Bar_to_BarType FOREIGN KEY (BarTypeCode)
REFERENCES BarType (BarTypeCode)
);
CREATE TABLE A -- Subtype of ‘Bar’.
(
AId INT NOT NULL, -- PK and FK.
X INT NOT NULL, -- Particular column.
CONSTRAINT PK_A PRIMARY KEY (AId),
CONSTRAINT FK_from_A_to_Bar FOREIGN KEY (AId)
REFERENCES Bar (BarId)
);
CREATE TABLE B -- (1) Subtype of ‘Bar’ and (2) supertype of ‘A’ and ‘B’.
(
BId INT NOT NULL, -- PK and FK.
Y INT NOT NULL, -- Particular column.
CONSTRAINT PK_B PRIMARY KEY (BId),
CONSTRAINT FK_from_B_to_Bar FOREIGN KEY (BId)
REFERENCES Bar (BarId)
);
CREATE TABLE C -- Subtype of ‘Foo’.
(
CId INT NOT NULL, -- PK and FK.
Z INT NOT NULL, -- Particular column.
CONSTRAINT PK_C PRIMARY KEY (CId),
CONSTRAINT FK_from_C_to_Foo FOREIGN KEY (FooId)
REFERENCES Foo (FooId)
);
С этой структурой вы избегаете хранения меток NULL в ваших базовых таблицах (или отношениях ), что внесет неоднозначность в вашу базу данных.
Целостность, последовательность и другие соображения
После того, как вы реализуете свою базу данных, вы должны убедиться, что (a) каждая исключительная строка супертипа всегда дополняется соответствующим аналогом подтипа и, в свою очередь, гарантировать, что (b) такая строка подтипа совместима со значением, содержащимся в столбце дискриминатора супертипа. , Поэтому довольно удобно использовать ACID TRANSACTIONS, чтобы убедиться, что эти условия выполняются в вашей базе данных.
Вы не должны отказываться от логической обоснованности, самовыражения и точности вашей базы данных, это те аспекты, которые определенно делают вашу базу данных более надежной.
Два ранее опубликованных ответа уже включают соответствующие пункты, которые, безусловно, стоит учитывать при проектировании, создании и управлении вашей базой данных и ее прикладными программами.
Получение данных с помощью определений VIEW
Вы можете настроить некоторые представления, которые объединяют столбцы разных групп подтипов супертипов , так что вы можете извлекать данные под рукой, например, не каждый раз записывая необходимые предложения JOIN. Таким образом, вы можете легко ВЫБРАТЬ непосредственно ИЗ ВИДА ( производного отношения или таблицы ), представляющего интерес.
Как видите, «Тед» Кодд был, несомненно, гением. Инструменты, которые он завещал, довольно сильны и элегантны, и, конечно же, хорошо интегрированы друг с другом.
Связанные ресурсы
Если вы хотите проанализировать какую-то обширную базу данных, которая включает отношения супертип-подтип, вы найдете полезными необычные ответы, предложенные @PerformanceDBA на следующие вопросы переполнения стека:
Заметка
1. Определение интеграции для информационного моделирования ( IDEF1X ) - это очень рекомендуемый метод моделирования данных, который был установлен в качестве стандарта в декабре 1993 года Национальным институтом стандартов и технологий США ( NIST ). Он основывается на (а) раннем теоретическом материале, написанном д-ром Э. Ф. Коддом; на (б) в сущности-связи с учетом данных, разработанного д - ром П. Ченом ; а также о (c) методике проектирования логических баз данных, созданной Робертом Г. Брауном. Стоит отметить, что IDEF1X был формализован с помощью логики первого порядка.