Хранилища данных,
OLAP, CRM: информация
 
 На главную | Книги | Ссылки | Рассылка | Письмо автору | RSS

Совет №36
Быть или не быть (централизации)

Материал опубликован с разрешения компании Ralph Kimball Associates
Авторы оригинала: Margy Ross (все статьи) и Bob Becker (все статьи)
Перевод на русский язык: Егор Демьянов
Оригинальный документ располагается здесь.

В отличие от Шекспира и некоторых «экспертов» по хранилищам данных, для нас в этом НЕТ вопроса.

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

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

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

Некоторые аналитики порочат репутацию витрин данных, списывая на этот подход возникновение всей массы проблем. Это грубое обобщение не отражает всей пользы, которую множество организаций получили от своих хорошо спроектированных витрин данных. Проблемы, которые мы перечислили выше, являются результатом отсутствующей, плохо определенной, либо неправильно выполняемой стратегии. И поэтому эти проблемы могут существовать при любом архитектурном подходе, включая корпоративное хранилище данных, архитектуру hub-and-spoke и распределенные/интегрированные витрины.

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

Как мы уже рассказывали, шина хранилища данных – это инструмент для описания общей стратегии интеграции данных в корпоративном хранилище данных. Она является каркасом для интеграции аналитической информации в компании. Шина хранилища данных определяется с помощью матрицы шины (как Ральф писал в статье для Intelligent Enterprise - www.intelligententerprise.com/db_area/archives/1999/990712/webhouse.shtml). Строки матрицы представляют основные бизнес-процессы в компании, а в столбцах представлены общие, согласованные измерения.

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

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

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

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

  • Задокументируйте существующие витрины/хранилища данных в вашей организации, отмечая перекрывающиеся данные.
  • Проведите укрупненную оценку основных неудовлетворенных бизнес-требований.
  • Соберитесь с основными заинтересованными лицами для разработки предварительной матрицы шины хранилища данных.
  • Выделите специалиста или рабочую группу по ведению каждого измерения, которое должно быть согласованным.
  • Спроектируйте согласованные измерения путем слияния атрибутов и/или согласования атрибутов измерения из существующих разрозненных систем. В реальности, это сложная задача договориться по всем атрибутам, но не позвольте этому остановить всю работу.
  • Добейтесь договорённости о согласованных измерениях в масштабе всей организации.
  • Разработайте план по инкрементальному переходу на согласованные измерения.

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

 

По этой теме можно также почитать:

 

Для удобства отслеживания новых публикаций на сайте рекомендую подписаться на рассылку или подписаться на канал RSS.

 

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.

Популярные страницы:

Советы разработчику хранилищ данных

OLAP

Моделирование

Книги

Книги на русском языке

Бесплатные книги

Производители OLAP

CRM

Производители CRM

Управление метаданными

Коллекция ссылок


[AD]

Найти: на

[ На главную | Книги | Ссылки | Рассылка | Письмо автору | Реклама на сайте ]

© Константин Лисянский, 2001-2008.

[AD] [AD] [AD]

Используются технологии uCoz