Распределенная обработка данных

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 19:34, 18 января 2019.

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

Обзор

Преимущества

Распределенная обработка данных имеет следующие преимущества:

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

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

Недостатки

Распределенная обработка данных имеет следующие недостатки:

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

История

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

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

Поэтому, в любом приложении можно выделить следующие компоненты:

  • компонент представления данных;
  • прикладной компонент;
  • компонент управления ресурсом.

Связь между компонентами осуществляется по определенным правилам, которые называют "протокол взаимодействия". Каждый из компонентов приложения при этом может работать на выделенном сервере (узле) или разделять ресурсы сервера с другими компонентами приложения. В связи с этим можно выделить следующие модели приложений: - двухзвенная модель (модель «клиент-сервер»); - трехзвенная модель (модель сервера приложений); - многозвенная модель. Двухзвенная модель позволяет распределить различным образом три компонента приложения между двумя узлами. Трехзвенная модель предполагает выделение для каждого из трех компонентов приложения свой сервер. Многозвенная модель позволяет отдельным компонентам использовать ресурсы нескольких серверов, например, распределенные базы данных. Компанией Gartner Group, специализирующейся в области исследования информационных технологий, предложена следующая классификация двухзвенных моделей взаимодействия клиент-сервер (см. рисунок 1)

Рисунок 1 - Классификация двухзвенных моделей:

Исторически первой появилась модель распределенного представления данных, которая реализовывалась на универсальной ЭВМ с подключенными к ней неинтеллектуальными терминалами. Управление данными и взаимодействие с пользователем при этом объединялись в одной программе, на терминал передавалась только "картинка", сформированная на центральном компьютере. Затем, с появлением ПК и локальных сетей, были реализованы модели доступа к удаленной базе данных. Некоторое время базовой для сетей ПК была архитектура файлового сервера. При этом один из компьютеров является файловым сервером, на клиентах выполняются приложения, в которых совмещены компонент представления и прикладной компонент (СУБД и прикладная программа). Протокол обмена при этом представляет набор низкоуровневых вызовов операций файловой системы. Такая архитектура, реализуемая, как правило, с помощью персональных СУБД, имеет очевидные недостатки - высокий сетевой трафик и отсутствие унифицированного доступа к ресурсам. С появлением первых специализированных серверов баз данных появилась возможность другой реализации модели доступа к удаленной базе данных. В этом случае ядро СУБД функционирует на сервере, протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса "клиент-сервер". Однако сетевой трафик остается достаточно высоким, кроме того, по прежнему невозможно удовлетворительное администрирование приложений, поскольку в одной программе совмещаются различные функции. Позже была разработана концепция активного сервера, который использовал механизм хранимых процедур. Это позволило часть прикладного компонента перенести на сервер (модель распределенного приложения). Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, что и SQL-сервер. Преимущества такого подхода: возможно централизованное администрирование прикладных функций, значительно снижается сетевой трафик ( т. к. передаются не SQL-запросы, а вызовы хранимых процедур). Недостаток - ограниченность средств разработки хранимых процедур по сравнению с языками общего назначения (C и Pascal). На практике часто используется смешанный подход: - простейшие прикладные функции выполняются хранимыми процедурами на сервере; - более сложные функции реализуются на клиенте непосредственно в прикладной программе. В настоящее время получило широкое распространение использование модели распределенного приложения. Характерной чертой таких приложений является логическое разделение приложения на две и более частей, каждая из которых может выполняться на отдельном сервере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. В этом случае двухзвенная архитектура клиент-сервер становится трехзвенной, а в некоторых случаях, она может включать и больше звеньев.(см. рисунок 2)

Рисунок 2 - Структура клиент-серверного приложение с БД:

Распределенная обработка данных

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

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

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

Системы распределённой обработки данных

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

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

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

Рисунок 3 - Режим работы с БД:

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

