Технология разработки и внедрения Хранилищ Данных

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

Особое назначение модели предприятия – определение и формализация данных, необходимых в процессе принятия решения. Существуют два подхода к бизнес-анализу:

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

2. анализ бизнес-событий. Он используется при проектировании СППР на основе ХД и обеспечивает наибольшую эффективность:

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

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

• объединяет управляющие и информационные потоки;

• наглядно показывает, какая именно информация нужна при обработке бизнес-события и в каком виде она представляется.

Т.е., бизнес-событие имеет более тесную связь с информационными и управляющими потоками, чем бизнес-процесс.

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

• распределение пользователей системы: географическое, организационное, функциональное;

• доступ к данным: объем данных, необходимый для анализа, уровень агрегированности данных, источники данных (внешние или внутренние), описание информации, используемой совместно различными функциональными группами предприятия;

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

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

3. Витрины Данных

Идея Витрины Данных (Data Mart) возникла сравнительно недавно, когда стало очевидно, что разработка корпоративного хранилища – долгий процесс. Это обусловлено как организационными, так и техническими причинами:

• информационная структура реальной компании, как правило, очень сложна, и руководство зачастую плохо понимает суть происходящих в компании бизнес-процессов;

• технология принятия решений ориентирована на существующие технические возможности;

• может возникнуть необходимость в частичном изменении организационной структуры компании;

• требуются значительные инвестиции до того, как проект начнет окупаться;

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

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

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

Витрина Данных – специализированное хранилище, которое обслуживает одно из направлений деятельности компании (например: учет запасов или маркетинг). Происходящие здесь бизнес-процессы, во-первых, относительно изучены, а во-вторых, не столь сложны, как процессы в масштабах всей компании. Количество сотрудников, занимающихся конкретной деятельностью невелико (рекомендуется, чтобы Витрина обслуживала не более 10-15 человек). Стоимость такого проекта значительно ниже стоимости разработки корпоративного Хранилища. Необходимо заметить, что разработка такого проекта способствует продвижению новой технологии и приводит к быстрой окупаемости затрат. Следовательно, необходимо запараллелить процессы разработки корпоративного Хранилища и разработку, и внедрение Витрин Данных.

Витрины Данных дешевле и проще в построении и базируются на более дешевых серверах Microsoft Windows NT, а не мультипроцессорных UNIX-комплексах. Но рост числа Витрин вызывает сложность их взаимодействия, так как не удается сделать витрины полностью независимыми. Витрины Данных нацелены на специфические нужды определенной службы, занимающейся либо закупками, либо произведенными товарами, либо планированием. Преимущество Витрин данных, по сравнению с Хранилищем, состоит в возможности быстрого получения сведений для поддержки решений в нужном месте, не задействуя при этом информационную систему всей корпорации. В то же время витрины данных могут быть и частью хранилища. Из хранилищ данных информация «перетекает» в различные отделы, отфильтровываясь в соответствии с заданными настройками СППР. Витрины хранят обобщенную информацию, тогда как более подробные данные можно найти в Хранилище. Пользователи имеют доступ к подмножествам хранилищ (т.е. к витринам данных), что улучшает обработку отдельных запросов, а к хранилищам обращаются лишь в случае необходимости. Такая стратегия обеспечивает важное преимущество, – реализуется единый подход к корпоративным данным. В витрины данных направляются копии информации из единого хранилища, и сотрудники разных подразделений на свои вопросы не рискуют получить разные ответы.

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

Сочетание взаимосвязанных хранилищ и витрин данных увеличивает производительность: в витрины данных в стиле OLAP (On-line Analytical Processing – оперативный анализ данных) помещаются заранее агрегированные данные из хранилища, что ускоряет обработку запроса, т.к. обрабатывается меньший объем данных, разбитых уже на категории. Это эффективно в том случае, если данные не подвержены частым изменениям. В противном случае придется часто проводить реорганизацию базы данных. Что целесообразнее применять: единое хранилище; самостоятельные витрины данных; витрины, связанные с хранилищем; витрины, соединенные с неким промежуточным программным обеспечением? На этот вопрос однозначного ответа нет, т.к. оптимальный вариант вытекает из требований бизнеса, интенсивности запросов, сетевой архитектуры и необходимости быстрой реакции.

Хранилище Метаданных (Репозиторий)

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

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

Широко известны Репозитории, входящие в состав популярных САSE-средств (Power Designer (Sybase), Designer 2000 (Oracle), Silverrun (CSA Research)), систем разработки приложений (Developer 2000 (Oracle), Power Builder (Sybase)), администрирования и поддержки информационных систем (Platinum, MSP). Все они, однако, решают частные задачи, работая с ограниченным набором метаданных, и предназначены, и основном, для облегчения труда профессионалов — проектировщиков, разработчиков и администраторов информационных систем.

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

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

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

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

