Гайдамакин Н. А. 12 страница

Технологически в реляционных СУБД техника представ­лений реализуется через введение в язык SQL-конструкций, позволяющих аналогично технике «событий-правил-процедур» создавать именованные запросы-представления:

CREAТЕ VIEW ИмяПредставленият AS

SELECT...

FROM...

...;

В данных конструкциях после имени представления и клю­чевого слова AS размещается запрос на выборку данных, соб­ственно и формирующий соответствующее представление ка­кого-либо объекта базы данных.

Авторизация представлений осуществляется применением команд (директив) GRANT, присутствующих в базовом переч­не инструкций языка SQL (см. п. 4.1) и предоставляющих пол­номочия и привилегии пользователям:

GRANT SELECTON ИмяПредставления TO ИмяПользователя1, ИмяПользователя2,...;

Соответственно директива REVOKE отменяет уставленные ранее привилегии.

Несмотря на простоту и определенную изящность идеи «представлений», практическая реализация подобной техноло­гии построения и функционирования распределенных систем встречает ряд серьезных проблем. Первая из них связана с раз­мещением системного каталога базы данных, ибо при фор­мировании для пользователя «представления» распределенной базы данных ядро СУБД в первую очередь должно «узнать», где и в каком виде в действительности находятся данные. Тре­бование отсутствия центральной установки приводит к выводу о том, что системный каталог должен быть на любой локаль­ной установке. Но тогда возникает проблема обновлений. Если какой-либо пользователь изменил данные или их структуру в системе, то эти изменения должны отразиться во всех копиях системного каталога. Однако размножение обновлений систем­ного каталога может встретить трудности в виде недоступнос­ти (занятости) системных каталогов на других установках в момент распространения обновлений. В результате может быть не обеспечена непрерывность согласованного состояния дан­ных, а также возникнуть ряд других проблем.

Решение подобных проблем и практическая реализация распределенных информационных систем осуществляется че­рез отступление от некоторых рассмотренных выше принци­пов создания и функционирования распределенных систем. В зависимости оттого, какой принцип приносится в «жертву» (отсутствие центральной установки, непрерывность функцио­нирования, согласованного состояния данных и др.) выдели­лись несколько самостоятельных направлений в технологиях распределенных систем — технологии «Клиент-сервер», тех­нологии реплицирования, технологии объектного связывания.

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

5.2. Технологии и модели «Клиент-сервер»

Системы на основе технологий «Клиент-сервер» истори­чески выросли из первых централизованных многопользова­тельских автоматизированных информационных систем, ин­тенсивно развивавшихся в 70-х годах (системы main frame), и получили, вероятно, наиболее широкое распространение в сфе­ре информационного обеспечения крупных предприятий и кор­пораций.

В технологиях «Клиент-сервер» отступают от одного из главных принципов создания и функционирования распределен­ных систем — отсутствия центральной установки. Поэто­му можно выделить две основные идеи, лежащие в основе кли­ент-серверных технологий:

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

• много пользователей (клиентов) на различных вычисли­тельных установках, совместно (параллельно и одновременно) обрабатывающих общие данные.

Иначе говоря, системы, основанные на технологиях «Кли­ент-сервер», распределены только в отношении пользователей, поэтому часто их не относят к «настоящим» распределенным системам, а считают отдельным, уже упоминавшимся классом многопользовательских систем.

Важное значение в технологиях «Клиент-сервер» имеют понятия сервера и клиента.

Под сервером в широком смысле понимается любая сис­тема, процесс, компьютер, владеющие каким-либо вычисли­тельным ресурсом (памятью, временем, производительностью процессора и т. д.).

Клиентом называется также любая система, процесс, ком­пьютер, пользователь, запрашивающие у сервера какой-либо ресурс, пользующиеся каким-либо ресурсом или обслуживаемые сервером иным способом.

В своем развитии системы «Клиент-сервер» прошли не­сколько этапов, в ходе которых сформировались различные модели систем «Клиент-сервер». Их реализация и, следователь­но, правильное понимание основаны на разделении структу­ры СУБД на три компонента:

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

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

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

