Раздел 18. Проектирование информационных систем

115. Архитектуры реализации корпоративных информационных систем на платформах Sun, Microsoft, Linux.

При построении корпоративных информационных сетей, как правило, используются две базовые архитектуры: Клиент-сервер и Интернет/Интранет

Выбирая платформу для АИС, нужно учитывать множество аспектов. На решение влияют соображения, связанные с надежностью (кластеризация и балансировка нагрузки), среды разработки, работы над содержанием узла и защиты информации.

Архитектура клиент-сервер

Клиент (Прикл.прогр ч.1, интерфейс выхова удаленных приложений, вызовы хранимых процедур, драйвер БД) <---> Сервер приложений (Прикл. прогр. ч2, Драйвер БД) <---> Сервер БД (прикл. прогр. ч3., БД

+ высокая степень защиты, большой выбор сред и я зыков программирования, большой опыт разработки, снижение нагрузки на сервер

- слежность раверстки, особенно на множество клиентов

Архитектура Internet-Intranet

Клиент (Браузер, JAVA) <---> Сервер (HTTP-сервер, веб страницы, сценарии, апплеты <--> сервер БД)

- сильная загрузка сервера, безопасность

+ удобство и быстрота разверртывания особенно для множества клиентов

1. Особенности функционирования АИС на платформе Sun.

Solaris - это современная операционная система UNIX клона. Примечательно, что она, опережая свое время, позволяет работать с 64-разрядными прикладными программами и имеет собственные расширения, которые помогают ей выдерживать высокие пользовательские нагрузки Web-узлов с интенсивным обменом информацией. В Solaris также предусмотрены замечательные возможности применения серверных прикладных программ и средств разработки сторонних производителей.

РИСУНОК 114-1 - Функциональная схема информационной системы на базе Solaris

Ключевой момент для понимания различий между платформами Linux, Microsoft и Sun - способ, которым серверные программы каждой из них обрабатывают большое число подключений. Обычно это делается в многопотоковом режиме. Многопотоковый режим возникает, когда прикладная программа (также называемая процессом) содержит множество небольших блоков исполняемого кода, работающих независимо друг от друга и, возможно, одновременно на разных процессорах. Эти потоки могут совместно пользоваться ресурсами и представляют собой способ организации программы, позволяющий одновременно выполнять несколько задач.

Модель потоков Solaris весьма сложна. Она состоит из потоков на уровне ядра (kthreads) - реальных объектов, передаваемых отдельному процессору; потоков на пользовательском уровне и промежуточной структуры, называемой облегченным (lightweight) процессом. Это позволяет тонко управлять структурой прикладной программы и реализации в ней прикладной многозадачности.

Stronghhold на платформе Solaris

Создатели Web-сервера Stronghold (и Apache, основы Stronghold) считают, что многопотоковые программы обычно менее надежны, чем "монолитные". Такое различие стратегий объясняет значительные расхождения показателей производительности, поскольку и Sun Web Server 2.1, и Netscape Enterprise используют второй процессор, установленный в испытательных системах. Поэтому Stronghold, в зависимости от прикладного ПО, не столь эффективно использует оборудование Sun, содержащее до 64 процессоров.

Netscape на платформе Solaris

Netscape Enterprise Server 3.61 - Web-сервер, избранный для реализации большинства крупных узлов на основе Solaris, в том числе и корпорации Sun. Инструментальные средства фирмы Netscape, а также предлагаемые независимыми производителями, способствуют разработке сложных прикладных программ для Web с помощью сценариев на языках JavaScript, CORBA, Java.

Еще одна важнейшая система, стоящая за добротными программами для Web на серверах Netscape, - сервер прикладных программ Netscape Application Server (NAS). Сервер NAS - среда программирования для объектов на языках C++ и Java - обеспечивает масштабируемость и устойчивость к сбоям прикладных программ. В NAS имеются инструменты для создания многоуровневых программ, объединяющих HTML и запросы к базам данных на серверах NAS.

Sun Web Server

Sun Web Server (SWS) обеспечивает разработку программ, конечно же, на языке Java. На SWS можно использовать сервлеты и разнообразные возможности, такие как CORBA. Сервлеты (servlet) - это Java-программы, запускаемые на сервере и, подобно CGI, передающие сверстанные HTML-страницы браузеру. Для сервлет существует собственный API к функциям рабочей среды сервера. В SWS также предусмотрена возможность использования серверных Java-страниц (Java Server Pages) - способа обращения к серверным функциям Java со страниц Web и из CGI-программ.

При соответствующем использовании Web-серверов на платформе Solaris, эта операционная система на многопроцессорных станциях превосходит по производительности Windows NT. Такого результата достигла Sun Microsystems благодаря использованию Solaris Network Cache and Accelerator (SNCA) - мощного механизма кэширования для Web-сервера. SWS победил в испытаниях при обслуживании статических страниц. При выполнении динамических CGI-испытаний Netscape на платформе Solaris превзошел и SWS, и IIS для Windows NT.

2. Особенности функционирования АИС на платформе Microsoft.

РИСУНОК 114-2. Функциональная схема информационной системы на платформе Windows NT.

Microsoft Windows NT Server

Windows NT 4 Server и Internet Information Server (IIS) являются исключительно коммерческой web-платформой, разработанной компанией Microsoft. Данная ОС имеет удобный интуитивно понятный интерфейс взаимодействия с пользователем, что делает её довольно привлекательной для использования. Windows NT 4 Server оснащена службой балансировки нагрузки (Windows NT Load Balancing Services), которая позволяет создавать группу серверов и распределять нагрузку между ними. Пользователи при этом видят только один IP-адрес и полагают, что существует только один сервер. Однако служба Load Balancing Services - это неполноценная кластерная система, поэтому она не способна обеспечить такое высокое быстродействие, как настоящий кластер. Windows NT не может работать с мощными аппаратными и программными средствами кластеров, в том числе с собственной службой Microsoft Cluster Service, продуктами серии Infinity компании IBM и продуктами NonStop производства Compaq. У Microsoft есть продукты всех этапов разработки для Web, однако обычно их заменяют изделиями других фирм. Пакет Allaire ColdFusion 4.0, как среда разработки для Web, - отличный пример этого.

Netscape Enterprise на платформе Windows NT

Netscape Enterprise в среде Windows NT представляет собой Web-сервер, ориентированный на большие нагрузки. Для него имеется множество моделей программирования. Например, помимо общепринятых моделей разработки HTML и CGI в продукте Netscape предусмотрены возможности работы с JavaScript на стороне сервера. Почти все функции сервера Netscape для Solaris работают и на платформе Windows NT.

При тестировании на производительность IIS показал неплохие результаты. Скорость при работе IIS достигнута за счет хорошо организованной обработкой файлового ввода-вывода. Дополняет обработку сообщений в Windows NT возможность асинхронного ввода-вывода, позволяющая обрабатывать запрос одновременно с выполнением операций ввода-вывода в файл или ЛВС. Подобная функция имеется в Solaris, но до сих пор не полностью реализована в Linux. По результатам теста IIS проигрывает SWW при обработке статических страниц, а Netscape Enterprise на платформе NT оказался менее производительным во всех режимах, чем на платформе Solaris.

3. Особенности функционирования АИС на основе Linux.

Рисунок 114-3 Функциональная схема информационной системы на платформе Linux.

Все больше растет популярность Linux и её респектабельность как платформы разработки для Web и корпоративных сред. Linux характеризуется рядом преимуществ, таких как широкое сообщество разработчиков открытого кода, поддержка многих моделей комплектующих, и, главная особенность состоит в том, что Linux полностью бесплатная ОС. Linux является разновидностью Unix и изначально создавалась для работы в сетях. В каждой новой версии Linux появляются некоторые усовершенствования, направленные на повышение масштабируемости и производительности серверных прикладных программ.

Apache и Stronghold

Для тестов в среде Linux был использован Stronghold Web Server 2.4.1 компании C2Net. Stronghold - это сервер с возможностями применения технологии SSL, в основе которого лежит Web-сервер Apache. Сервер Stronghold обладает всеми преимуществами Apache, в том числе мощными средствами обеспечения работы с виртуальными базовыми машинами (способность одного web-сервера обслуживать несколько машин одновременно).

Платформа Stronghold, подобно Linux, имеет заслуженную репутацию надежной и стабильной системы. Но Stronghold - и, следовательно, Apache - не оптимизированы для многопроцессорных сред. Поэтому Web-узлы, основанные на серверах Apache, лучше масштабировать путем добавления серверов, а не процессоров.

Напротив, IIS и Netscape Enterprise имеют многопотоковую архитектуру, которая масштабируется на несколько процессоров одного сервера. При испытаниях на многопроцессорных станциях они, как правило, обгоняли Stronghold.

Apache позволяет тонко настраивать ряд параметров (такие как число процессов, доступных клиентам). Для Apache, как и для других серверов, есть механизм работы сервлетам (Apache Jserv). Механизм работы с сервлетами встраивается в Apache в виде модуля и работает с любой совместимой с JDK 1.1 виртуальной Java-машиной. По производительности дуэт Apache-Linux оказался оптимальным для однопроцессорных систем. По обработке статических страниц он немного уступал SWW и IIS, а по стабильности работы превосходил серверы на платформеWindows NT.

Linux - это функциональность UNIX + пользовательско-ориентированный интерфейс Windows-систем. Большая часть поддерживаемого Linux оборудования - это то, что пользователи реально у себя имеют. Как в результате оказалось - большая часть популярной периферии для 80386/80486 поддерживается (действительно, Linux поддерживает оборудование, которое в ряде случаев не поддерживают некоторые коммерческие UNIX). Хотя некоторые достаточно экзотические устройства пока не поддерживаются.

Важным вопросом при создании АИС является обеспечение жизнестойкости и надежности работы информационных серверов. В качестве иллюстрации эффективности платформы приведем расчет параметров для сервера с 25000 посетителей в день. Подсчет загрузки: 24ч*60мин*60 сек=86400 секунд в сутках, если каждый посетитель берет с сервера по 10 документов (*.html + графика) то при равномерном распределении загрузки получается 3 обращения к серверу в секунду. Реальное распределение трафика носит характер кривой Гаусса либо синусоиды (в зависимости от содержания сервера), в максимумах которых загрузка достигает 10-20 обр/с. Для нормальной работы такому серверу необходимо около 400 Mb RAM, при хорошей настройке - не менее 200.

При правильной конфигурации сервера не рекомендуется использовать swap. все должно помещаться в оперативной памяти (имеется ввиду, что у сервера swap-область быть должна, но она обязана быть пустой). Для предотвращения перегрузок рекомендуется пользоваться несколькими правилами, снижающими загрузку сервера. Придерживаясь этих правил можно сэкономить около 30% ресурсов сервера.

Для статической информации всегда ставить last-modified в атрибут выдачу CGI-скриптов - документ без временного штампа не сохраняется в локальном кэше, и постоянно перезаписывается при просмотре.

CGI программы хранить в любом каталоге кроме /CGI-BIN/, т.к. proxy-серверы не кэшируют файлы, находящиеся в этих каталогах, и каждый раз вынуждены обращаться к вам на сервер.

Устанавливать поле last-modified у русского apache с автоматическим определением кодировки, чтобы на proxy-серверах не оставались файлы в некорректной кодировке.

Не применять авторедирект по чарсету в русском apache.

Не использовать фреймы, т.к. вместо одного файла появляется минимум 3.

Не использовать анимированные *.gif, т.к. некоторые NN обращаются к серверу перед каждым циклом.

404 код не делать cgi-скриптом, 404 код не делать "красивым" - с графическими изображениями и указаниями на прочие разделы, т.к. сошедший с ума робот собирает невероятное количество 404 ошибок, зацикливаясь в них на веки.

Создать на сервере файл robot.txt, т.к. это самый запрашиваемый документ на сервере, и иначе порождает массу 404 (см. п. 7). А также разумные роботы слушаются запретов в этом файле, что уменьшает нагрузку на сервер.

Не ставить баннеры наверху страницы, т.к. баннер сверху отнимает 1-2 реквеста из 4-х и в итоге грузится вперед тормозя ваши сайтовые картинки.

При вызове баннера не обращаться каждый раз к CGI, а подставлять вместо случайного числа любое число, что можно сделать, например, получив дату на JavaScript.

Вызывать баннеры программами на Си, т.к. Perl работает медленнее.

На одной машине должен размещаться только информационный сервер, не одновременно с почтой и др. сервисами.

На сегодня архитектура Internet/Intranet, в том числе и на платформе LINUX, уже используется при построении корпоративных ИС для решения задач автоматизации управления банками, управления проектированием, управления ТП, АСУ ТП, электронной коммерции, оперативной информации по курсу валют и акций и т.п.

116. Обработка ORACLE различных типов команд SQL и предложений PL/SQL, поддержание целостности данных, использование процедур и пакетов, использование триггеров базы данных, управление зависимостями между объектами схемы.

Обработка ORACLE различных типов команд SQL и предложений PL/SQL

• этапы исполнения каждого типа предложений SQL

• рекомендации по управлению транзакциями

• использование курсоров в предложениях SQL

• явное блокирование данных

• использование обработки массивов для улучшения производительности

• использование PL/SQL для улучшения производительности

Обработка предложений DML (UPDATE ЗАПРОСЫ)

Пример

EXEC SQL UPDATE emp SET sal = 1.10 * sal WHERE deptnp = :dept_number;

DEPT_NUMBER - это программная переменная, содержащая значение для номера отдела. При исполнении этого предложения SQL используется зна-чение переменной DEPT_NUMBER, поставляемое программой на языке C.

Этап 1: Создание курсора

Курсор создается через вызов программного интерфейса. Курсор создается независимо от конкретного предложения SQL; он создается в предвидении любого предложения SQL. В большинстве предложений создание курсора осуществляется автоматически. Однако в программах прекомпиляторов создание курсоров может осуществляться как неявно, так и явно, путем объявления курсора.

Этап 2: Разбор предложения

Во время разбора (PARSE) предложение SQL передается из пользовательского процесса в ORACLE, и разобранное представление этого предложения загружается в разделяемую область SQL. На этой фазе обработки предложения SQL может быть встречено много ошибок. Разбор - это процесс, который вы-полняет следующие действия:

• трансляцию предложения SQL и проверку его на законность

• обращения к словарю данных для проверки определений таблиц и столбцов

• получение блокировок разбора на требуемые объекты, с тем, чтобы их определения не были изменены во время разбора предложения

• проверку привилегий для доступа к адресуемым объектам схем

• определение плана исполнения, который будет применяться при исполнении предложения

• загрузку предложения в разделяемую область SQL

• для распределенных запросов - направление всего предложения или его частей на удаленные узлы, которые содержат адресуемые данные

Разбор предложения SQL выполняется только в том случае, если в разделяемом пуле не существует разделяемой области SQL, содержащей идентичное предложение SQL. В таком случае распределяется новая разделяемая область SQL, и предложение разбирается.

На фазе разбора выполняются те действия, которые необходимо выполнить лишь один раз, независимо от того, сколько раз будет исполняться это предложение. ORACLE транслирует каждое предложение SQL только один раз, а при последующих ссылках на это предложение повторяет исполнение ранее разобранного предложения.

Хотя при разборе предложения SQL выполняется проверка на ошибки, при этом идентифицируются лишь те ошибки, которые могут быть обнаружены ДО ИСПОЛНЕНИЯ ПРЕДЛОЖЕНИЯ. Таким образом, не все ошибки могут быть определены при разборе. Например, ошибки преобразования данных, ошиб-ки в данных (такие как попытки вставить повторяющиеся значения в первичный ключ), захваты, - все это такие ошибки или ситуации, которые могут быть встречены и распознаны лишь на фазе исполнения.

Обработка запросов

Запросы отличаются от других типов предложений SQL тем, что они возвращают данные как результат своего успешного исполнения. В то время как другие предложения возвращают просто признак успеха или неуспеха, запрос может вернуть одну строку или тысячи строк данных. Результаты запроса ВСЕ-ГДА ИМЕЮТ ТАБЛИЧНУЮ ФОРМУ, и строки этого результата ИЗВЛЕКАЮТСЯ (FETCH), либо по строке за раз, либо группами.

Этап 3: Описание результатов

Фаза описания (DESCRIBE) необходима только тогда, когда характеристики результатов запроса неизвестны, например, если запрос вводится интерак-тивно пользователем.

В этом случае фаза описания используется для определения характеристик (типов данных, длин и имен) результатов запроса.

Этап 4: Определение вывода

На фазе определения (DEFINE) для запросов вы специфицируете адреса, размеры и типы данных переменных, которые принимают каждое извлекае-мое значение. ORACLE выполняет преобразование типов данных, если необходимо.

Этап 5: Связывание переменных

К этому моменту ORACLE уже знает смысл предложения SQL, но еще не имеет достаточно информации для исполнения этого предложения. ORACLE нуждается в значениях всех переменных, участвующих в предложении; в нашем примере, ORACLE необходимо знать значение переменной DEPT_NUMBER.

Этот процесс называется СВЯЗЫВАНИЕМ ПЕРЕМЕННЫХ (BIND). Программа должна специфицировать местоположение (адрес в памяти), по кото-рому находится значение. Конечные пользователи приложений могут не догадываться о том, что они специфицируют связные переменные, потому что утили-та ORACLE может просто запрашивать у них очередное значение.

Поскольку вы указываете адрес (связывание по ссылке), вам не требуется повторять этап связывания перед повторным исполнением предложения. Вы можете просто изменять значение по этому адресу, а ORACLE находит это значение перед каждым исполнением, используя адрес памяти, предоставленный перед связыванием.

• Вы должны также специфицировать тип данных и длину каждого значения (если только они не выводятся и не подразумеваются по умол-чанию), на случай, если ORACLE должен выполнить преобразование типов данных.

Этап 6: Исполнение предложения

К этому моменту ORACLE имеет всю необходимую информацию и ресурсы, поэтому он исполняет предложение. Если это запрос или предложение INSERT, то никаких строк блокировать не требуется, потому что никакие данные не изменяются. Однако, если это предложение UPDATE или DELETE, то все строки, затрагиваемые данным предложением, блокируются от других пользователей базы данных до тех пор, пока не будет выдано очередное предложение COMMIT, ROLLBACK или SAVEPOINT в данной транзакции. Это гарантирует целостность данных.

Для некоторых предложений вы можете специфицировать число исполнений. Это называется ОБРАБОТКОЙ МАССИВА. При заданном числе испол-нений n, адреса входных (BIND) и выходных (DEFINE) переменных считаются адресами массивов размера n.

Этап 7: Извлечение строк результата запроса

На фазе извлечения (FETCH) строки выбираются и сортируются (если это запрошено запросом), и каждая очередная операция извлекает очередную строку результата, пока не будут извлечены все строки.

Поддрежание целостности данных

Использование ограничений целостности

Вы можете определять ограничения целостности для того, чтобы задействовать организационные правила по данным в ваших таблицах. Когда ограни-чение целостности включено, все данные в таблице должны подчиняться правилу, которое им специфицировано. Если вы после этого выдаете предложение SQL, которое модифицирует данные в этой таблице, то ORACLE проверяет, чтобы результирующие данные удовлетворяли ограничению целостности. Без ограничений целостности, такие правила должны были бы реализовываться программно в вашем приложении.

Реализация правил через ограничения целостности обходится дешевле, чем реализация эквивалентных правил путем выдачи предложений SQL в ва-шем приложении. Семантика ограничений целостности очень четко определена, так что внутренние операции, которые ORACLE выполняет для их реализа-ции, оптимизированы на более низком уровне, чем уровень предложений SQL.

Виды ограничений:

Использование процедур и пакетов

Установка умалчиваемых значений столбцов

Использование ограничений целостности UNIQUE

Использование ссылочных ограничений целостности

Выбор первичного ключа таблицы

Пустые значения и внешние ключи

Связи между родительскими и порожденными таблицами

Использование ограничений целостности CHECK

Ограничения на команду ALTER TABLE

Использование процедур и пакетов

Создание процедур и пакетов

Предварительные условия

Прежде чем вы сможете создавать процедуры или пакеты, ваш администратор базы данных, подключившись как SYS, должен запустить скрипт CATRPOC.SQL. Этот скрипт автоматически выполняет все скрипты, требуемые для процедурной опции. Местоположение этого скрипта зависит от операци-онной системы; обратитесь к вашему руководству по инсталляции.

Общие рекомендации по созданию процедур и пакетов

Напишите текст процедуры или пакета с помощью текстового редактора, и сохраните исходный код как текстовый файл. Затем введите в ORACLE оп-ределение этой процедуры или пакета, запустив этот файл как скрипт. Этот метод дает следующие удобства:

• Если в длинном определении процедуры или пакета встретится синтаксическая ошибка, вы сможете легко перезапустить соответствую-щий текстовый файл, после того как исправите ошибку.

• Если вам понадобится изменить определение процедуры или пакета, вы сможете отредактировать и вновь запустить соответствующий текстовый файл, чтобы заменить старую версию кода.

ORACLE сохраняет переданный ему исходный код процедуры или пакета в словаре данных. Этот исходный код можно извлечь с помощью одного из следующих обзоров словаря данных: ALL_SOURCE, USER_SOURCE или DBA_SOURCE. Примеры использования этих и других обзоров словаря данных приведены в секции «Вывод информации о процедурах и пакетах» на странице 7-23.

Создание независимых процедур и функций

Независимая хранимая процедура имеет две части:

СПЕЦИФИКАЦИЯ объявляет процедуру или функцию.

Спецификация состоит из следующей информации:

• имени процедуры

• имен и типов данных аргументов, если есть

Кроме этого, ТОЛЬКО для функций:

• типа данных возвращаемого значения

ТЕЛО определяет процедуру или функцию. Тело процедуры состоит из блока PL/SQL (который содержит предложения SQL и PL/SQL).

Обе части процедуры создаются в одном шаге с помощью команды CREATE PROCEDURE или CREATE FUNCTION.

Создание пакетов

Объявление пакета имеет две части:

СПЕЦИФИКАЦИЯ ПАКЕТА содержит объявления процедур пакета и функций, переменных, констант и исключений, которые доступны извне пакета.

ТЕЛО ПАКЕТА определяет процедуры и функции, курсоры и исключения, которые были объявлены в спецификации пакета. Тело пакета может также определять процедуры, функции, переменные, константы, курсоры и исключения, которые не были объявлены в спецификации пакета; однако эти объекты доступны лишь внутри сферы пакета.

Каждая часть пакета создается отдельной командой. Для создания спецификации пакета используйте команду CREATE PACKAGE. Для создания тела пакета используйте команду CREATE PACKAGE BODY.

Команда CREATE PACKAGE создает спецификацию пакета, содержащую объявления общих объектов этого пакета.

Привилегии, требуемые для создания процедур и пакетов

Чтобы создать независимую процедуру или функцию, либо спецификацию или тело пакета, вы должны удовлетворять следующим условиям:

• Вы должны иметь системную привилегию CREATE PROCEDURE для создания процедуры или пакета в вашей схеме, или системную привилегию CREATE ANY PROCEDURE для создания процедуры или пакета в схеме другого пользователя.

Создание такого объекта без ошибок, т.е. успешная компиляция процедуры или пакета, требует следующих дополнительных привилегий:

• ВЛАДЕЛЕЦ процедуры или пакета должен иметь явно назначенные объектные привилегии для всех объектов, адресуемых в теле проце-дуры или пакета; привилегий, полученных через роли, для этого недостаточно.

Замечание: Если привилегии владельца процедуры или пакета изменяются, процедура должна быть повторно аутентифицирована (подтверждена), прежде чем сможет быть выполнена. Если необходимая привилегия к адресуемому объекту отозвана от владельца процедуры (или пакета), то процедура не сможет выполняться.

Привилегия EXECUTE по процедуре дает пользователю право исполнять процедуру, принадлежащую другому пользователю. Привилегированные пользователи выполняют процедуру под доменом защиты владельца этой процедуры. Следовательно, такие пользователи никогда не обязаны иметь привиле-гии на объекты, адресуемые в процедуре. Это обстоятельство позволяет более упорядоченно и эффективно организовать стратегии защиты приложений и их применений. Более того, все процедуры и пакеты хранятся в словаре данных (т.е. в табличном пространстве SYSTEM). Никакие квоты не управляют количест-вом памяти, доступным пользователю, создающему процедуры и пакеты.

Вызов процедур

Процедуры можно вызывать из многих различных окружений.

Например:

• Процедура может быть вызвана из тела другой процедуры или из триггера.

• Процедура может быть вызвана пользователем интерактивно из инструмента ORACLE (такого как SQL*Plus).

• Процедура может быть вызвана явно из приложения (такого как приложение SQL*Forms или программа прекомпилятора).

Ниже приведены некоторые типичные примеры вызова процедур из этих окружений.

Вызов процедуры из другой процедуры или триггера

Процедура или триггер могут вызывать другую хранимую процедуру.

Замена процедур и пакетов

Невозможно явно изменить независимую процедуру или пакет; такой объект должен быть заменен новым определением процедуры или пакета. На-пример, если вы хотите слегка исправить одно из предложений в теле независимой процедуры, то нельзя просто изменить одно это предложение. Вместо этого вы должны заново создать всю процедуру. Если вы использовали текстовый редактор для написания своих процедур и пакетов, вы можете просто отредакти-ровать соответствующий текстовый файл и выполнить предложение CREATE PROCEDURE или CREATE PACKAGE BODY, чтобы определить новую версию кода. Аналогично, вы не можете переопределить отдельную процедуру внутри тела пакета; вы должны заменить тело пакета целиком.

Чтобы заменить процедуру или пакет, вы должны включить опцию OR REPLACE в соответствующее предложение CREATE PROCEDURE, CREATE FUNCTION, CREATE PACKAGE или CREATE PACKAGE BODY. Опция OR REPLACE введена для того, чтобы можно было заменять существующую проце-дуру или пакет новой версией, не затрагивая никаких грантов, которые были предоставлены для предыдущей версии этой процедуры или пакета.

Замечание: Альтернативно, процедуру можно удалить и создать заново. Однако при удалении процедуры будут удалены также все гранты, выданные на эту процедуру, так что их придется выдавать заново после повторного создания процедуры.

Например, предположим, что вы уже владеете процедурой SAL_RAISE или пакетом HIRE_FIRE. Если вы выдаете предложение CREATE PROCEDURE или CREATE PACKAGE BODY, чтобы создать новую версию этой процедуры или тела этого пакета, вы должны включить опцию OR RE-PLACE:

CREATE OR REPLACE PROCEDURE sal_raise . . . END;

CREATE OR REPLACE PACKAGE hire_fire . . . END hire_fire;

Если вы не включите опцию OR REPLACE, а процедура или пакет с таким же именем уже существует, то выдается ошибка, и существующая процеду-ра или пакет не изменяется.

Удаление независимых процедур и пакетов

Независимая процедура, независимая функция, тело пакета, или весь пакет могут быть удалены с помощью команд DROP PROCEDURE, DROP FUNCTION, DROP PACKAGE BODY и DROP PACKAGE, соответственно. Предложение DROP PACKAGE удаляет одновременно как спецификацию, так и тело пакета.

Следующее предложение удаляет процедуру OLD_SAL_RAISE в вашей схеме:

DROP PROCEDURE old_sal_raise;

Привилегии, требуемые для удаления процедур и пакетов

Чтобы удалить процедуру или пакет, вы должны иметь ее (его) в своей схеме, или иметь привилегию DROP ANY PROCEDURE. Нельзя удалить инди-видуальную процедуру внутри пакета; чтобы добиться этого, пересоздайте весь пакет, удалив из него ненужную процедуру.

Использование триггеров базы данных

Проектирование триггеров

Используйте следующие рекомендации при проектировании триггеров:

• Используйте триггеры для того, чтобы гарантировать, что при выполнении определенной операции будут выполнены связанные с ней действия.

• Используйте триггеры базы данных только для глобальных, централизованных операций, которые должны быть выполнены для соответ-ствующего предложения (предложения триггера), независимо от того, какой пользователь или приложение базы данных выдает это предложение.

• Не определяйте триггеров, дублирующих возможности, уже встроенные в ORACLE. Например, не определяйте триггеров для ввода в дей-ствие правил целостности данных, которые могут быть легко реализованы посредством декларативных ограничений целостности.

• [!] Будьте внимательны, чтобы не создавать рекурсивных триггеров. Например, создание такого триггера AFTER для предложения UPDATE по таблице EMP, который сам выдает предложение UPDATE по таблице EMP, приведет к рекурсивному возбуждению этого триггера вплоть до переполнения числа триггеров.

Так как триггер должен быть откомпилирован, когда он возбуждается впервые (а также при последующих возбуждениях, если он был вытеснен из сво-ей разделяемой области контекста), хорошей идеей является ограничение размера триггеров (приблизительно 60 строками). Компиляция триггеров меньшего размера не окажет существенного влияния на производительность системы. Если триггер должен исполняться многократно, предпочтительно включить код, исполняемый таким триггером, в хранимую процедуру (которая хранится в откомпилированной форме). В этом случае триггер будет вызывать откомпилиро-ванную хранимую процедуру, избегая затрат времени на компиляцию.

Создание триггеров

Триггеры создаются с помощью команды CREATE TRIGGER. Эту команду можно использовать в любом интерактивном инструменте (таком как SQL*Plus или SQL*DBA); при использовании в таких инструментах, одиночная наклонная черта («/»), вводимая как последняя строка, обозначает конец пред-ложения CREATE TRIGGER. Следующее предложение создает триггер, ассоциированный с таблицей EMP:

CREATE TRIGGER dummy

BEFORE DELETE OR INSERT OR UPDATE ON emp

FOR EACH ROW

WHEN (new.empno > 0)

DECLARE

/* переменные, константы, курсоры и т.п. */

BEGIN

/* блок PL/SQL */

END;

Предложение CREATE собъется, если в блоке PL/SQL будут обнаружены ошибки.

Последующие секции будут использовать этот пример, чтобы проиллюстрировать способы, которыми специфицируются различные части триггера.

Предварительные условия

Прежде чем создавать любые триггеры, вы должны выполнить скрипт CATPROC.SQL под учетным именем SYS. Этот скрипт автоматически запускает все скрипты, которые необходимы для процедурной опции или используются этой опцией. Местоположение этого файла зависит от операционной системы; обратитесь к вашему руководству по инсталляции.

Именование триггеров

Имена триггеров должны быть уникальными среди всех триггеров в той же схеме. Имена триггеров не обязаны быть уникальными по отношению к другим объектам схемы (таких как таблицы, обзоры, процедуры); например, таблица и триггер могут иметь одно и то же имя (хотя, во избежание путаницы, это не рекомендуется).

Опции BEFORE/AFTER

Либо опция BEFORE, либо опция AFTER должна быть указана в предложении CREATE TRIGGER, чтобы точно специфицировать, когда должно ис-полняться тело триггера по отношению к исполнению предложения триггера. В предложении CREATE TRIGGER опция BEFORE или AFTER задается непо-средственно перед ключевым словом, обозначающим предложение триггера. Например, триггер DUMMY, который был определен в предыдущем примере, является триггером BEFORE.

Триггеры строк AFTER несколько более эффективны, чем триггеры строк BEFORE. При триггерах строк BEFORE, затрагиваемые блоки данных долж-ны быть считаны (логической, а не физической, операцией чтения) один раз для триггера и еще один раз для предложения триггера. Альтернативно, при триг-герах строк AFTER, затрагиваемые блоки данных должны быть считаны лишь один раз, сразу для предложения триггера и для самого триггера.

Предложение триггера

Предложение триггера специфицирует:

• Тип предложения SQL, которое возбуждает тело триггера.

Допустимыми возможностями являются DELETE, INSERT и UPDATE. В спецификацию предложения триггера могут быть включены одна, две или все три этих опции.

• Таблицу, ассоциированную с триггером. Заметьте, что в предложении триггера может быть специфицирована ровно одна таблица (но не обзор).

Например, предложениями, возбуждающими триггер DUMMY, являются любые предложения DELETE, INSERT или UPDATE по таблице EMP. Лю-бое из следующих предложений возбудит триггер DUMMY, показанный в предыдущем примере:

DELETE FROM emp;

INSERT INTO emp VALUES ( . . . );

INSERT INTO emp SELECT . . . FROM

Привилегии, требуемые для создания триггеров

Чтобы создать триггер в своей схеме, вы должны иметь системную привилегию CREATE TRIGGER, а также одно из:

• владеть таблицей, специфицированной в предложении триггера, или

• иметь привилегию ALTER для таблицы, специфицированной в предложении триггера, или

• иметь системную привилегию ALTER ANY TABLE

Чтобы создать триггер в схеме другого пользователя, вы должны иметь системную привилегию CREATE ANY TRIGGER. Эта привилегия позволять создать триггер в любой схеме и ассоциировать его с таблицей любого пользователя.

Привилегии для объектов схем, адресуемых в теле триггера

Как и для хранимых процедур, владелец триггера должен иметь объектные привилегии для объектов, адресуемых в теде триггера, причем эти привиле-гии должны быть получены им явно (не через роли). Предложения в теле триггера оперируют под доменом защиты владельца триггера, а не того пользователя, который выдает предложение, возбуждающее триггер.

Отладка триггеров

Триггеры можно отлаживать с помощью тех же средств, которые применяются для отладки процедур и пакетов; см. секцию «Отладка процедур и паке-тов» на странице 7-15.

Изменение триггеров

Нельзя явно изменить триггер; его необходимо заменить новым определением триггера. Если вы используете текстовый редактор для создания ваших триггеров, вы можете просто отредактировать соответствующий текстовый файл и выполнить предложение CREATE TRIGGER, чтобы определить новую версию кода.

Заменяя триггер, вы должны включить в предложение CREATE TRIGGER опцию OR REPLACE. Опция OR REPLACE позволяет заменить сущест-вующий триггер новой версией, не затрагивая никаких грантов, которые были выданы для первоначальной версии этого триггера.

Альтернативно, триггер можно удалить и создать заново. Однако все гранты, которые были выданы для удаляемого триггера, также удаляются, и должны быть выданы заново после создания новой версии триггера.

Удаление триггеров

Для удаления триггера из базы данных используйте команду DROP TRIGGER. Например, чтобы удалить триггер с именем REORDER, введите сле-дующее предложение:

DROP TRIGGER reorder;

Привилегии, требуемые для удаления триггеров

Чтобы удалить триггер, вы должны иметь его в своей схеме, либо иметь системную привилегию DROP ANY TRIGGER.

Включение и выключение триггеров

Триггер может находиться в одном из двух различных режимов:

включен Включенный триггер выполняет свое тело, если выдано предложение триггера, и ограничение триггера (если есть) вычисляется как TRUE.

выключен Выключенный триггер не выполняет свое тело, даже если выдано предложение триггера, и ограничение триггера (ес-ли есть) вычисляется как TRUE.

Выключение триггеров

Вы можете временно выключить триггер, если имеет место одно из следующих условий:

• Объект, к которому обращается триггер, недоступен.

• Вы должны выполнить массовую загрузку данных, и хотите осуществить ее быстро, не возбуждая триггеров.

• Вы загружаете данные в таблицу, к которой применяется триггер.

По умолчанию, триггер включается в момент его создания. Чтобы отключить триггер, используйте команду ALTER TRIGGER с опцией DISABLE. На-пример, следующее предложение отключает триггер REORDER по таблице INVENTORY:

ALTER TRIGGER reorder DISABLE;

Вы можете одновременно отключить все триггеры, ассоциированные с таблицей, с помощью команды ALTER TABLE с опциями DISABLE и ALL TRIGGERS. Например, следующее предложение отключает все триггеры, определенные для таблицы INVENTORY:

ALTER TABLE inventory

DISABLE ALL TRIGGERS;

Включение триггеров

По умолчанию, триггер автоматически включается в момент его создания; однако позже он может быть выключен. Закончив задачу, для которой по-требовалось выключать триггер, вы можете снова включить его.

Чтобы включить триггер, используйте команду ALTER TRIGGER с опцией ENABLE. Например, следующее предложение включает триггер REORDER по таблице INVENTORY:

ALTER TRIGGER reorder ENABLE;

Вы можете одновременно включить все триггеры, ассоциированные с таблицей, с помощью команды ALTER TABLE с опциями ENABLE и ALL TRIGGERS. Например, следующее предложение включает все триггеры, определенные для таблицы INVENTORY:

ALTER TABLE inventory

ENABLE ALL TRIGGERS;

Привилегии, требуемые для включения и выключения триггеров

Для включения и выключения триггеров с помощью команды ALTER TABLE, вы должны либо владеть таблицей, либо иметь объектную привилегию ALTER TABLE для таблицы или системную привилегию ALTER ANY TABLE. Для включения или выключения индивидуального триггера с помощью коман-ды ALTER TRIGGER, вы должны либо владеть триггером, либо иметь системную привилегию ALTER ANY TRIGGER.

Примеры применения триггеров

Вы можете использовать триггеры разнообразными способами, чтобы привязать к своим нуждам управление данными в базе данных ORACLE. На-пример, триггеры обычно используются для:

• изощренного аудитинга

• предотвращения незаконных транзакций

• обеспечения ссылочной целостности между узлами в распределенной базе данных

• реализации сложных организационных правил

• ввода в действие комплексных правил защиты

• прозрачной регистрации событий

• автоматической генерации значений вычисляемых столбцов

• поддержания синхронных дублирований таблиц

Управление зависимостями между объектами схемы

Вопросы зависимостей

Когда вы создаете хранимую процедуру или пакет, ORACLE проверяет, что операции, которые выполняет эта процедура или пакет, возможны с точ-ки зрения доступа к адресуемым объектам. Например, если хранимая процедура содержит предложение SELECT, выбирающее столбцы из таблицы, то ORACLE проверяет, что эта таблица существует и содержит указанные столбцы. Если таблица впоследствии переопределяется так, что один из ее столбцов перестает существовать, то хранимая процедура может перестать правильно работать. По этой причине хранимая процедура называется ЗАВИСИМОЙ от данной таблицы.

В случаях, подобных этому, ORACLE автоматически управляет зависимостями между объектами схемы. После того, как объект схемы будет пере-определен, ORACLE автоматически перекомпилирует любую хранимую процедуру и функцию в вашей базе данных, зависящую от переопределенного объек-та, при очередном вызове этой процедуры или функции. Эта перекомпиляция позволяет ORACLE проверить, что процедуры и функции могут по-прежнему исполняться правильно на переопределенном объекте.

Устранение перекомпиляции во время выполнения

Избегайте перекомпиляции хранимых процедур, функций и пакетов во время выполнения ваших приложений. Такая перекомпиляция не только ухудшает производительность; хуже того, результирующие ошибки компиляции могут помешать использованию ваших приложений. Чтобы избежать пере-компиляций времени выполнения, соблюдайте следующие правила:

• Не переопределяйте объектов схемы (таких как таблицы, обзоры, хранимые процедуры и функции) в то время, когда работают ваши про-изводственные приложения. Переопределение объектов заставляет ORACLE перекомпилировать хранимые процедуры и функции, зависящие от этих объектов.

• Переопределив объект схемы, вручную перекомпилируйте все зависимые процедуры, функции и пакеты. Эта мера не только устранит фактор снижения производительности во время выполнения, но и немедленно уведомит вас об ошибках компиляции и позволит вам заблаговременно ис-править их.

Вы можете внучную перекомпилировать процедуру, хранимую функцию или пакет с помощью опции COMPILE команды ALTER PROCEDURE, ALTER FUNCTION или ALTER PACKAGE. Для дополнительной информации об этих командах обратитесь к документу ORACLE7 Server SQL Language Reference Manual.

Вы можете определить зависимости между объектами схем в вашей базе данных, запустив скрипт UTLDTREE.SQL. Точное имя и местополо-жение этого скрипта может зависеть от вашей операционной системы. Дополнительная информация о том, как использовать этот скрипт, приведена в тексте самого скрипта.

• Пакетируйте процедуры и функции, когда это возможно.

Если процедура или функция размещена в пакете, вы можете модифицировать ее определение, не заставляя ORACLE перекомпилировать дру-гие процедуры и функции, которые вызывают ее.

Есть несколько вопросов, касающихся зависимостей, которые должны рассматриваться перед тем, как удалять процедуру или пакет. Дополнитель-ная информация об этих вопросах содержится в документе ORACLE7 Server Concepts Manual. Ниже приведены некоторые рекомендации по управлению зави-симостями.

СТАРАЙТЕСЬ ИСПОЛЬЗОВАТЬ ПАКЕТЫ. Пакеты дают наиболее эффективный метод предотвращения излишних проверок зависимостей. Сле-дующий пример иллюстрирует преимущества пакетов.

Предположим следующую ситуацию:

• Независимая процедура PROC зависит от пакетированной процедуры PACK_PROC.

• Определение процедуры PACK_PROC изменяется, и тело пакета перекомпилируется.

• Спецификация процедуры PACK_PROC в спецификации пакета не изменяется.

Несмотря на то, что тело пакета перекомпилировано, независимая процедура PROC, зависимая от пакетированной процедуры PACK_PROC, не ста-новится недействительной и не требует перекомпиляции, потому что спецификация процедуры PACK_PROC не изменилась.

Эта техника особенно полезна в распределенных окружениях. Если процедуры всегда являются частями пакетов, то удаленные процедуры, которые зависят от локальных пакетированных процедур, никогда не становятся недействительными, пока спецификация пакета не заменяется или не становится не-действительной.

Каждый раз, когда вы перекомпилируете процедуру, вы должны проконсультироваться с администраторами других баз данных и разработчиками приложений, чтобы идентифицировать все удаленные зависимые процедуры и обеспечить их перекомпиляцию. Это позволит избежать перекомпиляций во время выполнения и выявит любые возможные ошибки компиляции, которые в ином случае были бы выданы пользователю приложения; для дополнительной информации обратитесь к секции «Ручная перекомпиляция недействительных обзоров, процедур, пакетов и триггеров» на странице 9-4.

АТРИБУТЫ %TYPE И %ROWTYPE. Атрибут %TYPE предоставляет тип данных переменной, константы или столбца. Этот атрибут особенно поле-зен при объявлении переменной или аргумента процедуры с типом данных, зависящим от определения столбца в таблице базы данных. Атрибут %ROWTYPE полезен, когда вы хотите объявить переменную-запись, которая должна иметь такую же же структуру, что и строка в таблице или обзоре, или строка, возвра-щаемая извлечением из курсора.

Объявление конструктов через атрибуты %TYPE И %ROWTYPE имеет следующие достоинства и недостатки.

• Вы не обязаны знать тип данных столбца или структуру таблицы. Например, список аргументов процедуры, которая вставляет строку в таблицу EMP, мог бы быть объявлен следующим образом:

CREATE PROCEDURE hire_fire(emp_record emp%ROWTYPE) AS ...

Если вы измените типы столбцов или структуру таблицы, то конструкты, определенные по этим типам или по структуре, автоматически изме-нятся соответствующим образом.

• Когда вы определяете конструкт через ОБЪЕКТ%TYPE или ОБЪЕКТ%ROWTYPE, этот конструкт становится зависимым от ОБЪЕКТА. Если ОБЪЕКТ изменяется, все зависимые от него конструкты становятся недействительными.

Коротко говоря, атрибуты %TYPE и %ROWTYPE позволяют устранить один тип зависимости, но создают другой.

Ручная перекомпиляция недействительных обзоров, процедур, пакетов и триггеров

ORACLE динамически (автоматически) перекомпилирует недействительный обзор или программную единицу PL/SQL при очередном обращении. Альтернативно, вы можете заставить ORACLE перекомпилировать обзор иди программную единицу, используя подходящую команду SQL с параметром COMPILE.

Принудительная (форсированная) перекомпиляция чаще всего используется для того, чтобы проверить на ошибки, когда известно, что зависимый объект недействителен, но он временно не используется; в таком случае для автоматической перекомпиляции пришлось бы дожидаться очередного обращения к объекту.

Чтобы идентифицировать недействительные зависимые объекты, опросите обзоры USER_/ALL_/DBA_OBJECTS.

Ручная перекомпиляция обзоров

Чтобы перекомпилировать обзор, используйте команду ALTER VIEW с параметром COMPILE. Например, следующее предложение перекомпилиру-ет обзор EMP_DEPT, содержащийся в вашей схеме: ALTER VIEW emp_dept COMPILE;

Привилегии, требуемые для ручной перекомпиляции обзоров

Для ручной перекомпиляции обзора вы должны либо иметь его в своей схеме, либо иметь системную привилегию ALTER ANY TABLE.

Ручная перекомпиляция процедур и функций

Чтобы перекомпилировать независимую процедуру или функцию, используйте команду ALTER PROCEDURE/FUNCTION с параметром COMPILE. Например, следующее предложение перекомпилирует хранимую процедуру UPDATE_SALARY, содержащуюся в вашей схеме:

ALTER PROCEDURE update_salary COMPILE;

Ручная перекомпиляция пакетов

Чтобы перекомпилировать тело пакета или тело вместе со спецификацией пакета, используйте команду ALTER PACKAGE с параметром COMPILE. Например, следующие предложения перекомпилируют только тело и тело со спецификацией пакета ACCT_MGMT_PACKAGE, соответственно:

ALTER PACKAGE acct_mgmt_package COMPILE BODY;

ALTER PACKAGE acct_mgmt_package COMPILE PACKAGE;

Следующий синтаксис позволяет выполнить перекомпиляцию всех пакетов, процедур и функций. Объекты при этом перекомпилируются в порядке зависимости, что позволяет перекомпилировать каждый из них лишь один раз.

EXECUTE DBMS_UTILITY.COMPILE_ALL;

Привилегии, требуемые для ручной перекомпиляции процедур или пакетов

Для ручной перекомпиляции независимой процедуры или пакета вы должны либо иметь ее (его) в своей схеме, либо обладать системной привилеги-ей ALTER ANY PROCEDURE.

Ручная перекомпиляция триггеров

Чтобы перекомпилировать существующий триггер, независимо от того, включен от или выключен, используйте команду ALTER TRIGGER с пара-метром COMPILE. Например, следующее предложение форсирует компиляцию триггера с именем REORDER:

ALTER TRIGGER reorder COMPILE;

Привилегии, требуемые для ручной перекомпиляции триггеров

Для ручной перекомпиляции триггера вы должны либо иметь его в своей схеме, либо обладать системной привилегией ALTER ANY TRIGGER.

Вывод информации управления зависимостями

Следующие обзоры словаря данных выдают информацию о прямых зависимостях и об управлении зависимостями:

• USER_ \ ALL_ \ DBA_DEPENDENCIES

• USER_ \ ALL_ \ DBA_OBJECTS

Замечание: Для полного описания этих обзоров словаря данных обратитесь к приложению D.

Приведенные ниже примеры предполагают, что в базе данных были выданы следующие предложения:

CREATE TABLE emp . . . ;

CREATE PROCEDURE hire_emp BEGIN . . . END;

ALTER TABLE emp . . . ;

117. Политика защиты приложений: роли и управление привилегиями приложений, включение ролей приложений, управление привилегиями и ролями, создание, включение, выключение и удаление ролей, назначение и отзыв привилегий и ролей.

Политику защиты необходимо разрабатывать для каждого приложения.

Роли и управление привилегиями приложений. Чтобы упростить управление привилегиями приложений, для каждого приложения необходимо создать роль и назначить ей все привилегии, требуемые для выполнения приложения.

Группирование привилегий приложения в одну роль облегчает управление привилегиями. Возможности:

• можно назначать пользователям, работающим с приложением, одну роль, а не множество индивидуальных привилегий;

• Если нужно изменить привилегии, ассоциированные с приложением, это необходимо сделать лишь с привилегиями, назначенными одной роли, а не с привилегиями, которые были назначены всем пользователям этого приложения;

• можно определить, какие привилегии необходимы для выполнения конкретного приложения, опросив обзоры словаря данных;

• можно определить, какие пользователи имеют привилегии для тех или иных приложений, опросив обзор словаря данных.

Включение ролей приложений. Каждый пользователь может использовать много приложений и ассоциированных ролей. Необходимо разрешать пользователю лишь те привилегии, которые ассоциированы с ролью текущего (с которым работает) приложения.

Инструменты разовых запросов, такие как SQL*Plus, позволяют пользователю запустить любое предложение SQL, в том числе, включить или выключить любую роль, назначенную этому пользователю. Это может создать серьезную проблему защиты; если не принять необходимых мер предосторожности, пользователь какого-нибудь приложения может преднамеренно или непреднамеренно выполнить операции SQL, разрушительные для таблиц базы данных, используя в инструменте разовых запросов те привилегии, которые он получил через роль приложения. Чтобы избежать потенциальных проблем такого типа, используют следующие политики для ролей приложений:

1. Каждое приложение должно иметь несколько различных ролей:

• Одна роль должна содержать все привилегии, необходимые для успешной работы приложения;

• Другая роль должна содержать только неразрушающие привилегии, ассоциированные с приложением.

2. При своем запуске каждое приложение должно выдавать команду, включающую одну из ролей, ассоциированных с этим приложением.

3. При завершении работы, каждое приложение должно выключать ранее включенную роль приложения.

4. Пользователям приложения должны быть назначены все необходимые роли этого приложения. Администратор может запретить пользователю использовать данные приложения с инструментами разовых запросов, не назначая этому пользователю даже неразрушающей роли приложения.

Каждое имя пользователя в базе данных считается схемой – доменом защиты, который может содержать объекты схемы. Доступ к базе данных и ее объектам контролируется привилегиями, назначенными каждой схеме. Большинство схем можно рассматривать как имена пользователей, т.е. учетные имена, которые позволяют пользователям соединяться с базой данных и обращаться к объектам в базе данных.

Управление привилегиями и ролями. Необходимо определить какие типы пользователей будут работать с приложением, и какой уровень доступа должен быть позволен этим пользователям для выполнения их задач. Пользователей распределяют по ролевым группам, а затем определяют привилегии, которые должны быть назначены каждой роли приложения. Обычно через роль приложения конечным пользователям назначаются объектные привилегии. Объектная привилегия позволяет пользователю выполнять определенное действие на конкретной таблице, обзоре, последовательности, процедуре, функции или пакете. В зависимости от типа объекта, существуют различные типы объектных привилегий.

Создание роли. Использование роли может быть защищено ассоциированным паролем. Если роль создана без защиты, то она может быть включена или выключена любым пользователем, которому она назначена. В приложениях базы данных обычно используют средства авторизации. Создаваемая роль должна иметь уникальное имя среди существующих имен пользователей и других ролей в базе данных. Роли не содержатся в схемах пользователей. После создания роль не имеет никаких привилегий, ассоциированных с ней. Чтобы ассоциировать привилегии с новой ролью, ей нужно назначить привилегии или другие роли.

Включение и выключение ролей. Для того, чтобы привилегии, ассоциированные с ролью, стали доступными в текущей сессии пользователя, эта роль должна быть включена. В каждый момент времени могут быть включены некоторые, все или ни одной из ролей, назначенных пользователю. Включение ролей никогда не затрагивает тех привилегий, которые были назначены пользователю явно. Умалчиваемая роль - это роль, которая автоматически включается для пользователя, когда он создает сессию. Список умалчиваемых ролей пользователя должен включать те роли, которые соответствуют его типичным служебным обязанностям. Пользователь (или приложение) может явно включить роль с помощью команды SQL SET ROLE.

Удаление ролей. Если удалить роль, то домены защиты всех пользователей и ролей, которым была назначена удаляемая роль, немедленно отразят отсутствие привилегий этой роли. Все роли, косвенно назначавшиеся через удаленную роль, также будут удалены из затрагиваемых доменов защиты. Удаление роли автоматически удаляет ее из списков умалчиваемых ролей всех пользователей.

Назначение и отзыв привилегий и ролей. Для назначения системных привилегий и ролей другим ролям и пользователям команда SQL GRANT. Объектные привилегии могут назначаться ролям и пользователям с помощью команды SQL GRANT. Для отзыва системных привилегий и ролей команда SQL REVOKE. Объектные привилегии можно отзывать с помощью команды SQL REVOKE.