Маслов А.В. Проектирование информационных систем в экономике - файл n1.doc

приобрести
Маслов А.В. Проектирование информационных систем в экономике
скачать (8885.5 kb.)
Доступные файлы (1):
n1.doc8886kb.22.08.2012 14:38скачать

n1.doc

1   2   3   4   5   6   7
Тема 6. ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНЫХ

КОРПОРАТИВНЫХ ЭИС
6.1. Основные понятия и особенности проектирования клиент-серверных экономических информационных систем (КЭИС)
Архитектура современных КЭИС базируется на принципах клиент-серверного взаимодействия программных компонентов информационной системы.

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

Клиентом является приложение, посылающее запрос на обслуживание сервером. Задачей клиента являются инициирование связи с сервером, определение вида запроса на обслуживание, получение от сервера результата обслуживания, подтверждение окончания обслуживания.


Рис. 6.1. Структура локальной вычислительной сети




Клиент-серверная архитектура реализует многопользовательский режим работы и является распределенной, когда клиенты и серверы располагаются на разных узлах локальной или глобальной вычислительной сети. Пример локальной сети с одним сервером представлен на рис. 6.1. Преимущество локальной сети перед централизованной вычислительной системой заключается в открытом подключении и использовании вычислительных ресурсов с помощью единой передающей среды без пересмотра принципов взаимодействия ранее установленного вычислительного оборудования, то есть простой масштабируемости КЭИС.

В общем случае схема клиент-серверной архитектуры включает три уровня представления: уровень представления (презентации) данных пользователем; уровень обработки данных приложением и уровень взаимодействия с базой данных.

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

Клиент-серверная архитектура в вычислительной сети может быть реализована по-разному. Выбор конкретной схемы определяется различными вариантами территориального распределения удаленных подразделений предприятия, требованиями эксплуатационной надежности, быстродействием, простотой обслуживания. Рассмотрим различные схемы клиент-серверной архитектуры (рис. 6.2).

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

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

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

Двухуровневая клиент-серверная архитектура основана на использовании только сервера базы-данных (DB-сервера), когда клиентская часть содержит уровень представления данных, а на сервере находится база данных вместе с СУБД и прикладными программами.

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

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

Обращение к базе данных осуществляется на языке SQL, который фактически стал стандартом для реляционных баз данных. Отсюда сервер баз данных часто называют SQL-сервером, который поддерживается всеми реляционными СУБД: Oracle; Informix, MS SQL, ADABAS D, InterBase, SyBase и др. Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.). При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер (Open Data Base Connectivity), который обеспечивает возможность пересылки и преобразования данных из глобальной базы данных в структуру базы данных клиентского приложения. Применение этой технологии позволило разработчикам не заботиться о специфике работы с той или иной СУБД и делать свои системы переносимыми между базами данных. За время своего существования ODBC стал стандартом де-факто на алгоритм доступа к разнородным базам данных, и на сегодняшний день насчитывается более 160 прикладных систем, которые работают с источниками информации через драйверы ODBC.



Рис. 6.2. Варианты клиент-серверной архитектуры КЭИС


Трехуровневая клиент-серверная архитектура позволяет по мешать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс (Application Program Interface) устанавливается связь клиентских рабочих станций. Работа клиентской части приложения сводится к вызову необходимых функций сервера приложения, которые называются «ceрвисами». Прикладные программы в свою очередь обращаются к серверу базы данных с помощью SQL-запросов. Такая организация позволяет еще более повысить производительность и эффективность КЭИС за счет:

Многоуровневая архитектура «Клиент-сервер» создается для территориально-распределенных предприятий. Для нее в общем случае характерны отношения «многие ко многим» между клиентскими рабочими станциями и серверами приложений, между серверами приложений и серверами баз данных. Такая организация позволяет более рационально организовать информационные потоки между структурными подразделениями в процессе выполнения общих деловых процессов. Так, каждый сервер приложений, как правило, обслуживает потребности какой-либо одной функциональной подсистемы и сосредоточивается в головном для подсистемы структурном подразделении, например, сервер приложения по управлению сбытом – в отделе сбыта, сервер приложения по управлению снабжением – в отделе закупок и т.д. Естественно, что локальная сеть каждого из подразделений обеспечивает более быструю реакцию на запросы основного контингента пользователей из соответствующего подразделения. Интегрированная база данных находится на отдельном сервере, на котором обеспечиваются централизованное ведение и администрирование общих данных для всех приложений.

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

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

