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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При описании технологии заполнения Хранилища будем различать три взаимосвязанные задачи: Сбор Данных (Data Acquisition), Очистка Данных (Data Cleansing) и Агрегирование Данных (Data Consolidation).

Под Сбором Данных будем понимать процесс, который состоит в организации передачи данных из внешних источников в Хранилище. Лишь некоторые аспекты этого процесса полностью или частично автоматизированы в имеющихся продуктах. Прежде всего, это относится к интерфейсам с существующими БД. Как правило, здесь имеется несколько возможностей. Во-первых, поддерживаются интерфейсы всех крупных производителей серверов баз данных (Oracle, Informix, ADABAS и т. д.). Во-вторых, практически всегда имеется ODBC-интерфейс, и, в-третьих, можно извлекать данные из текстовых файлов в формате CSV (comma separated values) и из некоторых структурированных файлов, например файлов dBase. Набор имеющихся интерфейсов - важнейшая характеристика, которая часто позволяет оценить, для каких задач проектировался продукт. Так, если среди поддерживаемых интерфейсов имеются AS/400, DB2/400, IMS, VSAM (как в популярном продукте PASSPORT фирмы Carleton), то он предназначен скорее для использования в системах, работающих на больших мэйнфреймах, чем в сети из ПК. Несколько иной набор интерфейсов предлагает, например, хорошо известный продукт InfoPump фирмы PLATINUM Technology, который обеспечивает поддержку Lotus Notes, Microsoft Access, dBase и работу с текстовыми файлами. Крупные производители серверов либо имеют собственные средства сбора данных либо устанавливают партнерские отношения с производителями таких средств и разрабатывают инструментарий промежуточного уровня для тиражирования "чужих" данных (таков, например, Replication Server фирмы Sybase).