Лекция 15.

Разработка многопользовательских баз данных

1. Многопользовательские базы данных.

2. Совместное использование данных предприятия.

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

1. Многопользовательские базы данных.

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

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

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

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

управление структурой базы данных

управление параллельной обработкой

распределение прав и обязанностей по обработке

обеспечение безопасности базы данных

восстановление базы данных

управление СУБД

поддержание репозитория данных.

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

Управление параллельной обработкой

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

В большинстве приложений баз данных работа пользователей организована в форме транзакций (transactions), известных также как логические единицы работы (logical units of work, LUW). Транзакция — это последовательность действий с базой данных, в которой либо все действия выполняются успешно, либо не выполняется ни одно из них (в последнем случае база данных остается без изменений). Такая транзакция иногда называется атомарной (atomic), поскольку она выполняется как единое целое.

При этом для начала выполнения транзакции программа должна дать команды на начало транзакции (Start Transaction), сохранение транзакции (Commit Transaction) и откат транзакции (Rollback Transaction). Конкретная форма этих команд различается в разных СУБД.

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

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

Терминология блокировки

Блокировки могут налагаться либо автоматически, по инициативе СУБД, либо командой, которая передается СУБД прикладной программой или запросом пользователя. Блокировки, налагаемые СУБД, называются неявными блокировками (implicit locks), а блокировки, налагаемые по команде, — явными блокировками (explicit locks). Некоторые СУБД предусматривают блокировку на уровне страницы, другие – на уровне таблицы, а третьи – на уровне базы данных. Размер блокируемого ресурса называется глубиной детализации блокировки (lock granularity). При большой глубине детализации СУБД легче справляется с администрированием блокировки, но такие блокировки часто являются причиной конфликтов. Блокировки с маленькой глубиной детализации сложно администрировать (СУБД приходится отслеживать и проверять гораздо больше деталей), но конфликты при этом менее часты.

Блокировки различаются также по типу. При монопольной блокировке (exclusive lock) блокируются все виды доступа к элементу. Ни одна другая транзакция не может читать или изменять данные. Коллективная блокировка (shared lock) блокирует элемент от изменения, но не от чтения. То есть другие транзакции могут свободно читать данный элемент, если они не пытаются изменить его.

Оптимистическая и пессимистическая блокировки

Блокировки могут налагаться двумя основными стилями. При оптимистической блокировке (optimistic locking) делается предположение, что конфликта не произойдет. Данные считываются, транзакция обрабатывается, производятся обновления, а после этого делается проверка, не возник ли конфликт. Если нет, транзакция завершается. Если да, транзакция повторяется до тех пор, пока не сможет успешно завершиться. При пессимистической блокировке (pessimistic locking) предполагается, что конфликт обязательно произойдет. Сначала налагаются блокировки, затем обрабатывается транзакция, а после этого блокировки снимаются.

В листинге 1 приведен пример каждого из стилей наложения блокировок для транзакции, которая уменьшает количество карандашей в таблице ПРОДУКТ на пять штук. При оптимистической блокировке сначала данные считываются, и текущее количество карандашей сохраняется в переменной СтароеКоличество. Затем обрабатывается транзакция и в предположении, что все прошло успешно, налагается блокировка на таблицу ПРОДУКТ. Эта блокировка может затрагивать только строку карандашей, но возможно, глубина детализации будет и большей. В любом случае, запускается SQL-оператор, обновляющий строку карандашей, с условием WHERE Количество = СтароеКоличество. Если никакая другая транзакция не изменила атрибут Количество в строке карандашей, тогда результат оператора UPDATE будет успешным. Если какая-то другая транзакция изменила значения атрибута Количество в строке карандашей, выполнение оператора UPDATE будет неудачным, и транзакцию придется повторить.

Листинг 1. Сравнение оптимистической и пессимистической блокировок

Оптимистическая блокировка:

SELECT ПРОДУКТ.Название, ПРОДУКТ.Количество

FROM ПРОДУКТ

WHERE ПРОДУКТ.Название='Карандаш'

СтароеКоличество = ПРОДУКТ.Количество

Set НовоеКоличество = ПРОДУКТ.Количество - 5

{обработка транзакции - если НовоеКоличество < 0. генерируется исключение и т. д. если все в порядке:}

LOCK ПРОДУКТ {с определенной глубиной детализации}

UPDATE ПРОДУКТ

SET ПРОДУКТ.Количество = НовоеКоличество

WHERE ПРОДУКТ.Название = 'Карандаш'

AND ПРОДУКТ.Количество = СтароеКоличество

UNLOCK ПРОДУКТ

{проверяем, было ли обновление успешным: если нет. повторяем транзакцию}

Пессимистическая блокировка:

LOCK ПРОДУКТ {с определенной глубиной детализации}

SELECT ПРОДУКТ.Название. ПРОДУКТ.Количество

FROM ПРОДУКТ

WHERE ПРОДУКТ.Название='Карандаш'

Set НовоеКоличество = ПРОДУКТ.Количество - 5

{обработка транзакции - если НовоеКоличество < 0. генерируется исключение и т. д. если все в порядке:}

UPDATE ПРОДУКТ

SET ПРОДУКТ.Количество = НовоеКоличество

WHERE ПРОДУКТ.Название = 'Карандаш'

UNLOCK ПРОДУКТ

{проверка на успешность обновления не требуется}

В случае пессимистической блокировки еще до начала работы на таблицу ПРОДУКТ налагается блокировка (с некоторой глубиной детализации). Затем считываются значения, обрабатывается транзакция, выполняется оператор UPDATE и таблица ПРОДУКТ разблокируется.

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

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

В листинге 2 показана транзакция с карандашами, в которой рамки транзакции указаны с помощью операторов BEGIN TRANSACTION, COMMIT TRANSACTION и ROLLBACK TRANSACTION. Рамки транзакции – это та информация, которая необходима СУБД, чтобы реализовывать различные стратегии блокировки. Если разработчик объявит теперь (через системный параметр или каким-либо другим способом), что ему нужна оптимистическая блокировка, СУБД неявным образом наложит блокировки, соответствующие этой стратегии, в правильном месте. Если после этого разработчик сменит тактику и запросит пессимистическую блокировку, СУБД неявно наложит свои блокировки в другом месте.

BEGIN TRANSACTION:

SELECT ПРОДУКТ.Название, ПРОДУКТ.Количество

FROM ПРОДУКТ

WHERE ПРОДУКТ.Название='Карандаш'

СтароеКоличество = ПРОДУКТ.Количество

Set НовоеКоличество = ПРОДУКТ.Количество - 5

{обработка части транзакции - если НовоеКоличество < 0. генерируется исключение, и т. д.}

LOCK. ПРОДУКТ {с определенной глубиной детализации)

UPDATE ПРОДУКТ

SET ПРОДУКТ.Количество = НовоеКоличество

WHERE ПРОДУКТ.Название = 'Карандаш'

{продолжение обработки транзакции}...