Первой полностью реляционной системой, работающей в многопользовательском режиме, была СУБД SYSTEM R, разработанная фирмой IBM, именно в ней были реализованы как язык манипулирования данными SQL, так и основные принципы синхронизации, применяемые при распределенной обработке данных, которые до сих пор являются базисными практически во всех коммерческих СУБД. Общая тенденция движения от отдельных mainframe-систем к открытым распределенным системам, объединяющим компьютеры среднего класса, получила название DownSizing. Этот процесс оказал огромное влияние на развитие архитектур СУБД и поставил перед их разработчиками ряд сложных задач. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД, использовавшей собственные модели, форматы представления данных и языки доступа к данным и т. д., к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в глобальную сеть компьютеров различных моделей и производителей. В то же время происходил встречный процесс - UpSizing. Бурное развитие персональных компьютеров, появление локальных сетей также оказали серьезное влияние на эволюцию СУБД. Высокие темпы роста производительности и функциональных возможностей PC привлекли внимание разработчиков профессиональных СУБД, что привело к их активному распространению на платформе настольных систем. Сегодня возобладала тенденция создания информационных систем на такой платформе, которая точно соответствовала бы ее масштабам и задачам. Она получила название RightSizing (помещение ровно в тот размер, который необходим). Однако и в настоящее время большие ЭВМ сохраняются и сосуществуют с современными открытыми системами. Причина этого проста - в свое время в аппаратное и программное обеспечение больших ЭВМ были вложены огромные средства: в результате многие продолжают их использовать, несмотря на морально устаревшую архитектуру. В то же время перенос данных и программ с больших ЭВМ на компьютеры нового поколения сам по себе представляет сложную техническую проблему и требует значительных затрат. Одновременная работа пользователей с базой данной, распределенной по нескольким компьютерам, расположенным в сети, называется параллельным доступом к распределенным БД. Подобные системы называются системами распределенных баз данных

Системы распределенных баз данных

Наиболее часто данные размещаются в БД. Ими обычно управляют локальные СУБД, то есть размещённые на том же компьютере. Когда несколько таких БД удалены друг от друга на большие расстояния, то возникает необходимость решения задач управления ими, то есть распределёнными БД. Для решения таких задач между ЭВМ с локальными СУБД и БД организуют сеть передачи данных по каналам связи, а в ней обеспечивают техническую и программную поддержку обмена данными. То есть в этом случае используют ПО, управляющее распределёнными базами данных, которые могут образовывать банки данных. Распределенные базы данных (Distributed Data Base, DDB) представляют определённым образом связанные между собой БД, рассредоточенные на какойлибо территории (локально или регионально), обеспечивающие свободный обмен информацией и поиск данных в них. Распределённая база данных предполагает хранение и выполнение функций управления данными в нескольких узлах и передачу данных между этими узлами в процессе выполнения запросов. Разбиение данных в распределённой базе данных может достигаться путём хранения различных таблиц на разных компьютерах или даже хранения разных частей и фрагментов одной таблицы на разных компьютерах. Для пользователя или прикладной программы не имеет значения, каким образом распределены данные между компьютерами. Работа с распределённой базой данных осуществляется так же, как и с централизованной, т. е. размещение БД должно быть прозрачно. При распределённой обработке работа с базой (представление данных, их обработка и др.) ведётся на компьютере клиента, а поддержание базы в актуальном состоянии – на сервере. При этом такие БД обычно располагаться на нескольких серверах – различных узлах компьютерной сети, а некоторые данные могут дублироваться. Размещение частей общей БД бывает избыточным или безызбыточным. При избыточном размещении определяют степень дублирования частей (фрагментов) единой БД. Чтобы поддерживать целостность БД необходимо постоянно корректировать все её копии. Преимущества дублирования уменьшаются, когда увеличивается стоимость хранения её частей, что связано с необходимостью обеспечивать устойчивость системы. Создание распределённых баз данных (РБД) вызвано попыткой одновременного решения двух задач: интеграции и децентрализации. Интеграция подразумевает централизованное управление и ведение баз данных. Децентрализация обеспечивает хранение данных там, где они появились и обрабатываются. При решении этих задач снижается стоимость системы и увеличивается степень её надёжности, а также повышается скорость обработки данных. Решение задач интеграции и децентрализации распределенных баз данных привело к появлению нового вида программного обеспечения, на котором остановимся более подробно

