Лекция 5 распределенные базы данных

• Название: Лекция 5 распределенные базы данных
• Дата: 17.05.2023
• Размер: 206.91 Kb.
• Имя файла: 385568.pptx
• Тип: Лекция; #1138554

ЛЕКЦИЯ 5 РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

Основные принципы создания и функционирования распределенных баз данных
Трудности в практической реализации распределенных систем

технология клиент-сервер
технология тиражирования
технология объектного связывания

1. Много организационно и физически распределенных пользователей работают с общими данными; пользователи с разными именами, полномочиями и задачами, расположены на разных вычислительных системах.

2. Логически и физически распределенные данные, составляющие единое взаимосвязанное целое – общую БД, могут находиться на различных вычислительных установках.

Именно эти две идеи положены в основу создания распределенных ИС и баз данных.

Понятие распределенной БД (DDB)

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

Определение идеальной DDB Криса Дейта

Локальная автономия (local autonomy)
Независимость узлов (no reliance on central site)
Непрерывные операции (continuous operation)
Прозрачность расположения (location independence)
Прозрачная фрагментация (fragmentation independence)
Прозрачное тиражирование (replication independence)
Обработка распределенных запросов (distributed query processing)
Обработка распределенных транзакций (distributed transaction processing)
Независимость от оборудования (hardware independence)
Независимость от операционных систем (operationg system independence)
Прозрачность сети (network independence)
Независимость от баз данных (database independence)

1. Локальная автономия

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

2. Независимость от центрального узла

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

3. Непрерывные операции

Это качество можно трактовать как возможность непрерывного доступа к данным (известное выражение "24 часа в сутки, семь дней в неделю") в рамках DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах.
Это качество можно выразить лозунгом "данные доступны всегда, а операции над ними выполняются непрерывно".

4. Прозрачность расположения

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

5. Прозрачная фрагментация

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

6. Прозрачность тиражирования

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

7. Обработка распределенных запросов

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

8. Обработка распределенных транзакций

Это качество DDB можно трактовать как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных.
Эта цель достигается применением двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.

9. Независимость от оборудования

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

10. Независимость от операционных систем

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

11. Прозрачность сети

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

12. Независимость от баз данных

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

ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ DDB

Возникающие проблемы:

Проблемы техники представлений (Views)
Проблема целостности данных
Проблема обработка распределенных запросов
Проблема межоперабельности

Определение представления

Представлением называется сохраняемый в БД авторизованный глобальный запрос на выборку.
Авторизованность означает возможность запуска его конкретным поименованным пользователем.
Глобальность означает возможность выборки данных из всех БД, находящихся на разных узлах системы.


В результате таких глобальных авторизованных запросов для конкретного пользователя создается некая виртуальная БД, со своим перечнем таблиц, связей, со своей схемой данных.
Техника представлений реализуется через введение в язык SQL специализированных конструкций.
Практическая реализация техники представлений встречает ряд серьезных проблем.


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


Проблемы практической реализации представлений

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


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

Обработка распределенных запросов

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

Межоперабельность

Во-первых, - это качество, позволяющее обмениваться данными между БД различных поставщиков. Как, например, тиражировать данные из базы данных Informix в Oracle и наоборот? Ответом стало появление продуктов, выполняющих тиражирование между разнородными БД.
Во-вторых, это возможность некоторого унифицированного доступа к данным в DDB из приложения. Возможны как универсальные решения (стандарт ODBC), так и специализированные подходы.
Очевидный недостаток ODBC - недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения не поддерживаются.

ОТСТУПЛЕНИЕ ОТ ПРИНЦИПОВ ИДЕАЛЬНОЙ DDB КРИСА ДЕЙТА

Если в жертву приносится принцип 2 (независимость узлов ), то получаем DDB, реализованную по технологии клиент -сервер.
Если в жертву приносится принцип 3 (непрерывные операции ), то получаем DDB, реализованную по технологии реплицирования (тиражирования).
Если в жертву приносится принцип 1 (локальная автономия ), то получаем DDB, реализованную по технологии объектного связывания.

ТЕХНОЛОГИИ "КЛИЕНТ-СЕРВЕР"

Основной принцип данной технологии заключается в разделении функций стандартного клиентского приложения на четыре группы:

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

Логические компоненты СУБД

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

Модели технологии «клиент-сервер»

Модель файлового сервера (File Server — FS);
Модель доступа к удаленным данным (Remote Data Access — RDA);
Модель сервера базы данных (DataBase Server — DBS);
Модель сервера приложений (Application Server — AS).


7.6.3 Модель файлового сервера (FS)

Сетевая ОС

