Краткосрочные и долгосрочные задачи хранилища данных

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

Ларисса Мосс, Сид Эйдельмен, перевод Intersoft Lab.

В первой статье серии (DM Review, Сентябрь 1999), мы выявили недостатки традиционных СППР и упомянули сложности в управлении данными.
Теперь мы можем оценить ту роль, которую хранилище данных играет, или должно играть, в решениях в области управления данными. Хранилище данных не является еще одной базой данных СППР. Это среда, состоящая из одной или более баз данных, спроектированная для доставки соответствующего и согласованного бизнес-анализа (business intelligence) во все бизнес-подразделения организации.
Чтобы избежать той же беды, которая постигла информационный инжиниринг при попытках решить все проблемы управления данными за один ударный подход, вам потребуется разделить задачи вашего хранилища данных на две категории: краткосрочные и долгосрочные цели.

Краткосрочные цели

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

Улучшайте качество данных

Поскольку обычным недостатком СППР являются "грязные данные", вы почти гарантировано будете уделять внимание качеству своих данных на каждом этапе реализации хранилища данных. Очистка данных представляет собой достаточно неприятную проблему в организации хранилищ. С одной стороны, предполагается, что хранилище данных обеспечит чистые, интегрированные, соответствующие и согласованные данные, извлеченные из множества источников. С другой стороны, мы стоим лицом к лицу с расписанием разработки, составленным в расчете на 6-12 месяцев. Практически невозможно достичь обеих целей одновременно, не идя на какие-либо компромиссы. Трудность в том, чтобы определиться с существом этих компромиссов. Здесь мы приводим некоторые руководящие принципы для выявления ваших специфических задач при очистке ваших исходных данных:
Никогда не пытайтесь очистить ВСЕ данные. Каждому хотелось бы иметь тщательно очищенные данные, но никто не согласен платить за это или ждать когда процесс очистки завершиться. Очистка вообще всех данных займет слишком много времени. Затраченное время и стоимость как правило превышают выигрыш.
Никогда не говорите, что очищать НЕЧЕГО. Другими словами, всегда планируйте что-либо очищать. В конце концов, одна из причин создания хранилища данных - это необходимость обеспечить более чистые и надежные данные, чем содержащиеся в имеющихся у вас системах OLTP и СППР.
Определите, какие преимущества вы получите от очистки данных.
Исследуйте основания для построения хранилища данных:

• Имеются ли у вас несовместимые отчеты?


• Что является причиной их несовместимости?


• Являются ли причиной "грязные данные" или это программные ошибки?


• Сколько денег вы теряете из-за "грязных данных"?


• Какие данные загрязнены?

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

• Анализ данных.


• Определение корректных значений данных и корректирующих алгоритмов.


• Написание программ очистки данных.


• Исправление старых файлов и баз данных (если это необходимо).

Сравните стоимость очистки с ценой потерь от того, что данные останутся грязными. В бизнесе все должно быть обосновано с точки зрения затрат. Это применимо и к очистке данных. Сравните стоимость очистки для каждого элемента данных с потерями, которые понесет бизнес при том, что они останутся грязными, и решите, включать ли его в вашу задачу по очистке данных. Если финансовые потери превысят стоимость очистки, внесите этот элемент в список данных "на очистку". Если стоимость очистки превысит финансовые потери, не вносите данные в этот лист.
Расставьте приоритеты в данных, которые вы предполагаете очищать. Сложность компромиссов в том, что необходимо уравновесить время, затрачиваемое на проект, и цели, которые вы пытаетесь достичь. Даже если вы были осторожны в отборе данных для очистки, у вас все равно будет слишком много данных в списке "на очистку". Расставьте приоритеты в вашем списке.
После расстановки приоритетов, про каждый элемент данных из списка спросите: Может ли он быть очищен? Возможно, вам придется провести некоторое исследование для выяснения, не остались ли "хорошие данные" еще где-либо. Объектами поиска могут стать другие файлы и базы данных, старая документация, папки с руководствами и даже ящики стола. Иногда значения данных настолько закручены, что для написания преобразовательной логики вам придется искать каких-нибудь "патриархов", которые все еще помнят, что означают все эти величины. Затем будет время, когда, после нескольких дней исследования, вы обнаружите, что вы не можете очистить некоторый элемент данных, даже если хотите; и вам придется изымать этот пункт из вашей задачи по очистке данных.
Поскольку вы задокументировали вашу задачу по очистке данных, вам надо будет включить в нее следующую информацию:

• Степень текущей "загрязненности" (в процентах либо в количестве записей).


• Финансовые потери от этой "загрязненности".


• Стоимость соответствующей очистки.


• Степень "чистоты", который вы хотите достичь (в процентах либо в количестве
  записей).

Сведите к минимуму количество несовместимых отчетов

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

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

• Насколько серьезно они нарушают решения бизнеса?


• Каковы финансовые потери от неверных решений?


• Насколько значимы различия?


• Насколько сложно согласовать эти отчеты?

Определите стоимость рассмотрения этих проблем с данными в процессе обсуждения. Оцените, сколько времени займет:

• Убедить заинтересованные бизнес-подразделения принять участие в процессе урегулирования разногласий между ними?


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


• Отделить согласующиеся представления от несогласующихся?


• Прийти к пониманию определений и содержимого данных для согласованного представления?


• Создать новые данные для несогласующихся представлений?


• Прийти к пониманию определений и содержимого новых данных?

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

• Степень воздействия на решения бизнеса.


