Моделирование DataVault для справочной таблицы доменов
Folks,
Быстрая версия: Как мне моделировать HUB, SAT и LINK, когда у меня есть несколько ссылок на поиск домена в моем HUB_SAT? Если бы вы должны были моделировать их в общем из исходной схемы, как бы вы различали FK, которые должны быть LINK, и FK, которые должны быть ссылками?
Длинная версия:
Я строю общее решение для генерации моделей DV из существующей схемы 3NF MSSQL. В моей исходной базе данных у меня есть одна огромная справочная таблица доменов, которая содержит большинство ключей бизнес-поиска
- Ключ INT (Уникальный)
- TypeID INT
- Описание VARCHAR
- Почтовый код
- ... некоторые другие области, которые не имеют отношения к обсуждению
На мой взгляд, существует четыре основных варианта ссылки на эту таблицу.
- Создайте его как HUB, а затем создайте таблицы LINK для каждого бизнес-HUB, который ссылается на него.
- Создайте его как одну таблицу ReferenceLookup и включите R_ReferenceID в таблицу SAT
- Создайте отдельную таблицу ReferenceLookup для каждого TypeID и ссылку из SAT, используя R_ReferenceID
- Создайте отдельные концентраторы для каждого TypeID и сгенерируйте таблицы LINK
- Создайте одну таблицу LINK с таблицей LINK_SAT для хранения сведений о том, какое эталонное значение отображается в LINK
и из них № 3 выглядит как лучший дизайн (но также и самый сложный для правильной модели - тем более, что в моем случае таблица соответствия имеет FK для таблицы типов)
В Википедии для DataVault справочные таблицы ссылаются со спутников, но никогда не связываются с физическими внешними ключами.
Мой общий код основан на шаблоне проектирования, как описано в пошаговом руководстве BIML DataVault.
Я просматриваю все таблицы в исходной схеме, чтобы определить, являются ли они HUB (имеют PK и несколько FK плюс поля, которые не являются FK), SAT (имеют PK и только один FK) или LINK (имеют PK, более одного FK и все поля в PK/FK)
Я тогда строю:
- Концентраторы с идентификатором HUB_ID и исходным PK
- SAT с полями не FK исходной таблицы HUB
- SAT для исходных таблиц SAT
- ССЫЛКИ из исходных таблиц ССЫЛКИ
- ССЫЛКИ из отношений HUB FK
Все это работает до определенного момента (то есть у меня есть таблицы для всего вышеперечисленного), однако есть некоторые довольно широкие таблицы, в которых значительное количество полей представляют собой просто поля R_RefID, все они смотрят на один и тот же HUB, и все они связаны с ФК таблицы сущностей, ссылающиеся на справочную таблицу
Таблица активов источника EG имеет справочные поля для: - Тип актива - Назначение актива - Менеджер актива - Финансист актива - ...
Итак, в предварительной модели у меня есть:
- ASSET_HUB (HubID, Asset_ID)
- ASSET_SAT (SAT_ID, BuildDate, DisposalDate,....)
- Lookup_HUB (Hub_ID, LookupID)
- ASSET_Lookup_1_LINK) (Link_ID, ASSET_HUB_ID, Lookup_HUB_ID)
- ASSET_Lookup_2_LINK) (Link_ID, ASSET_HUB_ID, Lookup_HUB_ID)
- ASSET_Lookup_3_LINK) (Link_ID, ASSET_HUB_ID, Lookup_HUB_ID)
- ASSET_Lookup_4_LINK) (Link_ID, ASSET_HUB_ID, Lookup_HUB_ID)
но нет способа определить, что каждая из таблиц LINK представляет в доменной модели
Как бы вы поступили, опрашивая схему, чтобы определить, является ли таблица подлинным кандидатом в HUB или она должна быть таблицей REF, а как определить, следует ли рассматривать FK как LINK или SAT.R_RefID. Я придерживаюсь стратегии, а не кода (но я не собираюсь отказываться от кода, если он предлагается:)) Моя исходная БД - SQL2008R2, а среда разработки - SQL2016_Dev.
В ответ на tobi6:
В исходной системе бизнес-объект имеет ряд полей атрибутов, которые являются просто типами XXX_ID, которые ищут свои дескрипторы из справочной таблицы домена. Если вы моделируете эту ссылочную таблицу домена как HUB, то вам нужно либо иметь отдельные таблицы ссылок для каждого поиска (таблицы LINK генерируются автоматически, поскольку в бизнес-объекте есть FK), либо несколько активных записей LINK с LINK_SAT, чтобы определить, какие атрибут, который вы отслеживаете (фактически это создает 5-й вариант шаблона проектирования). Если я помечаю таблицу ссылок домена как REFerence, то XXX_ID остаются в HUB_SAT, что выглядит как лучшее решение, но сложнее моделировать в общем. Т.е. как мне определить, должен ли бизнес-объект FK создать LINK, LINK и LINK_SAT или SAT.R_RefID