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

¥Щ

Покатмщ \ данные о <

плате

Локальный сервер

Локаньные банные о

плате

Локальный сервер

Центральный сервер

Рис. 12.3. Горизонтально секционированные данные

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

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

Пример: выплата страхового возмещения

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

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

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

-обнсвляемшй снитж

оеноапявиьШ

Локальный сервер

Обновления

Обновления

Локальный сервер

Главная S 1<та5пиц1 рспользувипя

только

Центральный сервер

Рис. 12.4. Использование обновляемых снимков для распространения итоговых данных

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

Пример: обновление через глобальную сеть

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

момент все еще крайне сложно при помощи одной базы данных Oracle обслуживать свыще 2000 одновременно работающих пользователей.

Почти так же сложно поддерживать 100000 одновременно работающих пользователей на одном мэйнфрейме, но этот уровень сервиса нeoбxoдиf ряду предприятий, и они изо дня в день обеспечивают его вот уже несколько лет, причем время работы в таком режиме превыщает 99%.

Вы (или ваще руководство) можете отвергнуть вариант с мэйнфреймом по ряду понятных причин:

высокая стоимость аппаратных средств;

больщой сетевой трафик;

высокая стоимость разработки;

больщие сроки разработки.

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

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