CREATE SERVER canada_server TYPE oracle VERSION 9 WRAPPER net8
    OPTIONS (NODE ?nodename?);
CREATE SERVER credit_server TYPE oracle VERSION 8.1.7 WRAPPER net8
    OPTIONS (NODE ?nodename?);
CREATE SERVER xml_server WRAPPER xml_wrapper;

				
			

В начало

Серверные опции.

Интеграционное ПО WebSphere Information Integrator основывается на серверных атрибутах, используемых для проверки того, что все возможности каждого источника данных правильно используются. Серверные атрибуты в "объединяющем сервере" хранят характеристики каждого источника данных. Компилятор запросов использует их характеристики и ограничения при планировании исполнения запроса. Используя серверные опции для настройки атрибутов внешних серверов, вы можете указать нахождение источника данных (машинный код), данные безопасности соединения (идентификатор и пароль), а также некоторые характеристики, влияющие на производительность. Каждый компонент wrapper содержит набор атрибутов, согласующихся с типом данных и версией источника данных, который он поддерживает.

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

Некоторые атрибуты, такие как COLLATING_SEQUENCE, могут влиять на выбор операций для обработки во внешнем источнике. Этот серверный атрибут указывает объединяющему серверу, является ли нумерованная последовательность (COLLATING SEQUENCE) одинаковой, как во внешнем источнике, так и на объединяющем сервере. Помимо того, что эта серверная опция позволяет сортировать данные символьного типа во внешнем источнике, она также разрешает проверку диапазонов (например, string_col > string_constant), а также разрешает предикатам LIKE выполняться удаленно. В зависимости от операции возможность вычислить ее во внешнем источнике может способствовать общему повышению производительности обработки запроса.

К примеру, источники данных, такие как мейнфреймы DB2 для z/OS и OS/390, используют нумерованную последовательность, основанную на кодировке EBCDIC. Настройкой серверной опции по-умолчанию для таких источников является значение 'N', так как такая схема характерна только для DB2 для z/OS и OS/390. По-умолчанию в СУБД DB2 Universal Database используется ASCII схема, а порядок сортировки по-умолчанию упорядочен в алфавитном порядке.

Хотя некоторые другие источники, такие как Oracle, также используют ASCII схему, их порядок сортировки отличается от сортировки в СУБД DB2 Universal Database. Федеративную систему возможно сконфигурировать так, чтобы схема сортировки совпадала с источниками, такими как СУБД Oracle, использующими сортировку IDENTITY. Чтобы этого добиться, необходимо использовать дополнительное выражение COLLATE USING IDENTITY в операторе CREATE DATABASE. В этом случае вы можете установить серверный признак COLLATING_SEQUENCE в позицию ‘Y’ для источников, использующих схему ASCII и порядок сортировки IDENTITY.

Объединяющая система предоставляет оператор SET SERVER OPTION. Его нужно использовать для поддержания серверного признака в рабочем состоянии в том случае, если приложение соединено с объединяющим сервером. При обрыве соединения ранее установленный признак восстанавливается. Для получения более подробных описаний смотрите DB2 UDB SQL Reference (см. Ресурсы). Для получения самого подробного списка настраиваемых общих и серверных опций смотрите документ IBM DB2 Information Integrator Data Source Configuration Guide (см. Ресурсы).

В начало

Отображения пользователя

Платформа WebSphere Information Integrator поддерживает отображения пользователя, обеспечивая этим дополнительный уровень безопасности. Вы можете создать отображение для каждого идентификатора и пароля пользователя в ПО WebSphere Information Integrator во внешнем источнике данных. Такие отображения могут быть созданы как для реляционного источника табличных данных, так и для нереляционного. XML-файлы не требуют регистрации отображений пользователя, а потому дополнительный уровень аутентификации не создается. В случае объединяющей системы, формат SQL-операторов для регистрации отображений пользователя следующий:

				
				
