Средства языка 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 необходимо знать, каким образом данный механизм реализован в используемой СУБД.

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