Ю. А. Григорьев, Г. И. Ревунков - Банки данных

12. Логическое проектирование систем распределенной обработки данных

Рис. 12.7. Пример базы данных «Поставщик» с двумя таблицами

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

Здесь общий атрибут «Код поставщика» является ключом таблицы Адрес.

3. Таблицы А и В могут и не иметь общих атрибутов. Но в этом случае теряется возможность соединения (связывания) этих таблиц.

Расмотрим случай, когда неправильное построение БД приводит к из­ быточности, потенциальной противоречивости, к аномалиям включения и удаления данных. Например, БД приведенная на рис. 12.6, имеет следую­ щие недостатки:

1) избыточность. Адрес поставщика повторяется для каждого постав­ ляемого им товара;

2)потенциальная противоречивость (аномалия обновления). Вследст­ вие избыточности при изменении адреса поставщика важно не забыть обно­ вить этот адрес во всех записях, куда он входит;

3)аномалия включения. В базу данных не может быть записан адрес поставщика, если он в настоящее время не поставляет по меньшей мере один товар. Можно, конечно, поместить неопределенное значение (NULL) в поля «Товар» и «Цена за единицу» записи поставщика. Но если он начнет поставлять некоторый товар, важно не забыть удалить запись (кортеж) с неопределенными значениями. Хуже того, поля «Код поставщика» и «То­ вар» образуют ключ таблицы «Поставщик» (см. рис. 12.6) и поиск кортежей

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

4)аномалия удаления. После удаления из базы всех товаров постав­ щика теряется и его адрес.

Схема базы данных, представленная на рис. 12.7, не имеет указанных

210

12.1. Разработка логической схемы базы данных

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

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

Для схемы, показанной на рис. 12.6, атрибут «Адрес поставщика» за­ висит не только от ключа («Код поставщика», «Товар»), но и от атрибута «Код поставщика». Поэтому таблица, приведеная на рис. 12.6, не находится в третьей нормальной форме. После декомпозиции (см. рис. 12.7) каждая из новых таблиц «Адрес» и «Товар» находится в третьей нормальной форме.

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

Выбор способа тиражирования данных в распределенной системе.

В настоящее время в СРОД поддерживаются два метода автоматической репликации (копирования) данных:

•синхронный (метод двухфазной фиксации);

•асинхронный (метод тиражирования).

Первый метод репликации рассматривается в гл. 13. Рассмотрим спо­ собы тиражирования данных, относящихся к асинхронному методу.

На рис. 12.8 приведена общая схема организации тиражирования. В процессе выполнения ПП ведет так называемые логические транзакции. Транзакция начинается командой НТ и завершается командой КТ. При вы­ полнении программы сервер СУБД сохраняет в журнале изменений отметки начала и конца транзакции, а также все изменения, выполненные в БД за этот период. Сервер, где можно модифицировать таблицы БД, называют первичным сервером, а изменяемые данные таблиц — первичными данны­ ми. В узле, содержащем первичные данные, для каждой тиражируемой БД запускается специальный компонент: менеджер журнала транзакций (LTM — Log Transfer Manager). Он подключается к серверу СУБД и получает от него уведомления о завершении транзакций. Данные (транзакция) из журнала изменений передаются репликационному серверу, обслуживающему этот узел.

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

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

•все данные тиражируются из одного первичного сервера.

211

12. Логическое проектирование систем распределенной обработки данных

Журнал изменений

Репликационный сервер"

Публикации

Подписка

Server 3

Ограничения 1 на первич­

ный ключ записей, кото­

рые могут тиражироваться , Server 2 'Server 3

Ограничения 2..

Рис. 12.8. Схема тиражирования данных

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

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

Тираэюирование ш первичного (основного) узла (рис. 12.9). Эта схема яв­ ляется основной и она реализована во всех крупных СУБД, поддерживающих распределенную обработку (Oracle, Sybase, DB/2 и др.). В СУБД Informix реали­ зован механизм полного тиражирования данных одного сервера на другой (ре­ зервный). Наличие одного (для группы строк таблицы) первичного сервера яв­ ляется принципиально важным, так как позволяет избежать:

•зацикливания при обновлении (копия не может распространять изменения),

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

212

12.1. Разработка логической схемы базы данных

Первичный сервер (чтение и обновление таблиц)

Тиражирование

Вторичные серверы (копии только на чтение)

Рис. 12.9. Трфажирование из основного узла

Первичный сервер

Тиражирование

Специальный кабель

Копии

Резервный первичный сервер

Рис. 12.10. Тиражирование из первичного сервера или его резерва

онный сервер вторичного сервера принимает и обрабатывает транзакции также последовательно).

Тираоюирование из первичного сервера и его резерва (рис. 12.10). Эта схема реализуется в системах с СУБД Oracle и Ingres. Здесь резервный сер­ вер работает в режиме горячего резервирования: измененные данные тут же пересылаются на резервный сервер. Резервный сервер периодически опра­ шивает основной сервер по специальному кабелю. Если при очередном оп­ росе основной сервер не отвечает, то резервный сервер считает, что первич­ ный сервер вышел из строя, и начинает работать в качестве основного. Он принимает изменения и тиражирует их на вторичные серверы. Ясно, что основной и резервный серверы должны быть подключены к одной сети. Использование резерва резко повышает надежность всей системы.

Поточная модель (рис. 12.11). Владелец, т.е. узел, который объявля­ ется первичным, может меняться динамически. Эта схема использована в

