Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Название:Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Автор:
- Жанр:
- Издательство:БХВ-Петербург
- Год:2006
- Город:Санкт-Петербург
- ISBN:5-94157-609-9
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ краткое содержание
Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.
Для разработчиков баз данных
Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
* Когда не используются полномочия на уровне столбца, создается только одно разрешение. Нет способа удалить права к одним столбцам и сохранить для других. Нужно будет отменить разрешения, содержащие права, которые вы хотите отменить, и добавить новые с исправленными правами.
Спасибо правилам привилегий SQL - "самая забавная штука от Marx Brothers", по словам коллеги - можно предоставлять как на уровне столбца, так и на уровне таблицы привилегии UPDATE и REFERENCES одному и тому же пользователю. Это может привести к путанице, если права пользователя на уровне столбца UPDATE или REFERENCES отменяются, а те же полномочия пользователя на уровне таблицы сохраняются.
Просмотры предоставляют элегантный способ ограничения доступа к таблицам, ограничивая столбцы и/или строки, которые видимы пользователю, позволяя при этом выполнить любые настройки. Эта тема обсуждалась в главе 24.
Права REFERENCES к столбцам
Привилегия REFERENCES является необходимым дополнением при предоставлении полномочий к таблице, у которой есть внешний ключ. Она нужна, если пользователь, создающий внешний ключ в таблице, не владеет таблицей, на которую ссылается этот ключ.
REFERENCES предоставляет полномочия к столбцам. Должны быть включены все столбцы, на которые ссылается внешний ключ таблицы, к которой предоставляются права. Если оператор GRANT REFERENCES ссылается на таблицу без указания столбцов, то полномочия предоставляются к каждому столбцу. Столбцы, которые не указаны в связи между внешним ключом и первичным ключом главной таблицы, не включаются в привилегию.
Вы можете задать только ключевые столбцы и, возможно, сохранить некоторую избыточность, если первичная таблица содержит очень много столбцов. Если вы сделаете так, вы должны задать все связанные ключевые столбцы. Упрощенный синтаксис выглядит так:
GRANT REFERENCES
ON <���первичная-таблица> [ (<���ключевой-столбец>
[, <���ключевой-столбец> [, . . . ] ] ) ]
ТО <���пользователь>
[WITH GRANT OPTION] ;
Следующий пример предоставляет привилегии REFERENCES К таблице DEPARTMENTS пользователю CHALKY, позволяя CHALKY записывать внешний ключ, который ссылается на первичный ключ таблицы DEPARTMENTS, даже если он не владеет этой таблицей:
GRANT REFERENCES ON DEPARTMENTS (DEPT_NO) TO CHALKY;
! ! !
СОВЕТ. Если видимость ключей не является проблемой, предоставьте привилегии REFERENCES для PUBLIC
. ! .
Привилегии к объектам
Когда для триггера, хранимой процедуры или просмотра нужен доступ к таблице или просмотру, достаточно, чтобы владелец объекта, к которому требуется доступ, сам объект или пользователь, использующий триггер, процедуру или просмотр, имел необходимые полномочия.
С другой стороны, привилегии к таблице могут быть предоставлены процедуре, а не индивидуальным пользователям для повышения безопасности. Пользователю нужна только привилегия EXECUTE к процедуре, которая осуществляет доступ к таблице.
Хранимой процедуре, просмотру или триггеру иногда нужны привилегии для доступа к таблице или просмотру, которые имеют другого владельца. Для предоставления привилегий триггеру или хранимой процедуре включите соответствующее ключевое слово TRIGGER или PROCEDURE перед именем модуля.
В следующем примере процедуре COUNT_CHICKENS предоставляются полномочия INSERT к таблице PROJ_DEPT_BUDGET:
GRANTINSERTON PROJ_DEPT_BUDGETTO PROCEDURE COUNT_CHICKENS;
Для использования хранимой процедуры пользователям, триггерам или другим хранимым процедурам нужна к ней привилегия EXECUTE. ЕСЛИ просмотр выбирает выходные поля из хранимой процедуры выбора, просмотр должен иметь привилегию
EXECUTE, а не привилегию SELECT.
Упрощенный синтаксис выглядит следующим образом:
GRANT EXECUTE
ON PROCEDURE <���имя-процедуры> TO <���получатель>;
<���получатель> = [ PROCEDURE <���имя-процедуры> [, <���имя-процедуры> [, ..]]] [ TRIGGER <���имя-триггера> [, <���имя-триггера> [, ...]]] [ VIEW <���имя-просмотра> [, <���имя-просмотра> [, ...]]] | <���имя-роли> | <���пользователь-или-список> | PUBLIC [WITH GRANT OPTION];
Хранимой процедуре или триггеру нужна привилегия EXECUTE К хранимой процедуре, если она имеет другого владельца. Помните, что владельцем триггера является пользователь, создавший таблицу.
Если ваш оператор GRANT EXECUTE предоставляет привилегии для PUBLIC, то никакие другие типы получателей привилегий не могут быть представлены в качестве аргументов то.
В следующем примере оператор GRANT EXECUTE предоставляет привилегию к процедуре CALCULATE_BEANS двум обычным пользователям FLAT FOOT и KILROY и Двум Хранимым процедурам, чьи владельцы не являются владельцами CALCULATE_BEANS:
GRANT EXECUTE ON PROCEDURE CALCULATE_BEANS
TO FLATFOOT,
KILROY,
PROCEDURE DO_STUFF, ABANDON_OLD ;
Привилегии к просмотрам являются довольно запутанными. Владелец просмотра должен предоставить пользователям привилегию SELECT, как это сделал бы владелец таблицы. Сложности начинаются, если просмотр является изменяемым - естественным образом или через триггеры просмотра- или если просмотр включает другие просмотры или хранимые процедуры выбора. Изменения данных изменяемого просмотра фактически выполняют изменения в базовых таблицах. Если владельцы базовых объектов еще не предоставили пользователю соответствующих прав (INSERT, UPDATE, DELETE, EXECUTE) к базовым таблицам и объектам, а также к хранимым процедурам выбора или к просмотрам, то пользователю нужно их получить от владельца просмотра.
Привилегии REFERENCES неприменимы к просмотрам за исключением одной (обычно опускаемой) ситуации. Если просмотр использует таблицу, которая имеет внешние ключи, ссылающиеся на другие таблицы, то просмотру нужны привилегии REFERENCES к этим другим таблицам, если эти таблицы сами не используются в данном просмотре.
Подробности см. в разд. "Привилегии" главы 24.
Множество привилегий и множество получателей привилегий
Есть возможность предоставлять несколько привилегий в одном операторе и предоставлять одну или более привилегий множеству пользователей или объектов.
Для предоставления получателю нескольких привилегий к таблице перечислите предоставляемые привилегии в списке, отделяя друг от друга запятыми. Следующий оператор назначает полномочия INSERT и UPDATE К таблице DEPARTMENT пользователю
CHALKY:
GRANT INSERT, UPDATE ON DEPARTMENT TO CHALKY;
Список привилегий может быть любой комбинацией в любом порядке привилегий
SELECT, INSERT, UPDATE, DELETE и REFERENCES. Привилегия EXECUTE должна назначаться в отдельном операторе.
Привилегия REFERENCES не может быть назначена просмотру.
Привилегия ALL объединяет привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES В одном пакете. Например, следующий оператор предоставляет CHALKY полный пакет полномочий к таблице DEPARTMENT:
Читать дальшеИнтервал:
Закладка: