Infology.Ru

Joy Mundy, Warren Thornthwaite, Ralph Kimball

Описание от издателя
Эта прорывная книга является первой из серии Kimball Toolkit, которая является продукто-ориентированной. Инструментарий BI от компании Microsoft претерпел значительные изменения при разработке SQL Server 2005. SQL Server 2005 - это первая жизнеспособная полноценная платформа для хранилищ данных (DWH) и business intelligence, которая предлагается по цене, делающей технологии хранилищ данных и business intelligence доступными широкому кругу организаций. Эта книга должна предложить практические методы и направить эти организации через мириады проблем к истинному успеху, который измеряется ценным вкладом в бизнес-результат.
Читать дальше »

Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite

Хорошая книга для начала изучения хранилищ данных.
Эта книга даст вам понимание того, что нужно иметь в виду при построении хранилища данных. Она будет полезна как начинающим, так и специалистам, уже занимающимся хранилищами данных. Усилия по сбору информации в одно издание заслуживает уважения. Главы о многомерном моделировании очень хороши (автор является известным популяризатором данного подхода к моделированию). CD-ROM, который продается в комплекте с книгой, содержит много полезной информации, которая поможет вам сэкономить много времени, если ваш проект создается с нуля.
Читать дальше »

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

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

Проблема именования полей возникает всякий раз, когда приходится строить многомерную модель. Именование действительно непростое дело: разные люди понимают под одними и теми же словами разные вещи, как, например, «доход» (revenue), или наоборот – используют разные наименования для одного и того же объекта или понятия, например «продажи» (sales). Это в природе человека: большинство из нас не хочет отказываться от того, что понятно и привычно, и переучиваться на нечто новое. Задачу определения имен в модели решает, как правило, «стюард данных» (data steward). Если именно Вам выпало разбираться с этим политическим кошмаром, может оказаться полезным изложенный далее подход из трех шагов. Первые два обычно делаем до того, как знакомить с моделью бизнес-пользователей. Третий – после того, как бизнес-пользователи уже увидели и осознали модель. Читать дальше »

Пользователи часто хотят видеть данные, сгруппированные различным образом. В простейшем случае одно подразделение (к примеру, маркетинговый департамент) имеет свою иерархию клиентов, а другое подразделение (к примеру, отдел продаж) хочет видеть другую иерархию. Если все действительно настолько просто, то имеет смысл включить обе иерархии в измерение «Клиент» и назвать их правильным образом. К сожалению, большее число иерархий, встроенных прямо в измерение, сделает его малопригодным для использования.

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

Большинство реляционных СУБД поддерживают использование значения NULL для представления отсутствующих данных. NULL сбивает с толку как разработчиков хранилищ данных, так и пользователей, потому что СУБД обрабатывает отсутствующие значения иначе, нежели нули и пустые строки, хотя NULL и очень похожи на последние. В этом совете исследуются три основных области, в которых мы сталкиваемся с отсутствующими значениями в исходных данных, и даются рекомендации по действиям в каждой ситуации.

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

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

Недавно мы загрузили простой пример такой дополнительной таблицы, которая отображает почтовые индексы на Маркетинговые Регионы (Media Market Area). Нашим ребятам из Управления Маркетинга было интересно посмотреть, каково распределение доли наших клиентов по маркетинговым регионам в сравнении со всем остальным населением.
Читать дальше »

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

Подсчёт элементов медленно изменяющегося измерения

Проблема состоит в том, чтобы не насчитать больше, чем есть. В таблице медленно изменяющегося измерения (SCD) “Клиент” у нас будет несколько записей для каждого клиента, поэтому простой запрос на подсчёт количества клиентов в определённом регионе возвратит завышенное количество для всех клиентов, данные о которых изменялись (и, соответственно, имеется несколько записей). Кто-то, возможно, склонится к тому, чтобы выполнить подсчёт путём операции COUNT DISTINCT над ключами, уникально идентифицирующими клиентов в оперативной системе, если они доступны. Здесь проблема заключается в том, что если атрибут, по которому вы проводите подсчёт уникальных значений, изменился, как в случае изменения статуса клиента, вы всё же рискуете сделать ошибку, поскольку ключ клиента может быть уникальным в пределах штата. Нам нужен способ ограничения медленно изменяющегося измерения до одной записи на каждого клиента. Мы можем это сделать, если наиболее свежая запись для каждого клиента в таблице измерения будет содержать признак “текущая запись”. Это позволит нам выполнять подсчёт наиболее актуальных состояний клиентов. Вы даже можете создать отдельную таблицу, представление или предопределённый запрос, который будет возвращать записи о клиентах, имеющие только статус “текущая запись”, что позволит их корректно подсчитывать.
Читать дальше »