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

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

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

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

3) Создайте хранилище данных с помощью базы данных Postgres

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

введите описание изображения здесь

Есть две основные таблицы, Occurrence и Canonical, от которых наследуется набор других (нарисованных красным и синим цветом соответственно). Обратите внимание, что существует 2 дочерних типа данных, ObserverNodeOccurrence и CanonicalObserverNode, которые имеют дополнительные отношения "многие ко многим" с другой таблицей.

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

введите описание изображения здесь

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

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




Ответы (2)


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

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

person Laurenz Albe    schedule 01.07.2019

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

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

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

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

person Marmite Bomber    schedule 01.07.2019