Какую политику следует применять для загрузки этого типа источника в DWH?

Question

Угадайте, у нас есть приложение для управления претензиями на предприятии. Это приложение имеет различные таблицы, такие как:

1. типов Требований
2. Журнал претензии
3. Претензия таблица
4. стол пользователя
требование
5. пользователя реляционная таблица

Приложение позволяет пользователю для создания новых типов заявок (1), а затем администратор может принять этот тип или удалить его. Кроме того, это приложение позволяет создавать заявку (3) и регистрировать ее. Это также регистрирует ip и другие параметры (2). Наконец, у нас есть пользовательская таблица, потому что только некоторые пользователи могут создавать претензии (4) и таблицу, в которой хранятся заявки, созданные для каждого пользователя (5).

Все эти таблицы имеют внешние и первичные ключи, которые должны соблюдаться за правильность использования приложения.

Теперь мы хотим загрузить это в DWH. Все таблицы должны быть усечены и загружаться каждый день, потому что все таблицы могут иметь новые строки или даже удалять строки каждый день. В этом случае у нас есть два способа сделать это:

• Загрузите каждый стол без FK и PK. Затем DWH похож на резервную копию, поскольку целостность данных проверяется в исходных таблицах.
• Загрузите столы с ПК и FK. DWH также проверяет целостность данных, но затем процесс ETL должен удалить FK, а затем может обрезать таблицу, чтобы окончательно восстановить FK и снова загрузить таблицу. Я не знаю, может ли он создать какое-либо усложнение базы данных.

Каков правильный подход к DWH, когда источник обеспечивает целостность данных? Должна ли DWH проверять целостность данных с реляционными ключами или хранить данные только для создания отчетов и панелей мониторинга?

В случае отчетов и панелей мониторинга возможно первый вариант действителен, но что произойдет, если эти данные пройдут через массовый процесс, загруженный в другое приложение, которое должно взорвать те же самые отношения, что и исходное приложение?

Answer 1

Ответ может зависеть от базы данных, на которой выполняется ваш хранилище данных. Поэтому я дам вам конкретный ответ Oracle. В целом рекомендуется создать ПК/ФК, но используйте RELY DISABLE NOVALIDATE. Это приводит к созданию метаданных, которые определяют отношения, но без индексов, которые, вероятно, не нужны в вашем DW. Связь PK/FK позволяет Oracle выполнять ряд оптимизаций, которые иначе не могли.