Сравнение режимов именования System Naming и SQL Naming: Часть 1

Полномочия и привилегии для SQL-объектов базы данных

При исполнении SQL-приложений вы можете запускать их с использованием различных соглашений о назначении имен – System Naming или SQL Naming. Режим именования System Naming соответствует традиционным методам, применяющимся в системах IBM i, таким как поддержка библиотек. С другой стороны, режим именования SQL Naming определен в стандарте на SQL и используется всеми остальными базами данных. На вопрос о различиях между режимами SQL Naming и System Naming обычно отвечают, что схема и объект разделяются или косой чертой, или пробелом. Однако в использовании режимов SQL Naming и System Naming имеется также множество других различий, особенно в отношении полномочий доступа и владения объектами базы данных. В данной статье особенности SQL Naming и System Naming описываются главным образом с точки зрения различий с этих двух соглашений об именовании в полномочиях владения и доступа при создании объектов базы данных DB2 (таблиц, хранимых процедур и триггеров).

Бригитта Хаузер, инженер по программному обеспечению, Toolmaker Advanced Efficiency GmbH

Birgitta Hauser photoБиргитта Хаузер (Birgitta Hauser) является инженером по программному обеспечению с 2008 года. В настоящее время она работает в компании Toolmaker Advanced Efficiency GmbH (Германия), где специализируется в таких областях, как RPG, SQL и веб-разработка для платформы IBM i. Б. Хаузер получила диплом по экономике и с 1992 года занимается программированием для платформы AS/400. Кроме того, она оказывает консалтинговые и образовательные услуги разработчикам на языках SQL и RPG. С 2002 года Б. Хаузер часто выступает в пользовательских группах COMMON в Германии, Швейцарии и США. И, наконец, Б. Хаузер является соавтором двух пособий серии IBM Redbooks, а также автором нескольких статей и обзоров по RPG и SQL для немецких журналов.



05.12.2012

Соглашения об именовании при создании объектов базы данных

При создании объектов базы данных разработчик может выбрать метод именования, который соответствует традиционному поведению IBM i, т.е., режим именования System Naming (*SYS), или правилам стандарта SQL, т.е., режим именования SQL Naming (*SQL).

Основное различие между DB2 for i и другими системами управления базами данных (СУБД) состоит в том, что СУБД DB2 for i интегрирована в операционную систему. Такая интеграция позволяет любому пользователю IBM i непосредственно обращаться к базам данных DB2 for i с использованием своего профиля пользователя операционной системы и с ассоциированными с этим профилем полномочиями доступа. Другие базы данных не интегрированы в операционную систему, поэтому необходимо задавать конкретных пользователей базы данных с индивидуальными полномочиями доступа.

Именование по умолчанию, используемое для создания объектов базы данных с помощью SQL, зависит от среды, в которой выполняются команды на языке SQL DDL (Data Definition Language).

Режим именования System Naming используется по умолчанию для всех серверных SQL-сред, таких как STRSQL (Start SQL Interactive Session) и RUNSQLSTM (Run SQL Statements), а также для встроенного SQL в программах на языках высокого уровня, таких как RPG или COBOL.

Режим именования SQL Naming по умолчанию используется в клиентских SQL-средах, таких как System i Navigator, IBM Rational Developer for Power Systems Software (RDp), в программном обеспечении связующего уровня (ODBC, JDBC и т.д.), а также в сторонних SQL-инструментах.

Чтобы избежать несоответствия в полномочиях и методах доступа к объектам, необходимо решить, использование какого режима именования (System Naming или SQL Naming) будет наилучшим образом работать в вашей среде приложений. Возможно, в некоторых средах вам придется изменить режим именования по умолчанию, — чтобы обеспечить соответствие с соглашением о назначении имен, которые вы используете в своей среде приложений.

Интерфейс продукта System i Navigator

Если вы захотите использовать интерфейс продукта System i Navigator при создании своих объектов базы данных, вы сможете следующим образом заранее задать режим именования для последующего использования.

Откройте свое соединение, дважды щелкните на пиктограмме Database и выберите задачу Preferences, как показано на рисунке 1. System i Navigator – настройка опции Preferences.

