Кириллов В.В., Громов Г.Ю. - Введение в реляционные базы данных. Литература для вузов isbn 9785941577705 в книге рассматриваются основные понятия баз данных и систем управления ими
 Скачать 11.62 Mb.
|
|
Глава 7. Организация доступа к базе данных Глава 8. Внесение изменений в базу данных Глава 9. Транзакции и параллелизм Глава 7 Организация доступа к базе данных 7.1. О системе баз данных В главе 1 рассматривалась концепция баз данных и архитектура СУБД. Эти сведения позволяют определить систему баз данных как компьютеризи- рованную систему, основное назначение которой — хранение информации и предоставление пользователям средств для ее извлечения и модификации. Система баз данных состоит из четырех главных компонентов: данные, аппа- ратное обеспечение, программное обеспечение и пользователи. 7.1.1. Данные Системы баз данных устанавливают как на персональные компьютеры (как правило, однопользовательские системы), так и на большие вычислительные машины (многопользовательские системы). В однопользовательских системах к базе данных может получить доступ одновременно только один пользова- тель, а в многопользовательских — сразу несколько пользователей. С точки зрения пользователей между этими системами фактически не существует большого различия, поскольку основная цель многопользовательских систем состоит в том, чтобы позволить каждому отдельному пользователю работать с ней так, как если бы он работал с однопользовательской системой. Разли- чия между этими двумя видами систем проявляются в их внутренней струк- туре и поэтому не видны конечному пользователю. В общем случае данные в базе данных являются интегрированными и разде- ляемыми. Под интеграцией данных подразумевается возможность предста- вить базу данных как объединение нескольких отдельных файлов данных, полностью или частично исключающее избыточность хранения информа- ции. Разделяемость данных — это возможность использования несколькими Часть III. Язык SQL. Изменение данных 160 различными пользователями отдельных элементов, хранимых в базе данных: каждый пользователь может получить доступ к одним и тем же данным, воз- можно, даже одновременно (параллельный доступ). Такое разделение дан- ных, с параллельным или последовательным доступом, частично является следствием того, что база данных имеет интегрированную структуру. Одним из следствий интеграции и разделяемости является то, что каждый кон- кретный пользователь обычно имеет дело лишь с небольшой частью всей базы данных, причем обрабатываемые различными пользователями части могут произвольным образом перекрываться. Иначе говоря, каждая база данных вос- принимается различными пользователями по-разному. Фактически, даже те два пользователя базы данных, которые работают с одними и теми же частями ба- зы данных, могут иметь значительно отличающиеся представления о них. 7.1.2. Аппаратное обеспечение Аппаратной части системы в данной книге уделяется мало внимания, так как проблемы, присущие этой области, не являются специфическими для систем баз данных и достаточно подробно освещены в литературе. 7.1.3. Программное обеспечение Между данными, которые реально хранятся на компьютере, и пользователями системы располагается СУБД. Все запросы пользователей на получение досту- па к базе данных обрабатываются СУБД. Все имеющиеся средства добавления файлов (или таблиц), выборки и обновления данных в этих файлах или табли- цах также предоставляет СУБД. Основная задача СУБД — дать пользователю базы данных возможность работать с ней, не вникая во все подробности рабо- ты на уровне аппаратного обеспечения. Следовательно, СУБД позволяет ко- нечному пользователю рассматривать базу данных как объект более высокого уровня по сравнению с аппаратным обеспечением, а также предоставляет в его распоряжение набор операций на языке высокого уровня (SQL). 7.1.4. Пользователи Пользователей можно разделить на три большие и отчасти перекрывающиеся группы (см. рис. 1.2). Прикладные программисты, создающие на каком-либо языке программи- рования (C++, Java, PHP или специализированном языке конкретной СУБД, например, PL/SQL) пакетные или интерактивные приложения, Глава 7. Организация доступа к базе данных 161 предназначенные для работы конечных пользователей. Они предоставля- ют пользователям непосредственный оперативный доступ к базе данных через рабочую станцию, терминал или персональный компьютер. Боль- шинство современных приложений относится именно к этой категории. Конечные пользователи, получающие доступ к базе данных с помощью одного из интерактивных приложений или же интерфейса, интегрирован- ного в программное обеспечение самой СУБД. Например, в составе СУБД Oracle существует встроенное приложение SQL*Plus, обеспечивающее интерактивное выполнение операторов языка SQL для определения дан- ных, манипулирования данными и определения правил доступа к СУБД Oracle. Оно может использоваться и как инструмент для создания отчетов. Существуют также различные бесплатные (например, Oracle SQL Developer) и покупные (например, PL/SQL Developer или TOAD) пакеты, предназна- ченные для повышения скорости разработки баз данных и приложений, а также упрощения ежедневных задач администрирования. Администраторы баз данных, работа которых заключается в создании самих баз данных и организации технического контроля, необходимого для обеспечения решений, принятых при проектировании базы данных. Они (он) несут также ответственность за обеспечение необходимого бы- стродействия системы, ее техническое обслуживание и защиту данных. 7.2. Защита данных После создания базы данных, загрузки данными и ввода в эксплуатацию, не- обходимо подключить к ней пользователей и принять меры к защите храни- мых данных от несанкционированного доступа, изменения или разрушения. В самом общем виде требования к безопасности формулируются так: данные в любой таблице должны быть доступны не всем пользователям, а лишь некоторым из них; некоторым пользователям разрешено обновлять данные в таблицах, в то время как другие допускаются лишь к выборке данных из этих же таблиц; для некоторых таблиц необходимо обеспечить выборочный доступ к ряду ее столбцов; некоторым пользователям должен быть запрещен непосредственный (че- рез запросы) доступ к таблицам, но разрешен доступ к этим же таблицам в диалоге с прикладной программой. Часть III. Язык SQL. Изменение данных 162 Для обеспечения этих требований необходимо, чтобы каждый из пользовате- лей был известен СУБД и ему были предоставлены определенные права на доступ к тем или иным объектам базы данных. Обычно лиц, которым необходимо дать доступ к базе данных или которые желают получить такой доступ (и имеют на это право), включают в состав пользователей, давая им имя (идентификатор) и пароль. При этом админист- ратор базы данных сначала предоставляет каждому пользователю минималь- ный набор привилегий, расширяя затем этот набор для тех или иных пользо- вателей по мере необходимости. Так для студентов, с которыми работают авторы, создана база данных "UCHEB" (см. часть VI). В этой базе данных пользователями являются все студенты и преподаватели университета. Их имена практически совпадают с их идентификаторами ( ИД ) в таблице Н_ЛЮДИ (см. разд. 5.4). Эти имена и па- роли выдаются студентам при поступлении и используются ими в процессе обучения как для работы с Корпоративным порталом университета (http://cis.ifmo.ru), так и для работы с базой данных во время занятий и раз- личных видов внеурочной деятельности. Студентам предоставляется воз- можность соединяться с базой данных "UCHEB", делать разнообразные за- просы на получение данных из ее таблиц, создавать собственные базы данных (в пределах выделенных квот) и т. п. Привилегии в СУБД могут быть разделены на две категории. Системные привилегии позволяют пользователям выполнять определен- ное действие на уровне системы или над конкретным типом объектов. К системным привилегиям можно отнести, например, привилегию на соз- дание таблиц ( CREATE TABLE ) или привилегию на удаление строки из лю- бой таблицы в базе данных ( DELETE ANY TABLE ). Большинство системных привилегий должны быть доступны только администраторам и разработ- чикам приложений. Бесконтрольная их выдача может создать реальную угрозу как функционированию системы, так и потери данных. Объектные привилегии позволяют пользователям выполнять определен- ные действия с конкретным объектом. К объектным привилегиям, на- пример, относятся привилегии на удаление строки в определенной таблице или запуск определенной процедуры. Объектные привилегии назначаются конечным пользователям для того, чтобы они могли работать с приложе- ниями к базе данных для решения конкретных задач. Наряду с привилегиями, ограничивающими доступ к таблицам, ключевую роль в защите данных играют также представления (см. разд. 4.2). Создавая представление и давая пользователю разрешение на доступ к нему, а не к ис- ходной таблице, можно тем самым ограничить доступ пользователя к опре- Глава 7. Организация доступа к базе данных 163 деленным столбцам и строкам. Таким образом, представления позволяют осуществить четкий контроль над тем, какие данные доступны тому или иному пользователю. Наконец, возможна и более изощренная (но редко используемая) форма за- щиты — шифрование данных, т. е. хранение и передача особо важных дан- ных в зашифрованном виде. 7.3. Средства языка SQL В действующем стандарте языка SQL поддерживаются как механизм автори- зации доступа (задания привилегий), так и механизм представлений. Шифро- вание данных в стандарте отсутствует и поддерживается (при необходимости) специальными приложениями. В СУБД Oracle есть механизм шифрования данных (см. разд. 13.3.1). 7.3.1. Предложение GRANT Это предложение назначает пользователям и ролям (см. далее) привилегии, которые позволяют им обращаться к объектам базы данных и использовать их (т. е. объектные привилегии). Синтаксис предложения GRANT в стандарте SQL:2003 имеет вид: GRANT { {объектная_привилегия [,...]| роль [,...]} } [ON имя_объекта_базы] [TO получающий_привилегию [,...] ]; Рассмотрим ключевые слова. Объектная_ привилегия В этом предложении можно присвоить одну или несколько привилегий, раз- деляя их запятыми (нельзя лишь объединять ALL PRIVILEGES с другими при- вилегиями). Существуют следующие стандартные привилегии: ALL PRIVILEGES — краткое обозначение всех привилегий, которое не ре- комендуется использовать, поскольку это способствует неаккуратному на- значению прав доступа; EXECUTE — предоставляется право запускать хранимую процедуру, поль- зовательскую функцию или пакет (см. главу 18); { SELECT | INSERT | UPDATE | DELETE } — предоставляется право вы- полнять соответствующие операции применительно к указанному объекту базы данных (таблице, представлению и пр.); Часть III. Язык SQL. Изменение данных 164 REFERENCES — предоставляется право определять ограничения, обеспечи- вающие ссылочную целостность. Ограничимся пока этими объектными привилегиями. Роль Роль — это именованный набор привилегий, которые можно присваивать пользователям и другим ролям базы данных. Если роль назначается пользо- вателю, этот пользователь получает все привилегии и допуски, содержащие- ся в данной роли. Роли повсеместно используются как один из лучших спо- собов обеспечения безопасности и управления привилегиями в базе данных. Роль должна быть заранее создана с помощью предложения CREATE ROLE (см. далее). ON имя_объекта_базы Привилегии присваиваются для доступа к конкретному существующему объ- екту базы данных ( имя_объекта_базы ). К объектам базы данных относятся: таблицы, представления, последовательности, хранимые процедуры и т. д. TO получатель_привилегии Привилегия присваивается указанному в получатель_привилегии пользовате- лю или роли. Можно присваивать привилегии нескольким пользователям и (или) ролям, для чего их разделяют запятыми. В качестве альтернативы можно присвоить привилегии с ключевым словом PUBLIC , это означает, что все пользователи (в том числе и те, которые появятся в будущем) будут иметь указанные привилегии. В Oracle существует значительно больше, чем в стандарте, объектных приви- легий и ключевых слов. С ними можно познакомиться в разд. 4.4.5. Например, пусть нами был создан новый пользователь Повар , которому мы хотим назначить привилегию на выборку данных из таблицы Меню пользова- теля COOK GRANT SELECT ON COOK.МЕНЮ TO Повар; Создадим роль Пансион и предоставим ей несколько привилегий: CREATE ROLE Пансион; GRANT SELECT ON COOK.РЕЦЕПТЫ TO Пансион; GRANT SELECT ON COOK.ТРАПЕЗЫ TO Пансион; GRANT SELECT ON COOK.ВИДЫ_БЛЮД TO Пансион; GRANT SELECT ON COOK.БЛЮДА TO Пансион; Назначим роль Пансион пользователю Повар : GRANT Пансион TO Повар; Глава 7. Организация доступа к базе данных 165 7.3.2. Предложение REVOKE Предложение REVOKE служит для отмены назначенных привилегий и ролей и имеет синтаксис: REVOKE { {привилегия [,...]| роль [,...]} } [ON имя_объекта_базы] [FROM имя_получателя [,...] ]; Рассмотрим ключевые слова. привилегия В этом предложении можно отменить одну или несколько привилегий досту- па, разделяя их запятыми. ALL PRIVILEGES — отменяются все назначенные привилегии доступа к указанному объекту; EXECUTE — отменяется право запускать хранимую процедуру, пользова- тельскую функцию или пакет; { SELECT | INSERT | UPDATE | DELETE } — отменяется право выпол- нять соответствующие операции применительно к указанному объекту ба- зы данных (таблице, представлению и пр.); REFERENCES — отменяется право определять ограничения, обеспечиваю- щие ссылочную целостность. Роль Отменяется назначение роли пользователю или другой роли. ON имя_объекта_базы Пользователь или роль лишаются привилегии доступа к конкретному суще- ствующему объекту базы данных ( имя_объекта_базы ). К объектам базы дан- ных относятся: таблицы, представления, последовательности, хранимые про- цедуры и т. д. FROM имя_получателя Указывается пользователь или роль, лишающаяся данной привилегии. Например, пусть нам необходимо отобрать у пользователя Повар привилегию на выборку данных из таблицы Меню REVOKE SELECT ON COOK.МЕНЮ FROM Повар; Отменим роль Пансион у пользователя Повар : REVOKE Пансион FROM Повар; Часть III. Язык SQL. Изменение данных 166 7.3.3. Синонимы Синоним — псевдоним (дополнительное имя) для объекта (таблицы, пред- ставления, последовательности и пр.). Они используются для: маскировки действительного имени и владельца объекта; обеспечения общего доступа к объекту; достижения прозрачности местоположения для таблиц, представлений или программных единиц удаленной базы данных; упрощения кодирования предложений SQL для пользователей базы данных. Синтаксис предложения для создания синонима имеет вид: CREATE [ OR REPLACE ] [ PUBLIC ] SYNONYM [схема.]синоним FOR [схема.]объект; где объектом может быть: таблица; представление; материализованное представление; последовательность; хранимая процедура (функция или пакет); синоним. Синоним может быть общим ( PUBLIC ) или личным. Обычный пользователь может создать личный синоним, который будет доступен только этому поль- зователю. Администраторы баз данных чаще всего создают общие синони- мы, благодаря которым объекты базовых схем становятся доступными для общего пользования всех пользователей базы данных. Преимуществом общедоступных синонимов является то, что они могут соз- даваться и поддерживаться в одном месте. Если во время создания синонима определена схема, то пользователям не нужно указывать имя схемы при вы- полнении запросов по отношению к таблице. Одним из распространенных применений синонимов является создание общедоступного синонима табли- цы с таким же именем, что и у исходной таблицы. Например, для того чтобы все пользователи (в том числе и пользователь Повар ) могли обращаться к некоторым таблицам пользователя COOK без ука- Глава 7. Организация доступа к базе данных 167 зания имени схемы, необходимо после назначения привилегий (разд. 7.3.1) создать синонимы: CREATE PUBLIC SYNONYM МЕНЮ FOR COOK.МЕНЮ; CREATE PUBLIC SYNONYM РЕЦЕПТЫ FOR COOK.РЕЦЕПТЫ; CREATE PUBLIC SYNONYM ТРАПЕЗЫ FOR COOK.ТРАПЕЗЫ; CREATE PUBLIC SYNONYM ВИДЫ_БЛЮД FOR COOK.ВИДЫ_БЛЮД; CREATE PUBLIC SYNONYM БЛЮДА FOR COOK.БЛЮДА; 7.3.4. Представления Как уже упоминалось в разд. 4.3, представление — это пустая именованная таблица, определяемая перечнем тех столбцов таблиц и признаками тех их строк, которые хотелось бы в ней увидеть. Представление является как бы "окном" в одну или несколько базовых таблиц. Оно создается с помощью предложения CREATE VIEW (создать представление), упрощенный синтаксис которого имеет вид: CREATE [OR REPLACE] VIEW имя_представления {[(столбец [,...])]} AS предложение_select [WITH CHECK OPTION]; При выполнении этого предложения создается представление (виртуальная таблица) с именем, указанным в имя_представления Фраза OR REPLACE позволяет заменить существующее представление с име- нем имя_представления на новое. Список имен столбцов ( столбец [,...] ), количество которых должно совпа- дать с количеством столбцов, генерируемых предложением_select , должен быть определен лишь в тех случаях, когда: хотя бы один из столбцов предложения_select не имеет имени, так как создается с помощью выражения, SQL-функции или константы; два или более столбцов подзапроса имеют одно и то же имя. Если же список отсутствует, то представление наследует имена столбцов из подзапроса. Необязательная фраза WITH CHECK OPTION (с проверкой) указывает, что для операций INSERT и UPDATE над этим представлением должна осуществляться проверка, обеспечивающая удовлетворение WHERE -фразы подзапроса. Например, создадим представление Мясные_блюда CREATE VIEW Мясные_блюда AS SELECT БЛ, Блюдо, В, Выход Часть III. Язык SQL. Изменение данных 168 FROM Блюда WHERE Основа = 'Мясо'; которое может рассматриваться пользователем как новая таблица в базе данных. Уничтожение ненужных представлений выполняется с помощью предложе- ния DROP VIEW (уничтожить представление), имеющего следующий формат: DROP VIEW представление; Операции выборки из представлений Создав представление Мясные_блюда , пользователь может считать, что в базе данных реально существует такая таблица, и дать, например, запрос на полу- чение из нее всех данных: SELECT * FROM Мясные_блюда; результат которого имеет вид БЛ Блюдо В Выход 2 Салат мясной З 200 6 Мясо с гарниром З 250 9 Суп харчо С 500 13 Бастурма Г 300 14 Бефстроганов Г 210 Поскольку при определении представления может быть использован любой допустимый подзапрос, то выборка данных может осуществляться как из ба- зовых таблиц, так и из представлений: CREATE VIEW Горячие_мясные_блюда AS SELECT Блюдо, Продукт, Вес FROM Мясные_блюда, Состав, Продукты WHERE Мясные_блюда.БЛ = Состав.БЛ AND Продукты.ПР = Состав.ПР AND В = 'Г'; Если теперь возникла необходимость получить сведения о горячих мясных блюдах, в состав которых входят помидоры, то можно сформировать запрос SELECT Блюдо, Продукт, Вес FROM Горячие_мясные_блюда Глава 7. Организация доступа к базе данных 169 WHERE Блюдо IN ( SELECT Блюдо FROM Горячие_мясные_блюда WHERE Продукт = 'Помидоры') и получить: Блюдо Продукт Вес Бастурма Говядина 180 Бастурма Помидоры 100 Бастурма Лук 40 Бастурма Зелень 20 Бастурма Масло 5 Легко заметить, что данный запрос, осуществляющий выбор данных через два представления, выглядит для пользователя точно так же, как обычный SELECT , оперирующий обычной базовой таблицей. Однако СУБД преобразует его при выполнении в эквивалентную операцию над лежащими в основе ба- зовыми таблицами (перед выполнением проводит слияние выданного поль- зователем SELECT с предложениями SELECT из описаний представлений, хра- нящихся в каталоге). Обновление представлений Рассматриваемые в главе 8 операции DELETE , INSERT и UPDATE могут опериро- вать не только базовыми таблицами, но и представлениями. Однако если из базовых таблиц можно удалять любые строки, обновлять значения любых их столбцов и вводить в такие таблицы новые строки, то этого нельзя сказать о представлениях, не все из которых являются обновляемыми. Безусловно обновляемыми являются представления, полученные из единст- венной базовой таблицы простым исключением некоторых ее строк и (или) столбцов, обычно называемые "представление-подмножество строк и столб- цов". Таким является представление Мясные_блюда , полученное из базовой таблицы Блюда исключением из нее столбца Труд и строк, не содержащих значение 'Мясо' в столбце Основа . Работая с ним, можно: вставить (операция INSERT ) новую строку, например строку (34, 'Шашлык', 'Г', 150) , фактически вставляя соответствующую строку (34, 'Шашлык', 'Г', 150, NULL) в лежащую в основе базовую таблицу Блюда ; Часть III. Язык SQL. Изменение данных 170 удалить (операция DELETE ) существующую строку из представления, на- пример строку (13, 'Бастурма', 'Г', 300) , фактически удаляя соответ- ствующую строку (13, 'Бастурма', 'Г', 300, 5) из таблицы Блюда ; обновить (операция UPDATE ) какое-либо поле в существующей строке, на- пример увеличить массу порции Бефстроганова с 210 до 250 граммов, фактически осуществляя то же самое изменение в соответствующем поле таблицы Блюда Однако если бы представление Мясные_блюда имело вместо столбца Выход столбец Вых_труд , полученный путем суммирования значений столбцов Вы- ход и Труд таблицы Блюда , то указанные ранее операции INSERT и UPDATE бы- ли бы отвергнуты системой. Действительно, как распределить вводимое значение столбца Вых_труд (153 или 254) между значениями столбцов Выход и Труд базовой таблицы Блюда ? Была бы отвергнута и операция удаления масла из состава Бастурмы, если бы ее попытались выполнить путем удаления строки ('Бастурма', 'Масло', 5) в представлении Горячие_мясные_блюда Встает множество вопросов: надо ли удалять из базовой таблицы Блюда строку, содержащую значение 'Бастурма' в столбце Блюдо ; надо ли удалять из базовой таблицы Продукты строку, содержащую значе- ние 'Масло' в столбце Продукт ; надо ли удалять из базовой таблицы Состав все строки, содержащие зна- чение 5 в столбце Вес ? Последний вопрос возник потому, что при конструировании представления Горячие_мясные_блюда в него не была включена информация о связях между лежащими в его основе базовыми таблицами Блюда , Состав и Продукты И следовательно, у системы нет прямых путей для поиска той единственной строки таблицы Состав , которая должна быть удалена. Таким образом, некоторые представления по своей природе обновляемы, в то время как другие таковыми не являются. Здесь следует обратить внимание на слова "по своей природе". Дело заключается не просто в том, что некоторая СУБД не способна поддерживать определенные обновления, в то время как другие СУБД могут это делать. Никакая СУБД не может непротиворечивым образом поддерживать без дополнительной помощи обновление такого пред- ставления, как Горячие_мясные_блюда . "Без дополнительной помощи" озна- чает здесь "без помощи какого-либо человека — пользователя". Как было указано ранее, к теоретически обновляемым представлениям отно- сятся представления-подмножества строк и столбцов. Однако существуют Глава 7. Организация доступа к базе данных 171 некоторые представления, которые не являются представлениями- подмножествами строк и столбцов, но также теоретически обновляемы. Хотя известно, что такие есть и можно привести их примеры, но невозможно дать их формального определения. Неверным является такое формальное опре- деление некоторых авторов — "нельзя обновлять соединение". Во-первых, в некоторых соединениях с успехом выполняется операция UPDATE , а, во- вторых, как было показано ранее, не обновляемы и некоторые представле- ния, не являющиеся соединениями. Кроме того, не все СУБД поддерживают обновление любых теоретически обновляемых представлений. Поэтому пользователь должен сам оценивать возможность использования операций DELETE , INSERT или UPDATE в созданном им представлении. Для чего нужны представления Одна из основных задач, которую позволяют решать представления, — обес- печение независимости пользовательских программ от изменения логической структуры базы данных при ее расширении и (или) изменении размещения столбцов, возникающего, например, при расщеплении таблиц. В последнем случае можно создать представление-соединение с именем и структурой расщепленной таблицы, позволяющее сохранить программы, существовав- шие до изменения структуры базы данных. Кроме того, представления дают возможность различным пользователям по- разному видеть одни и те же данные, возможно, даже в одно и то же время. Это особенно ценно при работе различных категорий пользователей с единой интегрированной базой данных. Пользователям предоставляют только инте- ресующие их данные в наиболее удобной для них форме (окно в таблицу или в любое соединение любых таблиц). Наконец, от определенных пользователей могут быть скрыты некоторые данные, невидимые через предложенное им представление. Таким образом, принуждение пользователя осуществлять доступ к базе данных через пред- ставления является простым, но эффективным механизмом для управления санкционированием доступа. Например, для того чтобы скрыть от какого-то пользователя сведения о ви- таминах, входящих в продукты (табл. 3.3), и данные о судаке ( Код_продукта=2 ) из той же таблицы, можно закрыть ему к ней доступ, а открыть доступ к представлению Составляющие : CREATE VIEW Составляющие AS SELECT Код_продукта, Продукт, Белки, Жиры, Углев FROM Продукты WHERE Код_продукта <> 2; Часть III. Язык SQL. Изменение данных 172 7.3.5. Разграничение доступа к записям таблицы В зависимости от выдвигаемых требований в общем случае существует два основных способа решения данной задачи: с использованием представлений; с использованием процедур, функций, пакетов. Оба метода имеют характерные особенности. Например, при использовании представления, сделанного по очень большой таблице или таблицам, в со- единениях будет наблюдаться резкое падение производительности, из-за того, что по представлению нельзя построить индекс. При работе с процедурами, функциями или пакетами теряется "прозрачность" представления. И к тому же возникает множество проблем, в случае изменения структуры таблиц, яв- но прописанных в тексте процедур, функций, пакетов. Так что необходимо очень тщательно подходить к выбору стратегии разграничения доступа. При использовании программных объектов подразумевается, что пользова- тель работает в первую очередь с приложением, а не с командной строкой SQL*Plus. Всю работу с таблицами в свете решаемой задачи можно разделить на два вида: пользователь работает только со своими строками, например которые он сам и создал; доступ пользователя к записям таблицы определяется каким-то более сложным образом, например, рядовые сотрудники имеют один уровень доступа, более продвинутые — имеют значительно расширенный доступ, а единицы — обладают правом работы со всей таблицей (мандатный кон- троль доступа). Соответственно, решение задачи в первом случае сводится к введению до- полнительного поля в таблицу, с которой производится работа. Во втором случае, все более серьезно. Для организации такого доступа нам потребуется создание дополнительной таблицы полномочий, в которой каждому пользо- вателю мы сопоставим его уровень доступа. Итак, разберем все по порядку. В качестве примера возьмем базу данных "COOK" и рассмотрим следующих ее пользователей: заведующий производством (пользователь zav ); первый агент по закупкам, работающий с питерскими организациями ( agent1 ); второй агент по закупкам, работающий с эстонскими организациями ( agent2 ). Глава 7. Организация доступа к базе данных 173 Соответственно нет необходимости в том, чтобы агенты по закупкам выясня- ли информацию о совершенных друг с другом сделках. А заведующему про- изводством неважно, кто совершил ту или иную сделку. Работа только со своими строками С использованием представлений Задача решается просто — создаются соответствующие представления для таблиц Поставщики и Поставки . И затем выдается привилегия на доступ к этим представлениям. А для заведующего производством можно дать на- прямую привилегию на SELECT этих таблиц. Однако предварительно нужно изменить эти таблицы следующим образом. АLTER TABLE Поставщики ADD agent_column VARCHAR2(20); АLTER TABLE Поставки ADD agent_column VARCHAR2(20); Соответственно в эти колонки будут заноситься имена пользователей- агентов, в таблицу Поставщики вручную, а в таблицу Поставки автоматически с помощью триггера (см. разд. 18.4). Скрипты по созданию триггеров и представлений: CREATE OR REPLACE TRIGGER postavshiki_ins BEFORE INSERT ON Поставщики FOR EACH ROW BEGIN :NEW.agent_column := USER; END postavshiki_ins; CREATE OR REPLACE TRIGGER postavki_ins BEFORE INSERT ON Поставки FOR EACH ROW BEGIN :NEW.agent_column := USER; END postavki_ins; CREATE VIEW postavshiki AS SELECT ПС, НАЗВАНИЕ, СТАТУС, ГОРОД, АДРЕС, ТЕЛЕФОН FROM ПОСТАВЩИКИ WHERE agent_column = USER; CREATE VIEW postavki AS SELECT ПС, ПР, ЦЕНА, К_ВО, ДАТА FROM ПОСТАВКИ WHERE agent_column = USER; Часть III. Язык SQL. Изменение данных 174 Скрипты для выдачи привилегий на работу с представлениями и таблицами (для удобства, все сделано с использованием ролей): GREATE ROLE zav_role; GRANT SELECT ON Поставщики TO zav_role; GRANT SELECT ON Поставки TO zav_role; GREATE ROLE agent_role; GRANT SELECT, INSERT ON postavshiki TO agent_role; GRANT SELECT, INSERT ON postavki TO agent_role; Выдаем роли пользователям zav , agent1 , agent2 GRANT agent_role TO agent1; GRANT agent_role TO agent2; GRANT zav_role TO zav; Далее они могут безболезненно работать с таблицами Поставщики и Поставки (хотя невредно было бы создать PUBLIC -синонимы). CREATE PUBLIC SYNONYM Поставщики FOR cook.Поставщики; CREATE PUBLIC SYNONYM Поставки FOR cook.Поставки; CREATE PUBLIC SYNONYM postavshiki FOR cook.postavshiki; CREATE PUBLIC SYNONYM postavki FOR cook.postavki; С использованием пакетов Пример использования пакета рассмотрен в разд. 18.5. |