CREATE USER MAPPING FOR user SERVER usa_server
	OPTIONS (REMOTE_AUTHID ?mvsuser1?, REMOTE_PASSWORD ?password?);
CREATE USER MAPPING FOR user SERVER canada_server
	OPTIONS (REMOTE_AUTHID ?orauser1?, REMOTE_PASSWORD ?password?);
CREATE USER MAPPING FOR user SERVER credit_server
	OPTIONS (REMOTE_AUTHID ?crduser1?, REMOTE_PASSWORD ?password?);

				
			

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

				
				
CONNECT TO my_federated_db USER etlin USING etlin_pwd 
				
			

В начало

Транзитные соединения и привилегии

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

SQL-операторы и команды, посланные в транзитном соединении, включают некие операции ‘записи’ в отношении внешнего сервера. Таким образом, если существует транзакция в транзитном соединении к серверу А, то та же самая транзакция не может осуществить операцию записи с локальными данными на "объединяющем сервере" или с внешними данными на сервере, который не является сервером А.

Задачей администратора СУБД на "объединяющем сервере" является контроль тех пользователей СУБД DB2, которые могут открывать транзитные сессии к внешнему серверу. Доступ предоставляется с использованием оператора GRANT PASSTHRU, например:

				
				
GRANT PASSTHRU ON SERVER credit_server TO GROUP managers;
				
			

После предоставления прав доступа пользователи (например те, которые принадлежат группе менеджеров в приведенном примере) могут использовать транзитные соединения. Следующий пример иллюстрирует эквивалент операции RUNSTATS на сервере Oracle:

				
				
SET PASSTHRU credit_server;
ANALYZE TABLE bad_credit COMPUTE STATISTICS;
SET PASSTHRU RESET;
				
			

Но получение привилегии для использования транзитных соединений не является достаточным условием для получения доступа к внешним данным через ПО WebSphere Information Integrator. Пользователям необходимо иметь отображения пользователей или сравнимый механизм отображения (смотрите предыдущий раздел), чтобы успешно соединяться с определенным источником.

В начало

Псевдонимы

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

Точные данные об индексах и статистических показателях являются важнейшими параметрами для принятия решения об оценке стоимости исполнения плана оптимизатором запросов. В объединяющей системе уникальная индексная информация может потребоваться для операций обновления UPDATE/DELETE для некоторых источников данных. Если данные нужно хранить локально перед обновлением (например, когда на обновляемую таблицу также ссылается предикат в том же операторе UPDATE), объединяющая система использует уникальный индекс для симуляции положения курсора для тех источников данных, которые не поддерживают идентификатор строки rowid (например, редакции семейства СУБД DB2). Данные об определениях колонок, индексах и статистических показателях псевдонимов хранятся в системных каталогах объединяющей системы СУБД DB2.

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

				
				
CREATE NICKNAME usa.items FOR usa_server.mvsuser1.items;
CREATE NICKNAME usa.suppliers FOR usa_server.mvsuser1.suppliers;
CREATE NICKNAME usa.item_supplied FOR usa_server.mvsuser1.item_supplied;
CREATE NICKNAME canada.items FOR canada_server.orauser1.items;
CREATE NICKNAME canada.suppliers FOR canada_server.orauser1.suppliers;
CREATE NICKNAME canada.item_supplied FOR canada_server.orauser1.item_supplied;
CREATE NICKNAME bad_credit FOR credit_server.crduser1.bad_credit;
				
			

Так как синтаксис для определения псевдонимов для большинства нереляционных источников содержит больше тонкостей, возможно придется предоставить определения колонок при регистрации псевдонима для некоторых источников (таких, как например, обычные табличные файлы данных). Сonrol Center в платформе WebSphere Information Integrator предоставляет систему автоматического создания псевдонимов DDL для XML–данных, а посему, DDL-выражения, описанные здесь, приведены только в качестве примера. Так как заказ клиента может обычно содержать целый список продуктов, в примере он представлен двумя псевдонимами:

				
				
CREATE NICKNAME xml.orders
	(order_id char (10) OPTIONS (XPATH ?@id?),
	 order_date date OPTIONS (XPATH ?date/text()?),
	 customer_id char (10) OPTIONS (XPATH ?cid?),
	 order_amount decimal (31, 2) OPTIONS (XPATH ?./amount/text()?),
	 oid varchar (16) OPTIONS (PRIMARY_KEY ?YES?))
FOR SERVER xml_server
OPTIONS (FILE_PATH ?/home/administrator/orders/orders.xml?,
	 XPATH?//order?);

CREATE NICKNAME xml.order_items
	(oid varchar (16) OPTIONS (FOREIGN_KEY ?ORDERS?),
	 item_id char (10) OPTIONS (XPATH ?./item_id/text()?),
	 item_quantity integer OPTIONS (XPATH ?./quantity/text()?))
FOR SERVER xml_server
OPTIONS (XPATH ?.//item?);

				
			

В начало

Опции псевдонимов

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

Во время регистрации объекта данных в реляционном источнике данных отображения типов данных по-умолчанию определяют, каким образом типы данных в источнике должны отображаться на типы данных в СУБД DB2 в каждой колонке. Эти схемы отображения встроены в wrapper компоненты. Для получения более полного представления о том, какие отображения типов данных используются по-умолчанию для каждого источника данных, обратитесь к статье IBM DB2 Information Integrator Federated Systems Guide (см. Ресурсы).

Вы вероятно захотите изменить тип данных в столбцах, чтобы более точно согласовать типы данных. Например, тип DATE в СУБД Oracle отображается на тип DB2 TIMESTAMP по-умолчанию. Но, если, например, колонка с типом DATE содержит только данные о днях рождениях сотрудников организации, вы можете отобразить ее на тип DB2 DATE. Было бы удобно определить локальную колонку с типом DATE, так как она допускает использование предикатов с литералами DATE, но не требует функций преобразования типов (влиящих на ухудшение производительности).

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

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

Используйте опцию колонки VARCHAR_NO_TRAILING_BLANKS, чтобы распознать столбец псевдонима, не содержащий замыкающих символов. Компилятор запросов будет использовать эту информацию при проверке любых операций по сравнению символов и принятия решения о том, как интерпретировать эти операции. СУБД DB2 Universal Database преобразовывает запросы, используя сравнительную семантику дополнения пробелами, а именно: при сравнении срок неравной длины, используется сдвиг вправо копии более короткой строки, места заполняются пустыми символами таким образом, чтобы полная длина соответствовала длине более длинной строки. Это означает, что для строки ‘A’ найден эквивалент строке ‘A’ в СУБД DB2 Universal Database.

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

Чтобы компенсировать разницу в сравнительной семантике заполнения пробелами для некоторых операций, таких как предикаты, федеративная система переписывает предикаты с целью проверки, что та же семантика применяется, когда предикаты посылаются Oracle серверу. Может быть затронута производительность обработки таких операций, как DISTINCT, ORDER BY, GROUP BY, UNION, вычисление отношения (MIN()/MAX()), сравнение отношений и предикат IN. Использование параметра столбца VARCHAR_NO_TRAILING_BLANKS в целом повышает производительность обработки, так как он разрешает обработку большего количества операций во внешнем источнике, а также большую оптимизацию внешних SQL-предложений для поддержки доступа к индексам.

Параметр VARCHAR_NO_TRAILING BLANKS может быть установлен как серверная опция, при условии, если вы уверены, что все столбцы типа VARCHAR2 на сервере Oracle не имеют заполняющих пробелов. В общем, такое ограничение достаточно сложно реализовать. Поэтому использование параметра VARCHAR_NO_TRAILING_BLANKS в качестве серверной опции не рекомендуется.

Другой параметр столбца, NUMERIC_STRING, также может влиять на производительность. Он связан с строковыми типами данных и теми источниками данных, для которых серверная опция COLLATING_SEQUENCE не установлена в состояние 'Y.'

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

В нашем примере, item_id - это столбец с типом CHAR, который хранит только численные символы, как показано в следующем выражении:

				
				
ALTER NICKNAME usa.items ALTER COLUMN item_id
	OPTIONS (ADD NUMERIC_STRING ?Y?);
ALTER NICKNAME usa.item_supplied ALTER COLUMN item_id
	OPTIONS (ADD NUMERIC_STRING ?Y?);
ALTER NICKNAME canada.items ALTER COLUMN item_id
	OPTIONS (ADD NUMERIC_STRING ?Y?);
ALTER NICKNAME canada.item_supplied ALTER COLUMN item_id
	OPTIONS (ADD NUMERIC_STRING ?Y?);
				
			

В начало

Ограничения целостности на псевдонимах.

Если внешняя таблица имеет атрибуты, такие как ограничения по первичному ключу или другие ограничения, они могут быть распознаны объединяющим сервером посредством указания ограничений целостности на псевдонимах. Системой поддерживаются ограничения уникальности, ограничения по первичному ключу, а также проверочные, ссылочные и функционально зависимые ограничения. SQL-компилятор использует ограничения целостности для повышения производительности обработки запросов. Они предоставляют дополнительные сведения о данных, а также позволяют добиться лучшей оптимизации. Объединяющий сервер не накладывает ограничений целостности в момент операций обновления, таких как: insert, delete и update.

В модели данных, приведенной в примере, колонки item_id и suppl_id являются первичными ключами во внешних таблицах, перечисляющих продукты и поставщиков. Для источников данных, таких как СУБД DB2/390 и Oracle, объединяющая система автоматические извлекает данные по первичным ключам в момент отработки команды CREATE NICKNAME. Простой способ оценить, что объединяющая система получает данные о первичном ключе, заключается в написании запроса представлению каталога SYSCAT.TABCONST имеющего следующую конструкцию:

				
				
SELECT CHAR(constname, 30), type 
FROM syscat.tabconst 
WHERE tabname = 'ITEMS' and tabschema = 'USA';
				
			

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

Помимо этого, колонки item_id и suppl_id определены как внешние ключи для внешней таблицы item_supplied. Транслировать эти данные объединяющему серверу возможно путем определения ссылочных ограничений, используя следующие команды:

				
				
ALTER NICKNAME canada.item_supplied ADD CONSTRAINT fk1 
          FOREIGN KEY (item_id) REFERENCES canada.items(item_id)
          NOT ENFORCED;
ALTER NICKNAME canada.item_supplied ADD CONSTRAINT fk2 
          FOREIGN KEY (suppl_id) REFERENCES canada.supplier(suppl_id)
          NOT ENFORCED;

				
			

Те же определения могут быть использованы для определения ограничений по внешним ключам для псевдонима usa.item_supplied. Вхождение конструкции NOT ENFORCED в этому случае просто указывает, что ограничение не будет накладываться на объединяющем сервере. При необходимости запретить использование ограничений SQL-компилятором, можно воспользоваться оператором DISABLE QUERY OPTIMIZATION. Например:

				
				
ALTER NICKNAME canada.item_supplied ALTER FOREIGN KEY fk1 
          DISABLE QUERY OPTIMIZATION;

				
			

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

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

				
				

ALTER NICKNAME canada.items ADD CONSTRAINT ck 
	CHECK (item_id BETWEEN '0000000001' AND '5000000000');
ALTER NICKNAME usa.items ADD CONSTRAINT ck 
	CHECK (item_id BETWEEN '5000000001' AND '9999999999');

				
			

Определить схожие ограничения для псевдонимов поставщика:

				
				
ALTER NICKNAME canada.supplier ADD CONSTRAINT ck 
	CHECK (suppl_id) BETWEEN '0000000001' AND '2000000000');
ALTER NICKNAME usa.supplier ADD CONSTRAINT ck 
	CHECK (item_id) BETWEEN '2000000001' AND '3000000000');
				
			

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

				
				
