3. Распределенные
СУБД
В теоретическом
плане распределенные СУБД составляют
еще одно измерение в пространстве исследований
и разработок систем управления базами
данных. В этих системах приходится решать
все задачи, свойственные централизованным
СУБД, но, как правило, в более сложных
постановках. Кроме того, в распределенных
системах возникают и специфические проблемы,
от решения которых во многом зависит
эффективность, надежность и доступность
систем БД. В настоящее время большинство
распределенных СУБД базируется на реляционной
модели данных и рассчитано на использование
в локальных сетях ЭВМ. Многие проблемы
распространяются и на распределенные
СУБД в территориально разнесенных сетях,
и почти все проблемы сохраняются для
распределенных СУБД, основанных на других
моделях данных.
3.1. Синхронизация
доступа к данным
В централизованных
системах БД очень распространено
использование двухфазного протокола
синхронизационных захватов объектов
БД. В соответствии с этим протоколом
объект БД автоматически захватывается
транзакцией в соответствующем
режиме при первом обращении, и все
захваты данной транзакции освобождаются
только при ее завершении. В случае возникновения
конфликта по синхронизации транзакция
блокируется, пока объект не будет освобожден.
Следование этому протоколу может привести
к возникновению синхронизационного тупика
между двумя или более транзакциями. Задача
СУБД - распознать появление тупика и разрушить
его путем отката одной или нескольких
транзакций.
Распознавание
тупиков сводится к обнаружению
циклов в графе ожидания транзакций,
что является трудоемкой задачей
даже в централизованных СУБД. В распределенных
системах решение этой задачи может потребовать
неприемлемых накладных расходов (хотя
поиски алгоритмов с допустимыми затратами
продолжаются).
Поэтому более
часто в распределенных системах
применяются протоколы синхронизации,
основанные на временных метках. Это направление
само по себе очень широко, имеются разные
варианты и даже комбинации с протоколом
двухфазных захватов, но основной проблемой
реализации является отсутствие в распределенной
системе единого времени.
3.2. Управление
транзакциями
В истинно
распределенной СУБД транзакции
естественно утрачивают линейную
структуру. Распределенная транзакция
в общем случае представляет
собой дерево, промежуточными узлами
которого являются распределенные
подтранзакции, а листья соответствуют
обычным линейным транзакциям локальных
СУБД.
Основной
проблемой управления транзакциями
в этом случае является корректное
завершение (фиксация) распределенной
транзакции. Классическим решением
является использование давно известного
протокола двухфазной фиксации. Однако
прямое использование этого протокола
порождает значительное число служебных
сообщений между составляющими распределенную
систему локальными СУБД. Большое число
исследований посвящено поискам более
экономичных протоколов.
3.3. Поддержание
копий данных в нескольких
узлах сети
Основным
накладным расходом при выполнении
распределенного запроса является
пересылка данных между узлами
сети. Одним из способов сокращения
этого накладного расхода является
поддержание копий наиболее часто используемых
данных в нескольких узлах сети с учетом
порождаемых этим дополнительных накладных
расходов по поддержанию согласованности
копий при модификации данных.
Другим основанием
для поддержания копий является
увеличение уровня доступности данных
при выходе из строя узлов сети или коммуникационных
линий, вследствие чего утрачивается связность
сети. Теоретически доступ к некоторому
объекту БД может продолжаться в любом
разделе сети, содержащем его копию. Однако
приходится решать ту же проблему согласования
копий при изменениях объекта данных.
Существует масса подходов к решению этой
проблемы от полного разрешения любого
доступа к любой копии объекта во всех
разделах сети с проведением сложной процедуры
согласования копий после восстановления
связности сети до разрешения модификации
объекта только в одном разделе. Для обнаружения
этого раздела обычно применяются различные
варианты алгоритма голосования.
3.4. Фрагментация
объектов БД
Альтернативный
подход, обеспечивающий максимальное
распараллеливание выполнения запроса
к БД, состоит в том, что отношение (если
говорить в терминах реляционной модели
данных) разбивается на ряд вертикальных
или горизонтальных фрагментов, и эти
фрагменты хранятся в разных узлах сети.
Понятно, что
теоретически это может обеспечить убыстрение
выполнения запроса, затрагивающего фрагментированное
отношение, но практически добиться этого
очень трудно. Основная проблема состоит
в резком расширении пространства поиска
вариантов выполнения запросов, с которым
должен работать оптимизатор запросов.
Имеются предложения
и исследования, связанные с комбинацией
поддержания копий и фрагментацией
объектов БД. В этом случае
поддерживаются копии фрагментов,
что, вообще говоря, решает обе
задачи, но еще больше усложняет
реализацию.
3.5. Алгоритмы
выполнения реляционных операций
Даже если
говорить только про реляционные
распределенные СУБД, которые наиболее
развиты в теоретическом и
практическом отношении, до сих
пор проводится масса исследований
в области оптимизации алгоритмов
выполнения реляционных операций (главным
образом, соединения удаленных отношений).
Таким образом,
даже рассмотрев только небольшую
часть проблем распределенных
систем, можно убедиться, что они
нуждаются в большом количестве
исследований и экспериментов. Начавшийся
в России переход к использованию локальных
сетей дает практическую возможность
проведения таких работ.
4. Системы БД
с многоуровневой защитой
Большинство
реально используемых современных
СУБД основано на реляционной
модели данных и языке баз данных SQL. Существенной
особенностью языка SQL, появившейся в нем
с самого начала, является обеспечение
защиты доступа к данным средствами самого
языка. Основная идея такого подхода состоит
в том, что по отношению к любому отношению
БД и любому столбцу отношения вводится
предопределенный набор привилегий. С
каждой транзакцией неявно связывается
идентификатор пользователя, от имени
которого она выполняется (способы связи
и идентификации пользователей не фиксируются
в языке и определяются в реализации).
После создания
нового отношения все привилегии,
связанные с этим отношением
и всеми его столбцами, принадлежат
только пользователю-создателю отношения.
В число привилегий входит
привилегия передачи всех или
части привилегий другому пользователю,
включая привилегию на передачу привилегий.
Технически передача привилегий осуществляется
при выполнении оператора SQL GRANT. Существует
также привилегия изъятия всех или части
привилегий у пользователя, которому они
ранее были переданы. Эта привилегия также
может передаваться. Технически изъятие
привилегий происходит при выполнении
оператора SQL REVOKE. Проверка полномочности
доступа к данным происходит на основе
информации о полномочиях, существующих
во время компиляции соответствующего
оператора SQL.
Долгое время
подход к защите данных от
несанкционированного доступа принимался
практически без критики, однако
в связи с распространяющимся
использованием реляционных СУБД
в нетрадиционных приложениях
все чаще раздается критика.
Если, например, в системе БД должна
поддерживаться многоуровневая защита
данных, соответствующую систему полномочий
весьма трудно, а иногда и невозможно построить
на основе средств SQL.
Вопросам
организации систем БД с развитыми
механизмами защиты в последнее
время уделяется очень большое
внимание. Можно выделить два
основных подхода. Первый подход
состоит в связывании с каждым
защищаемым объектом БД набора
допустимых привилегий и связывании
с каждым пользователем некоторого набора
прав доступа. Как таковая, эта техника
известна еще со времени первых ОС разделения
времени, но при ее применении в области
БД требуются дополнительный анализ, уточнения
и дополнения. Второй подход к защите данных
основан на использовании методов криптографии.
На самом деле упрощенные криптографические
методы тоже использовались и используются
в ОС для проверки прав доступа пользователя
(в частности, для кодирования паролей
пользователей). Развитые же методы кодирования
в основном применялись в информационных
системах специального назначения. Теперь
же кодирование с открытыми ключами все
чаще применяется в системах общего назначения.