Эволюция корпоративных информационных систем 4 (стр. 5 из 12)

· Компонентная архитектура. Представляет архитектуру ПО системы, ее декомпозицию на подсистемы и компоненты.

· Техническая архитектура. Описывает физические узлы системы и связи между ними.

Система Поддержки Принятия Решений (СППР) по виду автоматизированной ЭШтельности относятся к системам обработки и передачи информации. Объектами автоматизации являются технические процессы, связанные с информационным обеспечением управленческой и аналитической деятельности руководящего персонала и специалистов подразделений и высшего руководства компании. Целями системы являются:

· Интеграция ранее разъединенных детализированных данных:

O исторических архивов,

O данных из оперативных систем,

O данных из внешних источников.

· Разделение наборов данных, используемых для оперативной обработки, и наборов данных, используемых для решения задач поддержки принятия решений.

· Обеспечение всесторонней информационной поддержки максимальному кругу ЭШезователей.

Для реализации поставленных целей в рамках системы подлежат автоматизации следующие процессы:

· Сбор данных.

· Преобразование данных:

O Очистка данных.

O Согласование данных.

O Унификация данных.

O Агрегирование данных.

· Хранение данных:

O Промежуточное хранение данных.

O Накопление исторических данных.

· Предоставление данных потребителям.

· Сопровождение метаданных.

Информационное обеспечение

В общем случае информационное обеспечение системы состоит из пяти классов данных:

источников данных,
оперативного склада данных,
хранилища данных,
витрины данных,
репозитария метаданных.

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

· Измерения, их иерархии и уровень детализации. Например, для временного измерения должен быть определен минимальный интервал времени (день, неделя, месяц), по которому будут индексироваться показатели в витрине.

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

· Производные показатели и формулы их вычисления на основе базовых показателей.

Выбор конкретного способа представления витрин (ROLAP, MOLAP или HOLAP — см. далее) выполняется, как правило, на стадии реализации системы.

Выявленные измерения и показатели служат исходными данными для проектирования хранилища.

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

На пространстве, которое задается бизнес-измерениями, проектируются базовые и производные показатели, которые должны находиться в хранилище. Для больших систем целесообразно проводить сегментацию хранилища по предметным областям.

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

· Если имеется более одного источника, следует ли определить, какой из них лучше?

· Какие преобразования необходимо выполнить, чтобы приготовить источник к загрузке в хранилище?

· Согласуются ли структура источника и структура хранилища?

· Насколько согласуются данные источника с нормативно-справочной информацией?

· Что будет происходить, если источник имеет несколько месторасположений?

· Насколько аккуратны данные источника?

· Как источник обновляется?

· Каковы возраст и перспективность источника?

· Насколько полны данные?

· Что потребуется для интеграции данных источника в поток загрузки?

· Какова технология хранения данных в источнике?

· Насколько эффективно может осуществляться доступ к источнику?

На основе выполненного анализа принимаются следующие архитектурные решения:

· Определяются состав, содержание и источники потоков данных, которые будут поступать из источников в хранилище.

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

· При необходимости проектируются структуры оперативного склада данных и транзитных файлов.

· Выявляются данные, которые отсутствуют в источниках информационного хранилища. Для таких данных, как правило, проектируются процедуры и регламенты ручного ввода.

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

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

Компонентная архитектура

Система на самом верхнем уровне состоит, как правило, из двух видов ПО: общего и специального.

К общему ПО относятся:

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

o Серверы реляционных БД,

o Серверы МБД,

o Серверы приложений (поисковые, аналитической обработки, добычи знаний и др.).

· Специальное ПО представляет собой совокупность программ, разрабатываемых при создании Систем Поддержки Принятия Решений (СППР). Они объединяются в следующие подсистемы:

o Подсистему загрузки данных,

o Подсистему обработки запросов и представления данных,

o Подсистему администрирования.

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

Техническая архитектура

Серверное ПО работает под управлением серверов приложений и серверов БД на UNIX- или NT-платформах или мэйнфреймах. Клиентское ПО, устанавливается на ПК конечных пользователей. В последние годы наметилось стремительное внедрение технологии «тонкого» клиента, при которой на ПК пользователя находится лишь Web-броузер, а вся функциональность клиентского ПО загружается с сервера приложений в виде JavaScript- программ или апплетов. Техническая архитектура во многом зависит от масштабови требований, предъявляемых к ее производительности и надежности. В зависимости от этого серверные компоненты системы могут располагаться на одном компьютере или на нескольких. Сегменты хранилища и витрины данных в больших системах могут располагаться на нескольких компьютерах.

Реализация

Данная стадия проекта непосредственно связана с разработкой и тестированиемкомпонентов информационного и специального ПО системы в соответствии с разработанной на этапе проектирования архитектурой.