На рис. 8.4 представлена структура системы, где одновременно функционируют СУБД Oracle и Informix (эти СУБД взяты в качестве примера).
Рис. 8.4. Пример структуры системы распределенной обработки данных
Доступ из Oracle к таблицам Informix и обратно осуществляется с помощью шлюзов. Доступ к данным Oracle и Informix из Windows-приложений можно также организовать с помощью ODBC-драйверов (Open DataBase Connectivity) этих СУБД. Здесь для маршрутизации запросов к прикладным программам, выполняемым на разных серверах, используется менеджер транзакций Tuxedo.
Построение сложных систем распределенной обработки данных становится возможным благодаря тому, что архитектура современных СУБД носит открытый характер. «Открытой системе» присущи следующие особенности: переносимость, межоперабельность, расширяемость, масштабируемость, интернационализация.
Переносимость (портируемость – portability) – это такое разделение программной системы и ее операционного окружения, которое позволяет без существенных изменений перенести программу в другое операционное окружение.
Переносимость рассматривается в трех аспектах:
• возможность функционирования СУБД на множестве платформ;
• качество коммуникационных средств, обеспечивающих связь клиента и сервера способом, не зависящим ни от платформ клиента и сервера, ни от используемого сетевого протокола;
• качество средств разработки приложений СУБД, позволяющих переносить готовые приложения с платформы на платформу без изменения в исходных и, возможно, в двоичных кодах.
Первое касается собственно сервера СУБД, второе – организации взаимодействия клиента и сервера, третье – средств разработки приложений, поставляемых вместе с СУБД.
Мобильный сервер СУБД необходим в случаях, когда разработка и эксплуатация прикладной системы осуществляется на разных платформах, для вертикального и горизонтального масштабирования (см. ниже), а также в распределенной ИС, где может быть несколько узлов на базе разнородных платформ, но гарантировано абсолютно идентичное поведение сервера на всех этих узлах.
Межоперабельность (interoperabiIity) можно трактовать как свойство открытой системы, позволяющее встраивать эту систему как компонент в сложную разнородную распределенную информационную среду. Это достигается как за счет использования интерфейсов, соответствующих международным, национальным и промышленным стандартам, так и за счет специальных решений.
Для СУБД это свойство может означать следующее:
• возможность приложений, созданных средствами разработки данной СУБД, оперировать над БД в «чужом» формате так, как будто это собственные БД;
• свойство сервера СУБД, позволяющее ему выступать менеджером ресурсов (resource manager) в системе обработки распределенных транзакций (Distributed Transaction Processing – DTP);
• свойство СУБД, позволяющее ей служить поставщиком данных для любых приложений, созданных средствами разработки третьих фирм, поддерживающих некоторый стандарт обращения к БД.
Первое свойство достигается двумя путями: использование шлюзов, которые представляют собой специальные средства доступа к унаследованным (legacy) БД; встраивание в средства разработки данной СУБД драйверов связи с другими системами. Шлюзы обычно включают в состав коммуникационных средств СУБД (см. рис. 8.4), и их можно рассматривать как расширение сервера СУБД, в то время как драйверы – атрибут средств разработки приложений. Второе свойство определяется поддержкой СУБД ХА-интерфейса стандарта X/Open DTP, используемого в менеджерах транзакций. Наконец, третье свойство достигается за счет поддержки коммуникационными средствами СУБД стандарта ODBC, разработанного специалистами корпорации Microsoft.
Расширяемость можно трактовать как возможность качественного наращивания функций сервера СУБД. Это свойство используется разработчиками для следующих целей:
• для программирования процедур, расширяющих базовые возможности сервера СУБД в нужном для разработчика направлении. Большинство современных СУБД имеет в своем арсенале такой механизм, как хранимые процедуры, которые как раз и выступают как средство расширения;
• для качественно нового сценария взаимодействия клиента и сервера СУБД, в котором последний играет более активную роль и получает возможность влиять на клиента. Для этого используется механизм событий в БД – одно из наиболее популярных технических новшеств;
• для расширения спектра типов обрабатываемых данных, для интеграции в сервер возможностей обработки новых типов данных, характерных для ПО. Это обеспечивается сервером СУБД путем поддержки типов данных, определяемых пользователем (СУБД Ingres).
Масштабируемость можно трактовать как качество СУБД, гарантирующее, что в условиях резкого изменения характеристик задач (рост объемов данных, увеличение числа пользователей, усложнение запросов к БД, переход к распределенной обработке данных) система способна к ним адаптироваться. Масштабируемость СУБД означает, что ее разработчики заранее предусмотрели возможность расширения масштаба задач, оценили, в каком направлении произойдут изменения, продумали адекватные решения, реализовали соответствующие механизмы сервера СУБД. В этом состоит принципиальное, качественное отличие систем, прошедших долгий путь развития и по праву считающихся вершиной технологии реляционных СУБД (Oracle, Sybase, Informix и др.), от их более молодых конкурентов.
На практике масштабируемость обеспечивается многопотоковой, мультисерверной архитектурой, специальными возможностями поддержки сверхбольших БД (таких, как многотомные таблицы), оптимизатором запросов, опирающимся на статистические характеристики БД.
В более узком смысле масштабируемость можно трактовать как способность тонкой настройки системы при изменении характеристик среды функционирования. Традиционно выделяют вертикальное и горизонтальное масштабирование. Говоря о вертикальном масштабировании, обычно имеют в виду возможность замены платформы СУБД на новую, обладающую большей производительностью и надежностью. Под горизонтальной масштабируемостью, как правило, подразумевают возможность увеличения вычислительных мощностей за счет добавления в сеть новых компьютеров с установленными на них серверами СУБД.
Интернационализация. Отметим здесь только некоторые важные аспекты СУБД, позволяющие говорить об их «интернациональных» возможностях:
• очень важно, сколько бит используется для представления символа. Вряд ли возможна нормальная локализация системы (адаптация к требованиям национальной информационной среды), если для представления символа отводится семь бит. В профессиональных многопользовательских СУБД символ - это несколько байт, что дает возможность охватить практически весь спектр символов национальных алфавитов (включая иероглифы);
• исключительно важно, чтобы все ресурсы, связанные с поддержкой национальных алфавитов (кодовые таблицы, системные сообщения и т.д.) были вынесены из ядра СУБД на уровень файловой системы, а выбор алфавитов и кодировок достигался установкой соответствующих значений переменных окружения или параметров конфигурационных файлов;
• процедура локализации должна включать не только настройку соответствующих ресурсов локализации (создание и трансляцию кодовых таблиц, перевод системных сообщений), но и тестирование как сервера, так и всех средств разработки со всеми кодировками, которые предполагается
использовать в качестве базовых, причем на всех тех платформах, где предполагается промышленная эксплуатация системы. Более того, локализованная версия системы должна быть сертифицирована фирмой-производителем, а кодировки – поддерживаться официально.
В гл. 13 приведены свойства некоторых крупных СУБД, подтверждающие открытый характер этих систем.
Рис. 8.5. Организация связи HTML-документов с базами данных