ALTER NICKNAME canada.item_supplied ADD CONSTRAINT ck1 
	CHECK (item_id) BETWEEN '0000000001' AND '5000000000');
ALTER NICKNAME canada.item_supplied ADD CONSTRAINT ck2 
	CHECK (suppl_id) BETWEEN '0000000001' AND '2000000000');
				
			

Добавьте похожие данные для псевдонима usa.item_supplied.

В начало

Спецификация индексов

Во время регистрации реляционных псевдонимов компоненты доступа wrappers пытаются извлечь данные из внешнего каталога для объекта-предка. Часто отсутствует возможность получить индексную информацию, внешний источник возможно просто не имеет системного каталога для индексов или, возможно, внешний объект не имеет связанной с ним индексации во внешнем системном каталоге. Также возможен случай, когда таблица индексов добавляется для внешнего объекта после создания псевдонима. Для облечения работы объединяющего сервера по доступу к этой индексной таблице, можно определить индексы для внешнего объекта. Синтаксическая форма этого предложения является расширенной формой выражения CREATE INDEX (смотрите документ DB2 UDB SQL Reference). На объединяющем сервере индексы физически не создаются от имени данного псевдонима. Вместо этого в системный каталог добавляется запись, указывающая оптимизатору запросов на то, что такой индекс существует. Будучи осведомленным о всех внешних индексах, оптимизатор запросов будет генерировать более оптимальные планы исполнения запросов.