Направление тиражирования между серверами баз данных может быть:

Рассмотрим технологическую сеть техно-рабочего проектирования трехуровневой клиент-серверной КЭИС (рис. 6.3).


  1. Разработка общей структуры корпоративной информационной системы (П1)


Эта операция выполняется на основе описания предметной области D1 и технического задания D4, а также универсумов сетевых операционных систем и технических платформ (U1), серверов БД (U2), программных средств разработки КЭИС (U3). Выходом данной технологической операции служат описание выбранной конфигурации технических средств и сетевой операционной системы D3, описание выбранного сервера БД – D2, описание выбранных программных средств разработки КЭИС – D5, описание функциональной структуры КЭИС – D6. Сущность операции сводится к выбору программно-технической среды реализации КЭИС и распределению функций обработки данных КЭИС по уровням клиент-серверной архитектуры.



Рис. 6.3. Технологическая сеть техно-рабочего проектирования клиент-серверной КЭИС:

D1-описание предметной области; D2-описание выбранного сервера БД; D3-описание выбранной конфигурации технических средств и сетевой операционной системы; D4-техническое задание; D5-описание выбранных программных средств разработки КЭИС; D6-описание функциональной структуры КЭИС; D8-права доступа различным категориям пользователей КЭИС; D9-журнал заполнения областей БД; D10-сопровождающая документация; U1-универсум сетевых операционных систем и технических платформ; U2-универсум серверов БД; U3-универсум программных средств разработки КЭИС; G1-вычислительная сеть; G2-СУБД; G5-SQL описание БД с управляющими элементами; G6-программное обеспечение сервера;

G-приложения клиентских мест



Выбор сетевых операционных систем во многом зависит от технической платформы вычислительных средств. При использовании платформы INTEL наиболее распространенными сетевыми ОС являются WINDOWS 95, 98, NT 2000. При использовании других платформ, таких, как IBM, SUN, HP и других, применяют ОС UNIX различных версий для соответствующих платформ.

Выбор сервера БД для КЭИС основывается на анализе рынка серверов БД по различным критериям:

В качестве примера рассмотрим сравнение по вышеназванным критериям серверов БД ORACLE 7.0, MS SQL SERVER и ADABAS D. Сравнительный анализ серверов БД представлен в табл. 6.1.

Выбор программных средств разработки КЭИС определяется требованиями применяемой технологии проектирования КЭИС.

Разработка общей функциональной структуры корпоративной информационной системы на основе функционально-ориентированной или объектно-ориентированной модели проблемной области (см. тему 7) заключается в определении:

Основными правами доступа являются следующие:

• права на доступ к вычислительным ресурсам. Такие права задаются администратором вычислительной сети с помощью инструментов сетевой операционной системы. Процесс задания прав заключается в назначении различным категориям пользователей прав доступа к ресурсам сети и возможности выполнения над ними функций чтения, редактирования, записи. Например, пользователю с именем manager 1 доступны ресурсы, представленные в табл. 6.2.

Таблица 6.2

Сравнительный анализ серверов БД


Критерий

сравнения

ORACLE7.0

MS SQL

SERVER

ADABAS D

Независимость от типа

аппаратной архитектуры

ДА

ДА

ДА

Независимость от программно-аппаратной платформы

ДА

НЕТ

ДА

Поддержка стандарта открытых систем

ДА

ДА

ДА

Поддержка многопроцессорной и параллельной обработки

данных

ДА

ДА

ДА

Оптимальное хранение распределенных данных

ДА

НЕТ

ДА

Поддержка WEB серверов и работа с Интернет

ДА

ДА

ДА

Поддержка вторичных индексов

ДА

НЕТ

ДА

Непрерывная работа

ДА

ДА

ДА

Защита от сбоев

ДА

НЕТ

ДА

Простота использования

НЕТ

ДА

ДА

• права на доступ к объектам схемы базы данных КЭИС. Такие права задаются администратором сервера БД с помощью инструментов серверной СУБД. Процесс задания прав заключается в назначении различным категориям пользователей возможности выполнения над объектами схемы БД функций чтения редактирования, записи. Например, пользователю с именем manager 1 доступны объекты, представленные в табл. 6.3.


  1. Создание вычислительной сети (ВС) для КЭИС (П2)

