Название: Проектирование экономических информационных систем - Смирнова Г. Н.

Жанр: Информатика

Рейтинг:

Просмотров: 794


Глава 12

ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНЫХ КОРПОРАТИВНЫХ ЭИС

 

12.1

Основные понятия и особенности проектирования клиент-серверных экономических информационных систем (КЭИС)

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

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

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

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

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

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

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

 

Архитектура "Клиент-сервер"

Представление

данных пользователя

Приложение

База данных

 

Централизованная система

 

Архитектура "Файл-сервер"

Подпись:

 

Двухуровневая

архитектура "Клиент-сервер"

 

Трехуровневая

архитектура "Клиент-сервер"

 

 

Многоуровневая

архитектура "Клиент-сервер"

 

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

 

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

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

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

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

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

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

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

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

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

параллельности в работе сервера приложений и сервера базы данных, причем сервер приложений может быть менее мощ­ным по сравнению с сервером базы данных;

 

оптимизации доступа к базе данных через сервер приложений из клиентских мест путем диспетчеризации выполнения зап­росов в вычислительной сети;

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

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

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

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

19*

291

 

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

синхронный режим, когда тиражируемые данные обновляют­ся по мере возникновения необходимости одновременно на серверах баз данных во всех копиях. Требуемое быстродей­ствие каналов для синхронного режима - единицы Мбит в секунду;

асинхронный режим, когда тиражирование данных выпол­няется в строго определенные моменты времени, например каждый час работы информационной системы. Требуемое быстродействие каналов для асинхронного режима - едини­цы Кбит в секунду. Асинхронный режим может вызывать от­кладывание выполнения транзакций до момента обновления данных.

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

равноправным, т.е. в обоих направлениях;

сверху-вниз типа «ведущий/ведомый», когда на серверах фи­лиалов содержатся только некоторые подмножества данных центральной базы данных;

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

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

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

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

Подпись: П5
Разработка приложений клиентских мест

 

 

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

D1 - описание предметной области; D2 - описание выбранного сервера БД;

D3 - описание выбранной конфигурации технических средств и сетевой операционной системы; D4 - техническое задание; D5 - описание выбранных

программных средств разработки КЭИС; D6 - описание функциональной структуры КЭИС; D8 - права доступа различным категориям пользователей

КЭИС; D9 - журнал заполнения областей БД, D10 - сопровождающая документация; U1 - универсум сетевых операционных систем н технических платформ; U2 - универсум серверов БД; U3 - универсум программных

средств разработки КЭИС; G1 - вычислительная сеть; G2 - СУБД, G5 - SQL-описанне БД с управляющими элементами; G6 - программное обеспечение сервера, G7 - приложения клиентских мест

 

г

 

 

операции сводится к выбору программно-технической среды ре­ализации КЭИС и распределению функций обработки данных КЭИС по уровням клиент-серверной архитектуры.

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

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

независимость от типа аппаратной архитектуры;

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

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

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

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

поддержка WEB-серверов и работа с Интернет;

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

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

защита от сбоев;

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

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

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

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

функций сервера БД;

функций серверов приложений;

функций клиентских мест;

информации, которая необходима для выполнения этих функ­ций;

распределения серверов и клиентских мест по узлам вычисли­тельной сети;

прав доступа пользователей к КЭИС.

 

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

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

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

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

 

3. Создание схемы базы данных (БД) (ПЗ)

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

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

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

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

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

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

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

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

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

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

Подпись: П31 П32

Подпись: ПЗЗ
Подпись: П34

Создание области БД

Разработка управляющих элементов БД

<5Н

 

"(с*)   

 

[D10, G5)

 

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

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

 

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

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

когда меняется алгоритм данного действия, то администра­тор меняет только эту хранимую процедуру и все приложе­ния сразу начинают работать по-новому;

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

хранимая процедура пишется одним человеком, а использу­ется многими, следовательно, повышаются темпы разработ­ки КЭИС;

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

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

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

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

Разработка серверов приложений (175)

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

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

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

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

 

12.2

Проектирование систем оперативной обработки транзакций

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

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

Использование систем управления рабочими потоками

Под рабочим потоком будем понимать совокупность инфор­мационного и материального потоков в цепочке операций дело­вого процесса.

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

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

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

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

поддержка маршрутной карты предприятия, определяющей схему прохождения работ в деловом процессе;

обеспечение выбора исполнителей процессов по модели орга­низационной структуры предприятия;

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

автоматический контроль исполнения работ и информирова­ние руководителей;

 

і

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

открытые интерфейсы с внутренними и внешними приложе­ниями, подключение транзакций по Интернету;

сбор статистики о выполнении деловых процессов;

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

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

создание шагов задания;

оценку условий выполнения шага заданий;

обработку возникающих событий и принятие решений по со­общениям;

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

передачу управления между приложениями;

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

распределение результатов выполнения шага задания по по­лучателям;

ведение журнала операций.

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

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

жесткой маршрутизации;

свободной маршрутизации;

гибридной маршрутизации.

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

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

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

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

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

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

Смешанная маршрутизация допускает сочетание последова­тельной и параллельной маршрутизации.

Использование Интернет-приложений

Многоуровневая клиент-серверная архитектура распростра­няется на Интернет-приложения, связывающие множество учас­тников делового процесса, территориально удаленных друг от

 

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

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

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

«предприятие - предприятие», осуществление сделок закуп­ки-продажи товаров, выполнение совместных проектов. В первом случае между предприятиями осуществляется обмен документов: договоров, заказов, счетов, накладных, платеж­ных поручений. Причем в отличие от традиционного элект­ронного обмена данными (EDI - Electronic Data Interchange) возможна такая синхронизация транзакций, что два дело­вых процесса закупки и продажи по сути сливаются в один общий процесс. В случае осуществления проектов взаимная деятельность предприятий расширяется до проектирования изделий и планирования производства и образования совме­стных виртуальных предприятий. При этом обычно исполь­зуется международный стандарт для обмена данными по моделям продукции STEP (Standard for the Exchange of Product model data);

2o~2639

305

 

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

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

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

 

12.3

Проектирование систем оперативного анализа данных

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

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

 

Представление

данных пользователя

Клиент WEB

 

 

WEB-сервер

ИНТЕРНЕТ

SAP-сервер транзакций ИНТЕРНЕТ

Приложение

База данных

 

Рис. 12.6. Многоуровневая клиент-серверная архитектура для Интернет-приложений в системе R/3

 

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

20*

307

 

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

 

Показатели:

оборот,

издержки,

доходы,

инвестированный капитал

Тип процесса

 

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

 

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

интеграция или обобщение данных в ИХ из транзакционных баз данных по всем бизнес-процессам и структурным подраз­делениям предприятия в виде единого многомерного инфор­мационного пространства. Например, организуется хранение показателей объемов производства, сбыта, сервиса и т.д. в продуктовом, территориальном, отраслевом, временном и других разрезах;

произвольность агрегации данных на основе отделения от фак­тических данных независимых и равноправных измерений информационного пространства (признаков анализа инфор­мации, разрезов) в виде иерархий агрегации. Например, ре­гиональный признак анализа представляется в виде иерархии агрегации: «область - район - город - село», временной при­знак «год - квартал - месяц - день» и т.д.;

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

непротиворечивость данных во всех используемых источни­ках в течение определенного периода времени (например, дня), которая позволяет обеспечить единую точку зрения всех пользователей на экономическую систему;

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

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

Единообразно определенная структура многомерных данных с равноправными измерениями информационного простран­ства.

Пользователь не должен знать о том, где хранятся данные, как они организованы и как обрабатываются.

Поддержка многопользовательского режима оперативного анализа в среде «клиент-сервер».

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

Автоматическое обновление информации из оперативных баз данных.

Выполнение запросов без ограничений на количество изме­рений и уровней их агрегации примерно с одинаковым вре­менем реакции на запрос.

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

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

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

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

физической структуры, называемой MOLAP (Multidimensional OLAP), в которую с определенной периодичностью загружа­ются данные из файлов-источников, принадлежащих базам оперативных данных (например, один раз в день). Типичным

 

П/С хранения данных

П/С метаинфор-мации (репозиторий)

 

 

Представление (витрины) данных

Информацион­ная система руководителя EIS

Оперативный анализ данных OLAP

Интеллектуаль­ный анализ

данных Data Mining

WEB-лубли-кации

 

 

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

 

инструментальным средством, поддерживающим 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).

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

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

Подсистема метаинформации (репозиторий)

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

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

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

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

 

Подсистема преобразования данных (загрузки хранилища)

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

сбор данных (Data Acquisition);

очистка данных (Data Cleaning);

агрегирование данных (Data Consolidation).

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

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

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

Подсистема представления данных (организации витрин данных)

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

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

Подсистема оперативного анализа данных

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

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

Поворот. Добавление нового признака анализа.

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

Раскрытие (drill-down). Осуществляется декомпозиция призна­ка агрегации на компоненты, например, признак года разби­вается на кварталы. При этом автоматически детализируют­ся числовые показатели.