213

12. Логическое проектирование систем распределенной обработки данных

Рис. 12.П. Поточная модель тиражирования

Первичный сервер

Рис. 12.12. Иерархическая модель тиражирования

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

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

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

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

214

12.1. Разработка логической схемы базы данных

вторичном сервере, хранящем копию таблицы. Выполнение INSERT или UPDATE над первичной таблицей приведет, соответственно, к добавлению или обновлению записи в копии таблицы в результате работы системы реп­ ликации, для чего предусмотрен гибкий механизм конфигурирования так называемых функциональных строк (function strings), которые переопреде­ ляют любую операцию на макроязыке с подстановкой параметров.

Технологии тиражирования данных имеют следующие преимущества:

•данные всегда расположены там, где они обрабатываются, следова­ тельно, скорость доступа к данным существенно увеличивается;

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

•для принимающей БД репликатор исходной БД выступает как про­ цесс, инициированный одним пользователем;

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

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

•как часто одни и те же данные должны использоваться в разных узлах;

•какие данные должны тиражироваться;

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

Расмотрим эти факторы подробнее.

1.Если таблица часто используется в разных узлах и каналы связи между этими узлами достаточно надежны, то рекомендуется организовать тиражирование данных.

Рассмотрим пример. На рис. 11.1 представлена КС БД «БДЗ. Ценные бумаги». Если требуется оперативно принимать решения о купле/продаже ценных бумаг, то таблица «Курс продажи» должна храниться на серверах всех торговых площадок (бирж), где проходят торги, а также на серверах организаций (например, различных паевых фондов), заинтересованных в результатах торгов. Если разные части таблицы, хранящиеся в разных узлах, используются нечасто или каналы связи не совсем надежны, то лучше эти части таблицы хранить в разных узлах и связь между ними поддерживать с помощью удаленных запросов.

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

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

215

12. Логическое проектирование систем распределенной обработки данных

Сервер СУБД 01

Таблица "Курс продажи" (только чтение)

Данные котировок из других городов

Таблица "Курс продажи" в

И. Новгороде

Данные котировок в И. Новгороде

Рис. 12.13. Пример подписки на публикации

•«Курс продажи» — это вторичные данные (только для чтения) первич­ ной таблицы «Курс продажи», которая располагается на сервере СУБД 01;

•«Курс продажи в г. С.-Петербург (Н. Новгород)» — это локальные таблицы (для чтения и обновления), которые хранятся на серверах в соот­ ветствующих городах.

216

12.1.Разработка логической схемы базы данных

Входе торгов данные из таблицы «Курс продажи в г. С.-Петербург (Н. Новгород)» копируются с помощью удаленного запроса UPDATE в ос­ новную таблицу «Курс продажи», которая хранится в г. Москве.

Ясно, что при такой схеме хранения таблиц вторичные серверы долж­ ны получать данные только о тех торгах с ценными бумагами, которые прошли в других городах. Для этого необходимо организовать подписку сервера 02 на публикации «Код организации» = 01 и «Код организации» = 03. Здесь «Код организации» — это поле ключа таблицы «Курс продажи» (рис. 11.1), а 01 и 03 — коды соответствующих бирж. В этом случае основ­ ной сервер 01 будет копировать на сервер СУБД 02 только данные о торгах

вМоскве и Н. Новгороде. Аналогично можно выполнить подписку сервера 03 на публикации «Код организации» = 01 и «Код организации» = 02.

3.Теперь рассмотрим вопрос, как может быть выполнено обновление копии таблицы клиентом, работающим со вторичным сервером. Приведен­ ная на рис. 12.13 схема обновления данных имеет некоторые недостатки:

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

• для выполнения обновления (UPDATE) в таблице «Курс продажи» на основном сервере необходимо для вторичного сервера разработать спе­ циальную процедуру удаленного копирования по концу транзакции.

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

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

217

12. Логическое проектирование систем распределенной обработки данных

Биржа 01

(г. Москва)

Сервер СУБД 01

Таблица «Курс продажи» (чтение и обновление)

Данные котировок из всех городов (основная таблица)

Публикации Подписка

Рис. 12.14. Пример асинхронного вызова процедуры «Обновление»

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

218

12.1. Разработка логической схемы базы данных

Рис. 12.15. Окно Fastpath Table Mappig

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

Описание логической схемы базы данных с помощью пакета CASE*Dictionary. Продолжим рассмотрение примеров, приведенных в гл. 10 и 11. Запустите CASE*Dictionary (Oracle) и выберите пункт Design/Menu, чтобы начать этап проектирования.

1. В CASE*Dictionary имеются некоторые утилиты этапа проектиро­ вания, позволяющие быстро перейти к этапу проектирования от этапа ана­ лиза (концептуального проектирования). Выберите пункт Design/Data Design Utilities/Tastpath Table Mapping. Ha экране появится окно, показанное на рис. 12.15.

При отображении этого окна выводится подсказка для ввода имени приложения (если оно отсутствует). В данном случае следует ввести SECURITES, а записи в поде Entity оставить пустыми. Чтобы все опреде­ ленные ранее имена сущностей появились в окне, нажмите клавишу [Execute Query]. Перемещая курсор на каждое имя сущности и нажимая клавишу [Commit], можно задать для каждой сущности имя соответст­ вующей таблицы БД. После этого экран будет выглядеть как показано на

219