Исходя из особенностей реализации и распределения (рас­положения) в системе этих трех компонентов различают четы­ре модели технологий «Клиент-сервер»:*

• модель файлового сервера (File Server — FS);

• модель удаленного доступа к данным (Remote Data Access—RDA);

• модель сервера базы данных (DataBase Server — DBS);

• модель сервера приложении (Application Server — AS).

* Ладыженский Г.М. Системы управления базами данных — коротко о глав­ном//СУБД.—№№1-4.—1995.

 

5.2.1. Модель файлового сервера

Модель файлового сервера является наиболее простой и характеризует собственно не столько способ образования фак­тографической информационной системы, сколько общий спо­соб взаимодействия компьютеров в локальной сети. Один из компьютеров сети выделяется и определяется файловым сер­вером, т. е. общим хранилищем любых данных. Суть FS-модели иллюстрируется схемой, приведенной на рис. 5.2.

Рис. 5.2. Модель файлового сервера

В FS-модели все основные компоненты размещаются на клиентской установке. При обращении к данным ядро СУБД, в свою очередь, обращается с запросами на ввод-вывод данных за сервисом к файловой системе. С помощью функций опера­ционной системы в оперативную память клиентской установ­ки полностью или частично на время сеанса работы копирует­ся файл базы данных. Таким образом, сервер в данном случае выполняет чисто пассивную функцию.

Достоинством данной модели являются ее простота, от­сутствие высоких требований к производительности сервера (главное — требуемый объем дискового пространства). Следу­ет также отметить, что программные компоненты СУБД в дан­ном случае не распределены, т. е. никакая часть СУБД на сер­вере не инсталлируется и не размещается.

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

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

5.2.2. Модель удаленного доступа к данным

Модель удаленного доступа к данным основана на учете специфики размещения и физического манипулирования дан­ных во внешней памяти для реляционных СУБД. В RDA-модели компонент доступа к данным в СУБД полностью отделен от двух других компонентов (компонента представления и при­кладного компонента) и размещается на сервере системы. Ком­понент доступа к данным реализуется в виде самостоятельной программной части СУБД, называемой SQL-сервером, и инстал­лируется на вычислительной установке сервера системы. Фун­кции SQL-сервера ограничиваются низкоуровневыми операци­ями по организации, размещению, хранению и манипулирова­нию данными в дисковой памяти сервера. Иначе говоря, SQL-сервер играет роль машины данных. Схема RDA-модели приведена на рис. 5.3.

Рис. 5.3. Модель удаленного доступа к данным (RDA -модель)

В файле (файлах) базы данных, размещаемом на сервере системы, находится также и системный каталог базы данных, в который помещаются в том числе и сведения о зарегистриро­ванных клиентах, их полномочиях и т. п.

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

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

Другим, может быть неявным, достоинством RDA-модели является унификация интерфейса взаимодействия приклад­ных компонентов информационных систем с общими данны­ми. Такое взаимодействие стандартизовано в рамках языка SQL уже упоминавшимся специальным протоколом ODBC* (Open Database Connectivity), играющим важную роль в обеспечении интероперабельности, т. е. независимости от типа СУБД на клиентских установках в распределенных системах. Иначе го­воря, специальный компонент ядра СУБД на сервере (так на­зываемый драйвер ODBC) способен воспринимать, обрабаты­вать запросы и направлять результаты их обработки на клиен­тские установки, функционирующие под управлением реляционных СУБД других, не «родных» типов. Такая возможность суще­ственно повышает гибкость в создании распределенных инфор­мационных систем на базе интеграции уже существующих в какой-либо организации локальных баз данных под управле­нием настольных или другого типа реляционных СУБД. Спе­циальные драйверы ODBC могут обеспечить возможность ис­пользования настольной СУБД в качестве клиента SQL-серве­ра «тяжелой» многопользовательской клиент-серверной СУБД.

* Стандартный протокол доступа к данным на серверах баз данных SQL.

 

