RDA-модель
В RDA-модели (рис. 2.7) коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и прикладные функции («толстый» клиент).
Рис. 2.7. RDA-модель
Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (например, SQL) или вызовами функций специальной библиотеки (если имеется соответствующий API). Запросы к информационным ресурсам направляются по сети удаленному компьютеру-серверу базы данных. Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных. Говоря об архитектуре «клиент/сервер», в большинстве случаев имеют в виду именно эту модель.
Основным преимуществом RDA-модели является широкий выбор средств быстрой разработки приложений различных фирм. Существует множество инструментальных средств, обеспечивающих быстрое создание приложений, работающих с SQL- ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Подавляющее большинство этих средств разработки на языках четвертого поколения (включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления.
В то же время RDA-модель имеет ряд ограничений.
1. Очень большая загрузка сети. Приложение является нераспределенным, и вся его логика локализована на компьютере- клиенте, поэтому взаимодействие его с сервером посредством SQL-запросов приводит к передаче по сети данных большого объема, возможно, избыточных. Как только число клиентов возрастает, сеть становится узким местом, ограничивая быстродействие всей информационной системы.
2. Сложность ведения больших проектов.
Очевидно, что если различные по своей природе функции (функции представления и прикладные функции) смешаны в одной и той же программе, написанной на языке SGL, то при необходимости изменения прикладных функций приходится переписывать всю программу целиком. При коллективной работе над проектом, как правило, каждому разработчику поручается реализация отдельных прикладных функций, что делает невозможным контроль за их взаимной непротиворечивостью. Каждому из разработчиков приходится программировать интерфейс с пользователем, что ставит под вопрос единый стиль интерфейса и его целостность.3. Сложность обновления программного обеспечения, т.к. его замену необходимо производить одновременно на всех компьютерах-клиентах.
4. Низкий уровень безопасности, т.к. реализация разграничения доступа по функциям возможна только на стороне клиента, а на стороне сервера разграничение выполняется только по таблицам базы данных, что снижает уровень защищенности.
В DBS-модели (рис. 2.8) процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления («тонкий» клиент), а прикладные функции реализованы в хранимых процедурах (stored procedure), которые также называют компилируемыми резидентными процедурами, или процедурами базы данных. Они хранятся непосредственно в базе данных и выполняются на компьютере-сервере базы данных, где функционирует и компонент, управляющий доступом к данным, т.е. ядро СУБД.
Рис. 2.8. DBS-модель
DBS-модель реализована в некоторых реляционных СУБД (Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур — средство программирования ядра СУБД. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL.
Преимущества DBS-модели очевидны:
1) возможность централизованного администрирования бизнес-функций, размещенных на сервере;
2) снижение трафика в сети;
3) возможность разделения процедуры между несколькими приложениями и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.
Однако есть и недостатки:
1.
Средства, используемые для написания хранимых процедур, строго говоря, не являются языками программирования в полном смысле слова. Это разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональным возможностям с языками третьего поколения (C или Pascal) и тем более четвертого поколения. Они встроены в конкретные СУБД, и, естественно, рамки их использования ограничены. Следовательно, система, в которой прикладной компонент реализован при помощи хранимых процедур, не является мобильной относительно СУБД. В большинстве СУБД отсутствуют возможности отладки и тестирования хранимых процедур, что превращает последние в весьма опасный механизм. Во многих реализациях процедуры являются интерпретируемыми, что замедляет их выполнение.2. Не обеспечивается требуемая эффективность использования вычислительных ресурсов. Объективные ограничения в ядре СУБД не позволяют пока организовать в его рамках эффективный баланс загрузки, миграцию процедур на другие компьютеры- серверы БД и реализовать другие полезные функции. Попытки разработчиков СУБД предусмотреть в своих системах эти возможности (распределенные хранимые процедуры, запросы с приоритетами и т.д.) пока не позволяют добиться желаемого эффекта.
3. Децентрализация приложений — один из ключевых факторов современных информационных технологий — требует существенного разнообразия вариантов взаимодействия клиента и сервера. При реализации прикладной системы могут понадобиться такие механизмы взаимодействия, как хранимые очереди, асинхронные вызовы и т.д., которые в DBS-модели не поддерживаются.
На практике часто используются смешанные модели, когда поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).
В AS-модели (рис. 2.9) процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за ввод и отображение данных (т.е.
реализует функции первой группы). Прикладные функции выполняются группой процессов (серверов приложений), функционирующих на удаленном компьютере (или на нескольких компьютерах). Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается таким же способом, что и в RDA-модели. Серверы приложений выполняются, как правило, на том же компьютере, где функционирует менеджер ресурсов, однако могут выполняться и на других компьютерах.
Рис. 2.9. AS-модель
Основным элементом принятой в AS-модели трехзвенной схемы является сервер приложения. В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как служба (service) и предоставляет некоторые услуги всем программам, которые могут ими воспользоваться. Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения (Application Client — AC). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. AC обращается с запросом к конкретной службе, но не к AS, т.е. серверы приложений обезличены и служат лишь своего рода «рамкой» для оформления служб, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от АС, выстраиваются
в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами.
АС трактуется более широко, чем компонент представления. Он может поддерживать интерфейс с конечным пользователем (тогда он является компонентом представления), может обеспечивать поступление данных от некоторых устройств (например, датчиков), может, наконец, сам по себе быть AS. Последнее позволяет реализовать прикладную систему, содержащую AS нескольких уровней. Архитектура такой системы может выглядеть как ядро, окруженное концентрическими кольцами. Ядро состоит из серверов приложений, в которых реализованы базовые прикладные функции.
Кольца символизируют наборы AS, являющихся клиентами по отношению к серверам нижнего уровня. Число уровней серверов в AS-модели, вообще говоря, не ограничено.AS-модель в наибольшей степени отражает сильные стороны технологии «клиент/сервер»:
1) четкое разграничение логических компонентов приложения;
2) возможность баланса загрузки между несколькими серверами;
3) значительное снижение трафика между клиентом и сервером приложений, дающее возможность работы по медленным линиям связи;
4) высокий уровень защиты данных, т.к. они являются «спрятанными» за сервисами приложения, в которые можно встроить проверку полномочий клиента;
5) возможность использования в качестве клиентской части приложения стандартного браузера;
6) упрощение процесса обновления ПО.
Фундаментальное различие между моделями архитектуры «клиент/сервер» заключается в следующем. RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA- моделях прикладные функции приданы программе-клиенту, в DBS-моделях ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором — интегрируется в компонент доступа к информационным ресурсам. Напротив, в AS- модели реализована классическая трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. Собственно, из этой особенности AS-модели и вытекают ее преимущества.
Многоуровневая архитектура — развитие архитектуры «клиент/сервер». В своей классической форме она состоит из трех уровней (рис. 2.10):
Рис. 2.10. Многоуровневая архитектура
Трехуровневая архитектура позволяет сбалансировать нагрузку на узлы и сеть. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики.
Оптимизируется распределение программно-аппаратных ресурсов. Средства удаленного вызова процедур в наибольшей степени соответствуют идее распределенных вычислений, обеспечивая:1) вызов прикладной процедуры из любого узла сети;
2) передачу параметров;
3) удаленную обработку и возврат данных.
Интернет/Интранет-технологии в сочетании с многоуровневой архитектурой позволяют создать простые и удобные информационные системы. Структура приложения приобретает следующий вид (рис. 2.11):
Рис. 2.11. Архитектура на основе Интернет/Интранет-технологии
Современный бизнес крайне чувствителен к ошибкам в управлении, и для принятия грамотного управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности лечебно-профилактического учреждения. Рассмотрим наиболее важные задачи, решаемые с помощью информационных систем.
Бухгалтерский учет — наиболее часто реализуемая на сегодняшний день задача. Бухгалтерские ошибки стоят дорого, а задача бухучета наиболее просто реализуема, т.к. легко формализуется.
Управление финансовыми потоками — внедрение информационных технологий также обусловлено критичностью этой области к ошибкам. Неправильно построив систему расчетов с поставщиками и потребителями, можно спровоцировать кризис наличности даже при налаженной сети закупки, сбыта и маркетинга (аптечная сеть).
Управление складом, ассортиментом, закупками — внедрение информационных технологий в эту область позволяет избежать замораживания оборотных средств в чрезмерном складском запасе, выявить перспективные товары (медицинское оборудование, лекарственные препараты).
Управление производственным процессом — трудоемкая задача, включающая планирование и оптимальное управление производственным процессом. Решение этой задачи дает возможность грамотно планировать, учитывать затраты, проводить техническую подготовку производства, оперативно управлять процессом выпуска продукции в соответствии с производственной программой и технологией. В области медицины это полная автоматизация бизнес-процессов и формирование единого информационного поля здравоохранения на государственном и территориальном уровнях, страховая медицина. Информационные системы управляют бизнес-процессами, включая планирование, взаимоотношения с контрагентами, организацию логистики, финансовый анализ, управление персоналом и т.д.
Управление маркетингом предполагает сбор и анализ данных о фирмах, их продукции и ценовой политике, прогнозирование рекламных кампаний, моделирования внешнего окружения для определения оптимального уровня цен (лекарственные препараты, медицинское оборудование).
Документооборот является важным процессом деятельности любого предприятия. Отлаженная система учета документооборота отражает реальную текущую производственную деятельность предприятия. В области медицины это электронные истории болезни, электронные базы данных, справочники.
Оперативное управление предприятием — это корпоративная информационная система, решающая задачи текущего управления лечебно-профилактическим учреждением. Содержит большое число баз данных, фиксирующих всю возможную информацию о предприятии. Содержимое баз данных непрерывно пополняется и модифицируется.
Представление информации о фирме — каждое уважающее себя предприятие имеет свой Web-сервер, который решает следующие задачи:
• создание имиджа медицинского учреждения;
• максимальная разгрузка справочной службы путем представления необходимой информации о фирме, товарах, услугах, ценах и т.д.
Контрольные вопросы
1. Дайте определение понятия «корпоративная информационная система».
2. Укажите существенное отличие корпоративной информационной системы от других типов информационных систем.
3. Дайте определение понятия «транзакция».
4. Приведите пример классификации информационных систем по сфере применения.
5. Чем отличается Internet от Intranet?
6. Перечислите функциональные компоненты информационной системы.
7. Приведите пример архитектуры телеобработки.
8. Поясните архитектуру информационной системы на основе файл-сервера.
9. Поясните архитектуру информационной системы на основе «клиент/сервер ».
10. Перечислите модели архитектуры «клиент/сервер».
11. Поясните особенности архитектуры «клиент/сервер» на основе RDA-модели.
12. Поясните особенности архитектуры «клиент-сервер» на основе DBS-модели.
13. Поясните особенности архитектуры «клиент-сервер» на основе AS-модели.
14. Поясните особенности многоуровневой архитектуры.
15. Приведите примеры и назовите области применения информационных систем в медицине.
3.1.