Задание индекса, определяющее уникальный индекс, также транслирует объединяющей системе данные об уникальности индексированных столбцов. Также как обычный уникальный индекс, заведенный при регистрации реляционного индекса, такие данные помогают оптимизатору запросов сгенерировать более оптимальный план исполнения, включающий такие стратегии, как исключение из обработки ненужных операций DISTINCT.

В начало

Псевдонимы внешних представлений

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

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

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

Если же внешнее представление содержит сложный запрос, использование показателей статистики таблицы, таких как кардинальность псевдонима представления, может быть неверным. Например, представление, основанное на очень сложном запросе, возвращающее результат только из пяти строк (как, например, оператор GROUP BY), сложно оценить во внешнем источнике. Однако, если стоимость выполнения представления, осуществляющего этот сложный запрос, промоделировать данными статистики таблицы на объединяющем сервере (скажем, кардинальностью таблицы), доступ к этим пяти строкам сделает стоимость выполнения этого внешнего представления очень дешевым. Это будет иметь нежелательные последствия для оптимизации запроса.

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

В начало

Статистика Псевдонимов

ПО WebSphere Information Integrator использует оптимизатор, основанный на оценке стоимости плана запроса. Таким образом, чтобы оптимизатор мог оптимальным образом выполнить план, необходимо иметь точные статистические показатели. В настоящее время можно собирать статистику псевдонимов, используя один из следующих методов:

• Создание Псевдонимов:Во время создания псевдонима компонент wrapper собирает некоторые статистические данные для создаваемого псевдонима, просматривая статистику в каталогах во внешнем источнике и сопоставляя ее с статистикой DB2. В данный момент реляционные wrappers собирают и отображают следующую статистику (в тех случаях, когда это возможно):
  Таблица1. Показатели таблицы
  

  Статистика	Описание
  card (table cardinality)	Общее количество строк в таблице
  npages	Общее количество страниц, на которых присутствуют строки таблицы
  fpages	Общее количество страниц
  overflow	Общее количество избыточных записей в таблице

  Таблица2. Показатели столбца
  

  Статистика	Описание
  colcard (column cardinality)	Количество отдельных значений в столбце
  high2key	Второе наибольшее значение в столбце
  low2key	Второе наименьшее значение в столбце

  Таблица3. Показатели индекса
  

  Статистика	Описание
  firstkeycard	Количество отдельных значений первого ключа
  fullkeycard	Количество отдельных значений полного ключа
  nlevels	Количество уровней индекса
  nleaf	Количество конечных страниц
  clusterratio	Степень кластеризации данных при помощи индекса

  Важно также, чтобы на источнике данных была запущена схожая с runstat утилита, что даст возможность собрать текущую статистику при создании псевдонима. Но не каждый wrapper сможет собрать всю перечисленную статистику, потому как корректного соответствия между статистикой во внешнем источнике и его копии на "объединяющем сервере" может не быть. Как только статистика для псевдонима собрана, она не обновляется автоматически после того, как внешняя статистика обновилась во внешнем источнике для соответсвующей таблицы.
  Если существует псевдоним, чьи показатели требуют обновления, то для того, чтобы отразить новую внешнюю статистику в источнике данных, псевдоним, вероятно, придется удалить и снова создать. Однако, при этом остальные объекты в базе данных будут удалены, например, индексы, зависящие от псевдонима. Ниже приведены два варианта, позволяющие обновлять статистику без удаления объектов, зависящих от псевдонима.
• Утилита обновления статистики псевдонима в Control Center или хранимая процедура командной строки SYSPROC.NNSTAT:
  И утилита обновления статистики псевдонима в Control Center, и хранимая процедура командной строки SYSPROC.NNSTAT, извлекают внешнюю статистику, хранимую для внешнего объекта, для которого создан псевдоним. Во внутреннем представлении во внешней таблице создается копия псевдонима (shadow nickname). Псевдоним получает самые последние статистические данные на момент его создания. Эта статистика далее переносится из копии в существующий псевдоним. Копия псевдонима потом удаляется.
  Для более подробного пояснения об использовании утилиты обновления статистики псевдонима в Control Center или хранимой процедуры, обратитесь к документу IBM DB2 Information Integrator Federated Systems Guide (см. Ресурсы).
• Утилита getstats:
  Утилита getstats создает запросы внешнему источнику, чтобы оценить статистику. Например, кардинальность таблицы оценивается запросом select count(*) from nick
  Данная методика сбора статистики особенно хороша для псевдонимов внешних представлений, так как внешние источники обычно не собирают статистику представлений. Она также важна для OBDC псевдонимов, так как OBDC интерфейс может устанавливать соединения с любым источником, а оптимизатор запросов не имеет данных о согласованности статистик во внешнем каталоге и системных каталогах DB2.
  Так как утилита getstats способна лишь собирать статистику, оцениваемую SQL-операторами, она не может собирать физические данные (например, статистические показатели таблицы npages и fpages или показатели индекса nleaf и nlevels). Помимо этого, так так утилита создает запросы к данным псевдонима, скорость работы утилиты зависит от объема данных, на которые ссылается псевдоним. Для более подробных пояснений об использовании утилиты getstats, смотрите сайт WebSphere Information Integrator support site (см. Ресурсы).

В начало

Привилегии псевдонимов

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

				
				
GRANT SELECT ON eileen.nick1 TO PUBLIC;
GRANT SELECT ON usa.items TO GROUP managers;
				
			

Хотя пользователь eileen обладает привилегией для доступа к псевдониму, привилегия внешнего объекта-предка будет перепроверена внешним источником по внешнему идентификатору пользователя таким образом, что объединяющий сервер сможет установить соединение от имени пользователя eileen. Рисунок 4 поясняет эти различия:

В начало

Привилегии псевдонима в представлениях и пакетах

Представления и пакеты обеспечивают дополнительный уровень безопасности данных путем сокрытия внутреннего представления данных от пользователя. Когда вам выдаются привилегии для доступа к представлению или пакету, вы автоматически получаете доступ к таблицам, на которые ссылается представление или пакет. Однако, для псевдонимов дополнительная проверка привилегий проводится во внешнем источнике, так как требуется внешняя аутентификация для соединения с внешним источником. Рисунок 5 иллюстрирует отличия в поведении запроса:

В начало

Функции

