Infology.Ru

Дата оригинальной публикации: 2004-09-14
Автор оригинала: Ralph Kimball
Перевод на русский язык: Антон Задорожный
Оригинальный документ располагается здесь

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

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

Что такое профилирование данных?

Читать дальше »

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

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

Как и многое в нашей жизни, перемены неизбежны в атрибутах измерения. Большинство читателей Советов Разработчику хорошо знакомы с тремя базовыми техниками медленно меняющихся измерений (SCD):

Тип 1: Переписать атрибут заново.

Тип 2: Добавить еще одну запись в измерение

Тип 3: Добавить еще один атрибут

Читать дальше »

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

Читать дальше »

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

Наиболее общим и полезным измерением Время является календарь с уровнем гранулярности в один день. Это измерение имеет удивительно много атрибутов. Только некоторые из этих атрибутов (такие как имя месяца и год) могут быть получены непосредственно из SQL-выражения типа date-time. Праздники, рабочие дни, фискальные периоды, номера недель, индикатор последнего дня месяца и другие навигационные атрибуты должны быть встроены в календарное измерение и вся навигация по датам должна быть реализована в приложениях при помощи атрибутов измерения. Календарное измерение имеет несколько весьма необычных свойств. Это – одно из немногих измерений, которое полностью определено в начале проекта по хранилищу данных. У него также нет источника в общепринятом смысле. Лучший способ создать календарное измерение – это потратить полдня с электронной таблицей и построить его вручную. Десять лет по дням это меньше 4000 строк.

Читать дальше »

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

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

Читать дальше »

В журнале Intelligent Enterprise, в статье «Фундаментальные уровни гранулярности» я описал три различных типа гранулярности, к которым, похоже, сводятся все таблицы фактов. Помните, что таблица фактов является местом, где мы храним показатели, являющиеся результатом определенного бизнес-процесса. Таблицы измерений окружают и описывают эти показатели.
Помните также, что уровень гранулярности таблицы фактов – это точное определение того, что представляет собой запись таблицы фактов. Совершенно точно, первичный ключ таблицы фактов является уровнем гранулярности, но часто самым понятным определением уровня гранулярности является бизнес-понятие, нежели технический список внешних ключей. Для примера, уровень гранулярности таблицы фактов, представляющей процесс принятия заказа может быть «строка позиции в заказе», тогда как техническое описание ключа для этой таблицы может быть «номер накладной/ продукт/ рекламная акция».
Читать дальше »