Московский государственный университет имени М.В.Ломоносова
Опубликован: 10.10.2005 | Доступ: свободный | Студентов: 7972 / 393 | Оценка: 3.85 / 3.50 | Длительность: 22:03:00
Лекция 8:

Средства языка SQL для обеспечения авторизации доступа к данным, управления транзакциями, сессиями и подключениями

Заключение

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

Как легко видеть, при распространении привилегий и ролей могут возникать произвольно сложные ориентированные графы связей между объектами базы данных, владельцами привилегий, привилегиями и ролями. Если изображать сплошными стрелками передачу привилегий, прерывистыми - передачу ролей, пунктирными - владение привилегиями, а точечными - владение ролями, то даже по отношению к одной привилегии pr для одного объекта o может появиться следующий граф связей ( userID означает authID , отличный от имени роли ), показанному на рис.18.8.

Простейший граф идентификаторов пользователя, имен ролей, объектов и привилегий

Рис. 18.9. Простейший граф идентификаторов пользователя, имен ролей, объектов и привилегий

Как мог появиться такой граф? Пользователь с authID , равным userID1 (это мы предположили для упрощения, а вообще-то это могло быть и именем роли ), создает объект o, становится его владельцем и тем самым обладателем привилегии pr по отношению к этому объекту. Пользователь userID1 предоставляет полномочие pr роли role1 (с правом передачи ). Затем пользователю userID1 предоставляется роль role1 (с правом передачи ), и он получает право исполнять эту роль. От имени роли role1 полномочие pr передается пользователю userID2 (с правом передачи ), и этот же пользователь получает право исполнять роль role1 (с правом передачи ). Пользователь userID2 передает роли role2 роль role1 и полномочие pr (с правом передачи ). Наконец, от имени роли role2 полномочие pr и сама роль role2 передаются пользователю userID1.

Попробуйте теперь проследить, как будет выполняться операция

REVOKE pr ON o FROM role1 CASCADED

Какие узлы и дуги останутся в графе? Задача не очень сложная, но, очевидно, нетривиальная. И такого рода задачи приходится ежедневно решать администраторам больших и динамических SQL-ориентированных баз данных.

Теперь немного поговорим об управлении транзакциями. В стандарте SQL:1999 ничего не говорится о возможной реализации различных уровней изоляции. Конечно, это правильно, поскольку спецификация языка не должна накладывать какие-либо ограничения на реализации. Но, к сожалению, при использовании SQL-ориентированной СУБД некоторые знания о реализации механизма транзакций необходимы. Например, предположим, что имеются две транзакции T1 и T2, выполняемые в режиме изоляции SERIALIZABLE . Предположим, что они должны работать по "симметричному" плану, показанному на рис.18.9.

Взаимные "фантомы"

Рис. 18.10. Взаимные "фантомы"

Транзакции работают в наивысшем режиме изолированности. Эффект их выполнения должен быть эквивалентен эффекту некоторого последовательного выполнения транзакций T1 и T2. Но попробуйте придумать какой-либо корректный способ одновременного выполнения этих транзакций, который привел бы к эффекту их последовательного выполнения. Другими словами, для грамотного использования механизма транзакций на уровне языка SQL необходимо знать, каким образом данный механизм реализован в используемой СУБД.

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

Александра Каева
Александра Каева
Антон Честиков
Антон Честиков

Не вижу список тем из плана занятий. Проблема известна?

Ольга Ястребова
Ольга Ястребова
Россия
Марат Гаялиев
Марат Гаялиев
Россия, Республика Татарстан