Системы управления распределёнными базами данных

Доступ пользователей к распределенным базам данных и их администрирование осуществляются с помощью системы управления распределённой базой данных (СУРБД). Система управления распределёнными базами данных (Distributed dataBase management system, DDBMS) - это система управления базами данных, расположенными в нескольких узлах информационной сети. В СУРБД используется комбинация централизованного и локального способов хранения данных. Для решения задач с распределёнными БД, во-первых, необходимо организовать между этими ЭВМ сеть передачи данных, то есть соединить их каналами связи. Затем обеспечивают техническую и программную поддержку обмена данными между ними, образуя тем самым сеть ЭВМ. СУРБД создаются таким образом, чтобы максимально обеспечить соблюдение принципа независимости прикладных программ от локализации данных в сети. При этом логическое представление распределённой БД и манипулирование данными для прикладной программы ничем не отличаются от работы пользователя с локальной базой. Такие СУРБД оснащены каталогами, в которых хранятся структура сети, информация о локальных СУРБД и базах данных, а также программным обеспечением, которое на основе этой информации управляет взаимодействием прикладной программы и конкретной локальной базой данных сети. Сложность управления распределёнными базами данных во многом зависит от того, поддерживаются ли они однотипными локальными СУРБД, взаимодействие между которыми осуществляется просто. В противном случае в такую сеть включают различные программные и технические устройства, обеспечивающие единый интерфейс, согласование и возможность выполнения информационных процессов, например, использовать промежуточную интерфейсную СУРБД и др.

Модели распределенной обработки данных в современных СУБД

Распределенная обработка данных исходно связана с парадигмой открытых систем, которая появилась в 90-х годах и быстро эволюционировала. Ранее приложение (пользовательская программа) не разделялась на части, оно выполнялось некоторым монолитным блоком. Но возникла идея более рационального использования ресурсов сети. Действительно, при монолитном исполнении используются ресурсы только одного компьютера, а остальные компьютеры в сети рассматриваются как терминалы. Но теперь, в отличие от эпохи main-фреймов, все компьютеры в сети обладают собственными ресурсами, и разумно так распределить нагрузку на них, чтобы максимальным образом использовать их ресурсы. Для распределения нагрузки между узлами сети необходимо разработать модель разбиения единого монолитного приложения на отдельные части и определить принципы взаимосвязи между этими частями. Рассмотрим типовое интерактивное приложение, работающее с системой управления базой данных. Интерактивные приложения, работающие с базами данных(см. рисунок 4), выполняют функции, которые можно объединить в следующие группы: [Источник 2]

  • функции ввода и отображения данных (Presentation Logic);
  • прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
  • функции обработки данных внутри приложения (Database Logic);
  • функции управления информационными ресурсами (Database ManagerSystem);
  • служебные функции, играющие роль связок между функциями первых четырех групп.


Рисунок 4 - Структура типового приложения работающего с БД:

Презентационная логика

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

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

Некоторые возможности для организации презентационной логики приложений предоставляет знако-ориентированный пользовательский интерфейс, задаваемый моделями CICS (Customer Control Information System ) и IMS/DC фирмы IBM и моделью TSO (Time Sharing Option) для централизованной main-фреймовой архитектуры. Модель GUI — графического пользовательского интерфейса, поддерживается в операционных средах Microsoft Windows, в OS/2 Presentation Manager, X-Windows и OSF/Motif.

Бизнес-логика

Бизнес логика, или логика собственно приложений (Business processing Logic), — это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как C, C++, Cobol, SmallTalk, Visual-Basic.

Логика обработки данных

