Infology.Ru

Авторы: Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite

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

Купить книгу на Amazon.com

А, вот это второе издание этой книги, вышедшее в январе 2008 года.

Авторы: Ralph Kimball, Margy Ross, Warren Thorntwaite, Joy Mundy, Bob Becker

Я пока её не прочитал - заказал, получил и поставил в очередь на чтение. Прочитаю, отпишу. Если кто-то уже прочитал, просьба поделиться своими мыслями.

Купить второе издание на Amazon.com

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

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

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

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

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

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

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

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

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

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

Другими словами, мы хотим знать, в каких регионах наши позиции сильны, а в каких - не очень. Если эти дополнительные данные окажутся ценными для организации, мы продолжим их использование и добавим их в качестве дополнительных атрибутов к измерению “Клиент”. Но для начала мы хотим выполнить несколько запросов, чтобы убедиться в том, что эти затраты оправдаются.

Чтобы выполнить эти запросы, мы соединяем дополнительную таблицу с таблицей, хранящей информацию о клиентах, и выполняем подсчёт клиентов для каждого маркетингового региона. Однако мы должны быть внимательными, поскольку эти два набора данных не пересекаются на 100%. В таблице маркетинговых регионов есть почтовые индексы, для которых нет соответствующих записей о клиентах, и есть записи о клиентах, которым не соответствует ни один почтовый индекс маркетинговых кодов. Внутреннее соединение приведёт к тому, что мы недосчитаемся записей из обеих таблиц. Для иллюстрации этого можно использовать следующие две таблицы:

Если мы хотим увидеть, сколько клиентов у нас в каждом маркетинговом регионе, внутреннее соединение даст нам следующий результат:

Внутреннее соединение является соединением “по равенству”. Поскольку для почтового индекса 24166 нет эквивалентного маркетингового региона, запрос недосчитывает наших подписчиков, возвращая четырёх клиентов, вместо пяти. Мы также теряем информацию с другой стороны соединения, поскольку в результате запроса отсутствуют данные о регионах, в которых у нас нет клиентов (например, Gloucester). Переписав запрос с использованием полного внешнего соединения, мы получим следующий результат:

Теперь мы посчитали всех пятерых клиентов и увидели, что в регионе Gloucester они отсутствуют. Мы могли бы использовать функцию IFNULL для замены значения NULL на более дружественные значения, например, “неизвестный регион”. Заметьте, то, что вы считаете, сильно влияет на результаты. В нашем случае мы считали значения столбца Customer_Key. Если бы мы заменили это на count(*), мы могли бы в результате получить 7, поскольку * означает подсчёт всех строк, а полный результат состоит из семи строк. Если бы мы стали считать количество значений столбца MMA_to_Zipcode.Zip_Code, мы насчитали бы 6 значений, поскольку значение 94025 встречается два раза.

При использовании внешних соединений надо проявлять осторожность, можно легко разрушить логику, введя ограничение на одну из участвующих в соединении таблиц. Ограничение вида Customer_Age<25 привело бы к отчёту с абсолютно идентичной структурой и заголовками, но с меньшим количеством клиентов. Отчёт будет сбивать с толку, если явно не проставить названия.

Мы обнаружили, что комбинирование выражения CASE с функцией SUM является отличной хитростью, позволяющей выполнять в один проход подсчёт строк различных подмножеств полных результирующих наборов данных с обеих сторон полного внешнего соединения. Используя те же самые данные, что и в примерах выше, мы могли бы создать запрос, который возвратит нам полное количество записей для всех трёх областей набора данных. В операторе SELECT вы бы написали:

Sum(case when Media_Market_Area.Zip IS NULL then 1 else 0 end) AS Customer_Count_with_No_MMA,

Sum(case when count(customer_key)=0 then 1 else 0 end) as MMA_Count_with_No_Customers,

Sum(case when not(Media_Market_Area.Zip IS NULL or count(customer_key)=0) then 1 else 0 end as Count_MMAs_with_Customers)

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

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Warren Thornthwaite
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь

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

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

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

Подсчёт за промежутки времени

Подсчёт текущего количества элементов измерения очень полезен, однако реальную сноровку нужно демонстрировать при подсчёте на определённую дату из всей истории. Понимание того, как величины изменяются со временем, является одной из задач хранилища данных. Знание того, что на данный момент у нас 2311 клиентов полезно, а возможность сравнить эту величину с количеством клиентов год назад - ещё полезнее. Чтобы проводить исторические подсчёты подобного рода, вам понадобится медленно изменяющееся измерение. Например, чтобы подсчитать количество клиентов на конец 1999 года вы могли бы воспользоваться фильтром Row_Begin_Date<=’12/31/1999′ AND Row_End_Date>=’12/31/1999′ (выбор операций сравнения зависит от того, как вы установили ваши даты начала и окончания). В этом примере мы предположили, что когда в таблице измерения изменяется запись о клиенте, значение поля row_end_date первой записи на один день меньше значения поля row_begin_date второй записи, а наличия нескольких изменений в день не допускаются.

Если вы, действительно, хотите проявить воображение, то вместо прямого ограничения полей таблицы измерения “Клиент”, вы можете использовать всю мощь таблицы измерения “Период” для предоставления требуемой даты или даже нескольких дат. Используйте для этого те же самые операции сравнения для того, чтобы создать два соединения по неравенству с использованием поля Date вашей таблицы Period и полями Row_Begin_Date и Row_End_Date вашей таблицы измерения “Клиент”. Затем введите ограничение на значение поля Date таблицы Period, чтобы оно было равно требуемой дате. При этом вы сможете включить поле Date в результат выборки, чтобы увидеть, к какой дате относится искомое количество клиентов. Для того чтобы одним запросом посчитать количество для более, чем одной даты, например для последнего дня каждого года, уберите ограничение на поле Date таблицы Period, и добавьте ограничение Month_End_Flag=’y’. Оператор SQL выглядел бы следующим образом:

SELECT Period.Date, Customer.State, COUNT(Customer.Customer_Key)
FROM Customer, Period
WHERE Customer.Row_Begin_Date <=Period.Date
AND Customer.Row_End_Date >=Period.Date
AND Period.Month_End_Flag =’y’

Заметьте, что такой тип соединения по неравенству между таблицей Period и таблицей измерения может представлять трудности для ядра СУБД при больших размерах измерений. В нашем случае, мы построили битовые индексы (bitmapped indexes) по обоим полям с датами и получили неплохую производительность.

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

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Warren Thornthwaite
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь