Реализация распределенной базы данных с удаленным доступом

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

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

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

      В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащегося в программе. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных способов:  

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

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

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

      При выполнении любого оператора SQL, который  модифицирует базу данных, СУБД автоматически заносит очередную запись в журнал транзакций. Запись состоит из двух компонентов: первый - это состояние строки до внесения изменений, второй - ее же состояние после внесения изменений. Только после занесения записи в журнал транзакций (идеология «write ahead log»), СУБД действительно модифицирует базу данных. Если после данного оператора SQL был выполнен оператор COMMIT, то в журнале транзакций делается отметка о завершении текущей транзакции. Если же после оператора SQL следовал оператор ROLLBACK, то СУБД просматривает журнал транзакций и отыскивает записи, отражающие состояние измененных строк до модификации. Используя их, СУБД восстанавливает те строки в таблицах базы данных, которые были модифицированы текущей транзакцией - таким образом аннулируются все изменения в базе данных.

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

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

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

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

1. В процессе выполнения транзакции пользователь (или  программа) "видит" только согласованные  состояния базы данных. Пользователь (или программа) никогда не может  получить доступ к незафиксированным изменениям в данных, достигнутым в результате действий другого пользователя (программы).
2. Если две транзакции, A и B, выполняются параллельно, то СУБД полагает, что результат будет такой же, как если бы:

• транзакция A выполнялась первой, а за ней была выполнена транзакция B;
• транзакция B выполнялась первой, а за ней была выполнена транзакция A.

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

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

      В современных СУБД предусмотрен так  называемый протокол двухфазовой (или  двухфазной) фиксации транзакций (two-phase commit). Фаза 1 начинается, когда при  обработке транзакции встретился оператор COMMIT. Сервер распределенной БД (или компонент СУБД, отвечающий за обработку распределенных транзакций) направляет уведомление "подготовиться к фиксации" всем серверам локальных БД, выполняющим распределенную транзакцию. Если все серверы приготовились к фиксации (то есть откликнулись на уведомление и отклик был получен), сервер распределенной БД принимает решение о фиксации. Серверы локальных БД остаются в состоянии готовности и ожидают от него команды "зафиксировать". Если хотя бы один из серверов не откликнулся на уведомление в силу каких-либо причин, будь то аппаратная или программная ошибка, то сервер распределенной БД откатывает локальные транзакции на всех узлах, включая даже те, которые подготовились к фиксации и оповестили его об этом.

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

1.6 Средства  защиты данных  в СУБД

      Существенным аспектом современных СУБД является защита данных. В самом общем виде требования к безопасности реляционных СУБД формулируются так:

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

       Схема доступа к данным во всех реляционных  СУБД выглядит примерно одинаково и  базируется на трех принципах:  

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

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

      Привилегии  устанавливаются и отменяются специальными операторами языка SQL - GRANT (ПЕРЕДАТЬ) и REVOKE (ОТОБРАТЬ). Оператор GRANT указывает конкретного пользователя, который получает конкретные привилегии доступа к указанной таблице.

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

      Некоторые СУБД (Oracle, Sybase, InterBase) используют собственную систему паролей, в других (Ingres, Informix, MS SQL Server) применяется идентификатор пользователя и его пароль из операционной системы.

      Для облегчения процесса администрирования  большого количества пользователей  их объединяют в группы. Традиционно применяются два способа определения групп пользователей: 

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

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

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