Свертка (roll-up/drill-up). Операция, обратная раскрытию. При этом значения детальных показателей суммируются в агреги­руемый показатель.

Сечение (slice-and-dice). Выделение подмножества данных по конкретным значениям одного или нескольких измерений.

Подсистема интеллектуального анализа данных (извлечения знаний)

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

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

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

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

прогнозирование развития ситуаций, например прогнозирова­ние цен, объемов продаж, производства.

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

методы многомерного статистического анализа;

индуктивные методы построения деревьев решений;

нейронные сети.

Подсистема «Информационная система руководителя»

Информационная система руководителя предназначена для лиц, непосредственно принимающих решения. Поэтому интер­фейс таких систем должен быть в наибольшей степени упрощен­ным. Обычно в качестве интерфейса руководителям предприя­тий предлагается набор стандартных отчетов и графиков, настра­иваемых на потребности руководителя через систему меню. Часто в качестве интерфейса предлагаются диаграммы Ишикава («ске­лета рыбы»), представляющие собой саморазворачивающееся де­рево показателей, в котором листья ветвей раскрашиваются н разные цвета, символизирующие характер состояния показателя (нормальный, тревожный, кризисный). Лист любой ветви дерева показателей может быть развернут в таблицу значений показате ля или график. Подобные диаграммы применяются в таких кор поративных ЭИС, как R/3 и BAAN IV.

упрощение управленческого документооборота для процесса принятия управленческих решений и др.

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

бизнес-планирование - обоснование принятия стратегических решений;

контроллинг - анализ финансово-хозяйственной деятельнос­ти и выявление резервов совершенствования бизнес-процес­сов предприятия;

оперативный мониторинг и сравнительный анализ (bench­marking) важнейших показателей деятельности предприятия. Круг пользователей: руководители; референты руководителей,

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

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

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

внутренние источники: базы оперативных данных об объемах продаж, производства, закупок, издержках по центрам зат­рат, состоянии материальных, финансовых, людских ресур­сов;

внешние источники: официальные статистические данные о деятельности отрасли, смежных отраслях, состоянии финан­сов; нормативная государственная информация; маркетин­говая информация о зондировании рынка, состоянии кон­курентов; коммерческие базы данных специализированных компаний в области информационного бизнеса, например Reuters.

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

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

Подпись:

Подпись: П5
ы

СП

 

Формализация

 

ИХ

 

 

3

G6 ]

Рис. 12.9. Технологическая сеть проектирования информационного хранилища:

Д1 - материалы предпроектного обследования; Д2 - техническое задание; ДЗ - технико-экономическое обоснование проекта; Д4 - логическая структура данных ИХ; Д5- схема преобразования данных; Д6 - логическая структура данных витрин; Д7 - схема размещения ИХ в сетевой вычислительной среде, Д8 - проектная документация; Ш - универсум программных средств; U2 - универсум технических средств; U3 - универсум программных средств реализации ИХ; U4 - универсум техничес­ких средств реализации ИХ, G1 - репозиторий; G2 - настройка или процедуры инструментальных средств; G3 - наполнение информационного хранилища для MOLAP-структуры; G4 - модифицированный репозиторий; G5 - модифицированные настройки или процедуры инструментальных средств, G6 - модифицированное информационное хранилище для MOLAP-структуры

упрощение управленческого документооборота для процесса принятия управленческих решений и др.

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

бизнес-планирование - обоснование принятия стратегических решений;

контроллинг - анализ финансово-хозяйственной деятельнос­ти и выявление резервов совершенствования бизнес-процес­сов предприятия;

оперативный мониторинг и сравнительный анализ (bench­marking) важнейших показателей деятельности предприятия. Круг пользователей: руководители; референты руководителей,

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

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

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

внутренние источники: базы оперативных данных об объемах продаж, производства, закупок, издержках по центрам зат­рат, состоянии материальных, финансовых, людских ресур­сов;

внешние источники: официальные статистические данные о деятельности отрасли, смежных отраслях, состоянии финан­сов; нормативная государственная информация; маркетин­говая информация о зондировании рынка, состоянии кон­курентов; коммерческие базы данных специализированных компаний в области информационного бизнеса, например Reuters.

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

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

 

172. Разработка концептуальной модели ИХ

Этап разработки концептуальной модели ИХ соответствуеі этапу логического проектирования, который выполняется на основе технического задания Д2 и технико-экономического обо­снования ДЗ. На выходе этого этапа получаются логическая структура данных ИХ Д4, схема преобразования данных Д5, ло­гическая структура данных витрин Д6 и схема представления данных Д7.

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


Оцените книгу: 1 2 3 4 5