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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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