• организация прав доступа к метаданным;

• блокировка и разрешение конфликтов при совместном использовании метаданных (что очень часто возникает при изменении общих бизнес-понятий в рампах структурного подразделения);

• разделение метаданных между Витринами Данных;

• согласование метаданных ХД с Репозиториями САSE-средств, применяемых при проектировании и разработке Хранилищ;

• реализации пользовательского интерфейса с Репозиторием.

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

Поскольку большинство СASE-средств использует различные форматы метаданных, поставщики систем управления метаданными выработали стандарт обмена MDIS, обеспечивающий возможность интеграции CASE-средств в СППР на основе ХД. К сожалению, не все предлагаемые сегодня на российском рынке продукты соответствуют этому стандарту, поэтому преобразование форматов метаданных представляют собой достаточно сложный процесс, упростить который призваны специализированные программные продукты, в том числе, например, средства фирмы Evolutionary Technologies International или Prism Solutions (Data Warehouse Directory).

По завершении разработки структуры метаданных и системы управления ими, решается задача заполнения и обновления данных в ХД.

Загрузка Хранилища

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

При описании технологии заполнения Хранилища различают три взаимосвязанные задачи:

• Сбор Данных (Data Acquisition),

• Очистка Данных (Data Cleansing) и

• Агрегирование Данных (Data Consolidation).

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

1. поддерживаются интерфейсы всех крупных производителей серверов баз данных (Oracle, Informix, ADABAS и т. д.);

2. практически всегда имеется ODBC-интерфейс;

3. можно извлекать данные из текстовых файлов в формате CSV (comma separated values) и из некоторых структурированных файлов, например файлов dBase.

Набор имеющихся интерфейсов — важнейшая характеристика, которая часто позволяет оценить, для каких задач проектировался продукт. Так, если среди поддерживаемых интерфейсов имеются AS/400, 052/400, IMS, VSAM (как в популярном продукте PASSPORT фирмы Carleton), то он предназначен скорее для использования в системах, работающих на больших мэйнфреймах, чем в сети из ПК. Несколько иной набор интерфейсов предлагает, например, хорошо известный продукт InfoPump фирмы PLATINUM Technology, который обеспечивает поддержку LotusNotes, Microsoft Access, dBase и работу с текстовыми файлами. Крупные производители серверов либо имеют собственные средства сбора данных, либо устанавливают партнерские отношения с производителями таких средств и разрабатывают инструментарий промежуточного уровня для тиражирования «чужих» данных (таков, например, Replication Server фирмы Sybase).

Рис. 1.8. Склад данных с простой архитектурой клиент-сервер

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

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

Агрегация – отношение «часть - целое».

При заполнении Хранилища агрегированными данными мы должны обеспечить выборку данных из транзакционной базы данных и других источников в соответствии с метаданными, поскольку агрегирование происходит в терминах бизнес-понятий. Так, например, агрегированная величина «объем продаж продукта Х в регионе Y за последний квартал» содержит понятия «продукт» и «регион», которые являются бизнес-понятиями данного предприятия. Следует подчеркнуть, что задача выборки необходимых данных не может быть решена полностью автоматически: возможны коллизии (отсутствие необходимых данных, ошибки в данных и т. п.), когда вмешательство человека окажется необходимым. Далее, предполагая, что объектом анализа являются числовые показатели, связанные с бизнес-понятиями, такие как ОБЪЕМ ПРОДАЖ или ПРИБЫЛЬ, когда необходимо определить правила вычисления этих показателей для составных бизнес-понятий, исходя из их значений для более простых бизнес-понятий. Это и есть правила агрегирования.

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

Переход к базам данных клиент-сервер – относительно небольшой скачок в развитии хранилища данных. На рис. 1.8 и 1.9 показаны две альтернативные архитектуры хранилища данных, основанные на современной модели клиент-сервер.

На рис. 1.8 приложение EIS, написанное на языке Xbase осуществляет доступ к централизованному SQL-хранилищу данных посредством прикладного программного интерфейса ODBC. В такой среде довольно легко реализовать простейшую модель клиент-сервер, где один сервер обслуживает несколько клиентов.

На рис. 1.9 представлен более сложный вариант архитектуры клиент-сервер.

Доступ к логически централизованному на множестве платформ, осуществляется так же, как и в примере на рис. 1.8. Однако внутри хранилища данных для доступа к его распределенным компонентам применяется комбинация интерфейсов IDAPI и DRDA API. В таком случае приложение, выполняющееся над хранилищем данных, выступает в двоякой роли: как сервер для комплекса приложений EIS и как клиент, запрашивающий информацию у других серверов хранилища данных.

IDAPI

IDAPI

DRDA

Рис.1.9. Распределенный склад данных со сложной архитектурой клиент-сервер