Цели и задачи Хранилища данных: Часть 2: Краткосрочные цели

В этом номере Журнала Клуба знатоков мы предлагаем вашему вниманию подборку
статей по проблематике Хранилищ данных.
Первый материал представляет собой фрагмент книги "Управление проектом
Хранилища данных", вышедшей в издательстве Addison Wesley Longman 8 сентября
2000 г., и одновременно является одной из трех статей цикла, опубликованного в
DM Review и освещающего особенности современных Хранилищ данных. В этом цикле
авторы демонстрируют системный подход к построению Хранилища, призванный помочь
специалистам определиться с приоритетами и задачами на этапе его
проектирования. Однако такой подход будет большим подспорьем не только при
создании Хранилищ "с нуля", но и при внедрении готового Хранилища. Данная
статья рассматривает краткосрочные цели, то есть цели, которые могут быть
достигнуты на каждом из этапов реализации Хранилища данных. По каждой цели
даются конкретные рекомендации относительно путей ее достижения при
проектировании, реализации и внедрении Хранилища. Кроме того, в статье
представлен обзор проблем, с которыми могут столкнуться лица, связанные с таким
проектом.

В первой статье серии (DM Review, Сентябрь 1999), мы выявили недостатки традиционных СППР и упомянули сложности в управлении данными.

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

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

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

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

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

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

Никогда не говорите, что очищать НЕЧЕГО. Другими словами, всегда планируйте что-либо очищать. В конце концов, одна из причин создания Хранилища данных - это необходимость обеспечить более чистые и надежные данные, чем содержащиеся в имеющихся у вас системах OLTP и СППР.

Определите, какие преимущества вы получите от очистки данных. Исследуйте основания для построения Хранилища данных:

• Имеются ли у вас несовместимые отчеты?
• Что является причиной их несовместимости?
• Являются ли причиной "грязные данные" или это программные ошибки?
• Сколько денег вы теряете из-за "грязных данных"?
• Какие данные загрязнены?

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

• Анализ данных.
• Определение корректных значений данных и корректирующих алгоритмов.
• Написание программ очистки данных.
• Исправление старых файлов и баз данных (если это необходимо).

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

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

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

Поскольку вы задокументировали вашу задачу по очистке данных, вам надо будет включить в нее следующую информацию:

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

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

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

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

Определите влияние совокупности несовместимых отчетов:

• Насколько серьезно они нарушают решения бизнеса?
• Каковы финансовые потери от неверных решений?
• Насколько значимы различия?
• Насколько сложно согласовать эти отчеты?

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

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

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

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

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

• Степень воздействия на решения бизнеса.
• Финансовые потери от разногласий относительно данных.
• Стоимость урегулирования этих разногласий.
• Степень "разрешения", которую вы хотите достичь.

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

Метаданные до сих пор рассматривались как грязное слово на букву Д: документация. Тем не менее, метаданные необходимы для совместного доступа к данным и навигации по ним.

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

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

Навигация по данным. Мы предпочитаем думать о метаданных как о приятном слове на букву Н: навигация. Как только исходные данные очищены, преобразованы, агрегированы, просуммированы и рассечены несколькими различными способами, пользователи никогда снова не найдут их в Хранилище без помощи метаданных. Захват метаданных (то есть, определений данных, доменов, алгоритмов преобразования исходных данных, столбцы и таблицы, в которых находятся результирующие данные, и все другие технические компоненты) представляют собой только половину решения. Другой половиной является обеспечение простого доступа пользователей к данным и их полезности для пользователей.

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

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

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

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

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

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

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

• Общий уровень технической грамотности.
• Типы запросов, которые они способны написать.
• Нужно ли им манипулировать результатами запросов.
• Какие суммарные представления им нужны.
• Какие незапланированные возможности, в отличие от написания отчетов, им требуются.
• Как часто они буду обращаться к системе.
• Есть ли у них предыдущий опыт работы с инструментом составления запросов или отчетов.
• Уровень их мастерства в использовании таких инструментов.
• Их способность и скорость в изучении новых инструментов.

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

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

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

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

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

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

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

• Число лет, для которого вы хотите хранить историю.
• Будет ли история собираться с этого момента и далее (начальная загрузка) или вы загрузите некоторое количество ("X") прошлых лет.
• Имеют ли исторически файлы такую же структуру записей.
• Изменится ли формат данных с течением времени.
• Изменится ли домен (допустимые значения) с течением времени.
• Изменится ли иерархия организации с течением времени.
• Каков в действительности объем истории, присутствующий на диске или ленте.

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

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

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

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

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