Курсовая работа: Инфологическая модель базы данных "Защита доступа"
в качестве сервера базы данных используется гораздо более мощный компьютер
СУБД, используемая в качестве сервера базы данных, обладает более совершенными средствами обработки данных
Так как обработка запросов осуществляется на сервере базы данных, а не на рабочей станции, рабочая станция называется клиентом сервера базы данных. При работе в режиме клиент-сервер серверная часть системы управления базами данных устанавливается на файл-сервере, а клиентская часть — на рабочей станции. В ряде случаев клиентская и серверная части являются отдельными компонентами одной СУБД (например, Oracle или SQLbase). В других случаях в качестве клиентской части используются настольные СУБД или специальные системы разработки приложений клиент/сервер (например, PowerBuilderили SQLWindows), а в качестве сервера базы данных — мощная СУБД типа Oracle или SQL Server.
Основная задача, которая должна быть надежно решена при разработке многопользовательского приложения – это управление возможными столкновениями пользователей при одновременной модификации одних и тех же данных. Эта проблема должна быть решена на двух уровнях:
первый – это сведение количества таких конфликтов к минимуму и
второй – разработка четкого алгоритма их разрешения.
Таблица 1
| Низкая конкуренция (случай 1) | Высокая конкуренция (случай 2) |
| Блокировка записи | Запись данных в переменные |
| Чтение записи | Чтение переменных |
| Полноэкранное редактирование | |
| Запрос на сохранение данных | |
| Сохранение данных | Блокировка записи |
| -- | Запись данных из переменных в БД |
| Снятие блокировки с записи | |
В таблице 1 приведены два возможных алгоритма модификации данных в многопользовательских системах с низким и высоким уровнями конкуренции пользователей при попытке доступа к одним и тем же данным. В первом случае мы получаем несомненно более стабильную систему за счет захвата нужной записи и тем самым полного устранения возможности одновременной модификации одних и тех же данных. В то же время захваченные данные могут оставаться недоступными долгое время в случае, если пользователь вдруг заметил какую-то ошибку и надолго застрял в поисках путей ее исправления или просто решил отдохнуть в момент подноэкранного редактирования. Для избежания подобных ситуаций можно поставить ограничение на время редактирования, но тогда данные могут вдруг изчезнуть с экрана прямо на глазах изумленного зазевавшегося пользователя.
При втором варианте продожительность блокировки не зависит от поведения пользователя. Это время будет определяться только продолжительностью записи данных. Во время редактирования данные продолжают оставаться доступными для других пользователей. Хорошо ли это? Отлично, мы достигли потрясающей гибкости! Но в то же время получили массу забот, так как во время редактирования данных одним пользователем их может изменить и другой. При таком подходе есть риск, что после того, как первый пользователь успешно модифицирует запись, ее тут же освежит и второй работник, который в глаза не видел обновленных первым абонентом сети данных. Ведь у него на экране были данные из БД до их изменения первым пользователем.
Для решения этих проблем в СУБД предлагается использовать буферизацию данных . Рассмотрим типичный набор блокировок:
отсутствие буферизации.
пессимистическая буферизация записи;
оптимистическая буферизация записи;
пессимистическая буферизация таблицы;
оптимистическая буферизация таблицы.
Буферизация на уровне записи означает, что перед началом редактирования содержимое текущей записи будет сохранено во внутреннем буфере СУБД. Буферизация нв уровне таблицы сохраняет в буфере содержание всех отобранных для редактирования записей. Оптимистическая буферизация обеспечивает блокировку записей только на время сохранения содержимого буфера в файле, что соответствует приведенному выше случаю 2. Пессимистическая буферизация работает как в случае 1, то есть блокирует запись перед копированием ее содержимого в буфер.
Использование буферизации позволяет автоматизировать процесс переноса данных из полей БД в переменные и обратно. При этом группа функций позволяет получить исчерпывающую информацию о состоянии буферизованной таблицы, что дает возможность организовать очень эффективный алгоритм разрешения возможных конфликтов при изменении данных (схема их взаимодействия приведена на рисунке 1).
Рис.1 Функции для работы с буферизованной таблицей
OLDVAL() – возвращает первоначальное значение поля, которое было модифицировано, но не обновлялось.
CURVAL() – возвращает значение поля непосредственно с диска или из удаженного источника.
TABLEUPDATE() – фиксирует изменения, внесенные в буферизованную запись либо в буферизованную таблицу или курсор.
TABLEREVERT() – сбрасывает изменения, внесенные в буферизованную запись либо в буферизованную таблицу или курсор и восстанавливает содержимое по данным OLDVAL().
При буферизации таблицы мы имеем возможность добавлять и удалять записи в буфере. При добавлении новая запись помещается в конец буфера и получает номер с отрицательным значением. Доступ к этой записи может быть выполнен с помощью функции RECNO() с отрицательным параметром, например –1.
RECNO() - возвращает номер текущей записи в текущей или заданной таблице
При написании многопользовательских приложений необходимо учитывать, что целый ряд команд при их использовании выполняет автоматическую блокировку.
Если вы решили управлять блокировкой вручную, то придерживайтесь следующего алгоритма:
проверьте состояние блокировки записи или таблицы;
если блокировки нет, то требуемые ресурсы можно заблокировать;
если ресурсы блокированы, попробуйте еще раз, но при этом следует избегать слишком частых попыток. Кроме чрезмерной загрузки сети это ни к чему не приведет.