Помимо отображения типов данных по-умолчанию, библиотеки wrapper, включенные в платформу WebSphere Information Integrator также включают набор отображаемых функций. Они подсказывают компилятору запросов отображать встроенную функцию в СУБД DB2 (например, функцию SUM) на подходящий эквивалент функции во внешнем источнике. Если требуется, чтобы объединяющий сервер передал обработку функции в внешний источник, необходимо использовать отображение этой функции для этого источника. Это может способствовать общему повышению производительности выполнения запроса.

Если внешний источник содержит некую особенную функцию, не поддерживаемую ПО WebSphere Information Integrator, необходимо определить шаблон этой функции. Шаблон функции – это некое расширение пользовательской функции. Важно, чтобы запросы могли ссылаться на эти функции в источнике, в котором нет тех фунций, которые есть на объединяющем сервере. Для более подробного изучения использования выражения CREATE FUNCTION для шаблонов функций, обратитесь к справочнику DB2 UDB SQL Reference (см. Ресурсы).

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

В начало

Представления системного каталога

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

Таблица 4 перечисляет соответствующие объединенные объекты и представления системных каталогов DB2, которые могут быть использованы для локализации данных. Для получения дополнительной информации об определении каждого представления, обратитесь к справочнику DB2 UDB SQL Reference (см. Ресурсы).

В начало

Заключение

С появлением версии 7 СУБД DB2 Universal Database for Linux, UNIX и Windows компания IBM представила первую коммерческую систему управления данными, способную объединять данные реляционных и нереляционных источников. "Объединение" предоставляет вам новый уровень интеграции данных, осуществляя возможность "объединяющей системе" DB2 работать как виртуальная СУБД, в которой управление данными внешних источников происходит также, как управление локальными таблицами. Вы можете применять мощь СУБД DB2 и внешних источников, и получать значительные преимущества от использования возможностей по интеграции разнородных и распределенных информационных хранилищ в реальном времени, а также автономности, прозрачности системы, расширяемости и оптимизационных характеристик, которые предлагает система.

Версия интеграционного ПО WebSphere Information Integrator V8.2 еще болеше совершенствует технологию объединения данных, облегчая процесс создания "объединяющей системы". Вот некоторые наиболее важные характеристики новой версии:

• Таблицы материлизованных запросов, которые могут быть определены для запросов, ссылающихся как на реляционные, так и нереляционные псевдонимы для локального кэширования результирующих наборов
• Средство кэширования таблицы в Control Center, которое позволяет вам настроить локальные области кэширования псевдонимов, используя в качестве механизма обновления репликацию
• Средство обновления статистики псевдонима, предоставляющее возможность обновлять статистику псевдонима
• Монитор, следящий за общим состоянием вашей федеративной системы
• Возможность импорта данных в реляционный псевдоним и экспорта данных запросом, ссылающимся на псевдоним
• Модель улучшенной обработки, которая лучше использует возможности параллельной обработки запросов к псевдонимам в федеративной системе с секционированными данными (см.описание в документе "Parallelism in WebSphere Information Integrator V8.2" by S. Harris - раздел Ресурсы)
• Более широкий выбор нереляционных компонент доступа, включающий компоненты WebSphere Business Integration (WBI) и Web Services
• Инструментарий для разработки компонента доступа на языках C++ и Java, который позволяет разрабатывать ваши собственные библиотеки для доступа к собственным источникам данных из вашей федеративной системы.

При все большем количестве клиентов, использующих объединение данных, важность задач безболезненного объединения данных продолжает расти. Мы продолжим обращать пристальное внимание на развитие федеративных систем в сторону более мощных, обеспечивающих лучшее восприятие пользователя. Следите за новыми улучшениями в WebSphere Information Integrator from IBM.

Ресурсы

