Мартин Грубер - Понимание SQL (991940), страница 39
Текст из файла (страница 39)
Так как внешние ключи не используются в представлениях, привилегия REFERENCES никогда не используется при создании представлений. Все эти ограничения — определяются ANSI. Нестандартные привилегиисистемы (обсуждаемые позже в этой главе) также могут быть включены. В последующих разделах мы предположим, что создатели представлений которые мы обсуждаем, имеют частные или соответствующие привилегии во всех базовых таблицах.ОГРАНИЧЕНИЕ ПРИВИЛЕГИИ SELECT ДЛЯОПРЕДЕЛЕННЫХ СТОЛБЦОВПредположим, вы хотите дать пользователю Claire способность видеть толькостолбцы snum и sname таблицы Продавцов.
Вы можете сделать это, поместив именаэтих столбцов в представлениеCREATE VIEW ClairesviewAS SELECT snum, snameFROM Salespeople;и предоставив Claire привилегию SELECT в представлении, а не в самой таблицеПродавцов:GRANT SELECT On Clairesview to Claire;Вы можете создать привилегии специально для столбцов наподобии использования других привилегий, но, для команды INSERT, это будет означать вставку значений по умолчанию, а для команды DELETE, ограничение столбца не будет иметьзначения. Привелегии REFERENCES и UPDATE, конечно, могут сделать столбцы специфическими не прибегая к представлению.ОГРАНИЧЕНИЕ ПРИВЕЛЕГИЙ ДЛЯ ОПРЕДЕЛЕННЫХСТРОКОбычно, более полезный способ чтобы фильтровать привилегии с представлениями — это использовать представление чтобы привилегия относилась только к определенным строкам.
Вы делаете это, естественно, используя предикат впредставлении который определит, какие строки являются включенными. Чтобы предоставить пользователю Adrian, привилегию UPDATE в таблице Заказчиков, для всехзаказчиков размещенных в Лондоне, вы можете создать такое представление:CREATE VIEW LondoncustAS SELECT *FROM CustomersWHERE city = 'London'WITH CHECK OPTION;Затем Вы должны передать привилегию UPDATE в этой таблице для Adrian:GRANT UPDATE ON Londoncust TO Adrian;В этом отличие привилегии для определенных строк от привилегии UPDATE дляопределенных столбцов, которая распространена на все столбцы таблицы Заказчиков, но не на строки, среди которых строки со значением поля city иным чем London небудут учитываться.
Предложение WITH CHECK OPTION предохраняет Adrian от замены значения поля city на любое значение кроме London.ПРЕДОСТАВЛЕНИЕ ДОСТУПА ТОЛЬКО К ИЗВЛЕЧЕННЫМДАННЫМДругая возможность состоит в том, чтобы предлагать пользователям доступ куже извлеченным данным, а не к фактическим значениям в таблице.
Агрегатныефункции, могут быть весьма удобными в применении такого способа. Вы можете создавать представление которое дает счет, среднее, и общее количество для порядковна каждый день порядка:CREATE VIEW DatetotalsAS SELECT odate, COUNT (*), SUM (amt), AVG (amt)FROM OrdersGROUP BY odate;Теперь вы передаете пользователю Diane — привелегию SELECT в представлении Datetotals:GRANT SELECT ON Datetotals TO Diane;ИСПОЛЬЗОВАНИЕ ПРЕДСТАВЛЕНИЙ В КАЧЕСТВЕАЛЬТЕРНАТИВЫ К ОГРАНИЧЕНИЯМОдной из последних прикладных программ из серии, описанной в Главе 18, является использование представлений с WITH CHECK OPTION как альтернативы к ограничениям. Предположим что вы хотели удостовериться, что все значения поля cityв таблице Продавцов находятся в одном из городов где ваша компания в настоящеевремя имеет ведомство.
Вы можете установить ограничение CHECK непосредственнона столбец city, но позже может стать трудно его изменить, если ваша компания например откроет там другие ведомства. В качестве альтернативы, можно создатьпредставление, которое исключает неправильные значения city:CREATE VIEW CurcitiesAS SELECT *FROM SalespeopleWHERE city IN ('London', 'Rome', 'San Jose', 'Berlin')WITH CHECK OPTION;Теперь, вместо того, чтобы предоставить пользователям привилегии модифицирования в таблице Продавцов, вы можете предоставить их в представлении Curcities.Преимущество такого подхода — в том, что если вам нужно сделать изменение, выможете удалить это представление, создать новое, и предоставить в этом новомпредставлении привилегии пользователям, что проще, чем изменять ограничения.Недостатком является то, что владелец таблицы Продавцов также должен использовать это представление, если он не хочет, чтобы его собственные команды были отклонены.С другой стороны, этот подход позволяет владельцу таблицы и любым другимполучить привилегии модификации в самой таблице, а не в представлении, чтобы делать исключения для ограничений.
Это часто бывает желательно, но не выполнимо,если вы используете ограничения в базовой таблице. К сожалению, эти исключениянельзя будет увидеть в представлении. Если вы выберите этот подход, вам захочетсясоздать второе представление, содержащее только исключения:CREATE VIEW OthercitiesAS SELECT *FROM SalespeopleWHERE city NOT IN ('London', 'Rome', 'San Jose', 'Berlin')WITH CHECK OPTION;Вы должны выбрать для передачи пользователям только привилегию SELECT вэтом представлении, чтобы они могли видеть исключенные строки, но не могли помещать недопустимые значения city в базовую таблицу.
Фактически, пользователимогли бы сделать запрос обоих представлений в объединении и увидеть все строкисразу.ДРУГИЕ ТИПЫ ПРИВИЛЕГИЙВы разумеется хотите знать, кто же имеет право первым создать таблицу. Этаобласть привилегии не относится к ANSI, но не может игнорироваться. Все стандартные привилегии ANSI вытекают из этой привилегии; привилегии создателей таблицкоторые могут передавать привилегии объекта. Если все ваши пользователи будутсоздавать в системе базовые таблицы с разными размерами это приведет к избыточности в них и к неэффетивности системы. Притягивают к себе и другие вопросы:— Кто имеет право изменять, удалять, или ограничивать таблицы?— Должны ли права создания базовых таблиц отличаться от прав созданияпредставлений?— Должен ли быть суперпользователь — пользователь который отвечает заподдержание базы данных и следовательно имеющий наибольшие, или все привилегии, которые не предоставляются индивидуально?Пока ANSI не принимает в этом участие, а SQL используется в различных средах, мы не можем дать окончательный ответ на эти вопросы.
Мы предлагаем рассмотреть здесь кусок наиболее общих выводов.Привилегии, которые не определяются в терминах специальных объектов данных, называются привилегиями системы, или правами базы данных. На базисномуровне, они будут вероятно включать в себя право создавать объекты данных, вероятно отличающиеся от базовых таблиц (обычно создаваемыми несколькими пользователями) и представления (обычно создаваемые большинством пользователей).Привилегии системы для создания представлений должны дополнять, а не заменятьпривилегии объекта, которые ANSI требует от создателей представлений (описанныхранее в этой главе).Кроме того, в системе любого размера всегда имеются некоторые типы суперпользователей — пользователей, которые автоматически имеют большинство или всепривилегии, — и которые могут передать свой статус суперпользователя кому-нибудьс помощью привилегии или группы привилегий.
Администратор Базы Данных, илиDBA, является термином, наиболее часто используемым для такого суперпользователя и для привилегий, которыми он обладает.ТИПИЧНЫЕ ПРИВИЛЕГИИ СИСТЕМЫПри общем подходе имеется три базовых привилегии системы:- CONNECT (Подключить),- RESOURCE (Ресурс), и- DBA(Администратор Базы Данных).Проще, можно сказать, что CONNECT состоит из права зарегистрироваться иправа создавать представления и синонимы (см. Главу 23), если переданы привилегии объекта.
RESOURCE состоит из права создавать базовые таблицы. DBA — этопривилегия суперпользователя, дающая пользователю высокие полномочия в базеданных. Один или более пользователей с функциями администратора базы данныхможет иметь эту привилегию. Некоторые системы кроме того имеют специальногопользователя, иногда называемого SYSADM или SYS (Системный АдминистраторБазы Данных), который имеет наивысшие полномочия; это — специальное имя, а непросто пользователь со специальной DBA привилегией. Фактически только один человек имеет право зарегистрироваться с именем SYSADM, являющимся его идентификатором доступа. Различие весьма тонкое и функционирует по разному вразличных системах. Для наших целей, мы будем ссылаться на высокопривилегированного пользователя, который разрабатывает и управляет базой данных имея полномочия DBA, понимая что фактически эти полномочия — та же самая привилегия.Команда GRANT, в измененной форме, является пригодной для использования с привилегиями объекта как и с системными привилегиями.
Для начала передача прав может быть сделана с помощью DBA. Например, DBA может передать привилегию длясоздания таблицы пользователю Rodriguez следующим образом:GRANT RESOURCE TO Rodriguez;СОЗДАНИЕ И УДАЛЕНИЕ ПОЛЬЗОВАТЕЛЕЙЕстественно, появляется вопрос, откуда возьмется пользователь с именемRodriguez? Как определить его ID допуска? В большинстве реализаций, DBA создаетпользователя, автоматически предоставляя ему привилегию CONNECT.В этом случае, обычно добавляется предложение IDENTIFIED BY, указывающеепароль.
(Если же нет, операционная система должна определить, можете ли вы зарегистрироваться в базе данных с данным ID доступа.) DBA может, например, ввестиGRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon;что приведет к созданию пользователя, с именем Thelonius, даст ему право регистрироваться, и назначит ему пароль Redwagon, и все это в одном предложении.Раз Thelonious — уже опознаный пользователь, он или DBA могут использоватьэту же команду чтобы изменить пароль Redwagon.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