Создание ВС заданной архитектуры для КЭИС заключается в закупке и монтаже оборудования, а также инсталляции сетевого программного обеспечения и СУБД. На основе описания функциональной структуры D6, описания выбранной конфигурации технических средств и сетевой операционной системы D3, описания выбранного сервера БД D2 происходят создание вычислительной сети G1 и установка СУБД G2.

Таблица 6.3

Задание прав доступа

Таблица 6.4

Права доступа к объектам схемы

Базы данных

3. Создание схемы базы данных (БД) (П3)
На основе технического задания D4, описания выбранных программных средств разработки D5, описания функциональной структуры КЭИС D6, описания выбранного сервера БД D2 и его СУБД G2, конфигурации вычислительной сети G1 осуществляются разработка схемы БД с управляющими элементами – G5 и ее документирование D10.

Создание схемы БД сводится к выполнению следующих технологических операций (рис. 6.4).

Проектирование структуры распределенной базы данных (П31).

Разработка структуры распределенной базы данных D7 происходит на основе описания функциональной структуры КЭИС D6, как правило, с помощью CASE-технологии D5 с учетом описания выбранного сервера БД D2 в конкретной программно-технической среде G1 и СУБД G2. В результате строятся модель базы данных и подмодели для различных категорий пользователей на основе установления им прав доступа к данным.




Рис. 6.4. Технологическая сеть проектирования базы данных в

клиент-серверной среде:

D2-описание выбранного сервера БД; D5-описание выбранных программных средств разработки КЭИС; D6-описание функциональной структуры КЭИС; D7-структура базы данных; D10-сопровождающая документация; G1-вычислительная сеть; G2-СУБД; G3- область базы данных; G4 – SQL описание БД; G5-SQL описание БД с управляющими элементами


Создание области базы данных (П32).

Создание области базы данных G3 заключается в инициализации областей внешней памяти (системной, хранения данных, транзакций, хранения архивных данных). Данная операция выполняется системным администратором БД, который использует для этих целей средства СУБД сервера БД G2 и спроектированную структуру базы данных D7.

Загрузка SQL-описания БД (П33).

Загрузка SQL-описания БД G4 осуществляется системным администратором БД на основе схемы базы данных D7 средствами СУБД сервера БД G2.

Разработка управляющих элементов БД (триггеров, процедур и т. д.) (П34).

Разработка управляющих элементов G5, к которым относятся хранимые процедуры и триггеры, осуществляется на основе структуры базы данных D7 с учетом ее SQL-описания БД G4 и возможностей средств СУБД сервера БД G2. В результате получается готовая для эксплуатации схема базы данных с управляющими элементами, которая документируется в D10.

Хранимая процедура представляет собой вариант программного наполнения базы данных, основная функция которой – функциональное расширение схемы БД. Хранимая процедура выполняет то или иное логическое действие. Например, администратор банковской системы создает хранимую процедуру, которая реализует функцию «занести на счет номер X сумму Y».

Разработчик приложения пользуется этой процедурой, но не знает, как именно она работает. Это дает следующие преимущества:

Триггер БД – это механизм «событие – действие», который автоматически выполняет некоторый набор SQL-операторов, когда происходит некоторое событие. Событиями, на которые можно установить триггер, являются модификации данных. Причем триггер связан с конкретной таблицей БД. Триггер хранится как объект в базе данных. Создание триггеров позволяет установить правила обеспечения ссылочной целостности сервера БД.


  1. Создание сервера БД КЭИС (П4)


На основании разработанной схемы БД с управляющими элементами G5, описания выбранного сервера БД D2 и его СУБД G2 осуществляется создание сервера БД, то есть физическое наполнение БД и настройка программ доступа СУБД. Выходом данной операции служат физическое установление прав доступа различным категориям пользователей КЭИС D8, журнал заполнения областей БД D9.


  1. Разработка серверов приложений (П5)


Исходя из информационных потребностей пользователей D4 и их прав D8, используя программные средства разработки D5, разрабатывается сервер приложения G5 и сопровождающая документация D10.

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


  1. Разработка клиентских приложений на рабочих станциях (П6)



На основе информационных потребностей пользователей D4 и их прав D8, используя программные средства разработки D5, создаются приложения клиентских мест G7, а также сопровождающая документация D10. В частности, осуществляется проектирование пользовательского интерфейса клиентских частей приложений.
6.2. Проектирование систем оперативной обработки транзакций
Клиент-серверная архитектура КЭИС упрощает взаимодействие пользователей с информационной системой и между собой в процессе выполнения деловых процессов или длинных транзакций. Под длинной транзакцией будем понимать совокупность операций делового процесса, требующих обращения к КЭИС, каждая из которых не имеет ценности без выполнения всей совокупности. Под короткой транзакцией или просто транзакцией будем понимать отдельное обращение к одному из компонентов КЭИС или обращение клиента к серверу. С помощью обработки длинных транзакций КЭИС позволяет управлять достаточно сложными цепочками операций делового процесса как единым целым. Такие информационные системы называют системами оперативной обработки транзакций (OLTP – OnLine Transaction Processing).

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

Система управления рабочими потоками (СУРП) – это программный комплекс, который оперативно связывает персонал из различных подразделении предприятия и программные приложения в общий деловой процесс, позволяя его автоматизировать и управлять им как единым целым. СУРП интегрирует по управлению все взаимодействующие элементы рабочего потока, переключает потоки между приложениями, управляет выбором исполнителей операций (как персонала, так и программ). С позиции проектирования ЭИС СУРП обеспечивает выстраивание цепочек автоматизированных рабочих мест, которые обмениваются между собой информацией по вычислительной сети через распределенную базу данных. С позиции многоуровневой клиент-серверной архитектуры СУРП – это управляющая (супервизорная) программа, которая регулирует множественное взаимодействие клиентов и серверов приложений и баз данных в длинных транзакциях (рис. 6.5). Таким образом, клиент обращается не напрямую к серверу приложений, а через СУРП, которая выбирает необходимое приложение в зависимости от конкретных событий в деловом процессе.

СУРП создаются на основе использования специального программного обеспечения для организации коллективной (групповой – workgroup) работы в локальных вычислительных сетях. В эту систему входят средства электронного обмена сообщениями и маршрутизации, которые позволяют организовывать непосредственный обмен результатами работы между участниками делового процесса, мониторинг выполнения делового процесса со стороны руководства предприятия, а также инициировать работу исполнителей по завершении выполнения автоматических процедур. Система управления рабочим потоком может быть реализована на основе специализированного программного обеспечения, например Staffware, Workroute, или встроена в контур интегрированной ЭИС, как в системах комплексной автоматизации R/3 и BAAN IV.

Основными особенностями системы управления рабочими потоками являются:

Центральным компонентом СУРП является менеджер рабочих потоков, который выполняет следующие функции:

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

В работе менеджера рабочих потоков используются различные методы маршрутизации, основанные на определенных правилах. Так, в зависимости от предопределенности порядка выполнения процедур различают правила:




Рис. 6.5. Многоуровневая клиент-серверная архитектура на основе

использования СУРП


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

Свободная маршрутизация (ad hoс-маршрутизация) означает, что последовательность операций делового процесса не известна заранее и определяется только в ходе его выполнения. В этом случае решение о запуске определенной операции предоставляется участнику делового процесса, наделенному соответствующими правами.

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

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

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

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

Смешанная маршрутизация допускает сочетание последовательной и параллельной маршрутизации.
Использование Интернет-приложений
Многоуровневая клиент-серверная архитектура распространяется на Интернет-приложения, связывающие множество участников делового процесса, территориально удаленных друг от друга в рамках как одного, так и нескольких предприятий на основе применения сетевого протокола TCP/IP. Эти приложения разрабатываются для таких предметных областей, как управление финансами, логистикой, персоналом, учет и отчетность и др. Достоинство распределенных приложений заключается в устранении промежуточных звеньев делового процесса, когда пользователь, минуя обращения к тому или иному подразделению предприятия, напрямую обращается к информационной системе для выполнения требуемой функции. Причем обращение может быть выполнено из любого места, в любой день и в любое время суток в удобной для пользователя форме, используя обычную программу навигации (браузер) и мультимедийное представление информации в Интернете.

Типичными Интернет-приложениями являются:

• «работник (подразделение) – работник (подразделение)», приложения Интранета предполагают применение технологии Интернета для связи между сотрудниками одного предприятия. При этом используются описанные выше системы управления рабочими потоками.