• Оригинал статьи Using data federation technology in IBM WebSphere Information Integrator: Part 1: Design and configuration
  
  
• В статье IBM Federated Database Technology (developerWorks, Март 2002) авторов Л.Хаас (L. Haas) и Е. Лин (E. Lin) описывается федеративная технология IBM.
  
  
• В статье Data integration through database federation (IBM Systems Journal, Том. 41, №. 4, 2002) авторов Л.Хаас (L. Haas), Е. Лин (E. Lin) и М. Рот (M. Roth), рассматриваются основы объединения баз данных, показываются некоторые стили объединения данных, а также показываются условия, при которых следует использовать каждый способ объединения.
  
  
• Книга DataJoiner: A Practical Approach to Multi-Database Access (Proc. of the Intl. IEEE Conf. on Parallel and Distributed Information Systems, Austin, TX, USA, Сентябрь 1994) авторов П. Гупта (P. Gupta) и Е. Лин (E. Lin) описывает ПО DataJoiner, продукт, предшествующий появлению ПО IBM WebSphere Information Integrator.
  
  
• В статье Garlic: a new flavor of federated query processing for DB2 (Proc. SIGMOD 2002, Madison, WI, USA, Июнь 2002) авторов В. Жосифовский (V. Josifovski), П. Шварц (P. Schwarz), Л. Хаас (L. Haas) и Е. Лин (E. Lin) описана технология, которая позволяет клиентам IBM's DB2 Universal Database получать доступ к данным и специальным вычислительным функциям широкого спектра нереляционных источников
  
  
• В статье DB2 Information Integration: The Big Picture (developerWorks, Июль 2003) автора Х. Хейс (H. Hayes) предлагаются к рассмотрению вопросы по общему изучению решений и технологий интеграции данных IBM.
  
  
• В статье Information integration: A research agenda (IBM Systems Journal, Том. 41, №. 4, 2002) авторов А.Д. Джингран (A. D. Jhingran), Н. Маттос (N. Mattosw) и Х. Пирахеш (H. Pirahesh) рассматривается вопросы интеграции данных с трех точек зрения -типы данных, объединение и данные.
  
  
• В статье Information integration: A new generation of information technology (developerWorks, Июль 2003) авторов М. А. Рот (M. A. Roth), Д.С. Фольфсон (D. C. Wolfson), Дж. С. Кливейн(J. C. Kleewein) и С.Дж. Нелин (C. J. Nelin) рассматриваются бизнес-требования к интеграции данных и описывается подходящая для решения вопроса интеграции данных архитектура.
  
  
• Книга Getting Started on Integrating Your Information (IBM Redbooks, Февраль 2003) авторов С. Барагойн (C. Baragoin), Дж.Деркер (J. Dirker), С. Элкинс (C. Elkins), И. Харви (I. Harvey) и Ф.Ло (F. Lo), помогает проектировщикам и внедренцам понять технологии объединения данных, реализованных в DB2 Universal Database и WebSphere Information Integrator.
  
  
• Книга IBM DB2 Information Integrator Federated Systems Guide является основной документацией по продукту WebSphere Information Integrator.
  
  
• Книга IBM DB2 Information Integrator Data Source Configuration Guide объясняет концепции федеративных систем и предлагает основной справочник по конфигурированию федеративной системы.
  
  
• Книга IBM DB2 Universal Database Administration Guide: Performance является документацией к СУБД DB2, предлагающей основы достижения производительности и настройки.
  
  
• Том 1 и Том 2 книги IBM DB2 Universal Database SQL Reference - ваш основной справочник по использованию языка SQL в DB2 UDB.
  
  
• В статье Parallelism in WebSphere Information Integrator V8.2 (developerWorks, Февраль 2005) автор С.Харрис (S. Harris) рассматривает основные улучшения в применении технологии параллелизма появившиеся в выпуске WebSphere Information Integrator V8.2.
  
  
• Для получения консультаций по использованию WebSphere Information Integrator, воспользуйтесь ссылкой http://www.ibm.com/software/data/integration/db2ii/support.html.
  
  

Об авторах

Оценить эту статью

Комментарии

В начало