Проектирование хранилища базы данных: таблицы фактов и таблицы измерений - PullRequest
Новая
       30

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

11 голосов
/ 29 мая 2010

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

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

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

  • «ломтик и кости»
  • «детализация вверх / вниз» данных и
  • обычно можно просматривать данные с разных точек зрения

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

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

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

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

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

  • пол (правда / ложь)
  • демографическая классификация (A, B, C и т. Д.)

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

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

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

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

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

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

и т.д.

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

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

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

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

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

Ответы [ 4 ]

9 голосов
/ 29 мая 2010

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

weight_model_01.png

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

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

3 голосов
/ 30 мая 2010

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

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

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

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

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

3 голосов
/ 29 мая 2010

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

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

where sex_type.name = 'FEMALE'

чем 

where sex_type.is_male = 1

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

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

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

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

1 голос
/ 29 мая 2010

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

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

...