В корпоративной информационной системе R/3 (SAP) для реализации распределенных деловых процессов с помощью Интернет-приложений разработан специальный механизм Application Link Enabling (ALE), с помощью которого свободно связываются друг с другом программные компоненты, относящиеся к различным информационным системам. В частности, для взаимодействия программных компонентов предлагается использовать стандартные интерфейсы BAPI (Business Application Programming Interface). В системе R/3 в настоящее время разработано более 25 Интернет-приложений и более 100 BAPI интерфейсов к ним.

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


Рис. 6.6. Многоуровневая клиент-серверная архитектура для

Интернет-приложений в системе R/3


6.3. Проектирование систем оперативного анализа данных
Современные системы поддержки принятия решений и информационные системы руководителей основаны на применении специализированных информационных хранилищ (ИХ) и технологий оперативного анализа данных (ОLAP).

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

В основе информационного хранилища лежит понятие многомерного информационного пространства или гиперкуба (рис. 6.7), в ячейках которого хранятся анализируемые числовые показатели (например, объемы оборота, издержек, инвестиций и т.д.). Измерениями (осями) гиперкуба являются признаки анализа (например, время, группа продукции, регион, тип процесса, тип клиента и др.). При хранении признаки анализа отделяются от фактических данных, образуя так называемую инвертированную организацию хранения данных или структуру данных типа «звезда».




Рис. 6.7. Многомерная организация информационного хранилища

К особенностям хранимой информации в ИХ относятся:

С технологической точки зрения к архитектуре ИХ предъявляются общие требования [104].

• Удобный, «интуитивный» интерфейс пользователя, обеспечивающий простоту манипулирования данными.

Архитектура системы оперативного анализа данных представлена на рис. 6.8.

Рассмотрим состав основных подсистем информационного хранилища.

Подсистема хранения данных
Многомерное хранилище данных может быть организовано в виде одной из следующих структур:

• физической структуры, называемой MOLAP (Multidimensional OLAP), в которую с определенной периодичностью загружаются данные из файлов-источников, принадлежащих базам оперативных данных (например, один раз в день). Типичным инструментальным средством, поддерживающим MOLAP, являются Oracle Express (Oracle), Power Play (Cognos Corp), DataDirect (INTERSOLV);

• виртуальной структуры, называемой ROLAP (Relational OLAP), которая динамически используется при запросах, вызывающих физическое манипулирование с файлами-источниками из реляционных баз оперативных данных (формирование ответа на запрос к ИХ «на лету»). ROLAP-система рассматривается просто как надстройка над реляционными базами данных, обеспечивающая удобный интерфейс пользователя. Типичными инструментальными средствами, поддерживающими ROLAP, являются MetaCube (Informix), Business-Objects (BusinessObjects) и др.;

гибридной структуры, называемой HOLAP (Hybrid OLAP), которая используется при построении многоуровневых информационных хранилищ, применяемых на разных уровнях управления больших корпораций. Типичным инструментальным средством, поддерживающим HOLAP, является SAS System (SAS Institute).




Рис. 6.8. Архитектура информационного хранилища

Сравнительный анализ применения MOLAP и ROLAP хранилищ представлен в табл. 6.4.

Анализ параметров использования MOLAP и ROLAP информационных хранилищ показывает, что внедрение и эксплуатация ROLAP-систем являются более простыми и дешевыми по сравнению с MOLAP-системами, но уступают последним в эффективности оперативного анализа данных.
Подсистема метаинформации (репозиторий)
Репозиторий представляет собой описание структуры информационного хранилища: состава показателей, иерархий агрегации измерений, форматов данных, используемых функций, физического размещения на сервере, прав доступа пользователей, частоты обновления.

Важнейшей функцией репозитория является представление схем отображения структуры данных файлов-источников на структуре данных ИХ, в соответствии с которой осуществляется периодическая загрузка MOLAP-хранилища или непосредственная реализация запросов «на лету» в ROLAP-хранилищах.

В репозитории задается также схема отображения структуры ИХ на схемах представлений данных пользователей или витринах данных. Через репозиторий осуществляется интерпретация запросов к ИХ на проведение оперативного анализа данных.

Таблица 6.4

Сравнительный анализ применения MOLAP и ROLAP ИХ

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

Сбор данных предполагает передачу данных из источников в ИХ в соответствии со схемой отображения, представленной в репозитории.

