Организация удаленного доступа к распределенным базам данных
Для СУБД это качество означает следующее:
· способность приложений, созданных средствами разработки данной СУБД, оперировать над базами данных в "чужом" формате так, как будто это собственные базы данных;
· свойство СУБД, позволяющее ей служить в качестве поставщика данных для любых приложений, созданных средствами разработки третьих фирм, поддерживающих некоторый стандарт обращения к базам данных.
Первое достигается использованием шлюзов, второе - использованием интерфейсов ODBC (Open Database Connectivity) и BDE (Borland Database Engine).
Современные информационные системы требуют доступа к разнородным базам данных. Это означает, что в прикладной программе для реализации запросов к базам данных должны быть использованы такие средства, чтобы запросы были понятны различным СУБД, как реляционным, так и опирающимся на другие модели данных. Одним из возможных путей является обобщенный набор различных диалектов языка SQL.
Существует альтернатива технологии распределенных БД - тиражирование данных. Принципиальное отличие технологии тиражирования данных от технологии распределенных баз данных (которую часто для краткости называют технологией STAR) заключается в отказе от распределенных данных. Ее суть состоит в том, что любая БД (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные всегда размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.
Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащие различным узлам распределенной системы. Функции тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (replicator). Его задача - поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. Сигналом для запуска репликатора служит срабатывание триггера, перехватывающего любые изменения тиражируемого объекта БД. Возможно и программное управление репликатором посредством сигнализаторов о событиях в базе данных.
В качестве базиса для тиражирования выступает транзакция к БД. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность исследовать состояние принимающей БД на определенный момент времени.
Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависит от работы репликатора, который целиком находится в ведении администратора БД. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модифицировать.
Особенность технологии распределенных БД - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в распределенной БД. Недостаток технологии STAR - жесткие требования к производительности и надежности каналов связи. Если БД распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет десятки и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях обработка распределенных данных практически невозможна.
Реальной альтернативой технологии STAR является технология тиражирования данных, не требующая синхронной фиксации изменений. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критичные моменты времени. Следовательно, можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы.
Преимущества технологии тиражирования данных:
1. Данные всегда расположены там, где они обрабатываются - следовательно, скорость доступа к ним существенно увеличивается.
2. Передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным, как в технологии STAR), и к тому же в асинхронном режиме позволяет значительно уменьшить трафик.
3. Со стороны исходной БД для принимающих БД репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом.
4. Никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.
Технология тиражирования данных имеет и недостатки, вытекающие из ее специфики. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Они могут возникнуть, когда вследствие асинхронности передачи данных два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. Следовательно, при проектировании распределенной среды с использованием технологии тиражирования данных необходимо предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их разрешения.
1.4 Взаимодействие с PC-ориентированными СУБД
Первоначально профессиональные СУБД создавались для мощных высокопроизводительных платформ - IBM, DEC, Helwett-Packard, Sun. Но затем, учитывая все возрастающую популярность и широкое распространение персональных компьютеров, разработчики приступили к переносу (портированию) СУБД в операционные среды desktop-компьютеров (OS/2, NetWare, UnixWare, SCO UNIX).
В настоящее время большинство компаний - поставщиков СУБД развивает три направления своих систем. Во-первых, совершенствование СУБД для корпоративных информационных систем, которые характеризуются большим числом пользователей (от 100 и выше), базами данных огромного объема (их часто называют сверхбольшими базами данных - Very Large Data Base - VLDB), смешанным характером обработки данных (решение задач оперативной обработки транзакций и поддержки принятия решений) и т.д. Это - традиционная область mainframe-систем и приближающихся к ним по производительности RISC-компьютеров.
Другое направление - СУБД, поддерживающие так называемые рабочие группы. Это направление характеризуется относительно небольшим количеством пользователей с сохранением, тем не менее, всех "многопользовательских" качеств. Системы этого класса ориентированы преимущественно на "офисные" применения, не требующие специальных возможностей. Так, большинство современных многопользовательских СУБД имеют версии системы, функционирующие в сетевой операционной системе Novell NetWare. Ядро СУБД оформлено здесь как загружаемый модуль NetWare (NetWare Loadable Module - NLM), выполняющийся на файловом сервере. База данных также располагается на файловом сервере. SQL-запросы поступают к ядру СУБД от прикладных программ, которые запускаются на станциях сети - персональных компьютерах (отметим, что, несмотря на использование файлового сервера, здесь мы имеем дело с RDA-моделью).
Наконец, новый импульс в развитии получило направление настольных (desktop) версий СУБД, ориентированных на персональное использование - преимущественно в операционной среде MS Windows (системы этого класса получили неформальное определение "light" или "local").
Стремление компаний - поставщиков СУБД иметь фактически по три варианта своих систем, покрывающих весь спектр возможных применений, выглядит для пользователей чрезвычайно привлекательно. Действительно, для специалиста исключительно удобно иметь на своем портативном компьютере локальную базу данных (постоянно используемую во время командировок) в том же формате и обрабатываемую по тем же правилам, что и стационарную корпоративную базу фирмы, куда собранные данные могут быть без труда доставлены.
В последние годы (1987-94) в нашей стране было разработано множество программ, ориентированных на использование СУБД типа PARADOX, FoxPRO, dBASE IV, Clipper. При переходе на более мощную многопользовательскую СУБД у пользователей возникает естественное желание интегрировать уже существующие разработки в эту среду. Например, может возникнуть потребность хранить локальные данные на персональном компьютере и осуществлять к ним доступ с помощью системы FoxPRO, и одновременно иметь доступ к глобальной базе данных под управлением СУБД Oracle. Организация такого доступа, когда программа может одновременно работать и с персональной, и с многопользовательской СУБД, представляет собой сложную проблему по следующей причине.
Как известно, разработчики PC-ориентированных СУБД первоначально использовали свой собственный интерфейс к базам данных, никак не учитывая требования стандарта языка SQL. Лишь впоследствии они стали постепенно включать в свои системы возможности работы с базой данных при помощи SQL. В то же время для истинно многопользовательских СУБД интерфейс SQL - фактический стандарт. При этом возникла задача согласования интерфейсов СУБД различных классов. Она может решаться несколькими способами, но большинство из них имеют частный характер. Рассмотрим наиболее общее решение этой задачи.
Специалисты фирмы Microsoft разработали стандарт Open Database Connectivity (ODBC). Он представляет собой стандарт прикладного программного интерфейса прикладных (Application Programming Interface - API) и позволяет программам, работающим в среде Microsoft Windows, взаимодействовать (посредством операторов языка SQL) с различными СУБД, как персональными, так и многопользовательскими, функционирующими в различных операционных системах. Фактически, интерфейс ODBC универсальным образом отделяет чисто прикладную, содержательную сторону приложений (обработка электронных таблиц, статистический анализ, деловая графика) от собственно обработки и обмена данными с СУБД. Основная цель ODBC - сделать взаимодействие приложения и СУБД прозрачным, не зависящим от класса и особенностей используемой СУБД (мобильным с точки зрения используемой СУБД).
Отметим, что стандарт ODBC является неотъемлемой частью семейства стандартов, облегчающих написание и обеспечивающих вертикальную открытость приложений (WOSA - Windows Open Services Architecture - открытая архитектура сервисов системы Windows).
Интерфейс ODBC обеспечивает взаимную совместимость серверных и клиентских компонентов доступа к данным. Для реализации унифицированного доступа к различным СУБД было введено понятие драйвера ODBC (представляющего собой динамически загружаемую библиотеку).
ODBC-архитектура содержит четыре компонента:
· приложение;
· менеджер драйверов;
· драйверы;
· источники данных.
Роли среди них распределены следующим образом. Приложение вызывает функции ODBC для выполнения SQL-инструкций, получает и интерпретирует результаты; менеджер драйверов загружает ODBC-драйверы, когда этого требует приложение; ODBC-драйверы обрабатывают вызовы функций ODBC, передают операторы SQL СУБД и возвращают результат в приложение; источник данных (data source) - объект, скрывающий СУБД, детали сетевого интерфейса, расположение и полное имя базы данных и т.д.
Действия, выполняемые приложением, использующим интерфейс ODBC, сводятся к следующему. Для начала сеанса работы с базой данных приложение должно подключиться к источнику данных, ее скрывающему. Затем приложение обращается к базе данных, посылая SQL-инструкции, запрашивает результаты, отслеживает и реагирует на ошибки и т.д., то есть имеет место стандартная схема взаимодействия приложения и сервера БД, характерная для RDA-модели. Важно, что стандарт ODBC включает функции управления транзакциями (начало, фиксация, откат транзакции). Завершив сеанс работы, приложение должно отключиться от источника данных.
Слой доступа к данным, подобный ODBC использует в своих продуктах компания Borland. Эта система носит название Borland Database Engine (BDE) и имеет некоторые преимущества по сравнению с ODBC.
1.5 Обработка транзакций
Транзакция представляет собой последовательность операторов языка SQL, которая рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя. В то же время, это логическая единица работы системы. Транзакция реализует некоторую прикладную функцию, например, перевод денег с одного счета на другой в банковской системе.
Существуют различные модели транзакций, которые могут быть классифицированы на основании различных свойств, включающих структуру транзакции, параллельность внутри транзакции, продолжительность и т.д. Чаще всего имеют в виду традиционные транзакции, характеризуемые четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) - ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:
1. Свойство атомарности выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.
2. Свойство согласованности гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной согласованности данных.
3. Свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.
4. Свойство долговечности трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок).
Расширенные транзакции допускают формирование из ACID-транзакций иерархических структур. Если конкретная модель ослабляет некоторые из требований ACID, то речь идет об ослабленной транзакции.
Возможны два варианта завершения транзакции. Если все операторы выполнены успешно, и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, транзакция фиксируется.
Фиксация транзакции - это действие, обеспечивающее запись на диск изменений в базе данных, которые были сделаны в процессе выполнения транзакции. До тех пор, пока транзакция не зафиксирована, возможно аннулирование этих изменений, восстановление базы данных в то состояние, в котором она была на момент начала транзакции. Фиксация означает, что все результаты выполнения транзакции становятся постоянными. Они станут видимыми другим транзакциям только после того, как текущая транзакция будет зафиксирована. До этого момента все данные, затрагиваемые транзакцией, будут "видны" пользователю в состоянии на начало текущей транзакции.
Если в процессе выполнения транзакции произошла ошибка, база данных должна быть возвращена в исходное состояние. Откат транзакции - это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции.
Каждый оператор в транзакции выполняет свою часть работы, но для успешного завершения всей работы в целом требуется безусловное завершение их всех. Группирование операторов в транзакции сообщает СУБД, что вся эта группа должна быть выполнена как единое целое, причем такое выполнение должно поддерживаться автоматически.
В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащегося в программе. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных способов:
· оператор COMMIT означает успешное завершение транзакции; его использование делает постоянными изменения, внесенные в базу данных в рамках текущей транзакции;
· оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в базе данных в рамках этой транзакции; новая транзакция начинается непосредственно после использования ROLLBACK;
· успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор COMMIT);
· ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).
Откат и фиксация транзакций становятся возможными благодаря журналу транзакций. Он используется следующим образом.
Известно, что все операции над реляционной базой данных - это операции над строками таблиц. Следовательно, для обеспечения отката таблиц к предыдущим состояниям достаточно хранить не состояния всей таблицы, а лишь те ее строки, которые подверглись изменениям.
При выполнении любого оператора SQL, который модифицирует базу данных, СУБД автоматически заносит очередную запись в журнал транзакций. Запись состоит из двух компонентов: первый - это состояние строки до внесения изменений, второй - ее же состояние после внесения изменений. Только после занесения записи в журнал транзакций (идеология «write ahead log»), СУБД действительно модифицирует базу данных. Если после данного оператора SQL был выполнен оператор COMMIT, то в журнале транзакций делается отметка о завершении текущей транзакции. Если же после оператора SQL следовал оператор ROLLBACK, то СУБД просматривает журнал транзакций и отыскивает записи, отражающие состояние измененных строк до модификации. Используя их, СУБД восстанавливает те строки в таблицах базы данных, которые были модифицированы текущей транзакцией - таким образом аннулируются все изменения в базе данных.
Важные проблемы многопользовательских СУБД связаны с организацией с помощью механизма транзакций одновременного доступа множества пользователей к одним и тем же данным.