Складской дизайн базы данных: таблицы фактов и таблицы измерений

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

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

Ключевым дизайнерским решением в вашем случае, вероятно, является анализ данных, связанных с возрастом, если исследование продолжается. Поскольку возраст людей меняется со временем, в какой-то момент они перейдут в другую возрастную группу. В зависимости от того, зафиксированы ли группы в начале исследования или нет, это может определить, как вы хотите агрегировать.Я не обязательно говорю, что у вас должно быть групповое измерение, и вы должны достичь возраста через него, но вам может потребоваться определить правильный возраст / демографический аспект во время ETL. Но это зависит от конечного использования (или совместимость с двумя ролями измерения, связанными из таблицы фактов - исходная демография, которая никогда не меняется, и текущая демография, которая будет меняться со временем).

То же самое можно сказать и о географии. Хотя вы, очевидно, можете отслеживать географию человека, анализируя текущие географические изменения с течением времени, суть размерного DW состоит в том, чтобы все соответствующие измерения были напрямую связаны с фактом (то, что вы обычно можете получить в нормализованной модели через сеть Модель Entity-Relationship - они заблокированы во время ETL). Эта избыточность ускоряет анализ размерной модели в традиционных СУБД.

Обратите внимание, что многое из этого не применяется в массивно-параллельных DW, таких как Teradata, которые плохо работают со звездообразными схемами - им нравятся все данные, нормализованные и связанные с одним и тем же первичным индексом, потому что они являются первичным индексом для распределения. данные по блокам обработки.

Поиск по звездной схеме - это SQL-эквивалент точек пересечения диаграмм Венна. Как ясно видно из ваших примеров запросов, SEX_TYPE и DEMOGRAPHIC_CATEGORY - это наборы, по которым вы хотите искать, и, следовательно, они должны быть размерными.

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

where sex_type.name = 'FEMALE'

чем

where sex_type.is_male = 1

Кроме того, в реальном мире пол не является булевой величиной. Большинство приложений должны также собирать UNKNOWN и TRANSGENDER, и это, конечно, верно для приложений для здоровья/медицины, что вы, похоже, и делаете. Кроме того, это позволит избежать неприятных споров в офисе, если у вас есть коллеги-женщины.

Редактировать

"Я думаю о том, как справиться с случаями новых типов_пола и демографических категорий, которых еще нет в в базе данных"

Была мода на отказ от внешних ключей в Хранилищах данных. Но они предоставляют полезные метаданные, которые оптимизатор запросов может использовать для выработки наиболее эффективного пути поиска. Это особенно важно, когда нужно обработать большое количество данных и специальных запросов. Работа с новыми значениями размерности всегда будет сложной, если только ваши исходные системы не предоставят вам уведомление. Это действительно зависит от вашей установки.

Какой OLAP / инструмент уровня представления вы собираетесь использовать? Они часто имеют собственные функции для поддержки построения кубов, иерархий, агрегаций и т.д.

Нормальная форма обычно является наиболее надежной основой для гибкого и эффективного Хранилища данных, хотя Марты иногда денормализуются для поддержки определенного набора требований к отчетности. В отсутствие какой-либо другой информации я предлагаю вам стремиться к тому, чтобы ваша база данных находилась, по крайней мере, в нормальной форме Бойса-Кодда / 5-й нормальной форме.