В процессе очистки данных осуществляются проверка непротиворечивости (целостности), исключение дублирования данных, отбраковка шумовых (случайных) данных, восстановление отсутствующих данных, приведение данных к единому формату.

В случае необходимости агрегирования данных осуществляется суммирование итогов по заданным в репозитории признакам агрегации.
Подсистема представления данных (организации витрин данных)
Под витриной данных (Data Mart) понимается предметно-ориенти-рованное хранилище, как правило, агрегированной информации, предназначенное для использования группой пользователей обычно из 10–15 человек в рамках конкретного вида деятельности предприятия, например маркетинга, инжиниринга, финансового менеджмента и т.д.

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

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


Подсистема интеллектуального анализа данных

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

Типичными задачами интеллектуального анализа данных являются:

К основным методам интеллектуального анализа данных относятся:


Подсистема «Информационная система руководителя»
Информационная система руководителя предназначена для лиц, непосредственно принимающих решения. Поэтому интерфейс таких систем должен быть в наибольшей степени упрощенным. Обычно в качестве интерфейса руководителям предприятий предлагается набор стандартных отчетов и графиков, настраиваемых на потребности руководителя через систему меню. Часто в качестве интерфейса предлагаются диаграммы Ишикава («скелета рыбы»), представляющие собой саморазворачивающееся дерево показателей, в котором листья ветвей раскрашиваются в разные цвета, символизирующие характер состояния показателя (нормальный, тревожный, кризисный). Лист любой ветви дерева показателей может быть развернут в таблицу значений показателя или график. Подобные диаграммы применяются в таких корпоративных ЭИС, как R/3 и BAAN IV.
Подсистема WEB-публикации
Подсистема WEB-публикации предполагает преобразование полученной из ИХ информации в HTML-вид, доступный для ее просмотра удаленными клиентами с помощью широко распространенных браузеров Интернета.
Технология проектирования ИХ
Интеграция множества источников данных в рамках единого информационного хранилища представляет собой трудоемкую и дорогостоящую проектную задачу. Поэтому к процессу проектирования систем оперативного анализа данных на основе информационного хранилища в наибольшей степени относятся требования: очередности внедрения компонентов ИХ, обеспечивающей быструю отдачу от внедрения, и адаптивности логической и физической структуры ИХ к изменяющимся в ходе проектирования и эксплуатации информационным потребностям. Рассмотрим технологическую сеть проектирования информационного хранилища (рис. 6.9).
П1. Идентификация проблемной области
На основе материалов предпроектного обследования (Д1) осуществляется параметризация проекта создания информационного хранилища и выделяются все необходимые материальные, финансовые, людские и временные ресурсы на выполнение проектных работ, т.е. составляются техническое задание (Д2) и технико-экономическое обоснование проекта (Д3). В частности, в рамках технического задания в разрезе конкретных видов деятельности или бизнес-процессов формулируются цели и задачи, области применения и пользователи ИХ, устанавливаются источники исходных данных, определяются информационные потребности пользователей.

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

К важнейшим задачам, которые решаются с помощью ИХ, относятся:

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

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

Перечень источников данных:

Для каждого источника данных определяются параметры: территориальное расположение, административное подчинение, периодичность обновления, конфиденциальность и достоверность хранимой информации, форматы данных и характеристики программно-технической среды, объемы данных.

Информационные потребности пользователей. Для обоснования информационных потребностей выполняется анализ функций работников в рамках конкретных видов деятельности (бизнес-процессов), например бизнес-планирования, бюджетирования, маркетинга и т.д. В результате выявляется перечень регламентированных информационно-справочных документов и предполагаемых направлений формирования произвольных запросов.
П2. Разработка концептуальной модели ИХ
Этап разработки концептуальной модели ИХ соответствует этапу логического проектирования, который выполняется на основе технического задания Д2 и технико-экономического обоснования Д3. На выходе этого этапа получаются логическая структура данных ИХ Д4, схема преобразования данных Д5, логическая структура витрин данных Д6 и схема представления данных Д7.

Проектирование логической структуры ИХ осуществляется на основе анализа статистики использования конкретных информационно-справочных документов в процессе решения основных задач принятия решений. В результате выполнения операции производятся:

- отбор признаков анализа;

- построение схем агрегации показателей;

- построение схем обобщения признаков;

