2. Модели распределенных баз данных

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

Рассмотрим каждый класс систем более подробно.

2.1. Однородные и неоднородные системы

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

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

Противоположностью однородных систем РаБД являются, конечно, неоднородные распределенные системы баз данных. Неоднородные системы включают два или более существенно различающихся продукта управления данными (например, реляционные СУБД от разных поставщиков, таких, как Oracle и Digital Equipment Corp.*, или СУБД одного поставщика, но функционирующие на разных платформах и использующие различные структуры баз данных**, такие, как DB2 и SQL/DS компании IBM). На рис. 2.2 показана типичная конфигурация неоднородной распределенной базы данных. Неоднородные системы баз данных можно, в свою очередь, также подразделить на классы в широком диапазоне - от федеративных систем до различных типов систем мультибаз данных; существует и формальная таксономия неоднородных моделей.

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

2.2. Методы построения распределенных баз данных "сверху вниз" и "снизу вверх"

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

Однако при проектировании РаБД методом "сверху вниз" предполагается, что ее объекты не будут сосредоточены в одном месте, а распределятся по нескольким вычислительным системам (рис. 2.3). Распределение проводится путем фрагментации или тиражирования.

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

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

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

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

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

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

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

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

• управление метаданными;

• разрешение несоответствий типов данных в разных БД (элемент MOVIE_TYPE - тип фильма - в одной базе данных имеет числовое  представление, а в другой - символьное).