Окно Preferences предлагает следующие три опции. Опция Connection (all Systems) позволяет Вам заранее задать соглашение о назначении имен, которое будет использоваться для будущих соединений. Эта настройка также будет использоваться в качестве режима именования по умолчанию для будущего исполнения операторов Run SQL Scripts and Generate SQL, но НЕ будет влиять ни на какие существующие окна.

Рисунок 1. System i Navigator – настройка опции Preferences
System i Navigator – настройка опции Preferences

Инструмент Run SQL Scripts Tool продукта System i Navigator

Если вы желаете применить инструмент Run SQL Scripts Tool для исполнения SQL-скрипта, хранящегося в файле или введенного в интерактивном режиме, то для управления соглашением о назначении имен щелкните по ниспадающему меню Connection и выберите задачу JDBC Setup. Соглашение о назначении имен можно задать на вкладке Format.

Рисунок 2. System i Navigator – инструмент Run SQL Scripts – настройка соглашений о назначении имен
System i Navigator – инструмент Run SQL Scripts – настройка соглашений о назначении имен

Команда RUNSQLSTM (Run SQL Statements)

Если вы хотите выполнить SQL-операторы, хранящиеся в исходном физическом файле или в IFS-файле (Integrated File System), посредством команды RUNSQLSTM (Run SQL Statements), то соглашение о назначении имен для команды RUNSQLSTM можно указать с помощью параметра Naming, как показано в следующем примере. Выбранный SQL-скрипт будет выполняться с использованием SQL Naming.

Листинг 1. Настройка режима именования с помощью команды RUNSQLSTM
RUNSQLSTM SRCFILE(MYSCHEMA/QSQLSRC)   
          SRCMBR(MYSCRIPT)            
          NAMING(*SQL)   

Встроенный SQL в программе на языке высокого уровня

Если вы решите использовать в программе на языке высокого уровня (таком как RPG или COBOL) встроенный SQL для обработки данных в своих таблицах или для создания новых объектов базы данных, то по умолчанию будет использоваться режим именования System Naming.

Если вы захотите использовать режим SQL Naming, вы можете заранее задать соглашение о назначении имен в команде компиляции (CRTSQLRPGI, CRTSQLCBL1 или CRTSQLCI – в зависимости от языка программирования), как показано в следующем примере:

Листинг 2. Создание программы на встроенном SQL, использующей SQL Naming
CRTSQLRPGI OBJ(MYPGMLIB/MYSQLPGM)       
           SRCFILE(MYSRCLIB/QRPGLESRC)  
           SRCMBR(MYMBR)                
           OPTION(*SQL)                  

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

Листинг 3. Оператор SET OPTION для настройки режима именования
/Free
   Exec SQL   Set Option Commit=*NONE, Naming=*SQL
                         DatFmt=*ISO,  CloSQLCsr=*ENDACTGRP;
   //All other source code including embedded SQL statements
/End-Free

ODBC-драйвер IBM i Access for Windows

Соглашение о назначении имен для ODBC-соединений можно указать с помощью интерфейса администрирования IBM i Access for Windows - ODBC Administration или с помощью ключевых слов соединения.

На следующем рисунке показано, как осуществляется управление соглашением о назначении имен на вкладке Server интерфейса администрирования ODBC.

Рисунок 3. Настройка ODBC
Настройка ODBC

JDBC-доступ

Управление соглашением о назначении имен для JDBC-доступа может осуществляться посредством задания свойств соединения JDBC-драйвера в URL-адресе соединения.

Свойство соединения naming property может принимать значения sql и system согласно требуемому соглашению о назначении имен. По умолчанию используется SQL Naming.

При использовании режима System Naming список библиотек может быть заранее задан в свойстве libraries, как показано в следующем примере.

