Получить имена и объемы продаж всех служащих, опережающих план.

SELECT NAME, QUOTA, SALES FROM SALESREPS8CENTRALH0ST WHERE SALES > QUOTA

При работе с удаленными данными поддерживаются практически все базовые возможности Oracle (за исключением некоторых объектно-ориентированных расширений OracleS). Единственным обязательным требованием является то, что имя каждого объекта удаленной базы данных должно сопровождаться именем канала связи. Вот пример объединения двух таблиц, выполняемого на удаленном сервере Oracle:

Получить имена всех служащих, опережающих план, и узнать, в каких офисах они работают.

SELECT NAME, CITY, QUOTA, SALES

FROM SALESREPS8CENTRALH0ST, 0FFICES8CENTRALH0ST WHERE SALES > QUOTA

AND REP OFFICE = OFFICE

Oracle позволяет направлять удаленной базе данных не только запросы на выборку, но также запросы на обновление и инструкции DDL.

Создать на удаленном сервере таблицу с информацией о клиентах с самыми высокими лимитами кредита и заполнить ее данными из таблицы customers.

CREATE TABLE HIGHCUST@CENTRALHOST (CUST NUM INTEGER NOT NULL,

COMPANY VARCHAR(20) NOT NULL, REP NAME VARCHAR(15))

INSERT INTO HIGHCUST8CENTRALH0ST

SELECT COST NUM, COMPANY, NAME

FROM CUSTOMERSeCENTRALHOST, SALESREPS8CENTRALH0ST WHERE CREDIT LIMIT > 50000.00 AND CUST REP = EMPL NUM

Informix Universal Server располагает возможностями, подобными возможностям Oracle, но использует иной механизм идентификации удаленных баз данных и немного другой синтаксис. В архитектуре Informix рааяичаются удаленный сервер базы данньгх и удаленная база данных, управляемая этим сервером. Так гораздо удобнее работать с несколькими базами данных, расположенньгми на одном удаленном сервере. Предположим, что копия учебной базьг данных называется SAMPLE и располагается на удаленном сервере с именем CENTRALHOST. В этом случае эквивалентом вышеприведенных примеров для Oracle и Sybase будет следующий запрос:

Получить имена и объемы продаж всех служащих, опережающих план.

SELECT NAME, QVOTA, SALES

FROM SAMPLE8CENTRALH0ST:SALESREPS WHERE SALES > QUOTA

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

прозрачность доступа к удаленным данным

Достаточно написать лишь несколько запросов, чтобы почувствовать, насколько это неудобно и утомительно - при работе с удаленными базами данных уточнять имена таблиц и представлений именем базы данных, канала связи, сервера и т.п. Например, если в двух таблицах удаленной базы данных имеются столбцы с одинаковыми именами, в любом запросе, извлекающем данные из обеих таблиц, должны использоваться префиксы имен столбцов - имена таблиц, в которых, в свою очередь, должны быть префиксы для удаленного доступа. Вот полное имя столбца name в удаленной таблице salesreps, принадлежащей пользователю joe и хранящейся в удаленной базе данных sample на удаленном сервере centralhost в СУБД Informix:

SAMPLE@CENTRALH0ST,JOE.SALESREPS.NAME

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

CREATE SYNONYM REMOTE REPS FOR SAMPLE8CENTRALH0ST.JOE.SALESREPS

Эквивалентное определение синонима в Oracle выглядит так:

CREATE SYNONYM REMOTE REPS FOR JOE.SALESREPS@CENTRALHOST

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

REMOTE REPS.NAME

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

Некоторые производители СУБД идут еще дальше и позволяют в локальной базе данных создавать представления на основе удаленных таблиц. Вот пример инструкции Oracle, создающей представление east reps:

CREATE VIEW EAST REPS AS

SELECT EMPL NUM, NAME, AGE, CITY

FROM SALESREPS8CENTRALH0ST, OFFICES@CENTRALHOST WHERE REP OFFICE = OFFICE

AND REP OFFICE BETWEEN 11 AND 19

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

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

С прозрачностью удаленного доступа связан и еще один важный вопрос: если удаленные таблицы кажутся локальными, может ли пользователь формулировать запросы, в которых локальные и удаленные таблицы используются совместно! Можно ли, например, объединять таблицы, хранящиеся на разных серверах, и связывать информацию из удаленной и локальной баз данных Еще более серьезный вопрос возникает при анализе транзакций. Если СУБД допускает прозрачный доступ к удаленной базе данных, может ли пользователь обновитъ строку локальной базы данных и добавить сфоку в удаленную базу данных, а затем отменить всю транзакцию Поскольку удаленные ресурсы представляются полюователю локальными, очевидным ответом будет: Конечно, ведь локальные и удаленные таблицы должны представляться пользователю единой локальной базой данных

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

Дублирование таблиц

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

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