Распределенные банки данных

Следует выделить два класса систем распределенной обработки и систем распределенных данных:

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

2. системы распределенных данных, которые обеспечивают обработку распределенных запросов, используя информационные ресурсы, размещенные на различных ЭВМ сети.

Для распределенных баз данных свойственны следующие характеристики:

· база данных – это логически связанные, разделяемые на некоторое количество фрагментов данные;

· фрагменты распределяются по разным узлам, которые связаны между собой сетевыми соединениями;

· может быть предусмотрена репликация фрагментов;

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

Требования к распределенной обработке данных

Основные условия и требования к распределенной обработке данных:

· прозрачность относительно расположения данных (СУБД должна представлять все данные так, как если бы они были локальными);

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

· прозрачность относительно сети (СУБД должна одинаково работать в условиях разнородных сетей);

· поддержка распределенных запросов (пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах);

· поддержка распределенных изменений (пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах);

· поддержка распределенных транзакций (СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдельных системах, так и в сети);

· безопасность (СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа);

· универсальность доступа (СУБД должна обеспечивать единую методику доступа ко всем данным).

Любой пользователь или любая прикладная программа оперирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на одном и том же узле, проблемы расположения не возникает. Однако в том случае, когда прикладная программа запускается на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того чтобы получить доступ к базе данных на удаленном узле, необходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре «имя_узла, имя_БД», то прикладная программа становится зависимой от расположения БД. Например, обращение к БД «host: stock», где первый компонент – имя узла, будет зависимым от расположения.

Одно из возможных решений этой проблемы состоит в использовании виртуальных имен узлов. Управление ими обеспечивается специальным программным компонентом СУБД – сервером имен (Name Server), который адресует запросы клиентов к серверам.

Ни один из существующих Бнд не удовлетворяет всем указанным требованиям вследствие следующих практических проблем:

· низкая и несбалансированная производительность сетей передачи данных;

· в разных системах используются разные физические форматы и кодировки;

· трудности выбора схемы размещения системных каталогов;

· необходимость обеспечить совместимость СУБД разных типов и поставщиков;

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

Распределенные СУБД

Распределенные СУБД подразделяются на однородные и разнородные.

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

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

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

· расширенные службы установки соединений должны обеспечивать доступ к удаленным узлам и позволять передавать запросы и данные между узлами, входящими в сеть;

· расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных в сети;

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

· расширенные функции управления защитой, позволяющие обеспечить соблюдение правил авторизации и прав доступа к распределенным данным;

· расширенные функции управления параллельным выполнением, позволяющие поддерживать целостность копируемых данных;

· расширенные функции восстановления, учитывающие вероятность отказов в работе отдельных узлов и отказов линий связи.

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

Процедуры базы данных

В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т. д.

Использование процедур базы данных преследует четыре цели:

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

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

• значительное снижение трафика сети в системах с архитектурой «клиент—сервер». Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры;

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

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

Правила

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

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

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

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

Важнейшая цель механизма правил – обеспечение целостности базы данных. Один из аспектов целостности – целостность по ссылкам (referential integrity) – относится к связи двух таблиц между собой.

Размещение данных в распределенных БД

Размещение данных в распределенных БД характеризуется следующими понятиями:

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

• размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы доступа;

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

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

Существуют четыре стратегии размещения данных в системе:

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

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

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

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

Доступ к данным в распределенных БД

Мобильный интерфейс к базам данных на платформе Java — JDBC (Java Data Base Connectivity) – это интерфейс прикладного программирования (API) для выполнения SQL-запросов к базам данных из программ, написанных на платформенно-независимом языке Java, позволяющем создавать как самостоятельные приложения, так и аплеты, встраиваемые в Web-страницы.

JDBC имеет ряд следующих отличий;

· приложения загружают JDBC-драйвер динамически, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места;

· JDBC, как и Java в целом, не привязан к конкретной аппаратной платформе, следовательно проблемы с переносимостью приложений практически снимаются;

· использование Java-приложений и связанной с ними идеологии «тонких клиентов» обещает снизить требования к оборудованию клиентских рабочих мест.

Прикладные интерфейсы OLE DB и ADO – это прикладные интерфейсы доступа к данным с использованием SQL.

OLE DB (Object Linking and Embedding Data Base) специфицирует взаимодействие, обеспечивая единый интерфейс доступа к данным через провайдеров – поставщиков данных не только из реляционных БД. OLE DB предоставляет приложениям общее решение обеспечения доступа к информации независимо от типа источника данных.

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

ADO (Active Data Object) – это универсальный интерфейс высокого уровня. Модель объекта ADO не содержит таблиц, среды или машины БД. Здесь основными объектами являются следующие: объект Соединение, создающий связь с провайдером данных; объект Набор данных и объект Команда – выполнение процедуры, SQL-строки. В общем случае ADO можно рассматривать как язык программирования, позволяющий выбирать, модифицировать и удалять записи.