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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Марк Скот (Mark@microendeavors.com) руководит подразделением специальных проектов в компании Micro Endeavors, Inc.. Эта компания является партнером корпорации Microsoft в ранге Microsoft Solution Provider Partner, а также представляет собой сертифицированный учебный центр Microsoft (Certified Technical Education Center) в штате Пенсильвания. Он обладает сертификатами MSCE+I, MCSD, MCDBA и MCT. Консультирует и преподает средства разработки корпорации Microsoft и продукты BackOffice.