Логика обработки данных (Data manipulation Logic) — это часть кода приложения, которая связана с обработкой данных внутри приложения. Данными управляет собственно СУБД (DBMS). Для обеспечения доступа к данным используются язык запросов и средства манипулирования данными стандартного языка SQL. Обычно операторы языка SQL встраиваются в языки 3-го или 4-го поколения (3GL, 4GL), которые используются для написания кода приложения. Процессор управления данными (Database Manager System Processing) - это собственно СУБД, которая обеспечивает хранение и управление базами данных. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения.

Централизованная архитектура

В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы(см. рисунок 5).

Децентрализованная архитектура

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

  • распределенная презентация (Distribution presentation, DP);
  • удаленная презентация (Remote Presentation, RP);
  • распределенная бизнес-логика (Remote business logic, RBL);
  • распределенное управление данными (Distributed data management, DDM);
  • удаленное управление данными (Remote data management, RDA)

Рисунок 5 - Компоненты приложения:

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

Двухзвенная модель

Двухзвенная модель фактически является результатом распределения пяти указанных функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. Можно выделить следующие виды двухзвенной модели:[Источник 3]

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

В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двухуровневой модели. Модель удаленного управления данными также называется моделью файлового сервера (File Server, FS). В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиенте (см. рисунок 6)

Рисунок 6 - Структура типового приложения работающего с БД:

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

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

В модели удаленного доступа (Remote Data Access, RDA) база данных хранится на сервере. На сервере же находится ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. приведена на (см. рисунок 7)

Рисунок 7 - Структура модели удаленного доступа

Преимущества данной модели:

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

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

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

Действительно, например, если, например, необходимо выполнять контроль страховых запасов товаров на складе, то каждое приложение, которое связано с изменением состояния склада, после выполнения операций модификации данных, имитирующих продажу или удаление товара со склада, должно выполнять проверку на объем остатка. В случае, если объем остатка меньше страхового запаса, формировать соответствующую заявку на поставку требуемого товара. Это усложняет клиентское приложение, с одной стороны, а с другой - может вызвать необоснованный заказ дополнительных товаров несколькими приложениями. Для того чтобы избавиться от недостатков модели удаленного доступа, должны быть соблюдены следующие условия: 1. Необходимо, чтобы БД в каждый момент отражала текущее состояние предметной области, которое определяется не только собственно данными, но и связями между объектами данных. То есть данные, которые хранятся в БД, в каждый момент времени должны быть непротиворечивыми. 2. БД должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rules). Например, завод может нормально работать только в том случае, если на складе имеется некоторый достаточный запас (страховой запас) деталей определенной номенклатуры, деталь может быть запущена в производство только в том случае, если на складе имеется в наличии достаточно материала для ее изготовления, и т. д. 3. Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них: например, при достижении некоторым измеряемым параметром критического значения должно произойти отключение определенной аппаратуры, при уменьшении товарного запаса ниже допустимой нормы должна быть сформирована заявка конкретному поставщику на поставку соответствующего товара. 4. Необходимо, чтобы возникновение некоторой ситуации в БД четко и оперативно влияло на ход выполнения прикладной задачи. 5. Одной из важнейших проблем СУБД является контроль типов данных. В настоящий момент СУБД контролирует синтаксически только стандартно допустимые типы данных, то есть такие, которые определены в языке описания данных (data definition language, DDL), который является частью SQL. Однако в реальных предметных областях у нас действуют данные, которые несут в себе еще и семантическую составляющую, например, это координаты объектов или единицы различных метрик, например рабочая неделя в отличие от реальной имеет сразу после пятницы понедельник. Данную модель поддерживают большинство современных СУБД: Oracle, DB2, MS SQL Server. Основу данной модели составляет механизм хранимых процедур как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных, который иногда называется механизмом поддержки доменной структуры.(см. рисунок 8)

Рисунок 8 - Модель сервера баз данных

