Основные понятия систем с распределенной обработкой данных
SQL – инструкции для работы с транзакциями
SQL – инструкции для работы с сеансами
Для изменения настроек сеанса работы пользователя с базой данных в языке SQL используется команда установки SET. Эта команда имеет одну из следующих синтаксических конструкций:
SET <ключевое слово> ON|OFF
SET <ключевое слово> <опции>
SET <переменная>=<значение>
Таких команд установки в каждом диалекте обычно бывает много для реализации настройки сеанса пользователя. Например, для присвоения сеансу конкретной или текущей роли используется команда SET ROLE {<имя роли>|NONE}. Для определения уровня изолированности пользователей используется команда:
SET TRANSACTION ISOLATION LEVEL <опции>.
Транзакция – неделимая с точки зрения воздействия на базу данных последовательность операций, завершающаяся фиксацией или откатом. Главное назначение транзакций – это сохранение базы данных в целостном состоянии при выполнении различных операций. Для создания транзакции используется команда BEGIN TRANSACTION. Для выполнения отката транзакции, в результате чего база данных возвращается в исходное состояние, используется команда ROLLBACK. Для фиксации в базе данных сделанных в транзакции операций, используется команда COMMIT. В случае необходимости реализации логики внутри транзакции могут быть использованы точки сохранения транзакций – SAVEPOINT TRANSACTION. Понятие транзакции является фундаментальным в задачах систем с распределенной обработкой данных, основы которых будут рассмотрены в следующей главе.
Глава 6. Теоретические основы распределенных баз данных
Распределённая база данных – это база данных, состоящая из нескольких, возможно пересекающихся или дублирующих друг друга частей, хранимая в различных ЭВМ вычислительной сети. Распределённая база данных находится на рабочих станциях вычислительной сети.
Основная задача систем управления распределёнными базами данных состоит в обеспечении средства интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе. При этом должны обеспечиваться: простота использования системы, возможности автономного функционирования при нарушениях связности сети или при административных потребностях, высокая степень эффективности.
В настоящее время системы коллективного доступа к данным могут поддерживать одну из следующих трех моделей: модель файлового сервера, модель сервера базы данных, модель сервера приложений. Модель файлового сервера представлена на рисунке 6.1.
Уровень Рабочая станция Файловый сервер
представлений
Диалог с Технологические
пользователем
бизнес-правила Операторы файлы
обращения к СУБД
Файлы базы
ядро СУБД Выполнение
операторов данных
 | |||||
 | |||||
 | |||||
Запросы к файлу Данные из файла
Рисунок 6.1 – Модель файлового сервера
При реализации модели файлового сервера приложение выполняется на рабочих станциях, где находится и ядро СУБД, база данных расположена на сервере. Такие системы имеют низкую производительность, так как промежуточные данные передаются по низкоскоростной шине сети, а прикладные программы и ядро СУБД находятся на маломощных рабочих станциях. Такую модель в системах коллективного доступа к данным реализуют фактически локальные СУБД FoxPro, Access,Clipper,Paradox,dBase и другие. Модель файлового сервера не поддерживает распределенную обработку данных.
На рисунке 6.2 приведена модель сервера базы данных.
Уровень Рабочая станция Сервер
представления
Диалог с Файлы база данных
пользователем
бизнес-правила Операторы
обращения к Ядро СУБД
СУБД
 |
SQL операторы Результаты выполнения
 |  |
Рисунок 6.2 – Модель сервера базы данных
При реализации модели сервера базы данных приложение выполняется на рабочих станциях. Операторы не выполняются на рабочих станциях, а пересылаются для обработки на сервер. Ядро СУБД транслирует запрос и выполняет его, обращаясь к индексам и другим промежуточным данным. Обратно на рабочую станцию передаются только результаты обработки оператора. Эта модель поддерживает распределенную обработку данных. Модель сервера базы данных поддерживают такие СУБД как Oracle, MS SQL Server, Sybase, Informix, Ingress и другие. Системы с такой моделью имеют высокую производительность, так как по шине передаются только SQL-запросы и результаты выполнения. Сами запросы выполняются на высокоскоростных серверах. Недостатком такой модели является использование дорогих сервера и сети. На рисунке 6.3 показана модель сервера приложений.
Рабочая станция Сервер
Уровень Файлы базы данных
представления Вызов хранимых Сервер приложений
процедур Реализация Ядро
бизнес-правил СУБД
 | |||||
 |  |
Обращение к сервису Результаты выполнения сервиса
Рисунок 6.3 – Модель сервера приложений
Сервер приложений можно организовать с помощью хранимых процедур на языках, таких как PL/SQL, TRANSACT SQL и других. Эта модель также поддерживает распределенную обработку данных. Системы на базе моделей сервера базы данных и сервера приложений поддерживают архитектуру клиент-сервер. Сервер базы данных в системах распределенной обработки – это логический процесс, отвечающий за обработку запросов к базе данных. Клиент базы данных – это логический процесс, посылающий серверу запрос на обслуживание. Архитектура клиент-сервер позволяет нескольким клиентам использовать совместно один сервер. При большом числе клиентов такая архитектура приводит к увеличению вероятности отказов ее компонентов. Клиент также выполняет функции представления интерфейса пользователя и может выполнять несложные операции обработки данных. Другие функции распределены между несколькими компьютерами – серверами баз данных и сервером приложений. Серверы баз данных управляют данными, а сервер приложений выполняет все вычисления, связанные с реализацией бизнес - логики приложения. Такую архитектуру называют многозвенной.
Существуют различные виды распределенных баз данных. Возможны однородные и неоднородные распределённые базы данных. В однородном случае каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных – это актуальная, но очень сложная проблема. Многие решения известны на теоретическом уровне, но пока не удаётся справиться с главной проблемой – недостаточной эффективностью интегрированных систем. Более успешно практически решается промежуточная задача – интеграция неоднородных SQL-ориентированных систем. Понятно, что этому в большой степени способствует стандартизация языка SQL и общее следование производителей СУБД принципам открытых систем.