Системы управления базами данных (СУБД) стали сегодня общепризнанным инструментом создания прикладных программных систем. Эти инструментальные средства постоянно совершенствуются и фирмы-разработчики СУБД внимательно следят за успехами своих конкурентов, пытаясь оперативно включить в свои пакеты новые функции, реализованные у конкурентов. Правда внутренняя архитектура СУБД не всегда позволяет сделать это удачно.
Одной из наиболее интересных новых возможностей современных мощных коммерческих СУБД является поддержка распределенных баз данных. Распределенные базы данных реализуются в локальной или глобальной компьютерной сети. При этом части одной логической базы данных располагаются в разных узлах сети, возможно на разнотипных компьютерах с различными операционными системами. Даже данные одной таблицы реляционной СУБД могут физически храниться в разных узлах сети, размещенных, например, в разных городах страны. Причем пользователи любого узла такой распределенной СУБД имеют доступ к данным всех остальных узлов. Такое распределение данных позволяет, например, хранить в узле сети те данные, которые наиболее часто используются в этом узле. Такой подход облегчает и ускоряет работу с этими данными и оставляет возможность работать с остальными данными БД, хотя для доступа к ним требуется потратить некоторое время на передачу данных по сети.
Основной особенностью распределенной базы данных является ее "прозрачность" для пользователей и разработчиков приложений. Т.е. пользователи и разработчики представляют распределенную БД в виде некоторой единой логической локальной БД, не задумываясь о физическом расположении ее компонент. Все приложения создаются так, как будто бы они работают с этой единой логической локальной БД. Отладка приложений также может выполняться на локальной БД.
Перенесение частей этой локальной БД в различные узлы сети может выполняться в более позднее время администратором БД и оно не влечет за собой изменения приложений. Более того, пользователи и разработчики приложений могут даже не знать о том, где теперь физически размещены данные, с которыми они работают. Поиск и пересылку удаленных данных автоматически выполняют программные средства СУБД.
Конечно для того, чтобы реализовать такой простой для конечного пользователя и разработчика механизм представления распределенной БД, необходимо решить множество проблем. Наиболее очевидные из них связаны с обеспечением целостности и непротиворечивости данных распределенной БД, реализацией механизма поддержки "прозрачности" распределенной БД, реализацией единого механизма работы с частями БД, находящимися в СУБД различного типа и расположенными на разнотипных компьютерах с различными операционными системами, обеспечением приемлемого быстродействия прикладной системы и т.д.
Сегодня многие фирмы - разработчики СУБД заявляют о том, что они поддерживают работу с распределенными БД, однако при ближайшем рассмотрении в большинстве случаев эти заявления оказываются несколько преувеличенными. Специалисты в области СУБД считают, что только несколько пакетов СУБД позволяют в некоторой степени реализовать распределенную базу данных.
В работе дано следующее определение распределенной БД: "Распределенная БД - это множество физических баз данных, которые выглядят для пользователя как одна логическая БД". К сожалению на сегодняшний день ни одна СУБД полностью не реализует это определение. Наиболее близко к его реализации подошли следующие СУБД:
- Informix On-Line фирмы Informix Software;
- Ingres Intelligent Database фирмы Ingres Corp;
- Oracle (version 7) фирмы Oracle Corp;
- Sybase System 10 фирмы Sybase Inc.
Хотя ни одна из этих 4 СУБД полностью не реализует все функции распределенной СУБД, однако каждая из них реализует или в скором времени будет реализовывать поддержку работы с распределенной БД.
В большинстве случаев распределенная СУБД состоит из ядра СУБД и набора дополнительных продуктов, покупаемых отдельно, которые обеспечивают работу с распределенной БД. Некоторые фирмыразработчики СУБД встраивают средства работы с распределенной БД в ядро СУБД. Кроме того, различные фирмы вкладывают разные понятия в термин "распределенная СУБД" и по разному определяют набор необходимых для такой СУБД функций. Поэтому потенциальным покупателям распределенных СУБД очень непросто сравнивать эти СУБД между собой и делать правильный выбор. Однако существует некоторый набор функций, которые должны быть присущи каждой распределенной СУБД. Наиболее распространенным описанием этих функций является следующее:
"Распределенная СУБД обеспечивает пользователям доступ к информации независимо от того, какое оборудование и какое прикладное программное обеспечение используется в узлах сети. Пользователи при этом не обязаны знать, где физически размещаются данные и как надо выполнять физический доступ к ним. Распределенная СУБД позволяет выполнять горизонтальное и вертикальное "расщепление" таблиц и помещать данные одной таблицы в различных узлах сети. Запросы к данным распределенной БД формулируются так, как будто база данных локальна. При обработке транзакций и выполнении операций копирования/восстановления распределенной БД обеспечивается целостность всей БД.
Протоколы управления БД, например протокол двухфазной фиксации изменений, реализуют механизмы блокировки, обеспечивающие непротиворечивость данных. Средства глобальной оптимизации запросов автоматически выбирают наилучший способ выполнения в локальной или глобальной сети сложных транзакций, а специальные мониторы позволяют получать информацию о параметрах выполняющихся в разных узлах процессов и на основе этой информации выполнять настройку системы с целью обеспечения максимальной производительности работы."
Президент фирмы Alternative Technologies Макговерн сформулировал 13 основных функций, которые должна поддерживать распределенная СУБД [4]. Рассмотрим их подробнее.
1. РАСПРЕДЕЛЕННЫЙ СЛОВАРЬ (ДИРРЕКТОРИЯ) ДАННЫХ. В словаре содержится информация о типе данных, месте их размещения и о способе доступа к данным.
2. "ПРОЗРАЧНЫЙ ПРОТОКОЛ ДВУХФАЗНОй ФИКСАЦИИ ИЗМЕНЕНИЙ. Этот протокол обеспечивает непротиворечивость данных. При выполнении транзакции, изменяющей данные в нескольких узлах, протокол двухфазной фиксации обеспечивает успешное выполнение всей транзакции только в том случае, если успешно выполнилась обработка в каждом узле. Если же в одном из узлов обработка не выполнена успешно, то анулируются результаты работы всей транзакции.
3. ГОРИЗОНТАЛЬНАЯ И ВЕРТИКАЛЬНАЯ ФРАГМЕНТАЦИЯ. Эта функция позволяет "расщеплять" таблицу БД по строкам (горизонтально) и по столбцам (вертикально) и размещать части данных таблицы в разных узлах сети.
4.НЕЗАВИСИМОСТЬ ДУБЛИРОВАНИЯ ДАННЫХ. Это свойство СУБД позволяет создавать в узлах сети дубли данных без снижения производительности приложения и без нарушения непротиворечивости данных.
5. РАСПРЕДЕЛЕННЫЕ ПРЕДСТАВЛЕНИЯ (views). Представления могут формироваться при выполнении операции соединения (join) таблиц, размещающихся в разных узлах.
6. ОПТИМИЗАЦИЯ РАСПРЕДЕЛЕННЫХ ЗАПРОСОВ. Оптимизация алгоритмов выполнения сложных операций, например соединения таблиц, выполняется с учетом размещения данных в глобальной сети. При этом учитывается пропускная способность сети, ее загрузка и объем передаваемой информации, вычислительная мощность узлов. На основе этой информации делается вывод о том, где лучше всего производить операцию соединения таблиц (как наиболее трудоемкую операцию).
7. РАСПРЕДЕЛЕННЫЕ ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ. Эта функция обеспечивает ссылочную целостность данных. В узлах могут находиться таблицы, зависящие от некоторой таблицы-мастера. При модификации данных таблицы-мастера автоматически модифицируются зависимые таблицы.
8. ЛОКАЛЬНАЯ АВТОНОМИЯ. Администратор БД конкретного узла полностью контролирует данные локальной БД данного узла. Он может работать независимо от администраторов других узлов.
9. НЕПРЕРЫВНАЯ ОБРАБОТКА (continual operation). Обработка, выполняемая в локальном узле БД, не может быть прервана командами из другого узла. Т.е. в каждом узле обработка выполняется независимо и целиком.
10. НЕЗАВИСИМОСТЬ РАЗМЕЩЕНИЯ. Изменение места хранения данных не ведет к изменению работающих с этими данными приложений.
11. ОБРАБОТКА РАСПРЕДЕЛЕННЫХ ТРАНЗАКЦИЙ. Обеспечение ограничений целостности поддерживается и при выполнении транзакции, изменяющей несколько узлов.
12. ГЛОБАЛЬНАЯ ОБРАБОТКА ВЗАИМОБЛОКИРОВОК И ПРОБЛЕМ, ВОЗНИКАЮЩИХ ПРИ ОДНОВРЕМЕННОМ ДОСТУПЕ К ДАННЫМ. Блокировка данных может выполняться во всех узлах БД. Необходимо выявлять и разрешать ситуации, когда два узла взаимно блокируют друг друга.
13. НЕЗАВИСИМОСТЬ ОТ ТИПА КОМПЬЮТЕРОВ, ОПЕРАЦИОННЫХ СИСТЕМ, СЕТЕВЫХ ПРОТОКОЛОВ, ТИПОВ СУБД. Эта независимость осуществляется путем использования как встроенных в СУБД средств, так и шлюзов (gateways).
Многие фирмы, создающие приложения для работы в сети компьютеров, с большим интересом рассматривают возможность распределения по сети своих данных, которые сейчас хранятся централизованно. Очень удобно хранить часто используемые в данном локальном узле данные непосредственно в этом узле, оставляя возможность пользователям других узлов, у которых необходимость в работе с этими данными возникает редко, обращаться к ним по сети.
Хранение часто используемых данных в локальном узле резко снижает затраты на передачу данных по сети. В случае централизованного хранения эти затраты довольно велики. Физическое разделение большой централизованной БД на небольшие порции, при сохранении единого логического представления всей БД, позволяет более эффективно выполнять обработку данных.
Все эти преимущества распределенной СУБД достаточно очевидны. Поэтому одни фирмы хотят реализовать связь между своими БД, уже существующими в разных узлах сети. Другие фирмы, наоборот, хотят распределить по узлам сети данные, которые сейчас централизованно хранятся в одной большой машине. Однако мало кто из них задумывается о том, сколь дорого и сложно обеспечить непротиворечивость данных, распределенных по узлам сети.
Распределенные СУБД обычно работают медленнее, чем централизованные СУБД, и требуют выполнения сложных работ по администрированию. Поэтому часто более целесообразно работать с централизованной БД. Кроме того, пользователи должны понимать, что сегодня ни одна из 4 существующих распределенных СУБД не обеспечивает выполнения всех 13 требований, сформулированных Макговерном, хотя все 4 фирмы-разработчика и говорят о создании истинно распределенной СУБД. При ближайшем рассмотрении каждой из этих СУБД обязательно находится некоторое множество функций, которые по разному работают с распределенной и централизованной БД, причем очень сложно заранее сказать, как это скажется на работе приложения.
Результаты сравнения характеристик и функций 4 распределенных СУБД приведены в таблице. Из нее видно, что наиболее полно функции распределенной СУБД реализованы в СУБД Ingres и Oracle. Коротко рассмотрим возможности этих пакетов и то, как они реализуют требования Макговерна.
СУБД Ingres работает на множестве UNIX-платформ, на платформах DEC VMS, Hewlett-Packard MPE, DOS, Microsoft Windows 3.1, OS/2, Macintosh. Она также работает со многими сетевыми протоколами, включая Open System Interconnection Transport Class 4. Ingres имеет средства для доступа к данным СУБД DB2, Rdb, Allbase. Основные функции распределенной СУБД обеспечиваются дополнительной компонентой Ingres/Star. Она поддерживает оптимизацию распределенных запросов, позволяет читать и обновлять в рамках одной транзакции данные разных узлов, обеспечивает возможность удалять записи одновременно в нескольких узлах.
СУБД Informix-Online разработана для среды UNIX, но может также работать под Novell. Informix-Online имеет оптимизатор запросов и реализует те же функции работы с распределенной БД, что и Ingres, однако у Informix более жесткие требования к ресурсам компьютера, в частности ему требуется больше оперативной памяти.
СУБД System 10 фирмы Sybase в настоящее время находится в состоянии разработки. Она должна работать на UNIX-платформах, на платформах OS/2, Window NT, NetWare. System 10 будет работать с несколькими сетевыми протоколами и поддерживать связь с СУБД DB2, Oracle 7, Informix-Online, Rdb. System 10 будет иметь оптимизатор распределенных запросов, она позволит читать и обновлять данные нескольких узлов. Функции работы с распределенной БД будут реализованы с помощью дополнительной компоненты Replication Server.
В 7 версии СУБД Oracle реализовано множество функций для работы с распределенной БД. Среди них следует выделить оптимизатор распределенных запросов и средство чтения и обновления данных нескольких узлов в рамках одной транзакции. Oracle v 7 работает на более чем 80 вычислительных платформах, поддерживает большинство существующих коммерческих сетевых протоколов и может обмениваться данными с СУБД DB2, SQL/DS, Tandem Computers, NonStop SQL, Rdb, HP TurboImage. Разрабатываются шлюзы еще к 18 СУБД.
В Oracle словарь данных хранится также, как остальные данные, поэтому его таблицы могут быть распределены по узлам сети. Все операции с распределенной БД "прозрачны" для пользователей и разработчиков. В области обновления распределенной БД Oracle обогнал всех своих конкурентов. Пользователи Oracle могут с помощью компоненты SQL*Net "прозрачно" работать с данными (не обязательно данными Oracle), размещающимися на различных типах компьютеров и в различных узлах сети. Высокопроизводительное средство "прозрачного" обновления распределенной БД реализовано на основе оригинально выполненного двухфазного протокола фиксации изменений.
В Oracle 7 реализованы и остальные требования Макговерна. Так дублирование таблиц может выполняться 2 путями: с помощью триггеров (процедурно) и с помощью декларативного описания (средство копирования таблиц SNAPSHOT). Оптимизатор распределенных запросов позволяет выполнить как автоматическую, так и автоматизированную (с учетом пожеланий разработчика) оптимизацию. Он учитывает текущие объемные характеристики таблиц. Кроме распределенной ссылочной целостности Oracle поддерживает и ряд других распределенных декларативных ограничений целостности.
Все 4 рассмотренные СУБД поддерживают локальную автономию узлов. Это означает, что администратор БД может рассматривать локальную БД конкретного узла как самостоятельную БД. Все СУБД поддерживают ANSI стандарт языка SQL - ANSI SQL-89 и расширение этого стандарта. Запросы к БД формулируются на языке SQL. Дополнительно к непроцедурному языку SQL Oracle поддерживает свой собственный процедурный язык PL/SQL, а Sybase поддерживает свой язык Transact-SQL. Все 4 СУБД обеспечивают "прозрачный" механизм запроса, обновления и просмотра данных, размещенных в нескольких узлах. Уже отмечалось, что все 4 СУБД могут обмениваться данными с другими СУБД. Однако только двухфазный протокол фиксации Oracle 7 позволяет выполнять распределенные обновления данных в разных СУБД. Проблема заключается в том, что двухфазные протоколы фиксации изменений разных СУБД плохо совместимы между собой.
Все 4 пакета обеспечивают выполнение локальной и глобальной блокировки данных. Однако они реализуют эту блокировку на различных уровнях. Так Oracle по умолчанию реализует блокировку на уровне записи, а остальные СУБД - на уровне страницы или таблицы. Механизм блокировок позволяет предотвратить изменение данных, которые в это время контролируются другими пользователями. Тем самым обеспечивается целостность и непротиворечивость данных. Блокировка на уровне записи позволяет одновременно обновлять соседние записи одной и той же таблицы. Это резко снижает время ожидания, ускоряет обработку данных и уменьшает вероятность возникновения взаимоблокировок.
Все фирмы-разработчики распределенных СУБД намерены в будущем поддерживать архитектуру распределенной базы данных фирмы IBM (Distributed Relational Database Architecture). Правда хотя IBM уже давно объявила о начале работ по реализации этой архитектуры, она до сих пор не закончена. Это очевидно связано с очень высокой сложностью реализации объявленной архитектуры.
При выборе распределенной СУБД в первую очередь следует обратить внимание на то, какие операционные системы и сетевые протоколы она поддерживает. Однако не менее важным является и то, какие методы распределения данных реализованы в СУБД.
Один из способов распределенного хранения таблиц - это фрагментация. Таблица может быть расщеплена на части, которые будут помещены в разные узлы. Другой способ распределения данных- это дублирование (репликация). Можно создать дубли всей БД или ее частей и разместить эти дубли в узлах. Оба метода позволяют хранить данные именно в том узле, где они наиболее часто используются. Это сводит к минимуму затраты на передачу данных по сети и уменьшает использование процессоров и прочих ресурсов остальных узлов. При такой архитектуре БД приложения передача данных по сети выполняется достаточно редко.
Ни одна из рассматриваемых СУБД не реализует фрагментацию таблиц полностью. Однако для любой из рассмотренных СУБД программисты могут написать программы, которые будут имитировать фрагментацию. Хорошим средством фрагментации является и использование механизма представлений (views).
В СУБД Ingres реализован механизм дублирования. Фирма Sybase обещает реализовать дублирование в своем пакете Replication Server.
В Oracle 7 реализованы и фрагментация и дублирование. Причем дублирование может выполняться процедурно (с помощью триггеров) или быть задано в декларативном виде. При этом в БД создаются объекты типа SNAPSHOT (точная копия). Триггеры обеспечивают синхронизированный механизм дублирования таблиц при котором изменения, сделанные в таблицемастер, немедленно отображаются в дублирующие таблицы. SNAPSHOT обеспечивает асинхронное обновление, причем это обновление выполняется в определенное время или через определенные интервалы времени.
Простые SNAPSHOT работают на основе одной таблицы-мастера. Они позволяют обновлять в дублирующих таблицах только те строки, которые соответствуют измененным строкам таблицы-мастера. Сложные SNAPSHOT базируются на нескольких мастер-таблицах. В этом случае дублирующие таблицы создаются целиком каждый раз при обновлении мастер-таблиц.
После того, как данные распределены по разным узлам сети, важно найти и использовать эти данные. Для того, чтобы найти данные и преобразовать их в нужный формат, используются глобальные словари данных и дирректории. В словаре хранится информация о данных, их использовании, правах доступа к данным, а также о приложениях. Дирректории данных используются для того, чтобы определить, где хранятся данные и как их извлечь. Словари и дирректории могут быть глобальными и локальными. System 10 обещает, а Oracle и Ingres уже реализовали глобальный словарь данных.
В Ingres глобальный словарь реализуется с помощью компоненты Ingres/Star. Эта компонента извлекает информацию из всех локальных словарей данных и выполняет оптимизацию запросов. Недостатком такого подхода является то, что все данные словарей собираются на центральном узле Ingres/Star и при его отключении или сбое теряется доступ к остальным узлам распределенной БД. Для восстановления доступа придется создавать другой центральный узел.
Методы распределения данных конечно очень важны, однако сердцем современных распределенных СУБД является протокол двухфазной фиксации изменений. Этот протокол управляет выполнением транзакций, изменяющих данные нескольких узлов. Основная идея двухфазной фиксации заключается в следующем: недопустима ситуация при которой транзакция, изменяющая данные в нескольких узлах, выполняется в одних узлах и не выполняется в других узлах. Транзакция должна быть либо успешно выполнена во всех узлах, либо не выполнена ни в одном узле.
Все 4 рассматриваемые СУБД поддерживают выполнение двухфазного протокола фиксации изменений. Правда Ingres, Informix и Oracle делают это несколько лучше, чем Sybase. Для указания точки фиксации в них достаточно выполнить 1 команду (один оператор в программе). У Sybase для реализации протокола двухфазной фиксации приходится в каждом приложении писать процедуру из нескольких операторов.
Таким образом видно, что реализация протокола двухфазной фиксации у Ingres, Informix и Oracle не требует большого труда от программиста. Однако она выполняется по жесткому, заранее заданному алгоритму. У Sybase алгоритм выполнения двухфазной фиксации можно адаптировать к конкретным условиям, но при этом придется заниматься программированием.
Очень мощный и сложный алгоритм реализации протокола двухфазной фиксации изменений реализован в 7 версии СУБД Oracle. Он состоит из следующих этапов:
1. Запускается распределенная транзакция, включающая команду COMMIT.
2. Этап подготовки
a) Узел-родитель обращается к каждому из своих узлов-детей с просьбой "дать обещание", что он зафиксирует или откатит свою часть изменений только после получения определенной команды;
b) После того, как все узлы-дети готовы к работе, узел-родитель записывает в журнал redo log информацию о транзакции и устанавливает специальный флаг в состояние, говорящее о готовности узла к работе;
c) Узел сообщает своему узлу-родителю о том, что он готов к работе;
d) Узел не может завершить транзакцию до тех пор, пока не получит на это разрешение от узда родителя.
3. Этап фиксации
a) Узел записывает в журнал redo log информацию о том, что он фиксирует сделанные изменения (или откатывает их если были ошибки во время этапа подготовки);
b) Узел дает команду своим узлам-детям выполнить фиксацию изменений (или откатить изменения);
c) Узел информирует свой узел-родитель о том, что фиксация выполнена (или откачена);
d) После того, как все узлы зафиксировали или откатили изменения, снимается блокировка ресурсов.
Ключом к пониманию этого алгоритма является фраза "дать обещание", которая говорит о том, что некоторые совместные действия (фиксация или откат) будут выполнены в будущем. Фиксация изменений выполняется в каждом узле самостоятельно, поэтому узлы не должны ждать пока закончится фиксация в других узлах. Этот механизм можно использовать для защиты обновлений, выполняемых на большой машине, от обновлений, выполняемых на связанных с ней PC. Важно отметить, что при распределенном обновлении в качестве узлов фиксации могут использоваться и базы данных других СУБД и базы данных младших версий СУБД ORACLE. При этом двухфазная фиксация также будет гарантирована.
Фирма Sybase объявила, что она планирует изменить подход к реализации протокола двухфазной фиксации в своем новом продукте Replication Server для System 10. В этом продукте будет обеспечена простая реализация протокола двухфазной фиксации. Пользователи смогут объявить один из узлов главным контролером изменений. В нем будет накапливаться информация обо всех обновлениях данных и старых вариантах данных транзакции. Сбой одного из узлов БД не будет блокировать транзакцию. Будет уменьшена загрузка сети , поскольку при таком алгоритме резко уменьшается число сообщений, генерируемых протоколом двухфазной фиксации. Однако в случае сбоя главного узла-контролера изменения могут быть потеряны, а целостность БД нарушена.
Кроме того, существует опасность, что в течение времени распространения изменений во все узлы БД (а это 2 - 10 сек) будет нарушена непротиворечивость данных распределенной БД.
До сих пор среди специалистов идут споры о том, плох или хорош предлагаемый подход. Многие считают, что большинству пользователей нужна не полномасштабная распределенная БД, а возможность копировать данные в множество узлов под контролем единого центрального узла. Именно это и обеспечивает Replication Server. Кроме того, в Replication Server будет сохранена возможность реализовать старый алгоритм двухфазной фиксации изменений.
Важной характеристикой распределенной БД является то, как она обеспечивает поддержку ссылочной целостности между данными таблицы-мастера и данными связанных с ней таблиц. Рассмотрим пример ссылочной целостности. Предположим в распределенной БД имеются три таблицы:
- таблица, содержащая информацию о детях сотрудников;
- таблица, содержащая информацию о зарплатах сотрудников за год;
- таблица, содержащая информацию о темах, выполненных сотрудником.
Все эти таблицы содержат столбец "ФИО сотрудника". Правила обеспечения ссылочной целостности требуют, чтобы при изменении значений столбца "ФИО сотрудника" в одной таблице, автоматически выполнялась корректировка значений этого столбца в других таблицах. Для обеспечения ссылочной целостности используются 2 различных метода - триггеры и декларативные ограничения целостности стандарта ANSI. Все 4 рассматриваемые СУБД поддерживают аппарат триггеров, но в Informix их нельзя использовать для обеспечения ссылочной целостности.
Триггеры обычно используются для того, чтобы выполнить некоторую обработку данных, необходимую для конкретного приложения. Триггер - это небольшой фрагмент программы, написанный на языке программирования СУБД. Этот фрагмент является частью приложения. Примеров триггера может служить триггер обеспечения связи мастер - деталь при выборке данных. Он должен при переходе от одной записи таблицы-мастер к другой очистить буфер, хранящий старые записи таблицы-деталь и произвести выборку записей таблицы-деталь, связанных с новой записью таблицы-мастер.
Декларативные ограничения целостности позволяют записать правила обеспечения целостности не в виде фрагмента программы, а в виде набора правил, которые хранятся в словаре данных и автоматически выполняются ядром системы. Декларативные ограничения формулируются во время описания данных и выполняются для всех приложений, работающих с данной БД. Это позволяет программистам не встраивать триггерные программы реализации таких правил в каждое приложение, а описать их лишь 1 раз.
Ingres не поддерживает декларативные ограничения целостности для распределенной БД, у Informix эти ограничения не полностью соответствуют стандарту ANSI. Поскольку декларативные ограничения целостности проверяются для всех приложений, работающих с данными, для которых ограничения сформулированы, это несколько увеличивает суммарное время работы приложений (ведь для некоторых приложений эти проверки могут быть избыточными). Однако использование декларативных ограничений целостности обеспечивает более точное и полное соблюдение ограничений данной предметной области.
Рассмотрим пример, когда декларативные ограничения целостности приводят к выполнению избыточных действий и замедляют работу приложения. Предположим, что необходимо добавлять в таблицу, содержащую информацию о темах, выполненных сотрудником, информацию о новых темах, законченных сотрудником. Если установлены декларативные ограничения целостности, то каждый раз при добавлении записи с информацией о законченной теме будет выполняться проверка того, существует ли такой сотрудник в таблице "Сотрудники". Следовательно, если сотрудник Иванов И. И. закрыл 3 темы, то проверка выполнится 3 раза.
Если приложение, выполняющее модификацию рассматриваемой таблицы, будет писать хороший программист, то он создаст триггер, который проверит наличие сотрудника 1 раз, заблокирует запись в таблице "Сотрудники", чтобы не допустить ее изменения, и затем 3 раза выполнит операцию добавления записи о законченной теме.
Из этого примера видно, что используя декларативные ограничения целостности, мы перекладываем заботу об обеспечении целостности БД на ядро СУБД, но немного теряем в производительности. При работе в глобальной сети эти потери производительности могут оказаться существенными и придется использовать механизм триггеров.
Хотя все рассмотренные СУБД отличаются друг от друга по своим характеристикам и функциональным возможностям, очень сложно сформулировать правила выбора того или иного пакета. Необходимо очень тщательно анализировать функциональные возможности, производительность и сложность администрирования выбираемой СУБД, чтобы убедиться, что она отвечает Вашим требованиям. Немаловажным фактором является и то, насколько реально для Вас получить техническую поддержку выбираемого пакета. Дело в том, что все распределенные СУБД достаточно сложны в освоении и сопровождении. Следует узнать также поддерживает ли выбранный пакет работу с национальным языком (ввод данных, их преобразование, тексты сообщений, сортировка, работа с датой). Пока только фирма Oracle реализовала в своем пакете поддержку русского языка.
Необходимо проанализировать среду, в которой предполагается использовать СУБД (используемые в узлах компьютеры и операционные системы, используемые сетевые протоколы). Важно обратить внимание на быстродействие выбираемой распределенной СУБД. На сегодняшний день производительность распределенных СУБД не велика и если Вы создаете приложение, которое имеет жесткие требования по быстродействию, то возможно Вам придется отказаться от использования распределенной БД. Зарубежные фирмы регулярно проводят тестирование наиболее популярных коммерческих СУБД на различных вычислительных платформах. Сравнение функциональных характеристик проводится по специальным методикам. Производительность СУБД измеряется в транзакциях в секунду и определяется на основе стандартных тестов tcp A и tcpB.
Тест tcpA исследует то, как СУБД выполняет приложения типа OLTP (Online Transaction Processing). При этом в качестве тестового приложения используется стандартное приложение, выполняющее множество одновременных обновлений БД. Тест tcpB исследует то, как СУБД выполняет приложения типа MIS (Manager Information System) или DSS (Decision Support System). При этом в качестве тестового приложения используется стандартное приложение, выполняющее сложную обработку большого объема данных БД.
При работе распределенной СУБД по сети передается большой объем информации. Это запросы на обработку данных и их блокировку, сообщения о результатах выполнения операций и состоянии узлов, наборы данных, полученные в результате выборки. Очень часто при работе в глобальной сети эта информация перегружает сеть и производительность системы падает ниже допустимого уровня. Время ожидания ответа становится очень большим. Это может сделать систему неработоспособной. Следует учесть, что часто системы на основе распределенной СУБД могут эффективно работать только при использовании высокоскоростных сетей, а в низкоскоростных локальных сетях время отклика будет очень велико. Постарайтесь выбрать такую СУБД, которая больше всего подходит для Вашей среды эксплуатации, хотя скорее всего на 100 процентов Вас не удовлетворит ни один пакет.
Появление на рынке 7 версии СУБД Oracle и информация о свойствах разрабатываемой версии СУБД фирмы Sybase позволяют перейти от теоретической дискуссии о распределенных СУБД к их практическому использованию. Однако пользователи должны предварительно тщательно подумать о том, действительно ли им нужна распределенная СУБД.