Листинг 4. Настройка режима именования с помощью JDBC
conn = DriverManager.getConnection("jdbc:db2:*local: ...  
       ... naming=system;libraries=MYLIBA,MYLIBB,MYLIBX");

Провайдер ADO.NET продукта IBM i Access for Windows

При использовании ADO.NET соглашение о назначении имен и библиотечный список для System Naming могут быть заданы при установке соединения. Объект iDB2Connection подключается к DB2 for i. Соглашение о назначении имен указывается с помощью Connection String.

В следующем коде демонстрируется задание System Naming и библиотечного списка с помощью объекта iDB2Connection:

Листинг 5. Настройка режима именования с помощью ADO.NET
iDB2Connection conn = new iDB2Connection("DataSource=abc;
                               userid=XXX;password=YYY;
                               Naming=System;LibraryList=*USRLIBL,MYLIB");

SQL CLI – интерфейс уровня вызовов

При использовании функции SQL CLI соглашение о назначении имен – это атрибут, который может быть задан посредством функции SQLSetConnectAttr. Для выбора режима именования System Naming константу SQL_ATTR_DBC_SYS_NAMING следует передать в качестве параметра "атрибут", а константу SQL_TRUE – в качестве параметра "значение атрибута", как показано в следующем примере.

Листинг 6. Задание атрибутов соединения с помощью функции SQLCLI
rc = SQLSetConnectAttr(ConnHandle:
                       SQL_ATTR_DBC_SYS_NAMING:                       SQL_TRUE:
                       4);

Команда STRSQL (Start SQL Interactive Session)

Если вы хотите изменить систему именования, используемую при интерактивном исполнении ваших SQL-операторов, выполните CL-команду STRSQL , нажмите функциональную клавишу F13=Services, а затем выберите опцию 1 (Change Session Attributes).


Схема – контейнер для размещения объектов базы данных

Схема – это контейнер, используемый для хранения объектов базы данных. В случае IBM i термин "схема" (schema) используется как эквивалент термину "библиотека" (library).

Схемы или библиотеки могут быть созданы с помощью CL-команды CRTLIB (Create Library) или с помощью SQL-оператора CREATE SCHEMA. В отличие от команды CRTLIB, которая создает лишь пустой контейнер, вышеупомянутый SQL-оператор автоматически добавляет журнал, получателя журнала и несколько представлений каталога с информацией обо всех объектах базы данных, которые размещены в этой схеме.

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

Кто станет владельцем (профиль пользователя или групповой профиль), зависит от настройки опции OWNER для профиля пользователя. Если опции OWNER присвоено значение *GRPPRF, то профиль пользователя, указанный в опции GRPPRF, станет владельцем всех объектов, создаваемых этим пользователем, в противном случае профиль пользователя станет владельцем только данного объекта.

В следующем примере показана команда CHGUSRPRF (Change User Profile), используемая для указания группового профиля QPGMR в качестве владельца всех объектов, которые в будущем будут создаваться профилем пользователя PGMRGRP2.

Листинг 7. Команда Change User Profile задает опцию Owner = Group Profile
CHGUSRPRF USRPRF(PGMRGRP2)   
          GRPPRF(QPGMR)      
          OWNER(*GRPPRF)     

Все объекты учебной базы данных, которые создаются в этой статье, будут создаваться профилем пользователя с именем PGMRGRP2. Этот профиль пользователя связан с групповым профилем QPGMR. Исходя из этого, групповой профиль QPGMR будет владельцем всех объектов базы данных, создаваемых пользователем PGMRGRP2.

Создание схемы, использующей System Naming

При создании схемы с помощью оператора CREATE SCHEMA, использующего System Naming, применяются следующие правила

  • Владельцем схемы является профиль пользователя или групповой профиль – в зависимости от значения опции OWNER, задающей профиль пользователя.
  • Владелец имеет полномочия *ALL на объект, а полномочия *PUBLIC на объект основываются на системном параметре QCRTAUT (Create Default Public Authority), который по умолчанию имеет значение *CHANGE.

Создание схемы или библиотеки с помощью команды CRTLIB или с помощью оператора CREATE SCHEMA с System Naming дают одного и того же владельца и идентичные полномочия на объект.

Профиль пользователя PGMRGRP2 создает две схемы (PGMRUSR2 и PGMRXXX2) с помощью следующих SQL-операторов, использующих System Naming.

Листинг 8. Создание примера схемы
CREATE SCHEMA PGMRXXX2;
CREATE SCHEMA PGMRUSR2;

Владельцем обеих схем является групповой профиль QPGMR. У группового профиля есть полномочия *ALL на объект, а полномочиям *PUBLIC присваивается значение *CHANGE в соответствии со значением системного параметра QCRTAUT.

Рисунок 4. Оператор CREATE SCHEMA с именованием System Naming
Оператор CREATE SCHEMA с именованием System Naming

Владельца объекта и присвоенные полномочия на объект можно отобразить, настроить или удалить с помощью команды EDTOBJAUT (Edit Object Authority) или с помощью интерфейса System i Navigator Permission. Для доступа к этому интерфейсу в инструменте System i Navigator щелкните правой кнопкой на объекте базы данных и выберите задачу Permissions.

Владение объектом может быть изменено с помощью CL-команды CHGOBJOWN (Change Object Owner). В случае SQL Naming не существует никакого SQL-оператора или интерфейса System i Navigator для изменения владельца объекта.

Создание схемы, использующей именование SQL Naming

При создании схемы, использующей SQL Naming, применяются более сложные правила.

  • Если профиль пользователя с таким же именем, как у схемы, уже существует, то владельцем схемы и всех объектов, создаваемых в этой схеме, является этот профиль пользователя. Например, разработчик создает схему с именем WEBERP для нового веб-приложения. По случайному совпадению в организации имеется сотрудник по имени Weber Peter, профиль пользователя которого также имеет имя WEBERP. В результате профиль пользователя WEBERP становится владельцем схемы WEBERP.
  • Если имя схемы не соответствует никакому имени профиля пользователя, то владельцем этой схемы является профиль пользователя задания (job), которое исполняет оператор CREATE SCHEMA. При создании схемы с SQL Naming значение опции OWNER из определения профиля пользователя игнорируется.

Владелец – это единственный профиль пользователя, имеющий какие-либо полномочия относительно данной схемы. Если другим пользователям требуются полномочия на объект этой схемы, то владелец профиля пользователя с полномочиями на администрирование систем безопасности (*SECADM) или со всеми полномочиями на объект (*ALLOBJ) может предоставить требуемые полномочия схеме с помощью CL-команды GRTOBJAUT (Grant Object Authority).

Не существует никакого SQL-оператора для предоставления полномочий на объект схемы.

  • Для объектов базы данных, создаваемых с именованием SQL Naming, полномочиям *PUBLIC на объект всегда присваивается значение *EXCLUDE. Системное значение QCRTAUT игнорируется.

Чтобы сравнить различия между именованиями System Naming и SQL Naming, отбросим схемы, созданные ранее с именованием System Naming, и создадим их снова тем же пользователем, но с именованием SQL Naming.

При сравнении схемы по владению и по полномочиям на объект мы обнаружим несколько различий:

  • Владельцем схемы PGMRXXX2 является PGMRGRP2 (создатель этой схемы). Владелец, заданный для профиля пользователя PGMRGRP2, игнорируется.
  • Владелец PGMRGRP2 получает полномочия *ALL на объект, а полномочиям *PUBLIC на объект присваивается значение *EXCLUDE. Таким образом, имеются отличия от именования System Naming, при котором полномочия *PUBLIC на объект зависят от системного значения QCRTAUT. Соответственно, другому разработчику, который также является членом группового профиля QPGMR, не разрешается модифицировать схему или создавать объект в этой схеме. Такое поведение может порождать проблемы для организации, которая интенсивно использует групповые профили и у которой владельцем всех объектов, создаваемых любым разработчиком, должен становиться групповой профиль.
  • Владельцем схемы PGMRUSR2 является PGMRUSR2, поскольку уже имеется существующий профиль пользователя с таким именем. Ранее, при создании схем с использованием System Naming, владельцем обеих схем был групповой профиль QPGMR.
  • Владелец схемы PGMRUSR2 (имеющий имя PGMRUSR2), получает полномочия *ALL на объект, а полномочиям *PUBLIC присваивается значение *EXCLUDE Несмотря на то, что пользователь PGMRGRP2 был способен создать схему PGMRUSR2, у этого потребителя нет полномочий на эту схему. Пользователь PGMRGRP2 не имеет возможности модифицировать эту схему, а также создать или изменить любой объект в этой схеме.

На следующих снимках экрана показаны разрешения (также известные как полномочия) для схем, создаваемых с именованием SQL Naming.

Рисунок 5. Оператор CREATE SCHEMA с именованием SQL Naming
Оператор CREATE SCHEMA с именованием SQL Naming

Таблица, представления и индексы – объекты для обслуживания данных

Таблицы – это объекты для хранения персистентных данных пользователя в нескольких столбцах и строках.

Представления и индексы – это объекты базы данных, которые ассоциированы с некоторой таблицей, но не содержат данных.

Создание таблиц, представлений и индексов с именованием System Naming

Правила для задания владения и применения полномочий на объект соответствуют правилам, которые применяются при создании схем. Владельцем является создатель объекта или групповой профиль, а полномочиям *PUBLIC на объект присваивается системное значение QCRTAUT.

В следующем примере (Рисунок 6. Оператор CREATE TABLE с именованием System Naming) таблица EMPLOYEE создается с именованием System Naming в двух разных схемах (PGMRUSR и PGMRXXX) с помощью следующего SQL-оператора:

Листинг 9. Создание таблицы EMPLOYEE
Create Table MySchema/Employee                
      (FirstName VarChar(50) Not NULL Default '',  
       Name      VarChar(50) Not NULL Default '',  
       Street    VarChar(50) Not NULL Default '',  
       ZipCode   VarChar(15) Not NULL Default '',  
       City      VarChar(50) Not NULL Default '',  
       Country   Char(3)     Not NULL Default '',  
       Birthday  Date        Not NULL);

Обе эти схемы ранее создавались с помощью оператора CREATE SCHEMA с использованием именования System Naming. Их создателем являлся профиль пользователя PGMRGRP2. Владельцем обеих схем является групповой профиль QPGMR – согласно значению OWNER из профиля пользователя PGMRGRP2. Владельцем таблицы, созданной в схеме PGMRUSR, является групповой профиль – несмотря на наличие профиля пользователя PGMRUSR.

Владеющий профиль пользователя (QPGMR) имеет полномочия *ALL на объект, а полномочиям *PUBLIC присваивается значение *CHANGE (согласно системному значению QCRTAUT).

Соответственно всем пользователям, которые ассоциированы с групповым профилем QPGMR, разрешается обращаться к таблице EMPLOYEE в обеих схемах (PGMRXXX и PGMRUSR), а также модифицировать эту таблицу и даже удалять ее.

Рисунок 6. Оператор CREATE TABLE с именованием System Naming
Оператор CREATE TABLE с именованием System Naming

Создание таблиц, представлений и индексов с именованием SQL Naming

При использовании SQL Naming применяются иные правила.

  • Если существует профиль пользователя с таким же именем, как схема, в которой создается таблица, представление или индекс, то владельцем этой таблицы является вышеупомянутый профиль пользователя.
  • Если не существует никакого профиля пользователя с таким же именем, как у схемы, то владельцем будет профиль пользователя или групповой профиль – в зависимости от значения опции OWNER, определяющей профиль пользователя.
  • При создании объектов базы данных, отличных от схем с именованием SQL Naming, учитывается значение опции OWNER в определении профиля пользователя, и владельцем объекта базы данных становится групповой профиль.

В следующем примере Рисунок 7. Оператор CREATE TABLE с именованием SQL Naming в схеме, которая не соответствует никакому профилю пользователя показаны результирующие полномочия для таблицы EMPLOYEE, созданной в схеме PGMRXXX2 пользователем PGMRGRP2.

Владельцем таблицы EMPLOYEE является групповой профиль QPGMR. Владелец QPGMR имеет полномочия *ALL на объект, а полномочиям *PUBLIC присваивается значение *EXCLUDE. В результате всем пользователям, которые ассоциированы с групповым профилем QPGMR, разрешается не только обращаться к таблице EMPLOYEE, но также модифицировать или удалять эту таблицу.

Рисунок 7. Оператор CREATE TABLE с именованием SQL Naming в схеме, которая не соответствует никакому профилю пользователя
Оператор CREATE TABLE с именованием SQL Naming в схеме, которая не соответствует никакому профилю пользователя

В следующем примере (Рисунок 8. Оператор CREATE TABLE с именованием SQL Naming в схеме, которая соответствует какому-либо профилю пользователя) пользователь PGMRGRP2 пытается создать таблицу EMPLOYEE в схеме PGMRUSR2.

Эту же схему ранее уже создавал пользователь PGMRGRP2 с помощью оператора CREATE SCHEMA с именованием SQL Naming. Поскольку имеется профиль пользователя с именем PGMRUSR2, этот профиль пользователя становится владельцем схемы и получает полномочия *ALL на объект схемы, а полномочиям *PUBLIC присваивается значение *EXCLUDE.

Исполнение оператора CREATE TABLE заканчивается неудачей со значением состояния SQL State, равным 24501, поскольку пользователь PGMRGRP2 не авторизован в схеме PGMRUSR2 – несмотря на то, что именно он создал эту схему (На рисунке 5 «Оператор CREATE SCHEMA с именованием SQL Naming» показано, что у пользователя PGMRGRP2 отсутствуют полномочия на схему PGMRUSR2).

Чтобы позволить пользователю PGMRGRP2 создавать таблицу или любой объект в схеме PGMRUSR2 с именованием SQL Naming, соответствующий профиль пользователя или ассоциированный групповой профиль QPGMR должен быть явным образом авторизован в этой схеме – посредством команды GRTOBJAUT или команды EDTOBJAUT.

Рисунок 8. Оператор CREATE TABLE с именованием SQL Naming в схеме, которая соответствует какому-либо профилю пользователя
Оператор CREATE TABLE с именованием SQL Naming в схеме, которая соответствует какому-либо профилю пользователя

После того как групповой профиль QPGMR будет явным образом авторизован в схеме PGMRUSR2, пользователь PGMRGRP2 сможет создать таблицу EMPLOYEE в этой схеме.

Поскольку эта таблица создается с использованием именования SQL Naming, а PGMRUSR2 – это существующий профиль пользователя, данный профиль пользователя снова становится владельцем таблицы EMPLOYEE, с полномочиями *ALL на объект, а полномочиям *PUBLIC на объект присваивается значение *EXCLUDE (см. рисунок 9. Разрешения для схемы = профиль пользователя и таблица).

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

Рисунок 9. Разрешения для схемы = профиль пользователя и таблица
Разрешения для схемы = профиль пользователя и таблица

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

Создание объектов базы данных для существующих приложений с использованием именования SQL Naming может породить неожиданные проблемы на платформе IBM i.

Предположим, что все объекты базы данных для существующего приложения управления материалами хранятся в библиотеке с именем MAWI. Эта библиотека была создана достаточно давно с помощью команды CRTLIB. Владельцем библиотеки MAWI является групповой профиль QPGMR. Полномочия *PUBLIC на объект для библиотеки MAWI имеют значение *CHANGE.

В этой системе все имена профилей пользователей создаются посредством сочетания первых двух символов фамилии и первых двух символов имени. Сотрудника, занимающегося вводом данных в HR-подразделении, зовут Willy Maier, соответственно его профиль пользователя имеет имя MAWI.

Если разработчик создаст новую таблицу или новое представление в библиотеке MAWI с использованием именования SQL Naming, то владельцем этой новой таблицы станет Willy Maier, поскольку имя его профиля пользователя соответствует имени вышеупомянутой библиотеки. Лишь профиль пользователя MAWI будет иметь полномочия доступа к новой таблице или к новому представлению. Разработчик и любые другие пользователи будут исключены, поскольку именование SQL Naming по умолчанию принудительно присваивает полномочиям доступа *PUBLIC значение *EXCLUDE.


SQL-программы (SQL Routine)

SQL Routine – это исполняемые SQL-объекты, аналогичные программам на языках высокого уровня (HLL-программам). Термин SQL Routine используется для обозначения хранимой процедуры (stored procedure), триггера (trigger) или определяемой пользователем функции (user-defined function, UDF).

Эти программы пишутся на языке SQL или на языке высокого уровня, таком как RPG или Cobol. В любом случае хранимая процедура или UDF-функция создаются с помощью одного из следующих SQL-операторов:

  • CREATE PROCEDURE
  • CREATE FUNCTION

Владение и полномочия на объект для SQL-программ

Правила для задания владения объектом и полномочий аналогичны правилам, которые используются при создании таблиц, представлений и индексов с именованием SQL System Naming или с именованием SQL Naming.

TSQL-операторы, встроенные в программу, исполняются согласно соглашению о назначении имен, которое было использовано при создании этой программы – даже в том случае, если эта SQL-программа была вызвана в среде исполнения, в которой используется иной режим именования.

Например, хранимая процедура была создана из интерфейса, в котором использовалось именование SQL Naming. Если вызов этой хранимой процедуры осуществляется из программы на языке RPG (RPG-программе) с помощью операторов Embedded SQL, для которых по умолчанию используется именование System Naming, то встроенные SQL-операторы в этой RPG-программе используют именование System Naming, а SQL-операторы внутри хранимой процедуры выполняются с именованием SQL Naming.

Владение и полномочия доступа объекта этой программы используются только для того, чтобы вызвать эту программу. Значения владения объектом и полномочий могут быть (а могут и не быть) применены к SQL-оператору, выполняемому самой программой. Авторизационный идентификатор (или профиль пользователя), который применяется к SQL-запросам, исполняемым рассматриваемой программой, зависит от соглашения о назначении имен, которое действовало в момент создания программы, а также от того, являются ли выполняемые программой SQL-операторы статичными или формируются динамически. В случае использования именования System Naming продукт DB2 использует профиль пользователя, который осуществляет вызов программы. В случае использования именования SQL Naming для исполнения статических SQL-операторов внутри программы продукт DB2 задействует владельца программы по умолчанию для осуществления авторизационной обработки ее статических SQL-операторов.

Профиль пользователя, который вызвал программу, по умолчанию всегда применяется при исполнении динамических SQL-операторов этой программой, независимо от используемого режима именования (System Naming или SQL Naming).

Управление профилями пользователей, применяемыми при валидации защиты, а также при исполнении статических и динамических SQL-операторов, может осуществляться в ручном режиме в операторе SET OPTION – посредством задания опции USRPRF (User Profile for static SQL statements – Профиль пользователя для статических SQL-операторов) и опции DYNUSRPRF (User Profile for dynamic SQL statements – Профиль пользователя для динамических SQL-операторов).

Опции USERPRF может быть присвоено одно из следующих значений:

  • *NAMING: значение *USER используется для именования System Naming; значение *OWNER используется для именования SQL Naming
  • *OWNER: Статические SQL-операторы выполняются с полномочиями владельца
  • *USER: Статические SQL-операторы выполняются с полномочиями пользователя

Опции DYNUSRPRF могут быть присвоены следующие значения:

  • *USER: Значение по умолчанию для обоих режимов именования (System Naming и SQL Naming). Динамические SQL-операторы выполняются с полномочиями пользователя
  • *OWNER: Динамические SQL-операторы выполняются с полномочиями владельца

Если вы используете именование SQL Naming и хотите, чтобы ваши динамические SQL-операторы выполнялись с тем же профилем пользователя, как и ваши статические SQL-операторы, то необходимо присвоить обеим опциям (USRPRF и DYNUSRPRF) значение *OWNER или значение *USER.

Следующий SQL-оператор демонстрирует сокращенный исходный код для создания хранимой SQL-процедуры с использованием именования SQL Naming. На этапе исполнения все статические и динамические SQL-операторы, встроенные в эту процедуру, будут исполняться с полномочиями *OWNER – согласно значениям, специфицированным в выражении SET OPTION.

Листинг 10. Оператор CREATE PROCEDURE
Create Procedure PGMRUSR2.HSINFO (In Parm1   Integer)    
       Dynamic Result Sets 1                          
       Language SQL
       Set Option  DYNUSRPRF = *OWNER,USRPRF    = *NAMING                      
 Begin                                                
   /* Routine code goes here */                                             
 End  ;

Триггер

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

Владение триггерных программ определяется таким же образом, как для всех остальных SQL-программ, однако полномочия для объекта и полномочия исполнения задаются по-иному – с помощью оператора CREATE TRIGGER.

Полномочиям *PUBLIC для объекта присваивается значение *EXCLUDE, независимо от используемого режима именования (System Naming или SQL Naming). Для всех других объектов SQL, создаваемых с именованием System Naming, полномочиям *PUBLIC для объекта присваивается системное значение QCRTAUT.

В следующем примере показан исходный код для SQL-триггера, создаваемого с именованием System Naming.

Листинг 11. Оператор CREATE TRIGGER
CREATE TRIGGER PGMRUSR/TRGEMPLOYEE
       BEFORE INSERT ON PGMRUSR/EMPLOYEE
       REFERENCING NEW ROW AS N
       FOR EACH ROW
       MODE DB2ROW   
BEGIN ATOMIC
    /* Source code goes here */
 END;

На рисунке 10 показано окно разрешений для этой триггерной программы, создаваемой с именованием System Naming. Владельцем является групповой профиль QPGMR; он обладает всеми полномочиями на объект, а полномочиям *PUBLIC на объект присваивается значение *EXCLUDE.

Рисунок 10. Триггер, созданный с именованием System Naming
Триггер, созданный с именованием System Naming

Чтобы создать триггерную программу с именованием SQL Naming в схеме с таким же именем, как у существующего профиля пользователя, необходимо в явном виде "представить" создателя таблице или задать специальные полномочия – *ALLOBJ или *SECADM. Владельцем триггерной программы станет пользователь с таким же именем, как у схемы, либо профиль пользователя создателя или ассоциированный с ним групповой профиль – в зависимости от значения опции OWNER, описывающей профиль пользователя.

На рисунке 11 «Триггер, созданный с именованием SQL Naming» показано окно разрешений для триггерной программы, создаваемой пользователем PGMRGRP2 в схеме PGMRUSR2 с использованием именования SQL Naming. Поскольку имя PGMRUSR2 совпадает с именем существующего профиля пользователя, этот профиль пользователя становится владельцем данной триггерной программы. Владелец PGMRUSR2 имеет полномочия *ALL на объект, а полномочиям *PUBLIC на объект присваивается значение *EXCLUDE.

Рисунок 11. Триггер, созданный с именованием SQL Naming
Триггер, созданный с именованием SQL Naming

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


Полномочия GRANT / REVOKE

Вне зависимости от режима именования, который использовался при создании ваших объектов базы данных (System Naming или SQL Naming), следует тщательно проверить владение и полномочия на объект. Если поведение по умолчанию не соответствует вашим требованиям к защите, можно воспользоваться SQL-операторами GRANT и REVOKE для корректировки соответствующих настроек.

Полномочия на объект для любого профиля пользователя или группы и даже для публичного использования (*PUBLIC) могут быть заданы с помощью оператора GRANT. Если полномочия на объект необходимо удалить, можно воспользоваться оператором REVOKE. Операторы GRANT и REVOKE могут использоваться в сочетании со всеми объектами базы данных, к которым можно обратиться или которые можно выполнить, за исключением схем и триггеров.

Кроме того, можно воспользоваться CL-командами GRTOBJAUT (Grant Object Authority) и EDTOBJAUT (Edit Object Authority) для изменения полномочий на объекты базы данных. Следует, однако, отметить, что между CL-командами и SQL-операторами существуют некоторые различия с точки зрения предоставления полномочий.


Оператор SET SESSION AUTHORIZATION

Операторы SET SESSION AUTHORIZATION и SET SESSION USER могут оказывать влияние на владение объектом и на полномочия при работе с именованием SQL Naming.

После установления соединения оператор SET SESSION AUTHORIZATION или оператор SET SESSION может быть использован для переключения текущего профиля пользователя на другой профиль пользователя (идентификатор авторизации) с целью принятия полномочий доступа этого профиля пользователя. Таким образом, вы узнали, как значение профиля пользователя применяется к владению объектом и к полномочиям при создании объектов с именованием SQL Naming.


Заключение

К настоящему моменту вы должны хорошо понимать, почему существуют различия в присвоении полномочий владения и доступа для объектов DB2, создаваемых с использованием различных режимов именования (System Naming или SQL Naming).

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

  • Если вы собираетесь проектировать приложение, способное исполнять разные системы баз данных, то SQL Naming – это хороший способ для достижения максимальной степени мобильности.
  • Если вы работаете только с продуктом DB2 for i и должны поддерживать более старые приложения, сочетающие DDS-объекты и SQL-объекты базы данных, а также использовать специфические полномочия платформы IBM i (такие как групповые профили), то более подходящим решением станет System Naming.

Теперь вы сможете беспрепятственно заниматься планированием, проектированием, созданием и сопровождением объектов базы данных с использованием нужного режима именования – System Naming или SQL Naming.


Ресурсы

IBM i - DB2 for i Reference - 7.1 (Справочник по SQL для продукта DB2 for i)

Форум по продукту DB2 for i на веб-сайте IBM developerWorks

Обновления технологий IBM i на веб-сайте IBM developerWorks

Оригинал статьи: System versus SQL name : Part 1

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=848760
ArticleTitle=Сравнение режимов именования System Naming и SQL Naming: Часть 1
publish-date=12052012