Проектирование хранилища данных: таблицы фактов и таблицы измерений
Я строю хранилище данных бедного человека, используя СУБД. Я определил ключевые "атрибуты" для записи как:
- секс (истина/ложь)
- демографические классификации (А, B, C и т. д.)
- место рождения
- дата рождения
- вес (записывается ежедневно): тот факт, что записывается
мои требования должны иметь возможность запускать запросы "OLAP", которые позволяют мне:
- 'и dice'
- 'детализация вверх / вниз' данные и
- как правило, иметь возможность просматривать данные с разных точек зрения
после прочтения этой тематической области общее мнение, по-видимому, заключается в том, что это лучше всего реализовать с помощью таблиц измерений, а не нормализованных таблиц.
предполагая, что это утверждение истинно (т. е. решение лучше всего реализовано с использованием таблиц фактов и измерений), я хотел бы обратиться за помощью в разработке этих таблицы.
"естественные" (или очевидные) размеры:
- дата измерения
- географическое положение
, которые имеют иерархические атрибуты. Тем не менее, я борюсь с тем, как моделировать следующие поля:
- секс (истина/ложь)
- демографические классификации (А, B, C и т. д.)
причина, по которой я борюсь с этими полями, заключается в том, что:
- у них нет очевидных иерархические атрибуты, которые будут способствовать агрегации (Афайи) - которые предполагают, что они должны быть в таблице фактов
- они в основном статические или очень редко меняются - что предполагает, что они должны быть в таблице измерения.
может, эвристика я использую выше слишком сырой?
Я приведу несколько примеров о типе анализа, который я хотел бы провести на хранилище данных-надеюсь,что это прояснит ситуацию.
Я хотел бы агрегируйте и проанализируйте данные по полу и демографической классификации-например, ответьте на такие вопросы, как:
- как сравниваются веса мужчин и женщин в разных демографических классификациях?
- какая демографическая классификация (мужчины и женщины) показывает наибольшее увеличение веса в этом квартале.
etc.
может ли кто-нибудь уточнить, являются ли пол и демографическая классификация частью таблицы фактов или являются ли они (как я подозреваемый) таблицы измерений.?
также предполагая, что они являются таблицами измерений, может ли кто-нибудь разработать структуры таблиц (т. е. поля)?
"очевидными" схема:
CREATE TABLE sex_type (is_male int);
CREATE TABLE demographic_category (id int, name varchar(4));
может быть неправильным.
4 ответов
Не уверен, почему вы считаете, что использование РСУБД-это решение бедного человека, но надеюсь, что это может помочь.
таблицы dimGeography и dimDemographic являются так называемыми мини-измерениями; они позволяют нарезать на основе демографических и географических данных без необходимости присоединяться к dimUser, а также захватывать текущую демографию и географию пользователя во время измерения.
и кстати, когда в мире DW, многословный -- Gender = 'female', AgeGroup = '30-35', EducationLevel = 'university', etc.
Star schema searches являются эквивалентом SQL точек пересечения диаграмм Venn. Как ясно показывают ваши примеры запросов, SEX_TYPE и DEMOGRAPHIC_CATEGORY-это наборы, которые вы хотите искать, и, следовательно, должны быть измерениями.
Что касается структур таблиц, я думаю, что ваш дизайн для SEX_TYPE ошибочен. Для начала проще, интуитивно понятнее, проектировать запросы на основе
where sex_type.name = 'FEMALE'
чем
where sex_type.is_male = 1
кроме того, в реальном мире секс не логическое. Большинство приложений также должны собирать неизвестные и трансгендерные, и это, безусловно, верно для медицинских приложений, которые вы, похоже, делаете. Кроме того, это позволит избежать некоторых неприятных офисных споров, если у вас есть коллеги-женщины.
редактировать
"Я думаю о том, как бороться с случаях новых sex_types и демографической категории еще не в the база данных"
была мода за отсутствие внешних ключей в хранилищах данных. Но они предоставляют полезные метаданные, которые оптимизатор запросов может использовать для получения наиболее эффективного пути поиска. Это особенно важно, когда есть много данных и нерегламентированных запросов для обработки. Работа с новыми значениями измерений всегда будет сложной, если исходные системы не предоставят вам уведомление. Это действительно зависит от вашей установки.
Как правило, все числовые величины и меры являются столбцами в таблице фактов. Тогда все остальное-атрибут измерения. В каком измерении они принадлежат, довольно прагматично и зависит от данных.
в дополнение к предложениям, которые вы уже получили, я не видел упоминания о вырожденных измерениях. В этих случаях такие вещи, как номер счета-фактуры или метка времени порядкового номера, которая отличается для каждого факта, должны храниться в факте, иначе таблица измерений станет 1-1 с таблицей фактов.
ключевым проектным решением в вашем случае, вероятно, является анализ данных, связанных с возрастом, если исследование продолжается. Поскольку возраст людей меняется со временем, в какой-то момент они перейдут в другую возрастную группу. В зависимости от того, фиксированы ли группы в начале исследования или нет, это может определить, как вы хотите агрегировать. Я не обязательно говорю, что вы должны иметь групповое измерение и стареть через это, но что вы возможно, потребуется определить правильный возраст / демографический аспект во время ETL. Но это зависит от конечного использования (или размещения обоих с двумя ролями измерения, связанными из таблицы фактов - начальная демография, которая никогда не меняется, и текущая демография, которая будет меняться со временем).
аналогичная вещь может применяться к географии. Хотя вы, очевидно, можете отслеживать географию человека, анализируя текущие изменения географии с течением времени, точка размерного DW должна иметь все соответствующие измерения, связанные прямо с фактом (вещи, которые вы обычно можете получить в нормализованной модели через сеть модели отношений сущности-они блокируются во время ETL). Это резервирование делает анализ более быстрым на размерной модели в традиционных RDBMSes.
обратите внимание, что многое из этого не применяется в массово параллельных DW, таких как Teradata, которые не работают хорошо со звездными схемами - им нравятся все данные, нормализованные и связанные с тем же первичный индекс, потому что они первичный индекс для распределения данных по единицам обработки.
какой инструмент OLAP / presentation tier вы собираетесь использовать? Они часто имеют свои собственные функции для поддержки построения кубов, иерархий, агрегаций и т. д.
нормальной форме, как правило, наиболее прочную основу для гибкого и эффективного хранилища данных, витрин, хотя иногда ненормированные поддерживать определенный набор требований к отчетности. В отсутствие какой-либо другой информации я предлагаю вам стремиться к тому, чтобы ваша база данных была по крайней мере в Boyce-Codd / 5th Normal Форма.