• Финансовые потери от разногласий относительно данных.


• Стоимость урегулирования этих разногласий.


• Степень "разрешения", которую вы хотите достичь.

Например, должны ли прийти к согласию все пользователи или достаточно согласия только двух основных пользователей? Должны ли согласиться все 100% или допустимо 5% расхождение? Если решение не может быть принято в течение X дней, можно ли не исключить эти данные?

Захватите и обеспечьте доступ к метаданным

Метаданные до сих пор рассматривались как грязное слово на букву Д: документация. Тем не менее, метаданные необходимы для совместного доступа к данным и навигации по ним.
Совместный доступ к данным. Сегодня к большинству данных нет совместного доступа по ряду причин. Одной причиной является непонимание данных, а другой - недоверие к содержимому данных. Мы уже установили тот факт, что в целях решения этой проблемы пользователям следует обсудить свои взгляды на данные и выявить общие черты и различия этих взглядов. Две основных цели этой дискуссии представляют собой согласованные со всеми определения данных и домены (допустимые значения данных). Поскольку эти две цели часто неправильно понимаются и объявляются недостижимыми и просто напрасной тратой времени, мы должны четко представлять себе, что мы понимаем под этими целями.
Процесс достижения согласованных со всеми определений и доменов не означает, что сотни пользователей будут препираться до бесконечности о том, кто прав, а кто нет, а желаемый результат не является декларацией о победе наиболее сильного пользователя, навязавшего свою точку зрения остальным. Процесс включает небольшую группу людей, обычно состоящую из пяти-шести человек, включающую лиц, в чьи функции входит облегчение выполнения проекта, владельца данных и по одному официальному представителю от каждого бизнес-подразделения, использующего эти данные для принятия важных решений для бизнеса. Когда значительные разногласия касаются значения или содержимого данных, это признак высокой вероятности того, что все несогласные стороны "правы" и что существует более одного элемента данных. Возможно, это изучается в течение заранее определенного краткого периода времени, обычно не более нескольких дней, и создается новый элемент данных, название и определение которому дается этой группой. Если исследование не рождает новый элемент, владелец данных принимает окончательное решение по определению и содержимому. Принимая во внимание, что несогласные стороны не конфликтуют между собой, определение и содержимое, до некоторой степени, будет включать любой обоснованный вариант, понятный остальным заинтересованным бизнес-подразделениям. Теперь согласованные определения и содержимое для исходных и новых элементов данных задокументированы в репозитории метаданных и доступны всем пользователям организации.
Навигация по данным. Мы предпочитаем думать о метаданных как о приятном слове на букву Н: навигация. Как только исходные данные очищены, преобразованы, агрегированы, просуммированы и рассечены несколькими различными способами, пользователи никогда снова не найдут их в хранилище без помощи метаданных. Захват метаданных (то есть, определений данных, доменов, алгоритмов преобразования исходных данных, столбцы и таблицы, в которых находятся результирующие данные, и все другие технические компоненты) представляют собой только половину решения. Другой половиной является обеспечение простого доступа пользователей к данным и их полезности для пользователей.

Обеспечьте возможность совместного доступа к данным

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

Проектирование базы данных

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

• более низком уровне деталей и степени детализации, необходимой для удовлетворения всех различных потребностей в данных;
  
• типе доступа, необходимом для различных бизнес-подразделений.
  

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

• Уровнем технической грамотности пользователей.


• Бизнес-знаниями.


• Уровнем детализации, необходимым всем пользователям.


• Требующимися типами суммирования и агрегации.


• Типами запросов, которые будет писать каждый пользователь.


• Необходимой периодичностью (то есть, ежедневные, еженедельные или ежемесячные снимки).

Доступ к базе данных.

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

• Общий уровень технической грамотности.


• Типы запросов, которые они способны написать.


• Нужно ли им манипулировать результатами запросов.


• Какие суммарные представления им нужны.


• Какие незапланированные возможности, в отличие от написания отчетов, им требуются.


• Как часто они буду обращаться к системе.


• Есть ли у них предыдущий опыт работы с инструментом составления запросов или отчетов.


• Уровень их мастерства в использовании таких инструментов.


• Их способность и скорость в изучении новых инструментов.

Эта информация будет иметь наибольшую ценность для оценки и выбора инструментария, а также пригодится при обучении.

Интегрируйте данные из множества источников

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

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

• Имеют ли ключи к одним и тем же данным одни и те же типы, длины и домен данных.


• Идентифицируются ли одни и те же данные одним и тем же значением ключа.


• Могут ли быть реализованы новые отношения между данными.


• Степень детализации содержимого данных.


• Периодичность модернизации данных.

Соедините исторические данные с текущими данными

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

Сказав все это, вы должны определить следующие детали вашей задачи по соединению исторических данных с текущими данными:

• Число лет, для которого вы хотите хранить историю.


• Будет ли история собираться с этого момента и далее (начальная загрузка) или вы загрузите некоторое количество ("X") прошлых лет.


• Имеют ли исторически файлы такую же структуру записей.


• Изменится ли формат данных с течением времени.


• Изменится ли домен (допустимые значения) с течением времени.


• Изменится ли иерархия организации с течением времени.


• Каков в действительности объем истории, присутствующий на диске или ленте.

Следите за реалистичностью целей

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

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

Долгосрочные цели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда вы определяете цели и задачи реализации вашего хранилища данных, продолжайте задавать себе вопросы:

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

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

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

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

Оригинал статьи в формате Adobe Acrobat