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

Я создаю хранилище данных бедного человека, используя СУБД. Я определил ключевые атрибуты, которые будут записаны как:

sex (true/false)
демографическая классификация (A, B, C и т.д.)
место рождения
дата рождения
вес (записывается ежедневно): факт, который записывается

Мои требования состоят в том, чтобы иметь возможность запускать запросы "OLAP", которые позволяют мне:

'slice and dice'
"сверлить вверх/вниз" данные и
в целом, иметь возможность просматривать данные с разных точек зрения.

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

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

"Естественные" (или очевидные) размеры:

Размер даты
Географическое расположение

У кого есть иерархические атрибуты. Однако я борюсь с тем, как моделировать следующие поля:

sex (true/false)
демографическая классификация (A, B, C и т.д.)

Причина, по которой я борюсь с этими полями, заключается в следующем:

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

Может быть, эвристика, которую я использую выше, слишком груба?

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

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

Как мужские и женские весы сравниваются по разным демографическим классификациям?
Какая демографическая классификация (мужчины и женщины) показывает наибольшее увеличение веса в этом квартале.

и др.

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

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

"Очевидная" схема:

CREATE TABLE sex_type (is_male int);
CREATE TABLE demographic_category (id int, name varchar(4));

может быть неправильным.

Ответ 1

Не уверен, почему вы считаете, что использование RDBMS - это плохое решение для человека, но надеюсь, что это может помочь.

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

И кстати, когда в мире DW, verbose - Gender = 'female', AgeGroup = '30-35', EducationLevel = 'university', etc.

Ответ 2

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

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

where sex_type.name = 'FEMALE'

чем

where sex_type.is_male = 1

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

Edit

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Нормальная форма обычно является самой надежной основой для гибкого и эффективного хранилища данных, хотя Marts иногда денормализуются для поддержки определенного набора требований к отчетности. В отсутствие какой-либо другой информации я предлагаю вам стремиться к тому, чтобы ваша база данных находилась, по крайней мере, в Boyce-Codd/5th Normal Form.