3. Проектирование клиент-серверных корпоративных эис
3.а. Основные понятия и особенности проектирования клиент-серверных корпоративных систем (КЭИС)
Архитектура современных КЭИС базируется на принципах клиент-серверного взаимодействия программных компонентов информационной системы.
Сервер – процесс, обслуживающий информационную потребность клиента: поиск или обновление БД, в этом случае сервер носит название – сервер БД, обработку данных – сервер приложения.
Клиент – приложение, посылающее запрос на обслуживание сервера. Задача сервера – инициирование связи с сервером, определение вида запроса на обслуживание, получение от сервера результата обслуживания, подтверждение окончания обслуживания.
Клиент-серверная архитектура реализует многопользовательский режим работы и является распределенной, когда клиенты и серверы располагаются на разных узлах локальной или глобальной сети.
Схема клиент-серверной архитектуры включает три уровня представления:
уровень представления (презентации) данных пользователем;
уровень обработки данных приложением;
уровень взаимосвязи с БД.
Согласно схемы пользователь (клиент) в одном случае вводит данные, которые после контроля и преобразования некоторым приложением попадают в БД, а в другом случае запрашивает обработку данных приложением, которое обращается за необходимыми данными к БД. Получив необходимые данные сервер их обрабатывает, а результаты помещает либо в БД, либо выдает пользователю в удобной для него форме (текст.док-т, электронная таблица, график), или делает то и другое вместе.
Выбор конкретной схемы определяется различными вариантами территориального распределения удаленных подразделений предприятия, требованиями эксплуатационной надежности, быстродействием, простотой обслуживания.
На рис.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), который обеспечивает возможность пересылки и преобразования данных из глобальной БД в структуру БД клиентского приложения.
Представление
данных пользователя Приложение База данных
Ц
ентрализованная
Система
А
рхитектура
«
Файл-сервер»
Двухуровневая
архитектура
«клиент-сервер»
Т
рехуровневая
Архитектура
«клиент-сервер»
Многоуровневая
Архитектура
«клиент-сервер»
Рис.2. Варианты клиент-серверной архитектуры КЭИС
Трехуровневая клиент-серверная архитектура позволяет помещать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс (Application Program Interface) устанавливается связь клиентских рабочих станций. Клиентская часть приложения вызывает необходимые функции сервера приложения, называемые «сервисами». Прикладные программы в свою очередь обращаются к серверу БД с помощью SQL запросов. Такая организация позволяет повысить производительность и эффективность КЭИС за счет:
многократности повторного использования общих функций обработки данных в множестве клиентских приложений при существенной экономии системных ресурсов;
параллельности в работе сервера приложений и сервера БД, причем сервер приложений может быть менее мощным по сравнению с сервером БД;
оптимизации доступа к БД через сервер приложений из клиентских мест путем диспетчеризации выполнения запросов в сети;
повышение скорости и надежности обработки данных в результате дублирования ПО на нескольких серверах приложений, которые могут заменять друг друга в сети в случае перегрузки или выхода из строя одного из них;
переноса функций администрирования системы по проверке полномочий доступа пользователей с сервера БД на сервер приложений.
Многоуровневая архитектура «клиент-сервер» создается для территориально-распределенных предприятий. Здесь наблюдаются отношения «многие ко многим» между клиентскими рабочими станциями и серверами приложений, между серверами приложений и серверами БД. Такая организация позволяет более рационально организовать информационные потоки между структурными подразделениями. Каждый сервер приложений обслуживает потребности какой-либо одной функциональной подсистемы и сосредоточивается в головном для подсистемы структурном подразделении (сервер приложения по управлению сбытом – в отделе сбыта, сервер приложения по управлению снабжением – в отделе закупок и т.д.). Интегрированная БД находится на отдельном сервере, на котором обеспечиваются централизованное ведение и администрирование общих данных для всех приложений.
Ведение нескольких серверов БД особенно актуально для предприятий с филиальной структурой, когда в центральном офисе используется общая БД, содержащая общую нормативно-справочную (НС), планово-бюджетную информацию и консолидированную отчетность, а в территориально—удаленных филиалах поддерживается оперативная информация о деловых процессах. При обработке данных в филиалах для контроля используется плановая и НС информация из центральной БД, а в центральном офисе получение консолидированной отчетности сопряжено с оперативной информацией филиалов.
Техно-рабочее проектирование трехуровневой клиент-серверной КИС содержит:
1. Разработку общей структуры КЭИС
Сущность функциональной структуры КЭИС сводится к выбору программно-технической среды реализации КЭИС и распределению функций обработки данных КЭИС по уровням клиент-серверной архитектуры.
Выбор сетевых ОС зависит от технической платформы выч. Средств. При использовании платформы INTEL – Windows 95, 98, NT 2000. При использовании таких платформ, как IBM, SUN, HP – OC Unix различных версий.
Выбор сервера БД для КЭИС основывается на анализе рынка серверов БД по различным критериям:
независимость от типа аппаратной архитектуры;
независимость от программно-аппаратной платформы;
поддержка стандарта открытых систем;
поддержка многопроцессорной и параллельной обработки данных;
оптимальное хранение распределенных данных;
поддержка WEB-серверов и работа с Internet;
непрерывная работа;
простота использования.
Выбор программных средств разработки КЭИС определяется требованиями применяемой технологии проектирования КЭИС (CASE-средства).
Разработка общей функциональной структуры корпоративной информационной системы на основе функционально-ориентированной или объектно-ориентированной модели проблемной области заключается в определении:
функций сервера БД;
функции серверов приложений;
функций клиентских мест;
информации, необходимой для выполнения этих функций;
распределения серверов и клиентских мест по узлам вычислительной сети;
прав доступа пользователей к КЭИС.
2. Создание Вычислительной сети для КЭИС – закупка и монтаж оборудования, инсталляция сетевого ПО и СУБД.
3. Создание схемы БД:
проектирование структуры распределенной БД на основе описания функциональной структуры КЭИС с помощью CASE-технологии, с учетом описания выбранного сервера БД в конкретной программно-технической среде и СУБД;
создание области БД – инициализация областей внешней памяти (системной, хранения данных, транзакций, хранения архивных данных). Операция выполняется системным администратором БД;
загрузка SQL – описания БД - осуществляется системным администратором БД на основе схемы БД средствами СУБД сервера БД;
разработка управляющих элементов БД (триггеров, процедур и т.д.).
4. Создание сервера БД КЭИС - физическое наполнение БД и настройка программ доступа СУБД.
5. Разработка серверов приложений – набор сервисов (функций обработки данных) и монитор транзакций, осуществляющий управление выполнением сервисов по обслуживанию клиентских потребностей.
6. Разработка клиентских приложений на рабочих станциях – на основе информационных потребностей пользователей осуществляется проектирование пользовательского интерфейса клиентских частей приложений.
3.b. Проектирование систем оперативной обработки транзакций (OLTP).
Клиент-серверная архитектура упрощает взаимодействие пользователей с информационной системой и между собой в процессе выполнения деловых или длинных транзакций.*
С помощью обработки длинных транзакций КЭИС позволяет управлять достаточно сложными цепочками операций делового процесса как единым целым. Такие системы называют системами оперативной обработки транзакций (OLTP – OnLine Transaction Processing).
Основой современных систем оперативной обработки транзакций является управление рабочими потоками (workflow), в которых пользователи – клиенты взаимодействуют между собой и с множеством программных приложений через специальную управляющую (супервизорную) программу. Рабочий поток – это совокупность информационных и материальных потоков в цепочке операций делового процесса.
Система управления рабочими потоками (СУРП) – это программный комплекс, который оперативно связывает персонал из различных подразделений и программные приложения в общий деловой процесс. В такой ситуации клиент обращается не напрямую к серверу приложений, а через СУРП, которая выбирает приложение в зависимости от конкретных событий в деловом процессе. СУРП может быть реализована на основе специализированного программного обеспечения, например, Staffware, Workroute, или встроена в контур интегрированной ЭИС, как в системах комплексной автоматизации R/3 и BAAN IY.
Центральным компонентом СУРП является менеджер рабочих потоков, который выполняет следующие функции:
создание шагов задания;
оценку условий выполнения шага заданий;
передачу управления между приложениями;
синхронизацию несколько одновременно выполняющихся процессов;
распределение результатов выполнения шага задания по пользователям;
ведение журнала операций.
В работе менеджера рабочих потоков используются различные методы маршрутизации (жесткой, свободной, гибридной).
Использование Интернет-приложений. Многоуровневая клиент-серверная архитектура распространяется на Интернет-приложения, связывающие множество участников делового процесса, территориально удаленных дуг от друга в рамках одного или нескольких предприятий на основе применения сетевого протокола TCP/IP. Эти приложения разрабатываются для таких предметных областей, как управление финансами, логистикой, персоналом, учет и отчетность и др.
Интернет-приложениями являются:
«клиент - предприятие» - осуществление торговли по электронным каталогам, проведение электронного обслуживания клиентов (банковские, страховые, таможенные операции и т.д.);
«предприятие - предприятие» - осуществление сделок закупки-продажи товаров, выполнение совместных проектов. Между предприятиями происходит обмен документов: договоров, заказов, счетов, накладных, платежных поручений;
«работник (подразделение) – работник (подразделение)» - применение технологии Интернета для связи между сотрудниками одного предприятия.
В корпоративной ЭИС R/3 (SAP) для реализации распределенных деловых процессов с помощью Интернет-приложений разработан специальный механизм ALE (Application Link Enabling), с помощью которого связываются друг с другом программные компоненты, относящиеся к различным информационным системам.
3.с. Проектирование систем оперативного анализа данных (OLAP)
Современные СППР и информационные системы руководителей основаны на применении специализированных информационных хранилищ (ИХ) и технологий оперативного анализа данных (OLAP). ИХ – база обобщенной информации, формируемая из множества внешних и внутренних источников, на основе которой выполняются статистические группировки и интеллектуальный анализ данных. В основе ИХ лежит понятие многомерного информационного пространства или гиперкуба, в ячейках которого хранятся анализируемые числовые показатели (объемы оборота, издержек, инвестиций и т.д.). Измерениями (осями) гиперкуба являются признаки анализа (время, группа продукции, регион, тип процесса, тип клиента и др.).
Время
Показатели:
- оборот,
Группа - издержки
продуктов Тип - доходы
клиента - инвестированный
капитал
Тип процесса Регион
Рис. 3. Многомерная организация информационного хранилища
К особенностям хранимой информации в ХИ относятся:
интеграция или обобщение данных в ИХ в виде единого многомерного информационного пространства (хранение показателей объемов производства, сбыта, сервиса и т.д. в продуктовом, территориальном, отраслевом, временном и других разрезах;
обязательное хранение временного признака в данных, дающего возможность отслеживать динамику изменения показателей в течение длительного периода времени;
непротиворечивость данных во всех используемых источниках в течение определенного периода времени (дня);
обеспечение множества представлений структуры информационного хранилища для различных категорий пользователей: руководителей, аналитиков, менеджеров направлений деятельности.
Архитектура системы оперативного анализа данных представлена на рис.4.
Представление (витрины) данных
. . . . . . . . . .
Преобразование
данных
