Модель хранилища данных и таблицы поиска

Question

Я проектирую хранилище данных, которое использует модель Data Vault. В моем хранилище данных есть объект Specialty. Существует таблица поиска для этих специальностей, основанная на их кодах, которая имеет однозначное соответствие между Specialty_CD и Description. Существует история ввода данных для этой таблицы поиска (поскольку специальные коды могут изменить значение) и всех спутниковых таблиц в моем хранилище.

Я столкнулся с любопытным случаем, когда я хочу связать другую сущность в хранилище данных под названием "Профессионал" со специализацией, где профессионал может иметь несколько специальностей. Тем не менее, нет никакого специализированного субъекта. В моем текущем решении просто есть профессиональный концентратор, в котором хранятся бизнес-ключи и хеши бизнес-ключей для каждого специалиста, таблица ссылок, которая сопоставляет профессиональные хэш-коды BK со специальными кодами специальностей, которые используются в профессиональной практике, и справочная таблица из специальных кодов в описании. Подвох в том, что таблица ссылок соединяет концентратор с таблицей поиска, а не с другим концентратором. Я не могу помочь, но чувствую, что это ломает модель Data Vault. Это нарушает правила модели Data Vault? Разрушает ли это нормализацию всей моей модели?

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

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

Спасибо!

Answer 1

Вы ответили на свой вопрос: "Коды специальностей по специальностям, которые профессиональная практика"

Специальности, безусловно, являются основной бизнес-концепцией и центром. Тот факт, что он имеет только 2 поля (код и описание), не имеет значения.

Data Vault работает по шаблонам. Это не " только в базе данных, чтобы служить цели определения ". Если он будет удален, будет ли база данных работать? Например, я удалил почтовый индекс с адреса, по которому база данных будет продолжать работать. Я предполагаю, что если вы удалите Specialty, могут быть проблемы с некоторыми отчетами.

Вам нужно привыкнуть к тому, что у вас будет МНОЖЕЕ больше таблиц (около 7 - общая метрика) при создании хранилища необработанных данных.

PCD

Answer 2

Я думаю, что ваша модель должна выглядеть так

• Specialty_HUB (HUB_ID (pk), Specialty_CD)
• Specialty_SAT (SAT_ID (pk), HUB_ID (fk), Load_Date, Description)
• Professional_HUB (HUB_ID (pk), Professional_PK)
• Professional_SAT (SAT_ID (pk), (HUB_ID (fk), профессиональные сведения...)
• Profesional_X_Specialty_LNK (LNK_ID (pk), Load_Date, End_Date, Professional_HUB_ID (fk), Specialty_HUB_ID (fk))

ОБРАТИТЕ ВНИМАНИЕ, что в этом проекте у вас есть требование для End_Date в таблице ссылок, так как вам может потребоваться удалить одну ассоциацию независимо от статуса специалиста или специальности, и вам нужно будет убедиться, что ваша логика ETL подхватывает "удаления", Если коды, относящиеся к специальности, также могут измениться, то вам потребуется еще один уровень абстракции между таблицей ссылок и специальным SAT, чтобы обеспечить стабильность ссылок.