В этой модели бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур - специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу, которые требуются клиенту либо для вывода на экран, либо для выполнения части бизнес-логики, которая расположена на клиенте. Трафик обмена информацией между клиентом и сервером резко уменьшается. Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД. Термин "триггер" взят из электроники и семантически очень точно характеризует механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер. Каждый триггер представляет собой также некоторую программу, которая выполняется над базой данных. Триггеры могут вызывать хранимые процедуры. Механизм использования триггеров предполагает, что при срабатывании одного триггера могут возникнуть события, которые вызовут срабатывание других триггеров. Этот мощный инструмент требует тонкого и согласованного применения, чтобы не получился бесконечный цикл срабатывания триггеров. В данной модели сервер является активным, потому что не только клиент, но и сам сервер, используя механизм триггеров, может быть инициатором обработки данных в БД. И хранимые процедуры, и триггеры хранятся в словаре БД, они могут быть использованы несколькими клиентами, что существенно уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях. Для написания хранимых процедур и триггеров используется расширение стандартного языка SQL (например, в Oracle язык PL-SQL, в MS SQL Server язык Transact SQL). Недостатком данной модели является очень большая загрузка сервера. Действительно, сервер обслуживает множество клиентов и выполняет следующие функции: - осуществляет мониторинг событий, связанных с описанными триггерами; - обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;

  • обеспечивает исполнение внутренней программы каждого триггера;
  • запускает хранимые процедуры по запросам пользователей;
  • запускает хранимые процедуры из триггеров;
  • возвращает требуемые данные клиенту;
  • обеспечивает все функции СУБД (доступ к данным, контроль и поддержку

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

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

Трехзвенная модель или модель сервера приложений является расширением двухзвенной модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехзвенной модели приведена на рисунке 4.6. Этот промежуточный уровень содержит один или несколько серверов приложений.(см. рисунок 9)

Рисунок 9 - Модель сервера приложений

В этой модели компоненты приложения делятся между тремя исполнителями:

  • клиент;
  • серверы приложений;
  • серверы баз данных.

Клиент обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы; клиент может запускать локальный код приложения клиента, который может содержать обращения к локальной БД, расположенной на компьютере-клиенте. Клиент исполняет коммуникационные функции front-end части приложения, которые обеспечивают доступ клиенту в локальную или глобальную сеть. Дополнительно реализация взаимодействия между клиентом и сервером может включать в себя управление распределенными транзакциями, что соответствует тем случаям, когда клиент также является клиентом менеджера распределенных транзакций. Серверы приложений составляют новый промежуточный уровень архитектуры. Они спроектированы как исполнения общих незагружаемых функций для клиентов. Серверы приложений поддерживают функции клиентов как частей взаимодействующих рабочих групп, поддерживают сетевую доменную операционную среду, хранят и исполняют наиболее общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов, особенно в распределенных транзакциях. Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application). Отметим, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений. (On-line analytical processing.) В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как C, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость. Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки XA-протокола (X/Open transaction interface protocol), который поддерживается большинством поставщиков СУБД. Модель сервера приложений стала активно использоваться в глобальной сети Internet. В таком случае в сервер приложений тесно интегрируется с webсервером, например, Apache. Такой подход зарекомендовал себя как один из методов публикации баз данных в Internet

Источники

  1. Распределенная обработка данных. Технология «клиент-сервер // StudFiles [2019]. URL: https://studfiles.net/preview/2484532/page:19/ (дата обращения: 23.10.2017).
  2. Базы данных: модели, разработка, реализация // ИНТУИТ [2019]. URL: https://www.intuit.ru/studies/courses/1001/297/lecture/7417 (дата обращения: 24.10.2017).
  3. Учебное пособие М. В. Додонов, Е. В. Сопченко // СГАУ имени академика С.П. Королёва [2019]. URL: https://ssau.ru/files/education/uch_posob/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F%20%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%94%D0%BE%D0%B4%D0%BE%D0%BD%D0%BE%D0%B2%20%D0%9C%D0%92.pdf (дата обращения: 25.10.2017).