Oracle права на тип
Если бы мне принадлежал весь этот край, я бы
отдал его за то, чтобы сама королева Англии лежала в моих объятиях.
Carmina Burana, если верить Карлу Орфу
Введение
Наследование типов объектов - важнейшее свойство объектного подхода. В Oracle оно появилось с опозданием "на 1,2 версии", то есть в версии 9.2, а не сразу в 8.0. Но в конце концов его реализация оказалась достаточно полной. Это единичное (не множественное) наследование, и некоторые подробности его исполнения в Oracle иллюстрируются на примере ниже.
Типы в поликлинике
Предположим, имеется поликлиника, в здании которой могут находиться сотрудники и посетители. У тех и других есть для учета имена, но у сотрудников к тому же табельные номера, а у посетителей - номер регистрационной карты. Классическую ситуацию "типы-подтипы" можно в Oracle разрешить объектными средствами, например так:
Если бы фраза NOT FINAL в определении PERSON_TYP отсутствовала, не удалось бы создать подтипы EMPLOYEE_TYP и VISITOR_TYP. У подтипов же эта фраза оставлена на всякий случай, который сейчас представится. Например, пусть нужно среди сотрудников отличать врачей от обслуживающего персонала:
Данные о взаимозависимостях типов можно посмотреть в USER_TYPES:
Люди у проходной
И посетители, и сотрудники проходят через проходную, где отмечаются в таблице CHECKPOINT:
Вот как они могут "проходить":
Можно проверить, кто прошел:
Обратите внимание на использованное упрощение: никто не запретил пройти через проходную просто сотруднику (Scott), то есть не врачу и не обслуживающему персоналу. Желание запретить такого рода вставки в таблицу во многих случаях возникает вполне законно. Для запрета следовало было описать тип EMPLOYEE_TYP (а заодно и PERSON_TYP) как "абстрактный" (это термин объектно-ориентированного подхода):
Просмотр входивших
Пример просмотра (SELECT * …) уже приводился. Однако для получения данных в табличном виде запрос придется усложнить. Проблема, которую придется учитывать в таком запросе - наличие в поле PERSON разных строк одной и той же таблицы значений разных типов. Бороться с проблемой позволяет специальное расширение SQL:
(В скобках отмечу, что к сожалению для выдачи данных базового типа ANYTYPE в Oracle придумано отдельное решение).
Обратите внимание, что столбец для выдачи можно формировать, трактуя поле PERSON отправной таблицы и как, например, EMPLOYEE_TYP, несмотря на то, что в CHECKPOINT имеются и строки другого типа:
(Действительно, строки выводятся даже для персон, не являющихся сотрудниками, вследствие чего не имеющих табельного номера EMPID).
Отбор входивших персон конкретного типа можно сформулировать во фразе WHERE, для которой придуманы другие специальные конструкции:
Обратите внимание, что выдались строки с данными типа EMPLOYEE_TYP и всех его подтипов. Если же строки с данными подтипов выдавать не нужно, можно указать следующее:
Вот как можно объединить два приведенные выше варианта отбора - строк по типам во фразе WHERE и столбцов с атрибутами, возможно других, типов:
Обратите внимание, что по синтаксису, принятом в Oracle написать во фразе SELECT выдачу C.PERSON.PHONE, наподобие C.PERSON.NAME, не получится. Не получится даже написать SELECT c.person.empid …, несмотря на то, что фразой WHERE отбираются сотрудники, которые имеют табельный номер EMPID. Для обращения к свойствам подтипов вам все равно придется написать SELECT TREAT (c.person AS doctor_typ).empid …, указав явно подтип, где возникло это свойство. Для свойства NAME приведения типа не требуется, так как оно задано для ("основного") типа столбца PERSONS, то есть PERSONS_TYP, а не для подтипов PERSONS_TYP.
Плата за свободный проход или эволюция типов
К сожалению объектные свойства дают разработчику не только приятные моменты. Одной из оборотных сторон является сложность, более высокая, чем при работе с таблицами. В жизни далеко не всегда получается придумать схему данных правильно и сразу, и оставить будущему только работу с самими данными. Часто приходится вносить изменения в схему при наличии уже имеющихся данных. Тут-то объектный подход и обнаружит больше затруднений, чем поначалу могло бы хотеться.
Кроме того, поскольку у EMPLOYEE_TYP есть подтипы, потребовалось указать слово CASCADE, чтобы изменения распространились на них (можете проверить, что указание CASCADE не спасет ситуацию с ошибкой ORA-22327 выше).
К счастью обратное изменение свойства типа, с NOT INSTANTIABLE на INSTANTIABLE, не потребует никаких жертв и срабатывает всегда.
В жизни сложнее
В завершение нужно заметить, что пример в этой статье был сознательно упрощен. Конечно, в жизни вряд ли было бы целесообразно в таблицу CHECKPOINT включать объектное поле, хранящее все моделируемые свойства людей. (Это соответствует и "физике процесса": едва ли требуется сообщать вахтеру специализацию входящего врача и рабочий телефон, достаточно табельного номера). Персоны скорее всего должны бы рассматриваться как самостоятельные объекты, а в таблицу CHECKPOINT следовало бы включить ссылки на них. Но для понимания темы, затронутой в статье, это не существенно.
Я участвую в бакалавриате, и у меня нет особых проблем при предоставлении прав собственности пользователю A на хранимую процедуру, принадлежащую пользователю B в базе данных Oracle 10g mode = xe.
Пожалуйста, помогите мне написать команды sql для предоставления прав собственности на хранимую процедуру xyz другому пользователю A.
Я не уверен, что понимаю, что вы подразумеваете под "правами собственности".
Если пользователь B владеет хранимой процедурой, пользователь B может предоставить пользователю разрешение на выполнение хранимой процедуры
Затем пользователь A вызовет процедуру, используя полное имя, т.е.
В качестве альтернативы, пользователь A может создать синоним, чтобы избежать использования полного имени процедуры.
Вы не можете делать то, что, я думаю, вы просите.
Единственными привилегиями, которые вы можете предоставить для процедур, являются EXECUTE и DEBUG.
Как упоминал Джастин, способ предоставить права выполнения A для процедуры, принадлежащей B:
В вашей учетной записи DBA дайте USERB право создать процедуру с помощью гранта grant create any procedure to USERB
Процедура будет выглядеть
Я знаю, что это очень старый вопрос, но я надеюсь, что смогу немного его починить.
Пакеты и хранимые процедуры в Oracle выполняются по умолчанию, используя права пакета/процедуры OWNER, а не текущего пользователя.
Итак, если вы вызываете пакет, который создает пользователя, например, его владельца пакета, а не вызывающего пользователя, которому требуется создать пользовательскую привилегию. Абонент просто должен иметь разрешение на выполнение в пакете.
Если вы предпочитаете, чтобы пакет был запущен с использованием разрешений вызывающего пользователя, тогда при создании пакета вам необходимо указать AUTHID CURRENT_USER
Реализация инструкции GRANT в системе Oracle поддерживает огромное количество вариантов и изменений. Синтаксис ее следующий.
[WITH OPTION] [IDENTIFIED BY пароль] [WIТН ADMIN OPTION];
Вы можете присваивать несколько привилегий в одной инструкции, но эти привилегии должны относиться к одному типу (объектные, системные или ролевые).
Например, вы можете предоставить пользователю три объектные привилегии в одной таблице при помощи одной инструкции GRANT, затем при помощи отдельной инструкции назначить две системные привилегии какой-нибудь роли, а в третьей инструкции присвоить пользователю несколько ролей, но нельзя сделать все это в одной инструкции GRANT.
Ниже приводятся параметры инструкции GRANT платформы Oracle.
объект_имя_привилегия
Привилегии для доступа к указанному объекту схемы (например, таблице или представлению) присваиваются указанному получателю (имя_получателя) или роли. Вы можете объединять в одной инструкции несколько объектных привилегий, объектов схемы или получателей. Однако вы не можете объединять в одной инструкции присвоение системных привилегий или ролей с присвоением объектных привилегий. Существуют следующие объектные привилегии.
ALL [PRIVILEGES]
Присваиваются все доступные привилегии доступа к объекту схемы. Можно применять к таблицам.
ALTER
Предоставляется право изменять существующую таблицу при помощи инструкции ALTER TABLE. Можно применять к таблицам и последовательностям.
DEBUG
Предоставляется право обращаться к таблице при помощи отладчика. Этот доступ применим к любым триггерам таблицы и любой информации о коде SQL, напрямую обращавшемся к таблице. Можно применять к таблицам, представлениям, процедурам, функциям, пакетам, объектам Java и типам.
EXECUTE
Предоставляется право запускать хранимую процедуру, пользовательскую функцию или пакет. Можно применять к процедурам, функциям, пакетам, объектам Java, библиотекам, типам, индексным типам и пользовательским операторам.
INDEX
Предоставляется право создавать индексы по таблице.
(ON COMMIT REFRESH QUERY REWRITE>
Предоставляется привилегия создавать материализованные представления, обновляющиеся после транзакции (refresh-on-commit), или создавать материализованное представление для переписывания запросов к указанной таблице. Применяется только к материализованным представлениям.
Предоставляется привилегия читать и записывать файлы в директорию, указанную с помощью полного пути к директории операционной системы. Поскольку система Oracle имеет возможность сохранять файлы за пределами базы данных, серверный процесс Oracle должен быть запущен пользователем, имеющим привилегии доступа к указанным директориям. Вы можете включить в Oracle при помощи этого механизма систему обеспечения безопасности на уровне отдельных пользователей. Обратите внимание, что предложение WRITE можно использовать только с внешней таблицей, например файлом журнала или файлом ошибок.
REFERENCES
Предоставляется право определять ограничения, обеспечивающие ссылочную целостность. Можно использовать в таблицах.
(SELECT | INSERT | UPDATE DELETE>
Предоставляется право выполнять соответствующие команды SQL применительно к указанному объекту схемы. Можно использовать в таблицах, представлениях, последовательностях (только SELECT) и материализованных представлениях (только SELECT). Отметьте, что вы должны предоставить привилегию SELECT тому пользователю или роли, которому требуется привилегия DELETE. Вы можете назначать привилегии на уровне столбцов, включив в инструкцию, после имени объекта, заключенный в скобки список столбцов. Это возможно только при предоставлении объектных привилегий INSERT, REFERENCES или UPDATE в таблице или представлении.
UNDER
Предоставляется право создавать представления-потомки указанного представления. Используется только с представлениями и типами.
системная_привилегия
Указанная системная привилегия Oracle назначается одному или нескольким пользователям или ролям. Например, вы можете предоставлять такие привилегии, как CREATE TRIGGER или ALTER USER. В обоих случаях предоставление системной привилегии наделяет пользователя или роль правом выполнять команду с соответствующим именем. Полный список системных привилегий приводится в 3.2 ниже в этом разделе.
роль
Роль назначается пользователю или другой роли. Помимо пользовательских ролей существует несколько готовых системных ролей, поставляемых с Oracle.
CONNECT, RESOURCE и DBA
Предлагаются для обратной совместимости с предыдущими версиями Oracle.
Не используйте эти роли в текущей и более новых версиях Oracle, поскольку в будущем их поддержка может быть прекращена.
DELETEJOA TALOGJROLE, EXECUTEJJA TALOGJROLE и SELECT_СА TALOGJ.OLE
Пользователи, которым присвоена эта роль, могут удалять, выполнять и отбирать данные из словарных представлений и пакетов.
EXP_FULL_DATABASE и IMP_FULL_DATABASE
Пользователи, которым присвоена эта роль, могут запускать утилиты импорта и экспорта.
AQJJSERJROLE и AQ_ADMINISTRATORJROLE
Пользователи, которым присвоена эта роль, могут использовать или администрировать такую функциональность Oracle, как Advanced Queuing.
SNMPAGENT
Присваивается только Oracle Enterprise Manager и Intelligent Agent.
RECOVERY_CATA LOGO WNER
Предоставляется привилегия создавать пользователей, владеющих собственным каталогом восстановления.
HS_ADMIN_ROLE
Предоставляется привилегия обращаться к областям словарей данных, которые используются для поддержки гетерогенных служб Oracle.
ON имя_схемы
Пользователю или роли предоставляется привилегия доступа к объекту схемы. К объектам базы данных относятся: таблицы, представления, последовательности, хранимые процедуры, пользовательские функции, пакеты, материализованные представления, пользовательские типы, библиотеки, индексные типы, пользовательские операторы или синонимы всех этих объектов. Если имя схемы не будет указано, будет подразумеваться схема текущего пользователя. Платформа Oracle также поддерживает два ключевых слова для особых случаев.
DIRECTORY
Предоставляются права доступа к объекту-директории, который представляет собой объект Oracle, соответствующий директории в файловой системе.
JAVA
Предоставляются привилегии доступа к Java-объектам схемы SOURCE и RESOURCE.
Указывается пользователь или роль, получающая данную привилегию. Ключевое слово PUBLIC также можно использовать при отмене привилегии, назначенной для роли PUBLIC. Можно через запятую перечислить нескольких получателей привилегии.
WITH GRANT OPTION
Позволяет получателю привилегии назначать эти привилегии другим пользователям или роли PUBLIC, но никаким другим ролям.
WITH HIERARCHY OPTION
Позволяет получателю привилегии в объекте-родителе получить эти привилегии во всех объектах-потомках. Это касается и всех потомков, которые будут созданы в будущем. Вы можете использовать эту опцию только при назначении объектной привилегии SELECT.
IDENTIFIED BY пароль [WITH ADMIN OPTION]
Устанавливается или изменяется пароль, который получатель привилегии должен использовать, чтобы ему была предоставлена роль.
WITH ADMIN OPTION
Позволяет получателю осуществлять управление ролью, которую вы ему назначаете. Во-первых, это предложение позволяет получателю назначать и отзывать роль пользователям и неглобальным ролям. Оно также позволяет получателю удалить роль или изменить авторизацию, необходимую для доступа к ней.
Назначение привилегий пользователям вступает в силу немедленно. Назначение ролей вступает в силу немедленно, если роль задействована. В противном случае назначение вступает в силу после включения роли. Обратите внимание, что роли можно назначать пользователям и другим ролям (в том числе PUBLIC). Пример:
GRANT sales_reader ТО salesjnanager;
Чтобы предоставлять привилегии доступа к представлению, вы должны иметь в базовых таблицах представления данные привилегии, с указанием предложения WITH GRANT OPTION.
Если вы захотите предоставить привилегии всем пользователям, просто назначьте эти привилегии роли PUBLIC.
GRANT SELECT ON work_schedule TO public;
Тем не менее существуют определенные ограничения в предоставлении системных привилегий и ролей.
- Привилегия или роль не должна встречаться в инструкции GRANT больше одного раза.
- Роль нельзя назначить самой себе.
- Роли не могут назначаться рекурсивно, то есть нельзя назначить роль sales_reader роли sales_manager, а потом присвоить роль sales_manager роли sales_reader.
Вы можете присваивать несколько однотипных привилегий в одной инструкции GRANT. Однако эти привилегии должны относиться к объектам одного типа.
GRANT UPDATE (emp_id, job_id), REFERENCES (emp_id)
В качестве отступления, предоставление любых объектных привилегий доступа к таблице позволяет пользователю (или роли) блокировать таблицу любым режимом блокировки, используя инструкцию Oracle LOCK TABLE.
Почти все поддерживаемые Oracle функциональности и команды могут назначаться в виде привилегий в инструкции GRANT (как это показывает 3.2). Привилегии можно назначать не только применительно к объектам базы данных (таким, как таблицы и представления) и системным командам (таким, как CREATE ANY TABLE), но также и к объектам схем (таким, как DIRECTORY, JAVA SOURCE и RESOURCE).
Параметр ANY, показанный в 3.2, предоставляет права выполнения данной инструкции применительно к объектам указанного типа, принадлежащим любому пользователю в схеме. Без опции ANY пользователь сможет применять инструкции только к объектам в своей собственной схеме. Более полный список системных привилегий Oracle приведен в 3.2.
Все привилегии, показанные в 3.2 и содержащие ключевое слово ANY, имеют особое значение. В частности, ключевое слово ANY дает пользователям право выполнять указанную операцию в любой схеме. Если вы хотите включить сюда все пользовательские схемы, но исключить схему SYS, установите инициализационный параметр 07 DICTIONARY ACCESSIBILITY ъ заданное для него по умолчанию значение FALSE.
Дополнительная информация по теме
Некоторые советы и методы использования инструкции INSERT в базах данных на платформе Oracle
Правила и методы использования инструкции FETCH в базах данных на платформе Oracle
Способы и методы использования инструкции DELETE в базах данных на платформе Oracle
Некоторые советы и методы использования инструкции GRANT в базах данных на платформе DB2
По умолчанию аккаунт не имеет никаких прав в БД Oracle. Невозможно даже создать подключения без назначенных прав. И даже после получения прав на подключения, аккаунт не может сделать ничего полезного (или опасного) без получения соответсвующих прав. Права назначаются с помощью команды GRANT и убираются с помощью команды REVOKE. Дополнительные директивы команды используются для разрешения аккаунта делится правами которые у него есть с другими пользователями. По умолчанию только аккаунта администратора (SYS и SYSTEM) владеют правами назначения прав. Пользователь который назначает права другому пользователю называется grantor когда получатель прав – grantee. Права разбиты на две группы: системные права, которые грубо говоря позволяют пользователю совершать действия влияющие на словарь данных, и права над объектами, которые позволяют пользователю совершать действия влияющие на данные.
Системные права
Всего доступно около двух сотен системных прав. Большинство из них влияет на действия затрагивающие словать данных (такие как создание таблиц или пользователей). Остальные влияют на экземпляр или БД (создание табличны пространств, изменение параметров БД и создание сессий). Наиболее часто используемые права это
- CREATESESSION – права на подключения. Без этих прав вы даже не сможете подключиться к БД
- RESTRICTEDSESSION – Если БД запущена с директивой STARTUPRESTRICT или применялась команда ALTERSYSTEMENABLERESTRICTEDSESSION, то только пользователи с этими правами смогут подключаться к БД
- ALTERDATABASE – разрешает выполнять команды влияющие на физические структуры
- ALTERSYSTEM – разрешает изменять параметры экземпляра и структуры памяти
- CREATETABLESPACE – вместе с ALTERTABLESPACE и DROPTABLESPACE позволяют пользователю управлять табличными пространтсвами
- CREATETABLE – позволяет gratee создавать таблицы в своей схеме; включает возможность создавать, изменять и удалять таблицы, выполнять команды DML и select и управлять индексами
- GRANTANYOBJECTPRIVILEGE – позволяет grantee управлять правами объектов которые ему не принаджлежат, но не даёт прав ему самому
- CREATEANYTABLE – grantee может создавать таблицы которые принадлежат другим аккаунтам
- DROPANYTABLE – grantee позволяется удалять таблицы которые принадлежат другим аккаунтам
- INSERTANYTABLE, UPDATEANYTABLE, DELETEANYTABLE – даёт grantee право выполнять DML команды над объектами которые ему не принадлежат
- SELECTANYTABLE – Даёт право grantee выполнять SELECT к любмы таблицам.
Синтаксис для назначения прав
GRANT privilege [,privilege…] TO username;
После создания аккаунта, обычно назначаются права часто используемые пользователями кто вовлечён в разработку приложения
grant create session, alter session,
create table, create view, create synonym, create cluster,
create database link, create sequence,
create trigger, create type, create procedure, create operator
Эти права позволяют подключаться и настраивать сессию, создавать объекты и хранить PL/SQL объекты. Объекты могут быть созданы только в схеме аккаунта; нет прав к схемам других аккаунтов. Также создание объектов ограничивается лмимитами табличных пространств.
Другим вариантом назначения прав будет назначение grantee доступа для переназначения прав другим аккаунтам. Например
grant create table to scott with admin option;
grant create table to jon;
Выполнение этих команд позволит SCOTT создавать таблицы в совей схеме, и выполнять команду GRANT. SCOTT даёт права пользователю JON создавать таблицы – но JON сможет создавать таблицы только в схеме JON. На рисунке 6-5 показаны права пользователя в Database Control; ту же информацию можно получить выполнив запрос к представлению DBA_SYS_PRIVS.
Если системные разрешения были отозваны, все действия которые вы выполнили пока у вас были права остаются в силе. Если у вас были права с ADMIN OPTION то у всех пользователей которым вы назначили права – права остаются, несмотря на то что у вас права отозвали. Не остаётся записей кто именно назначил системные привилегии, таким образом невозможно забрать права CASCADE как показано на рисунке 6-6
Revocation of a system privilege will not cascade (unlike
revocation of an object privilege).
Права ANY дают доступ ко всем объектам в БД. Таким образом
grant select any table to scott
позволить аккаунту SCOTT выполнять запрос SELECT ко всем таблицам во всех схемах БД. Такое назначение прав считается дурным тоном и ANY права назначаются только DBA.
In fact, ANY is not as dangerous now as with earlier releases. It no longer
includes tables in the SYS schema, so the data dictionary is still protected. But
ANY should still be used with extreme caution, as it removes all protection
from user tables.
Объектные права
Объектные права дают доступ к выполнению команд DML и SELECT к соответствующим объектам и выполнению PL/SQL объектов. Эти права не существуют для объектов в схеме аккаунта; если у пользователя есть системные права CREATE TABLE – это значит что он может выполнять SELECT и DML запросы к таблицам которые он создал без дополнительных прав.
The ANY privileges, that grant permissions against objects in
every user account in the database, are not object privileges—they are
Объектные права применяются к разным группам объектов
GRANT privilege ON [schema.]object TO username [WITH GRANT OPTION];
grant select on store.customers to scott;
Можно использовать ALL чтобы применить права для всех операций, или использовать конкретное указание столбца таблицы или представления.
grant select on store.orders to scott;
grant update (order_status) on store.orders to scott;
grant all on store.regions to scott;
Эти команды позволят аккаунту SCOTT выполнять запрос SELECT ко всем столбцам таблицы ORDERS в схеме STORE но обновлять данные только в одном столбце. Также у аккаунта SCOTT есть доступ ко всем операциям к таблице REGIONS. На рисунке 6-7 отображается результат назначения прав при просмотре в Database Control
Granting privileges at the column level is often said to be bad practice
because of the massive workload involved. If it is necessary to restrict peoples’
access to certain columns, creating a view that shows only those columns will
often be a better alternative.
Использование директивы WITH GRANT OPTION позволит пользователю передавать свои права другим аккаунта. Оракл хранит информацию о том кто и кому дал доступ на объектном уровне; это позволяет отзывать права учитывая эту информацию. Рассмотрим пример
При установке Oracle по умолчанию создаются два пользователя/схемы - SYS и SYSTEM. Я написал "пользователя/схемы" потому, что при создании нового пользователя для него создается одноименная схема. Не сразу понятно чем понятие "пользователь" отличается от понятия "схема". Чтобы понять представьте пользователя Windows (Unix). Пользователь имеет имя ИмяПользователя и принадлежащую ему папку - C:\Users\ИмяПользователя ( /home/ИмяПользователя ). Так вот пользователь Oracle аналогичен пользователю Windows, а схема - аналогична папке пользователя. Точно так же как у пользователя Windows, у пользователя Oracle есть набор прав. Так же как папка пользователя Windows содержит различные файлы, также и схема Oracle содержит различные объекты - таблицы, последовательности, триггеры и др. Если продолжать аналогию, то пользователей SYS и SYSTEM можно считать Администратором Windows или root-пользователем Unix. Они имеют неограниченные права. И работать под ними не рекомендуется. По-этому сначала нужно создать еще одного пользователя.
1. Создание пользователя и предоставление ему прав
Создадим пользователя, например fiftin :
Мы создали пользователя fiftin с паролем 123456 . Он не имеет абсолютно никаких прав. Вы даже не сможете под ним зайти:
Для наделения пользователя правами существует команда GRANT . Например дадим права пользователю fiftin на вход:
Если теперь вы попробуете подключиться как пользователь fiftin у вас это получится. Но это все что разрешено пользователю fiftin. Наделим пользователя правами администратора:
Теперь вы можете подцепиться к БД под fiftin'ом как админ:
Создадим таблицу:
Вставим данные:
2. Права на создание таблиц
Создадим еще одного пользователя - test:
Дадим ему права:
Теперь пользователь test может подключаться и создавать таблицы. Попробуем создать таблицу (не забудьте зайти под test'ом):
Получаем ошибку:
Почему так? Оказывается для того чтобы обычный пользователь (не админ) мог что-либо создать в БД, ему нужно выделить для этого место. Зайдем снова под fiftin'ом и выполним команду:
Этой командой мы выделяем пользователю test 50Мб под его нужды. Попробуйте теперь зайти под пользователем test и создать таблицу и у вас получится.
Основы Oracle 18c - 19c часть 8 - права доступа, роли, учетные записи
Приведем наиболее часто используемые:
CREATE SESSION – право подключения к БД
ALTER DATABASE – право изменения БД
CREATE TABLESPACE – право создавать табличное пространтсво
ALTER TABLESPACE – право изменять табличное пространтсво
DROP TABLESPACE – право удалять табличное пространтсво
CREATE TABLE – право создавать, изменять, удалять таблицы в своей схеме
INSERT ANYTABLE – право добавлять данные в таблиц, которые не принадлежат учетной записи
UPDATE ANYTABLE – право изменять данные в таблиц, которые не принадлежат учетной записи
DELETE ANYTABLE – право удалять данные в таблиц, которые не принадлежат учетной записи
SELECT ANYTABLE – право выборки данных из таблиц, которые не принадлежат учетной записи
Синтаксис назначения прав:
GRANT privilege [,privilege…] TO User_Name;
Пример создания учетной записи (схемы) User_Name
С паролем User_Pass
Разрешаем занимаемое пространство в 10мб. от пространства по умолчанию USERS
CREATE USER User_Name IDENTIFIED BY User_Pass
DEFAULT TABLESPACE USERS QUOTA 10M ON USERS;
Пример, назначение всех основных привилегий для учетной записи:
GRANT CREATE SESSION, ALTER SESSION,
CREATE TABLE, CREATE VIEW, CREATE TRIGGER, CREATE PROCEDURE,
CREATE CLUSTER, CREATE DATABASE LINK,
CREATE SYNONYM, CREATE SEQUENCE, CREATE TYPE, CREATE OPERATOR
TO User_Name ;
В примере выше разрешено подключаться, настраивать сессию, создавать объекты в БД
Создавать объекты разрешено только в схеме аккаунта
Отсутствуют права к схемам других аккаунтов
Пример предоставления табличного пространства USERS по умолчанию для учетной записи User_Name:
ALTER USER User_Name DEFAULT TABLESPACE USERS
Создание ролей, учетных записей, пароля, связь ролей и учетных записей
Предоставление привилегий
Синтаксис:
GRANT privilege ON [schema.]object TO username [WITH GRANT OPTION];
Информация о имеющихся привилегиях
Отмена, удаление привилегий, ролей, четных записей
Читайте также: