Відповідно до моєї інтерпретації ваших специфікацій, ви хочете знайти спосіб реалізації двох різних (але пов'язаних ) структур підтипів-підтипу .
Для того, щоб розкрити підхід до досягнення формульованого завдання, я збираюся додати до розглядуваного сценарію два класичні гіпотетичні типи сутності, які називаються, 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 і Bar
Я не додав Fooі Barщоб модель виглядала краще, але щоб зробити її більш виразною. Я вважаю, що вони важливі через наступне:
Як Aі Bподіляється названий атрибут E, ця ознака говорить про те, що вони є типами суб'єктності виразного (але спорідненого) свого роду поняття , події , особи , вимірювання тощо, які я представляв за допомогою типу Barнадхідності, який, у свою чергу, є тип підменю Foo, який містить Dатрибут у верхній частині ієрархії.
Так як Cтільки акції одного атрибута з іншими типами сутностей обговорюваних, тобто D, цей аспект інсінуірует , що це тип subentity іншого роду концепції , події , особи , вимірювання і т.д., тому я зобразив цю обставину, в силу 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 був оформлений за допомогою логіки першого порядку.