Infology.Ru

Наши хранилища данных все больше и больше направлены на отслеживание детальных транзакций клиентов в почти реальном времени. Как указывает Patricia Seybold в своей замечательной книге Customers.com (Time Business, 1998), управление взаимоотношениями с клиентами означает наличие доступа к данным от всех процессов в организации, которые имеют дело с ними.

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

Дата публикации оригинала: 2005-02-08
Автор оригинала: Margy Ross
Перевод на русский язык: Олег Кузьменко
Оригинальный документ располагается здесь

Наверное, это просто совпадение, но в последнее время несколько человек задали мне схожий вопрос: «Следует ли командам хранилищ данных (DW) или business intelligence (BI) собирать требования от бизнеса?». Честно говоря, у меня волосы встают дыбом от такой постановки вопроса. Я обеспокоена тем фактом, что слишком много организаций чересчур обособили свои подразделения DW/BI.

Конечно, до некоторой степени это разграничение является естественным, особенно когда ресурсы, отведенные на DW/BI, растут по мере расширения инфраструктуры, создавая очевидные проблемы с нормой управляемости (наиболее простое определение этого термина: количество прямых подчинённых у одного менеджера - прим. переводчика). Также разделение труда позволяет специализацию. Если провести аналогию между инфраструктурой DW/BI и рестораном, то можно сказать, что некоторые члены команды чрезвычайно искусны в приготовлении блюд на кухне, в то время как другие очень заботливы и внимательны по отношению к клиентам, обеспечивая тем самым их повторный визит. Существует, насколько можно ожидать, немного официантов, которым вдруг следует облачиться в одеяния шеф-повара, и наоборот.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует распространенный миф, что ETL-инструменты самодокументируются. Это верно только в сравнении с самописными системами. Не верьте этому! Всегда нужно проектировать архитектуру ETL-системы. И всегда нужно документировать эту систему. Да, нужно писать документ.

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

ETL-поток начинается с передачи из источника (source system) в хранилище (DHW) свежей порции данных. Почти в любом хранилище требуется передавать только данные, изменившиеся с момента предыдущей загрузки. Полное обновление таблиц фактов (fact) и измерений (dimension) обычно нежелательно.

Вычленение в источнике только новых данных называется «захват изменившахся данных» (changed data capture) и часто сокращается до CDC в архитектурных диаграммах. Идея CDC кажется достаточно простой: передавать данные, которые изменились с момента последней загрузки. Но создать хорошую систему CDC не так просто, как кажется.
Читать дальше »

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

Как многие из вас Warren Thornthwaite и я работали с пререлизами Microsoft SQL Server 2005. Мы также добавляли последние штрихи в нашу новую книгу - The Microsoft Data Warehouse Toolkit ( Wiley, December 2005). Одна из задач, с которой мы столкнулись во время создания книги и во время консультирования наших клиентов, использующих SQL сервер, это стоит ли реализовывать ваше хранилище данных на платформе Microsoft на реляционной СУБД, на Analysis Services или на обоих? Ответ - в большинстве случаев на обоих.

Поскольку в течение многих лет создавались реляционные хранилища данных, очевидно, что это возможно. Microsoft добавил интересную функциональность в многомерную СУБД Analysis Services 2005, что по крайней мере в теории, делает возможным создать многомерную базу данных непосредственно из транзакционной системы, минуя реляционное хранилище данных. Но действительно ли это хорошая идея?
Читать дальше »