К недостаткам RDA-модели можно отнести высокие тре­бования к клиентским вычислительным установкам, так как прикладные программы обработки данных, определяемые спе­цификой предметной области АИС, выполняются на них. Дру­гим недостатком является все же существенный трафик сети, обусловленный тем, что с сервера базы данных клиентам на­правляются наборы (таблицы) данных, которые в определен­ных случаях могут занимать достаточно существенный объем.

5.2.3. Модель сервера базы данных

Развитием RDA-модели стала модель сервера базы данных. Ее сердцевиной является рассмотренный ранее механизм хра­нимых процедур. В отличие от RDA-модели, определенные для конкретной предметной области АИС события, правила и про­цедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и вы­полняется на сервере системы. Схематично DBS-модель при­ведена на рис. 5.4.

Рис. 5.4. Модель сервера базы данных (DBS-модель)

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

Следует, однако, заметить, что на сервере системы выпол­няются процедуры прикладных задач одновременно всех пользователей системы. В результате резко возрастают тре­бования к вычислительной установке сервера, причем как к объему дискового пространства и оперативной памяти, так и к быстродействию. Это основной недостаток DBS-модели.

К достоинствам же DBS-модели, помимо разгрузки сети, относится и более активная роль сервера сети, размещение, хранение и выполнение на нем механизма событий, правил и процедур, возможность более адекватно и эффективно «настра­ивать» распределенную АИС на все нюансы предметной обла­сти системы. Также более надежно обеспечивается согласованность состояния и изменения данных, и, вследствие этого, повышается надежность хранения и обработки данных, эффек­тивно координируется коллективная работа пользователей с общими данными.

5.2.4. Модель сервера приложений

Чтобы разнести требования к вычислительным ресурсам сервера в отношении быстродействия и памяти по разным вы­числительным установкам, используется модель сервера при­ложений. Суть AS-модели заключается в переносе прикладно­го компонента АИС на специализированный в отношении по­вышенных ресурсов по быстродействию дополнительный сервер системы. Схема AS-модели приведена на рис. 5.5.

Рис. 5.5. Модель сервера приложений (AS-модель)

Как и в DBS-модели, на клиентских установках распола­гается только интерфейсная часть системы, т.е. компонент представления. Однако вызовы функций обработки данных на­правляются на сервер приложений, где эти функции совместно выполняются для всех пользователей системы. За выполнени­ем низкоуровневых операций по доступу и изменению данных сервер приложений, как в RDA-модели, обращается к SQL-сер­веру, направляя ему вызовы SQL-процедур, и получая, соответ­ственно, от него наборы данных. Как известно, последователь­ная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзак­цией. В этом отношении сервер приложений от клиентов сис­темы управляет формированием транзакций, которые выпол­няет SQL-сервер. Поэтому программный компонент СУБД, ин­сталлируемый на сервере приложений, еще называют также монитором обработки транзакций (Transaction Processing Monitors — TRM), или просто монитором транзак­ций.

AS-модель, сохраняя сильные стороны DBS-модели, позво­ляет более оптимально построить вычислительную схему ин­формационной системы, однако, как и в случае RDA-модели, повышает трафик сети.

В еще не устоявшейся до конца терминологии по моделям и технологиям «Клиент-сервер» RDA-модель характеризуют еще как модель с так называемыми «толстыми», а DBS-модель и AS-модель как модели, соответственно, с «тонкими» клиен­тами. По критерию звеньев системы RDA-модель и DBS-мо­дель называют двухзвенными (двухуровневыми) системами, a AS-модель трехзвенной (трехуровневой) системой.

В практических случаях используются смешанные моде­ли, когда простейшие прикладные функции и обеспечение ог­раничений целостности данных поддерживаются хранимыми на сервере процедурами (DBS-модель), а более сложные функ­ции предметной области (так называемые «правила бизнеса») реализуются прикладными программами на клиентских уста­новках (RDA-модель) или на сервере приложений (AS-модель).

5.2.5. Мониторы транзакций

