Лучший подход для реализации наследования в хранилище данных на основе базы данных postgres

Question

Я разрабатываю многошаговый конвейер данных, который должен оптимизировать следующий процесс:

1) Извлечение данных из базы данных NoSQL ( MongoDB ).

2) Преобразование и загрузка данных в реляционную ( PostgreSQL ) базу данных.

3) Сборкахранилище данных, использующее базу данных Postgres

. Я вручную написал скрипт для обработки шагов 1) и 2), который является промежуточным конвейером ETL.Теперь моя цель - создать хранилище данных с использованием базы данных Postgres , но я столкнулся с несколькими сомнениями относительно дизайна DW.Ниже приведена размерная модель для реляционной базы данных:

Существуют 2 основные таблицы: Вхождение и Каноническое , от которого наследуют множество других (нарисованы красным и синим соответственно).Обратите внимание, что есть 2 дочерних типа данных, ObserverNodeOccurrence и CanonicalObserverNode , которые имеют дополнительное отношение «многие ко многим» с другой таблицей.

Я провел исследование относительно того, как наследование должно быть реализовано в хранилище данных, и подумал , что лучше всего было бы объединить семейные типы данных (таблицы super и child) водин столик .Для этого потребуется добавить дополнительные атрибуты и много из нулевых значений.Моя новая размерная модель будет выглядеть следующим образом:

Вопрос 1: Считаете ли вы, что это лучший подход для решения этой проблемы?Если нет, что бы?

Вопрос 2: Есть ли рекомендации по программному обеспечению для локальных хранилищ данных?(локально необходимо, так как оно содержит конфиденциальные данные)

Answer 1

Обычно меньшее количество таблиц для объединения и денормализации данных повышает производительность запросов для запросов к хранилищам данных, поэтому их часто считают полезными.

Это предполагает ваш второй дизайн стола. Значения NULL не занимают места в таблице PostgreSQL, поэтому вам не нужно об этом беспокоиться.

Answer 2

Как описано здесь есть три варианта реализации наследования в реляционной базе данных.

IMO единственный практический способ использования в хранилище данных - это опция Table-Per-Hierarchy , которая объединяет все объекты в одну таблицу.

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

Важно определить столбец дискриминатора , который однозначно определяет исходную сущность.