При проектировании структуры хранилища часто возникает желание использовать как можно больше агрегатов и за счет этого повысить производительность системы. Нетрудно подсчитать, что для модели "звезда" с 10 измерениями можно построить 10!=3.63 миллиона различных агрегированных значений, размещение которых в памяти при установлении связей с соответствующими измерениями приведет к резкому увеличению занимаемого дискового пространства и замедлению доступа к данным. Другая крайность состоит в использовании слишком малого числа агрегатов, а это может привести к необходимости выполнять агрегирование динамически, что заметно снижает эффективность запросов. По некоторым оценкам, при определении оптимального количества агрегатов следует придерживаться принципа 80:20 - 80% ускорения достигается за счет использования 20% кандидатов на агрегаты.
Идея Витрины Данных (Data Mart) возникла несколько лет назад, когда стало очевидно, что разработка корпоративного хранилища - долгий и дорогостоящий процесс. Это обусловлено как организационными, так и техническими причинами:
- информационная структура реальной компании, как правило, очень сложна, и руководство зачастую плохо понимает суть происходящих в компании бизнес-процессов;
- технология принятия решений ориентирована на существующие технические возможности и с трудом поддается изменениям;
- может возникнуть необходимость в частичном изменении организационной структуры компании;
- требуются значительные инвестиции до того, как проект начнет окупаться;
- как правило, требуется значительная модификация существующей технической базы;
- освоение новых технологий и программных продуктов специалистами компании может потребовать много времени;
- на этапе разработки бывает трудно наладить взаимодействие между разработчиками и будущими пользователями Хранилища.
В совокупности это приводит к тому, что разработка и внедрение корпоративного хранилища требуют значительных усилий по анализу деятельности компании и переориентации ее на новые технологии. Витрины Данных возникли в результате попыток смягчить трудности разработки и внедрения Хранилищ.
Сейчас под Витриной Данных понимается специализированное Хранилище, обслуживающее одно из направлений деятельности компании, например учет запасов или маркетинг. Важно, что происходящие здесь бизнес-процессы, во-первых, относительно изучены и, во-вторых, не столь сложны, как процессы в масштабах всей компании. Количество сотрудников, вовлеченных в конкретную деятельность, также невелико (рекомендуется, чтобы Витрина обслуживала не более 10-15 человек). При этих условиях удается с использованием современных технологий развернуть Витрину подразделения за 3-4 месяца. Необходимо отметить, что успех небольшого проекта (стоимость которого невелика по сравнению со стоимостью разработки корпоративного Хранилища), во-первых, способствует продвижению новой технологии и, во-вторых, приводит к быстрой окупаемости затрат.
Первые же попытки внедрения Витрин Данных оказались настолько успешными, что вокруг новой технологии начался настоящий бум. Предлагалось вообще отказаться от реализации корпоративного Хранилища и заменить его совокупностью Витрин Данных. Однако вскоре выяснилось, что с ростом числа Витрин растет сложность их взаимодействия, поскольку сделать витрины полностью независимыми не удается. Сейчас принята точка зрения, в соответствии с которой разработка корпоративного Хранилища должна идти параллельно с разработкой и внедрением Витрин Данных.
Фактическим стандартом структуры данных при разработке Витрины является "звезда", основанная на единственной таблице фактов. При построении схемы взаимодействия корпоративного Хранилища и Витрин Данных в рамках создания СППР рекомендуется определить некоторую специальную структуру для хранения исторических данных и дополнительно развернуть ряд Витрин, заполняемых данными из этой структуры. Тем самым удается разделить два процесса: накопление исторических данных и их анализ.
Принципиальное отличие Системы Поддержки Принятия Решений на основе Хранилищ Данных от интегрированной системы управления предприятием состоит в обязательном наличии в СППР метаданных. В общем случае метаданные помещаются в централизованно управляемый Репозитарий, в который включается информация о структуре данных Хранилища, структурах данных, импортируемых из различных источников, о самих источниках, методах загрузки и агрегирования данных, сведения о средствах доступа, а также бизнес-правилах оценки и представления информации. Там же содержится информация о структуре бизнес-понятий. Так, например, клиенты могут подразделяться на кредитоспособных и некредитоспособных, на имеющих или не имеющих льготы, они могут быть сгруппированы по возрастному признаку, по местам проживания и т. п. Как следствие, появляются новые бизнес-понятия: Постоянный клиент, Перспективный клиент и т. п. Некоторые бизнес-понятия (соответствующие измерениям в Хранилище Данных) образуют иерархии, например Товар может включать продукты питания и лекарственные препараты, которые, в свою очередь, подразделяются на группы продуктов и лекарств и т. д.
Широко известны Репозитарии, входящие в состав популярных 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).
Когда структура метаданных разработана и система управления ими спроектирована, решается задача заполнения и обновления данных в ХД.
Какие данные должны быть помещены в Хранилище? Как найти и извлечь эти данные? Как обеспечить корректность данных в Хранилище? Подобные вопросы являются ключевыми при проектировании Хранилищ. В сущности, определяя, чем заполняется Хранилище, мы неявно определяем спектр задач, которые будут решаться с его помощью, и круг потенциальных пользователей.
При описании технологии заполнения Хранилища будем различать три взаимосвязанные задачи: Сбор Данных (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).