Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Наиболее важный этап многомерного моделирования - это объявление
уровня детализации таблицы фактов. Объявление уровня детализации
означает ТОЧНОЕ определение того, что представляют собой записи
таблицы фактов. Помните, что запись таблицы фактов регистрирует
измерение величин. Примеры объявлений включают:
отдельный товар в чеке клиента розничного магазина, зарегистрированный
сканирующим устройством
отдельная операция по страховому полису
строка счёта, полученного от доктора
отдельный посадочный талон, используемый пассажиром авиарейса
Когда вы делаете такое объявление уровня детализации, вы можете
очень точно обсудить то, какие измерения возможны, а какие - нет.
Например, строка счёта от доктора (пример №3), возможно, будет иметь
следующие измерения:
Дата (обращения)
Доктор (может называться "предоставитель услуги")
Пациент
Процедура
Первичный диагноз
Местоположение (предполагается, кабинет доктора)
Организация, выставляющая счёт (организация, в которой работает
доктор)
Ответственная сторона (либо пациент, либо его законный представитель)
Основной плательщик (часто страховой план)
Вторичный плательщик (может быть, страховой план супруга или супруги
ответственной стороны) и, возможно, другие измерения.
Если вы следили за этим примером, я надеюсь, вы заметили некоторые
мощные эффекты объявления уровня детализации. Во-первых, вы можете
очень точно визуализировать многомерность отношения доктор-счёт-строка
счёта. Мы также можем обсудить источники в стиле ответов Да/Нет
на предмет возможности присоединения к этим данным измерений. Например,
мы, возможно, исключим "результат лечения" из этого примера,
поскольку большинство медицинских данных не привязываются ни к каким
категориям результатов.
НО, обычная "модель данных" визитов к доктору в стиле
диаграммы "сущность-связь" вполне может включать результат
лечения. В конечном счёте, в абстрактном смысле каждое лечение имеет
какой-то результат, не правда ли???
Дисциплина настаивания на объявлении уровня детализации в начале
разработки многомерной модели предостерегает нас от ошибки такого
характера. Модель оплачиваемых визитов к доктору, включающая результат
лечения, выглядела бы как многомерная модель, но она была бы нереализуемой.
Это моё главное возражение против многих современных предложений
"стандартных схем" в книгах и на компакт-дисках. Поскольку
они не придерживаются дисциплины уровня детализации, они часто объединяют
сущности, которые не существуют вместе в реальных источниках данных.
Второе главное понимание объявления уровня детализации доктор-счёт-строка
счёта - это то, что этот атомарный уровень детализации порождает
множество измерений! Выше мы перечислили 10 измерений, а те из вас,
которые являются экспертами в части автоматизации выставления счетов
за медицинские услуги, возможно знают о ещё нескольких. Очень интересно
осознавать, что чем на более детальном уровне измеряются показатели
(чем более атомарна запись таблицы фактов), тем больше вещей вы
знаете наверняка. И, как следствие, больше измерений! Это ещё одно
объяснение того факта, что атомарные данные выдерживают натиск "атак
непредвиденными запросами" со стороны конечных пользователей.
Атомарные данные имеют наибольшее количество измерений и могут быть
ограничены и агрегированы любым способом, который позволяет источник
данных. Атомарные данные идеально подходят для многомерного моделирования.
Все объявления уровня детализации, перечисленные в начале этого
совета, представляют самые детальные из возможных уровней детализации
соответствующих источников данных. Измеряемые показатели являются
"атомарными" и не могут быть далее детализированы. Но
вполне возможно объявить более высокие уровни детализации для каждого
из этих источников данных, которые будут представлять агрегаты атомарных
данных:
все продажи отдельного продукта в отдельном магазине за день
суммарные обороты по страховым полисам за месяц по направлениям
бизнеса
итоговые суммы за месяц счетов по видам лечения и диагнозам
количество пассажиров и другие показатели удовлетворённости
полётами за месяц по отдельным маршрутам
Эти более высокие уровни агрегации почти всегда будут иметь меньшее
количество и менее крупные измерения. Наш пример с доктором может
в конечном счёте привести к следующим измерениям:
Месяц
Доктор
Процедура
Диагноз
Было бы нежелательным включать в агрегированную таблицу фактов
все исходные измерения атомарных данных потому что обычно у вас
будет очень мало возможностей агрегирования!
Поскольку полезные агрегации обязательно сжимают и убирают измерения,
это приводит к осознанию того, что эти агрегированные данные следует
использовать вместе с базовыми детальными данными, потому что агрегированные
данные имеют меньше деталей о измерениях. Некоторых авторов это
смущает, и после объявления того, что витрины данных должны обязательно
состоять из агрегированных данных, они критикуют витрины данных
за то, что они "ожидают вопрос о бизнесе". Всё это непонимание
уходит когда агрегированные данные предоставляются ВМЕСТЕ с атомарными
данными, из которых они производятся.
Наиболее важным результатом объявления уровня детализации таблицы
фактов является установка отправной точки дискуссии об измерениях.
Но объявление уровня детализации также позволяет вам также прояснить
ситуацию с измеряемыми числовыми показателями. Проще говоря, факты
должны соответствовать уровню детализации. В нашем примере с доктором
наиболее очевидным измеряемым фактом была бы "сумма по счёту".
Возможны также другие факты, относящиеся к специфическим видам лечения,
полученным определёнными пациентами. Но "полезные" факты
наподобие нарастающей итоговой суммы, выставленной в счетах данному
пациенту за все виды лечения не соответствуют уровню детализации.
Когда фактические записи произвольным образом комбинируются генератором
отчётов, эти не соответствующие уровню детализации факты приводят
к бессмысленным бесполезным результатам. Их нужно оставить за пределами
дизайна. Вычисляйте такие агрегированные показатели с помощью вашего
приложения.
Подводя итог, старайтесь проектировать ваши многомерные модели
в следующем порядке:
примите решение об источниках данных
объявите уровень детализации таблицы фактов (предпочтительно,
на самом детальном уровне)
добавьте измерения для "всего, что вы знаете" об этом
уровне детализации
добавьте числовые факты для данного уровня детализации
Присылайте свои вопросы и комментарии по поводу объявления уровня
детализации.
Ralph Kimball (ralph@ralphkimball.com)
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS