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

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).

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

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

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

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

2.7. Анализ данных: OLAP

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

Страницы: 1, 2, 3, 4