Журнал ВРМ World

Мировая история развития технологий управления эффективностью бизнеса – обзоры зарубежных публикаций

Цели и задачи Хранилища данных: Часть 3: Долгосрочные цели

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

Во второй части этой серии статей (DM Review, Октябрь 1999 г.), мы рассмотрели краткосрочные цели Хранилищ данных. В этой статье мы завершаем нашу серию обсуждением долгосрочных целей и важности синхронизации всех задач Хранилища со стратегическими целями конкретной организации.

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

Приведем несколько примеров долгосрочных целей реализации Хранилища данных:

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

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

  • Все ли различные представления одинаковых данных вы выявили.
  • Какие представления вы планируете согласовать в рамках вашего проекта.
  • Какими представлениями вы не будете заниматься в рамках вашего проекта.

Обеспечьте объединенную (консолидированную) картину корпоративных данных. Одним из результатов вашего проекта будет входящая в него логическая модель данных. Добавляя новые данные и новые требования в последующие этапы создания Хранилища данных, вы расширите логическую модель данных. Спустя некоторое время эта модель вырастет в консолидированную картину корпоративных данных в рамках Хранилища данных.

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

Создайте виртуальную среду, предоставляющую все, что необходимо, за одно обращение.

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

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

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

Инструменты доступа к данным. Вторым уровнем этой архитектуры является набор инструментов доступа к данным. Он должен включать библиотеку запросов, хранящую запросы, заранее написанные с использованием этих инструментов или на собственном SQL.

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

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

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

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

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

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

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

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

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

Эта статья является фрагментом книги Управление проектом Хранилища данных, вышедшей в издательстве Addison Wesley Longman 08.09.2000 г.

Автор: Ларисса Мосс, Сид Эйдельмен