RDA-модель имеет ряд ограничений.

Отображение и управление данными

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

Виды моделей доступа к данным

модель доступа к удаленным данным (RemoteDateAccess - RDA);
модель сервера базы данных (DateBaseServer - DBS);
модель сервера приложений (ApplicationServer - AS).

В RDA-модели коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте.Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (языка SQL, например, если речь идет о базах данных) или вызовами функций специальной библиотеки (если имеется соответствующий API (API (интерфейс программирования приложений, интерфейс прикладного программирования) (англ. applicationprogramminginterface, API [эй-пи-ай]) — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) или операционной системой для использования во внешнихпрограммных продуктах.)). Запросы к информационным ресурсам направляются по сети удаленному компьютеру (например, серверу базы данных). Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных (рисунок 1). Говоря об архитектуре "клиент-сервер", в большинстве случаев имеют в виду именно эту модель.

Рис. 1. Модель доступа к удаленным данным

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

Рис. 2. Модель сервера базы данных

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

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

Рис. 3. Модель сервера приложений

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

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

RDA-модель

Главное преимущество RDA-модели лежит в практической плоскости. Сегодня существует множество инструментальных средств, обеспечивающих быстрое создание desktop-приложений, работающих с SQL-ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Иными словами, основное достоинство RDA-модели заключается в унификации и широком выборе средств разработки приложений. Подавляющее большинство этих средств разработки на языках четвертого поколения ( включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления.

RDA-модель имеет ряд ограничений.

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

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

DBS-модель

Несмотря на широкое распространение, RDA-модель уступает место более технологичной DBS-модели. Последняя реализована в некоторых реляционных СУБД (Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования ядра СУБД. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД. Попытки стандартизации языка SQL, касающиеся хранимых процедур, пока не привели к ощутимому успеху. Кроме того, во многих реализациях процедуры являются интерпретируемыми, что делает их выполнение более медленным, нежели выполнение программ, написанных на языках третьего поколения. Механизм хранимых процедур - один из составных компонентов активного сервера базы данных [2].

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

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

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

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

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

· расширение изобразительный средства языков процедур;

· средства отладки и тестирования хранимых процедур;

· предотвращение конфликтов процедур с другими программами;

· поддержка приоритетной обработки запросов.

Между тем эти возможности уже реализованы в AS-модели, которая в наибольшей степени отражает сильные стороны технологии "клиент-сервер".

AS-модель

Основным элементом принятой в AS-модели трехзвенной схемы является сервер приложения. В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как служба (service) и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения (ApplicaationClient - AC). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. AC обращается с запросом к конкретной службе, но не к AS, то есть серверы приложений обезличены и служат лишь своего рода "рамкой" для оформления служб, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от АС, выстраиваются в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами.

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

Нетрудно видеть, что AS-модель имеет универсальный характер. Четкое разграничение логических компонентов и рациональный выбор программных средств для их реализации обеспечивают модели такой уровень гибкости и открытости, который пока недостижим в RDA- и DBS-моделях.

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

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

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

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

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

На логическом уровне управление процессом накопления - это комплексы программ управления базами данных, получившие название систем управления базами данных. С увеличением объемов информации, хранимых в базах данных, при переходе к распределенным базам и банкам данных управление процессом накопления усложняется и не всегда поддается формализации.

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

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

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

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

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

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

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

Методы визуализации

Методы визуализации, в зависимости от количества используемых измерений, принято классифицировать на две группы [22]:

· представление данных в одном, двух и трех измерениях;

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

Дата добавления: 2018-06-01; просмотров: 373; Мы поможем в написании вашей работы!

Поделиться с друзьями:

12 3 Следующая ⇒

Мы поможем в написании ваших работ!