Сердцевиной и основой эффективности функционирова­ния многопользовательских систем «Клиент-сервер» является эффективное управление транзакциями. Собственно само понятие транзакции возникло именно в процессе исследования принципов построения и функционирования централизованных многопользовательских реляционных СУБД. Транзакции игра­ют важную роль в механизме обеспечения СУБД ограничений целостности базы данных. Ограничения целостности непос­редственно проверяются по завершению очередной транзакции. Если условия ограничений целостности данных не выполня­ются, то происходит «откат» транзакции (выполняется SQL-инструкция ROLLBAСК), в противном случае транзакция фик­сируется (выполняется SQL-инструкция COMMIT).

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

• потерянные изменения;

• «грязные» данные;

• неповторяющиеся чтения.

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

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

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

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

• синхронизационные захваты (блокировки) объектов базы данных;

• временные метки объектов базы данных.

В первом подходе определяется два основных режима зах­ватов — совместный режим (Shared) и монопольный режим (exclusive). При совместном режиме осуществляется разделя­емый захват, требующий только операций чтения. Поэтому та­кой захват еще называют захватом по чтению. При монополь­ном режиме осуществляется неразделяемый захват, требующий операций обновления данных. Такой захват, соответственно, еще называют захватом по записи.

Наиболее распространенным вариантом первого подхода является реализация двухфазного протокола синхронизаци­онных захватов (блокировок) объектов базы данных — 2PL (Two-Phase Locks). В соответствии с данным протоколом вы­полнение транзакции происходит в два этапа. На первом этапе (первая фаза) перед выполнением любой операции транзакция запрашивает и накапливает захваты необходимых объектов в со­ответствующем режиме. После получения и накопления необхо­димых захватов (блокировок) осуществляется вторая фаза — фиксация изменений (или откат по соображениям целостности данных) и освобождение захватов.

При построении сериальных планов допускается совме­щение только захватов по чтению. В остальных случаях тран­закции должны «ждать», когда необходимые объекты разблокируются (освободятся). Более изощрённые стратегии сериа­лизации транзакций основываются на «гранулировании» объектов захвата (файл базы данных, отдельная таблица, стра­ница файла данных, отдельная запись-кортеж). Соответствен­но при этом расширяется номенклатура синхронизационных режимов захватов, например в совместном режиме (по чте­нию) может быть захвачен и в целом файл и отдельные его стра­ницы, или в другом случае обеспечивается совместный режим захвата файла с возможностью монопольного захвата отдель­ных его объектов — таблиц, страниц или записей-кортежей). Грануляция синхронизационных блокировок позволяет строить более эффективные планы сериализации транзакций.

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

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

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

Более простой альтернативой технике синхронизационных захватов является техника временных меток. Суть этого ме­тода заключается в том, что каждой транзакции приписывает­ся временная метка, соответствующая моменту начала вы­полнения транзакции. При выполнении операции над объектом транзакция «помечает» его своей меткой и типом операции (чтение или изменение). Если при этом другой транзакции тре­буется операция над уже «помеченным» объектом, то выполня­ются действия по следующему алгоритму:

• проверяется, не закончилась ли транзакция, первой «по­метившая» объект;

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

• если первая транзакция не закончилась, то проверяется конфликтность операций (напомним, что конфликтно любое сочетание, кроме «чтение-чтение»);

• если операции неконфликтны, то они выполняются для обеих транзакций, а объект до завершения операций помечает­ся меткой более поздней, т. е. более молодой транзакции;

• если операции конфликтны, то далее происходит откат более поздней транзакции и выполняется операция более ран­ней (старшей) транзакции, а после ее завершения объект поме­чается меткой более молодой транзакции и цикл действий по­вторяется.

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

СУБД идеологии «Клиент-сервер», называемые иногда в противовес однопользовательским («настольным») «тяжелыми» системами (Oracle, SyBase, Informix, Ingres и др.), составляют одно из наиболее интенсивно развивающихся направлений цен­трализованных многопользовательских систем, охватывая сво­им управлением сотни тысяч гигабайтов фактографических данных, и в этом отношении еще долгое время будут играть роль фактического стандарта корпоративных информационных си­стем.

5.3. Технологии объектного связывания данных

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

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