FS-модель является базовой для локальных сетей ПЭВМ. Суть модели проста. Один из компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам.
Файловый сервер работает под управлением сетевой ОС и играет роль компонента доступа к информационным ресурсам (то есть к файлам). На других компьютерах в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент.
Протокол обмена представляет собой набор низкоуровневых вызовов, обеспечивающих приложению доступ к файловой системе на файловом сервере.

FS-модель и персональные СУБД

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

Недостатки модели FS

К технологическим недостаткам модели относят высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипулирования данными ("данные — это файлы"), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы).
Собственно, перечисленное не есть недостатки, это следствие внутренне присущих FS-модели ограничений, определяемых ее характером. Недоразумения возникают в том случае, когда FS-модель используют не по назначению — например, пытаются интерпретировать как модель сервера базы данных. Место FS-модели в иерархии моделей "клиент-сервер" — это место модели файлового сервера и ничего более.


Модель доступа к удаленным данным (RDA)

ЯДРО СУБД

Отличие RDA – модели от FS

Более технологичная RDA-модель существенно отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как правило, SQL-сервер.
В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Клиент поддерживает как функции ввода и отображения данных, так и чисто прикладные функции.
Доступ к информационным ресурсам на сервере обеспечивается либо операторами языка SQL, либо вызовами функций специальной библиотеки (если имеется интерфейс прикладного программирования — API)

Достоинство RDA-модели

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

Пассивная роль ядра СУБД в RDA

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

Недостатки RDA-модели

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


Модель сервера базы данных (DBS)

ЯДРО СУБД

Достоинства DBS-модели

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


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

Недостатки DBS-модели

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


Модель сервера приложений (AS)

Application Programming Interface (API) - стандарт прикладного программного интерфейса

Реализация AS-модели

В AS-модели процесс, выполняющийся на компьютере-клиенте, отвечает за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client — AC).
Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server — AS).
Все низкоуровневые операции над информационными ресурсами выполняются компонентом доступа на отдельном сервере, по отношению к которому AS играет роль клиента.

Двухзвенная схема разделения функций

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

Трехзвенная схема разделения функций

В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами.
AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors — TPM), которые выделяются как особый вид программного обеспечения, ориентированного на оперативную обработку распределенных транзакций.

Программное обеспечение промежуточного слоя (Middleware)

Трехзвенной AS – модель можно считать и потому, что в ней явно выделены:

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


Главная ошибка, которая может быть совершена при построении современных распределенных систем - это полное игнорирование ПО промежуточного слоя класса Middleware и использование вместо него двухзвенных моделей "клиент-сервер".
Существует фундаментальное различие между

двухзвенными моделями (технология «SQL-клиент - SQL-сервер» и

трехзвенными моделями (технология ПО класса Middleware, например, менеджера распределенных транзакций Tuxedo System).

В случае двухзвенной модели клиент явным образом запрашивает данные, зная структуру базы данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент передает СУБД SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка- точка«, для реализации которой все СУБД используют закрытый SQL-канал (например, Oracle SQL*Net).
Канал закрыт в том смысле, что невозможно, например, использовать программу шифрования SQL- запросов по специальному алгоритму (стандартные алгоритмы шифрования, используемые, например, в Oracle SQL*Net, не сертифицированы и вряд ли будут сертифицированы в будущем.)


В случае трехзвенной модели клиент явно запрашивает один из сервисов (предоставляемых прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ также в виде сообщения.
Клиент направляет запрос в информационную шину (которую строит менеджер Tuxedo System), ничего не зная о месте расположения сервиса.
Имеет место так называемый function shipping (то есть "поставка функций" клиенту). Важно, что для клиента база данных (в том числе и DDB) закрыта слоем сервисов. Более того, он вообще ничего не знает о ее существовании, так как все операции над базой данных выполняются внутри сервисов.

Вывод по моделям «Клиент-сервер»

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

Технология тиражирования

В отличие от распределенных баз DDB, тиражирование данных (Data Replication). предполагает отказ от их физического распределения и опирается на идею дублирования данных в различных узлах сети компьютеров.
Cуть технологии тиражирования состоит в том, что любая БД (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные всегда размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.

Тиражирование данных

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

Технологии - антиподы

Технология распределенных БД и технология тиражирования данных — в определенном смысле антиподы.
Краеугольный камень первой (DDB) — синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в распределенной БД.
"Ахиллесова пята" этой технологии— жесткие требования к производительности и надежности каналов связи.


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

Преимущества технологии тиражирования

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

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

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

Недостатки технологии тиражирования

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


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

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

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

Работа со связанными объектами

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


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

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

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