Лекция 19. Язык баз данных SQL: объектные расширения
Тесты
Заключение
В этой лекции были рассмотрены три темы, которые являются относительно независимыми, но относятся к средствам языка SQL, предназначенным для регулирования доступа пользователей к базам данных. На первый взгляд, материал этой лекции проще материала предыдущих лекций, посвященных языку SQL. Наверное, это действительно так, если говорить про чисто языковую сложность соответствующих операторов SQL. Но в действительности (которую мы старательно обходили в основных разделах лекции) дело обстоит гораздо сложнее.
Как легко видеть, при распространении привилегий и ролей могут возникать произвольно сложные ориентированные графы связей между объектами базы данных, владельцами привилегий, привилегиями и ролями. Если изображать сплошными стрелками передачу привилегий, прерывистыми – передачу ролей, пунктирными – владение привилегиями, а точечными – владение ролями, то даже по отношению к одной привилегии pr для одного объекта o может появиться следующий граф связей (userID означает authID, отличный от имени роли):
 |
Рис. 18.8. Простейший граф идентификаторов пользователя, имен ролей, объектов и привилегий
Как мог появиться такой граф? Пользователь с 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.9. Взаимные “фантомы”
Транзакции работают в наивысшем режиме изолированности. Эффект их выполнения должен быть эквивалентен эффекту некоторого последовательного выполнения транзакций T1 и T2. Но попробуйте придумать какой-либо корректный способ одновременного выполнения этих транзакций, который привел бы к эффекту их последовательного выполнения. Другими словами, для грамотного использования механизма транзакций на уровне языка SQL необходимо знать, каким образом этот механизм реализован в используемой СУБД.
И, конечно же, знания о реализации абсолютно необходимы при использовании механизма подключений и сессий. Слишком много в этой части стандарта отдается на волю реализации.
1 (1) Пусть роль R1 создается путем выполнения операции
CREATE ROLE R1
WITH ADMIN CURRENT_ROLE;
и текущим именем роли сессии, в которой выполняется эта операция, является R. При каких из указанных ниже условий будет успешно выполнена операция
GRANT R1 TO PUBLIC;?
(а) -
текущим именем роли сессии, в которой выполняется эта операция, является R
(б) +
операция выполняется в тот момент, когда идентификатором авторизации является R
(в) +
операция выполняется от имени идентификатора авторизации, которому была передана роль R с правом ее дальнейшей передачи
1 (2) Пусть в некоторой транзакции выполняются операции
CREATE ROLE R1
WITH ADMIN CURRENT_ROLE;
GRANT R1 TO AUDIT WITH ADMIN OPTION
GRANTED BY CURRENT_ROLE;
и текущим именем роли сессии, в которой выполняется эта операция, является R. При каких из указанных ниже условий будет успешно выполнена операция
DROP ROLE R1;?
(а) -
текущим именем роли сессии, в которой выполняется эта операция, является R
(б) -
операция выполняется в тот момент, когда идентификатором авторизации является R1
(в)
операция выполняется в тот момент, когда идентификатором авторизации является R
1 (3) Пусть в некоторой транзакции выполняются операции
CREATE ROLE R1
WITH ADMIN CURRENT_ROLE;
GRANT R1 TO R2 WITH ADMIN OPTION
GRANTED BY CURRENT_ROLE;
где R2 – имя некоторой существующей роли, и текущим именем роли сессии, в которой выполняется эта операция, является R. Пусть затем в некоторой другой транзакции, текущим именем роль которой является R2, выполняется операция
GRANT R1 TO R3 WITH ADMIN OPTION
GRANTED BY CURRENT_ROLE;
где R2 – имя некоторой существующей роли. При каких из перечисленных ниже условий будет успешно выполнена операция
REVOKE R1 FROM R3;
(а) -
именем текущей роли является R
(б) -
именем текущей роли является R2
(в) +
операция выполняется от имени authID, являющимся именем роли R или R2
2 (1) Пусть пользователь с текущим идентификатором пользователя userID1 от имени authID1, равного текущему имени роли role1, создает объект o, становится его владельцем и, тем самым, обладателем привилегии pr по отношению к этому объекту. Далее, от имени этого authID1 привилегия pr передается идентификатору пользователя userID1. Потом authID1 изменяется на userID1, и от его имени право на исполнение роли role1 передается роли с именем role2, являющемуся authID2 в некоторой сессии, текущим идентификатором пользователя которой является userID2. Наконец, от имени того же authID2 привилегия pr передается userID2. Что теперь произойдет, если от имени authID1 будет задана операция
REVOKE PR ON o FROM userID2 CASCADE;?
(а) -
userID2 лишится привилегии pr, но она останется у role1, role2 и userID1
(б) +
операция будет отвергнута
(в) -
привилегия pr сохранится только у role1
2 (2) Пусть пользователь с текущим именем роли role1 от имени authID, равного текущему идентификатору пользователя userID, создает объект o, становится его владельцем и, тем самым, обладателем привилегии pr по отношению к этому объекту. Далее, от имени этого authID привилегия pr передается роли role1, а сама роль – роли role2. После этого роль role2 передается userID. Какая из перечисленных ситуаций сложется после выполнения операции
REVOKE PR ON o FROM role1 CASCADE;?
(а) -
привилегия pr аннулируется у role1, role2 и userID
(б) +
привилегия pr аннулируется у role1 и role2
(в) -
привилегия pr аннулируется у role1 и role2, role2 лишится права исполнять role1, а userID лишится права исполнять роль role2
2 (3) Пусть пользователь с текущим именем роли role от имени authID1, равного текущему идентификатору пользователя userID1, создает объект o, становится его владельцем и, тем самым, обладателем привилегии pr по отношению к этому объекту. Далее, от имени этого authID1 привилегия pr передается роли role, а сама роль – текущему идентификатору пользователя userID2. После этого от имени роли role привилегия pr передается userID2. Какая из перечисленных ситуаций сложется после выполнения операции
REVOKE role FROM userID2 CASCADE;?
(а) -
у userID2 не будет ни привилегии pr, ни роли role
(б) +
у userID2 останется привилегия pr, но не будет роли role
(в) –
привилегия pr аннулируется у userID2 и role
3 (1) При каких уровнях изоляции транзакции в ней не допускается чтениt объекта базы данных, изменявшегося еще не завершенной транзакцией?
(а) -
READ COMMITTED
(б) -
REPEATABLE READ
(в) +
READ COMMITTED, REPEATABLE READ и SERIALIZABLE
3 (2) Пусть транзакция T выполняется на уровне изоляции REPEATABLE READ. После выполнения какого из перечисленных ниже операторов выборки в транзакции T может проявиться эффект фантомов?
(а) -
SELECT * FROM EMP WHERE EMP_NO = 4441;
и результат операции не пуст
(б) +
SELECT * FROM EMP WHERE EMP_NO = 4441;
и результат операции пуст
(в) -
SELECT * FROM EMP WHERE EMP_NO = 4441 OR DEPT_NO = 632;
3 (3) Пусть имеются некоторая таблица R и некоторое условие c, накладываемое на ее строки. Обозначим через ST(c), IT(c), UT(c) и DT(c) операции выборки строк из таблицы R по условию c; вставки строк в таблицу R, удовлетворяющих условию c; модификации и удаления строк из таблицы R по условию c соответственно, выполняемые транзакцией T. Пусть теперь одновременно выполняются три транзакции: T1 = (IT1(c), ST1(c), DT1(c), COMMITT1), T2 = (ST2(c), UT2(c), ST2(c), COMMITT2), T1 = (ST3(c), COMMITT3). Какие из указанных ниже реальных последовательностей выполнения операций соответствуют уровню изоляции SERIALIZABLE?
(а) +
ST3(c), ST2(c), COMMITT3, UT2(c), ST2(c), COMMITT2, IT1(c), ST1(c), DT1(c), COMMITT1
(б) +
IT1(c), ST1(c), DT1(c), COMMITT1, ST2(c), ST3(c), COMMITT3, UT2(c), ST2(c), COMMITT2
(в) -
IT1(c), ST1(c), ST3(c), ST2(c), COMMITT3, UT2(c), ST2(c), COMMITT2, DT1(c), COMMITT1
Пусть имеются некоторая таблица R и некоторое условие c, накладываемое на ее строки. Обозначим через ST(c), IT(c), UT(c), DT(c), SPT(spn) и RBT(spn) операции выборки строк из таблицы R по условию c; вставки строк в таблицу R, удовлетворяющих условию c; модификации и удаления строк из таблицы R по условию c; установки точки сохранения и отката до точки сохранения с именем spn соответственно, выполняемые транзакцией T.
4 (1) Пусть одновременно выполняются три транзакции: T1 = (ST1(c), SPT1(spn1), IT1(c), DT1(c), ST1(c), RBT1(spn1), COMMITT1), T2 = (ST2(c), SPT2(spn2), UT2(c), ST2(c), RBT2(spn2), COMMITT2), T1 = (ST3(c), COMMITT3). Какие из указанных ниже реальных последовательностей выполнения операций соответствуют уровню изоляции SERIALIZABLE?
(а) +
ST1(c), ST2(c), ST3(c), SPT1(spn1), IT1(c), DT1(c), ST1(c), RBT1(spn1), SPT2(spn2), UT2(c), ST2(c), RBT2(spn2), COMMITT1, COMMITT2, COMMITT3
(б) -
ST3(c), COMMITT3, SPT1(spn1), IT1(c), DT1(c), ST2(c), SPT2(spn2), UT2(c), ST1(c), RBT1(spn1), COMMITT1, ST2(c), RBT2(spn2), COMMITT2
(в) +
ST1(c), SPT1(spn1), IT1(c), DT1(c), ST1(c), RBT1(spn1), ST2(c), SPT2(spn2), UT2(c), ST2(c), RBT2(spn2), ST3(c), COMMITT3, COMMITT1, COMMITT2
4 (2) Пусть одновременно выполняются три транзакции: T1 = (ST1(c), SPT1(spn1), IT1(c), RBT1(spn1), DT1(c), ST1(c), RBT1(spn1), DT1(c), COMMITT1), T2 = (ST2(c), SPT2(spn2), UT2(c), ST2(c), RBT2(spn2), ST2(c), COMMITT2), T1 = (ST3(c), SPT3(spn3), UT3(c), RBT3(spn3), COMMITT3). Какие из указанных ниже реальных последовательностей выполнения операций соответствуют уровню изоляции SERIALIZABLE?
(а) +
ST1(c), SPT1(spn1), IT1(c), RBT1(spn1), ST2(c), SPT2(spn2), UT2(c), ST2(c), RBT2(spn2), ST3(c), SPT3(spn3), UT3(c), RBT3(spn3), DT1(c), ST1(c), RBT1(spn1), ST2(c), COMMITT2, DT1(c), COMMITT1, COMMITT3
(б) -
ST1(c), SPT1(spn1), IT1(c), ST2(c), SPT2(spn2), UT2(c), ST2(c), RBT2(spn2), RBT1(spn1), DT1(c), ST1(c), RBT1(spn1), DT1(c), COMMITT1, ST3(c), SPT3(spn3), UT3(c), RBT3(spn3), COMMITT3, ST2(c), COMMITT2
(в) +
ST1(c), SPT1(spn1), ST2(c), SPT2(spn2), ST3(c), SPT3(spn3), IT1(c), RBT1(spn1), UT2(c), ST2(c), RBT2(spn2), UT3(c), RBT3(spn3), DT1(c), ST1(c), RBT1(spn1), ST2(c), COMMITT2, COMMITT3, DT1(c), COMMITT1
4 (3) Пусть одновременно выполняются три транзакции: T1 = (ST1(c), SPT1(spn1), IT1(c), SPT1(spn2), DT1(c), ST1(c), RBT1(spn2), ST1(c), RBT1(spn1), DT1(c), COMMITT1), T2 = (ST2(c), UT2(c), SPT2(spn2), DT2(c), ST2(c), RBT2(spn2), ST2(c), COMMITT2), T3 = (ST3(c), SPT3(spn3), UT3(c), RBT3(spn3), DT3(c), COMMITT3). Какие из указанных ниже реальных последовательностей выполнения операций соответствуют уровню изоляции SERIALIZABLE?
(а) +
ST1(c), SPT1(spn1), IT1(c), SPT1(spn2), DT1(c), ST1(c), RBT1(spn2), ST1(c), RBT1(spn1), ST2(c), UT2(c), SPT2(spn2), DT2(c), ST2(c), RBT2(spn2), ST3(c), SPT3(spn3), UT3(c), RBT3(spn3), ST2(c), COMMITT2, DT3(c), COMMITT3, DT1(c), COMMITT1
(б) +
ST1(c), ST2(c), ST3(c), SPT3(spn3), SPT1(spn1), UT2(c), SPT2(spn2), DT2(c), ST2(c), RBT2(spn2), IT1(c), SPT1(spn2), DT1(c), ST1(c), RBT1(spn2), ST1(c), RBT1(spn1), UT3(c), RBT3(spn3), DT3(c), COMMITT3, DT1(c), COMMITT1, ST2(c), COMMITT2
(в) -
ST1(c), SPT1(spn1), IT1(c), SPT1(spn2), DT1(c), ST1(c), RBT1(spn2), ST2(c), UT2(c), SPT2(spn2), DT2(c), ST2(c), RBT2(spn2), ST3(c), SPT3(spn3), UT3(c), RBT3(spn3), ST1(c), RBT1(spn1), DT1(c), COMMITT1, ST2(c), COMMITT2, DT3(c), COMMITT3
В последней лекции этого курса мы кратко изложим существо объектных расширений, которые включены в стандарт SQL:1999. В этом изложении мы основываемся не на официальном тексте стандарта (он очень формален и скучен), а на книге Джима Мелтона Advanced SQL:1999. Understanding Object-Relational and Other Advanced Features (Morgan Kaufmann Publishers, 2003), которая, по сути, является неформальным описанием семантики (rationale) соответствующей части языка. В указанной книге объектным расширениям языка SQL посвящено более 200 страниц. Естественно, наше изложение будет гораздо более кратким.