22.5. Заключение

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

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

Рис. 22.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. Предположим, что они должны работать по «симметричному» плану, показанному нарис. 22.9.

Рис. 22.10.Взаимные «фантомы»

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

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