Infology.Ru

Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite

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

Дата публикации оригинала: 2005-11-07
Автор оригинала: Ralph Kimball
Перевод на русский язык: Татьяна Лякишева
Оригинальный документ располагается здесь

В совете № 69 «Идентифицируем бизнес-процессы» Мардж Росс разъяснила, как важно идентифицировать бизнес-процессы организации при построении модели хранилища данных, и дала рекомендации о том, как это сделать. Теперь углубимся в некоторые детали.
Фокус на бизнес-процессах критически важен для успешной реализации решения в области хранилищ/BI по методу Кимбалла. Бизнес-процессы – это строительные блоки хранилища данных, создаваемого на основе многомерной модели. Мы предлагаем разрабатывать хранилище последовательно, итерационно, захватывая по бизнес-процессу за шаг. Вы спросите: что такого волшебного в бизнес-процессах? Как их выявление поможет нам в моделировании? Ответ заключается в том, что, правильная идентификация бизнес-процессов «запускает» весь процесс проектирования многомерной модели. Я не раскрою особого секрета, если скажу, что каждый бизнес-процесс порождает по крайней мере одну таблицу фактов, поэтому идентификация бизнес-процессов существенным образом определяет и то, какие таблицы фактов мы построим.
Читать дальше »

Многие команды разработчиков излишне рьяно берутся за дело. Они принимаются за разработку раньше, чем  потратят достаточно времени и сил на проектирование модели данных, составление исчерпывающего набора бизнес-правил, планирование процедур загрузки. Они устремляются вперед на всех парах, а в результате получают в хранилище неверные или неполные данные, переделывают свою работу, и доставляют сами себе хлопоты.

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

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

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

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

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

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

Некоторые из вас могут справедливо заметить, что фраза «текстовый факт» является оксюмороном. Тем не менее, мы часто получаем вопросы от наших клиентов или студентов о полях с индикаторами или заметками, которые вроде бы должны находиться в таблице фактов, но при этом не являются показателями, ключами измерений или вырожденными измерениями (см. Совет №46).

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

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

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

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

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

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

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

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

В отличие от Шекспира и некоторых «экспертов» по хранилищам данных, для нас в этом НЕТ вопроса.
В этой статье мы обсудим проблемы, с которыми сталкиваются «взрослеющие» витрины/хранилища данных. В то время как некоторые организации только начинают интересоваться хранилищами данных, другие уже достаточно долго используют их. По мере становления отрасли, причины основных проблем, связанных с хранилищами данных, эволюционируют. В последнее время централизация позиционируется как некий волшебный эликсир. Утверждается, что централизация способна превратить разрозненные витрины данных в «золото» путем уменьшения затрат и увеличения производительности. Хотя централизация и может привести к более эффективной эксплуатации, она, по сути, не решает более важных проблем интеграции и согласованности данных.
Читать дальше »

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

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