- определение временного горизонта хранения показателей;

- отбор первичных и производных показателей для хранения;

- выбор типа логической структуры ИХ;

- распределение показателей по типам логической структуры.

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

Сложность структуры данных показателей предопределяет выбор ее типа: «звезды» с однородной структурой признаков для всех показа- телей или «расширенной снежинки» с применением нескольких типов хранилищ показателей. В последнем случае осуществляется распределение показателей по типам хранилищ.

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

В частности, на этом этапе осуществляется анализ альтернативных источников данных, например выбор из числа коммерческих баз данных, а также устанавливаются схемы преобразований исходных данных в хранимые структуры ИХ. Сложность схем отображения источников данных в структуру хранилища предопределяет выбор типа ИХ: MOLAP, ROLAP, HOLAP.

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

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

В рамках логически спроектированных витрин данных осуществляется выбор методов анализа данных для конкретных категорий пользователей. В частности, выявляется потребность в применении определенных видов статистического и интеллектуального анализа данных.
П3. Формализация ИХ
Этап формализации завершает техническое проектирование информационного хранилища. На основе спроектированной на предшествующей операции архитектуры ИХ (Д4–Д6) и универсумов программно-технических средств (U1–U2) осуществляется выбор схемы размещения ИХ в сетевой вычислительной среде (Д7) и программно-технических средств реализации ИХ (U3–U4).




Выбор схемы размещения ИХ в сетевой вычислительной среде осуществляется в зависимости от выбранного типа организации и предполагает определение числа уровней хранения:

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

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

Расчет объемов ИХ осуществляется путем суммирования объемов хранимых данных на всех MOLAP-серверах с учетом необходимого индексирования (специальных индексирующих таблиц для доступа к основным данным), а также объемов метаинформации репозитория для MOLAP и ROLAP-организации. Объемы ИХ рассчитываются на текущий момент времени и на перспективу с учетом внедрения всех компонентов системы.
П4. Реализация проекта ИХ
Этап реализации проекта ИХ выполняется на основе выбранных программных (U3) и технических средств (U4), а также построенных на этапе концептуального моделирования компонентов ИХ (Д4–Д6) и схемы размещения ИХ (Д7) путем наполнения репозитория (G1), настройки или программирования других инструментальных средств (G2), наполнения информационного хранилища для MOLAP-структуры (G3), создания проектной документации (Д8).

Наполнение репозитория ИХ осуществляется путем ввода определений:

• структуры ИХ, источников и витрин данных;

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

Наполнение ИХ предполагает автоматическую загрузку информации из источников данных в ИХ с MOLAP-организацией, которая повторяется с заданной в репозитории периодичностью. Эта операция в последующем предполагает очистку ИХ от ненужных и устаревших данных; управление данными на различных уровнях хранения; автоматическое обновление агрегированных данных.
П5. Внедрение и опытная эксплуатация
Заключительный этап создания ИХ предполагает комплексное тестирование всех компонентов ИХ (G1–G3) с исправлением всех возникающих ошибок (G4–G6), последующим обучением пользователей и постоянным администрированием в соответствии с установленными правилами и документацией проекта (Д8).
Вопросы для самопроверки


  1. Что понимается под клиент-серверной архитектурой? Что такое сервер и клиент?

  2. Какие существуют уровни представления клиент-серверной архитектуры?

  3. Какие существуют варианты клиент-серверной архитектуры?

  1. Какие преимущества обеспечивает клиент-серверная архитектура?

  2. Что такое репликация данных, и какие существуют режимы ее осуществления?

  3. Какие операции выполняются на стадии техно-рабочего проектирования клиент-серверной архитектуры?

  4. Какие операции включает проектирование базы данных в клиент-серверной среде?

  5. Что представляет собой система оперативной обработки транзакций (OLTP-система)?

  6. Каковы особенности создания систем управления рабочими потоками?

  7. Каковы особенности создания Интернет-приложений?

  8. Что представляет собой система оперативного анализа данных (OLAP-система)?

  9. Каковы особенности организации информации в информационных хранилищах?

  10. Какие требования предъявляются к архитектуре информационных хранилищ?

  11. Каковы основные компоненты архитектуры информационного хранилища?

  12. Каковы основные технологические операции проектирования информационного хранилища?

1   2   3   4   5   6   7


Тема 6. ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНЫХ
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации