Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.
Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.
Недостаток предыдущей архитектуры в том, что резко возрастает нагрузка на сервер, а если он выходит из строя, то работа всей системы останавливается. Поэтому в некоторых случаях в систему добавляется так называемый сервер приложений, на котором выполняется вся вычислительная работа. Другой сервер баз данных обрабатывает запросы пользователей, на третьем может быть установлена специальная программа - монитор транзакций, которая оптимизирует обработку транзакций и балансирует нагрузку на серверы. В большинстве практических случаев все серверы соединены последовательно - позвенно, и выход из строя одного звена если и не останавливает всю работу, то, по крайней мере, резко снижает производительность системы. Такой вариант реализации называют многозвенной архитектурой.
Чтобы избежать недостатков рассмотренных архитектур, были придуманы специальные технологии, позволяющие создавать программу в виде набора компонентов, которые можно запускать на любых серверах, связанных в сеть (компоненты как бы распределены по сети). Основное преимущество подобного подхода в том, что при выходе из строя любого компьютера специальные программы-мониторы, которые следят за корректностью работы компонентов и позволяют им «переговариваться» между собой, сразу перезапуская временно пропавший компонент на другом компьютере. При этом общая надежность всей системы становится очень высокой, а вычислительная загрузка распределяется между серверами оптимальным образом. Доступ к возможностям любого компонента, предназначенного для общения с пользователем, осуществляется с произвольного клиентского места. При этом, так как все вычисления происходят на серверах, появляется возможность создавать «сверхтонкие клиенты» - программы, только отображающие получаемую из сети информацию и требующие минимальных компьютерных ресурсов. Благодаря этому доступ к компонентной системе возможен не только с ПК, но и с небольших мобильных устройств. Частный случай компонентного подхода - доступ к серверным приложениям из браузеров через Интернет. Такой подход называется распределенной архитектурой.
Классическая архитектура "клиент-сервер" имеет двухзвенную схему. Архитектура "клиент-сервер" допускает различные варианты реализации. В первоначальном (централизованном) варианте архитектуры "клиент-сервер" приложение (пользовательская программа) не разбивалось на части, используя ресурсы только одного мощного компьютера. СУБД, данные и приложения хранились на одном мощном мини-компьютере или мейнфрейме, принимающим входную информацию с пользовательского терминала и отображающего на нем данные (разделение функций было на процессном уровне – один процесс выполнял функции клиента, другой – сервера). С появлением персональных компьютеров и локальных вычислительных сетей появилась возможность распределения ресурсов по всем компьютерам сети с позиции максимального использования их ресурсов. Основным принципом разбиения приложения на части является разделение на группы функций стандартного интерактивного приложения:
Функции ввода и отображения данных (Presentation Logic – презентационная логика). К этой функции относятся все интерфейсные экранные формы, с которыми работает пользователь, а также отображаемая на экране результативная и справочная информация.
Прикладные функции, определяющие основные алгоритмы решения задач (Business Logic – бизнес-логика).
Функции обработки данных внутри приложения (Database Logic – логика обработки данных).
Функции управления информационными ресурсами (Database Manager Logic). Это собственно СУБД, обеспечивающая хранение и управление базами данных.
Служебные функции, играющие роль связок между функциями первых четырех групп.
В децентрализованной архитектуре "клиент-сервер" существуют различные варианты распределения функций между компьютером-сервером и компьютером-клиентом в двухзвенной модели: от мощного сервера, на котором производится практически вся работа, до мощного клиента, когда большая часть функций выполняется компьютером-клиентом, а сервер обрабатывает поступающие к нему по сети SQL-запросы. Наиболее популярные из них.
В модели удаленного доступа к данным (Remote Data Access, RDA) на сервере хранится база данных и ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика. Клиент обращается к серверу с запросом на языке SQL, либо посредством средств пользовательского интерфейса (API - Application Programming Interface - Интерфейс программирования приложений, набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Используется программистами для написания всевозможных приложений). Данную модель поддерживает большое число серверных СУБД, имеющих SQL-интерфейсы, и инструментальных средств, обеспечивающих создание клиентской части.
Модель сервера БД (Database Server – DBS) характеризуется тем, что функции компьютера-клиента ограничиваются презентационной логикой. Большая часть бизнес-логики переложена на сервер. Иногда такую модель называют моделью с "тонким клиентом". Эта модель является более технологичной, чем RDA и применяется в таких СУБД как Informix, Ingres, Sybase, Oracle, SQL MS Server.
Существуют и более сложные варианты реализации архитектуры "клиент-сервер", например, трехзвенные информационные системы с использованием серверов приложений, реализующих бизнес-логику информационной системы (модель сервера приложений – Application Server (AS)).
Центральным звеном модели является сервер приложений, на котором реализуется несколько прикладных функций. Серверов приложений может быть несколько, и каждый из них представляет свой вид сервиса.
Программные средства сервера приложений относятся к категории программного обеспечения промежуточного слоя, которое определяется как "некоторый набор процедур или функций, обеспечивающих взаимодействие двух разнородных программ". Программные средства этой категории применимы к компьютерным сервисам практически любого вида, включая управление базами данных и информацией. Многие компании-поставщики программного обеспечения выпускают программные продукты, основанные на стандартах IDAPI, ODBC, DRDA или других стандартах промежуточного слоя и предоставляющие интерфейсные возможности для клиента и сервера.
Затрагивая вопрос о категории промежуточного слоя необходимо упомянуть о программных системах промежуточного слоя – мониторах транзакций.
Транзакцией называется совокупность операций манипулирования данными (вставкой, удалением, выборкой, обновлением) в системах баз данных, которая переводит базу данных из одного целостного (непротиворечивого) состояния в другое целостное состояние. Транзакция рассматривается как некоторое неделимое с точки зрения пользователя действие над базой данных. Например, транзакцией может быть последовательность операций по формированию заказа на сборку компьютера в компьютерной фирме: ввод нового заказа с реквизитами заказчика, формирование платежного документа, запрос на комплектующие. С точки зрения сотрудника компьютерной фирмы, это единая операция: если она будет прервана, то база данных потеряет свое целостное состояние. Восстановление данных в СУБД является составной часть управления данными и подразумевает восстановление самой базы данных, т.е. возвращение базы данных в правильное состояние в случае изменения данных в результате сбоя. Восстановление данных реализуется через механизм транзакций. Завершение транзакции означает, что все операции, входящие в состав транзакций, успешно завершены и результат их работы сохранен в базе данных. Откат транзакции означает, что все уже выполненные операции отменяются и все объекты базы данных, затронутые этими операциями возвращены в исходное состояние. Для реализации возможности отката транзакций большинство СУБД поддерживают запись в журналы транзакций, позволяющие сохранять промежуточные состояния и восстанавливать исходные данные при откате. Существуют различные модели транзакций.
Под монитором обработки транзакций (Transaction Processing Monitor – TPM) понимаются средства программного обеспечения промежуточного слоя, предназначенные для обеспечения эффективного управления информационными и вычислительными ресурсами в распределенных системах при обработке транзакций. Понятие транзакции в TPM шире, чем транзакция в СУБД. Основными функциями TPM являются: аутентификация пользователей и проверка полномочий доступа, управление коммуникациями, необходимыми для выполнения транзакций, собственно управление транзакциями, включая управление блокировкой ресурсов, журнализацию, фиксацию, откаты и восстановление транзакций.
Встраиваемая СУБД - СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы.
Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.
Доступ к данным в условиях распределенности представляет сложную задачу, требует выделения значительных вычислительных ресурсов и затрат на передачу информации. В рамках решения данной комплексной задачи специалистами IBM была предложена четырехуровневая схема доступа к распределенным данным, такое расчленение проблемы обеспечивает хорошую основу для понимания принципов управления распределенными ресурсами
Уровень 1. Удаленный запрос. На данном уровне пользователь может выполнить инструкцию SQL, которая производит доступ или модификацию информации в одной удаленной базе данных.
Пользователь может таким образом обращаться к разным базам данных, но при этом СУБД не поддерживает транзакции, состоящие из нескольких инструкций (согласно терминологии IBM, транзакция – "удаленная единица работы").
Очевидно, что возможности удаленных запросов ограничены, такие запросы полезны в условиях однократного или кратковременного доступа к данным, хранящимся на удаленной станции. При этом обработка данных производится в основном средствами станции, инициирующей запрос.
Уровень 2. Удаленная транзакция. На данном уровне обеспечиваются более сложные транзакции, состоящие из нескольких инструкций SQL.
У пользователя появляется возможность задать СУБД последовательность инструкций SQL, осуществляющих доступ и модификацию данных в удаленной базе, а затем выполнить или отменить всю последовательность целиком, как одну транзакцию, которая может быть успешно завершена или целиком отвергнута. При этом все инструкции, составляющие транзакцию, должны быть адресованы к одной базе данных.
Для обеспечения связи СУБД различных типов при удаленных транзакциях часто используются так называемые шлюзовые программы. Некоторые шлюзовые программы не только обеспечивают выполнение удаленных транзакций, но и дают пользователю возможность объединять в одном запросе таблицы из локальной базы данных с таблицами из удаленной базы данных, управляемой СУБД другого типа. Однако эти программы не обеспечивают (и не могут обеспечить) выполнение транзакций, необходимых для реализации более высоких уровней доступа к распределенным данным. Например, шлюзовая программа может обеспечить по отдельности целостность локальной базы данных и целостность удаленной базы данных, но не гарантирует полного выполнения транзакций в разных узлах сети.
Уровень 3. Распределенная транзакция. На данном уровне каждый отдельный пользователь посредством SQL может обращаться с запросом на выборку или модификацию данных к одной базе данных в одной удаленной вычислительной системе. Транзакция, представляющая собой последовательность операторов SQL, может обращаться к двум или более базам данных, которые могут быть расположены в различных системах. При этом СУБД гарантирует целостность транзакций, т.е. то, что все части транзакции во всех участвующих системах будут завершены или целиком отменены. Очевидно, что уровень сложности системы, поддерживающей подобные транзакции должен быть на порядок выше, чем для предыдущих.
Чтобы обеспечить выполнение распределенной транзакции необходимо активное взаимодействия отдельных СУБД, участвующих в транзакции. Данное взаимодействие обычно осуществляется при помощи специального протокола, называемого протоколом двухфазного выполнения, основное назначение которого поддерживать целостность распределенных транзакций без участия пользователя.
Уровень 4. Распределенный запрос. На данном уровне один оператор SQL может обращаться к таблицам из двух или более баз данных, которые расположены в различных вычислительных системах. При этом СУБД отвечает за автоматическое выполнение оператора во всех системах, участвующих в запросе. Транзакция представляет собой последовательность инструкций. Как и на предыдущем уровне, СУБД должна обеспечить целостность распределенной транзакции во всех участвующих системах.
На уровне распределенных запросов предъявляются повышенные требования к программам оптимизации инструкций. На данном уровне оптимизирующая программа при оценке альтернативных способов обслуживания оператора SQL должна учитывать скорость передачи данных в сети. Например, если локальной СУБД приходится многократно обращаться к некоторой удаленной таблице (допустим при создании объединения), то, эффективнее будет скопировать по сети некоторую часть таблицы целиком, посредством одной операции групповой передачи данных, чем многократно считывать по сети отдельные записи.
Оптимизирующая программа должна также определить, какая СУБД будет эффективнее управлять выполнением оператора. Например, если большая часть таблиц находится в удаленной системе, то, вероятно, было бы эффективнее, чтобы обработку выполняла удаленная СУБД этой системы. Однако при чрезмерной загрузке удаленной системы такое решение может оказаться малоэффективным. В целом, задача оптимизирующей программы становится и более сложной, и более важной.
Архитектура "клиент-сервер" на базе Интернет имеет трехуровневую организацию. Пользовательским интерфейсом является Web-браузер, расположенный на персональном компьютере – "тонком" клиенте. Web-браузер взаимодействует с Web-сервером, последний в свою очередь является клиентом для сервера баз данных. Наиболее часто в качестве сервера БД используется SQL-сервер.
Различают следующие механизмы доступа к БД: на стороне Web-сервера и на стороне Web-клиента.
В первом случае обращение к серверу БД производится следующим путем. Web-клиент заполняет специальную форму запроса к БД и пересылает ее Web-серверу. Программами Web-сервера вызываются внешние по отношению к ним программы в соответствии с соглашениями одного из интерфейсов: СGI (Common Gateway Interface - «общий интерфейс шлюза») или API. Внешние программы пишутся на языках программирования типа С++, Perl, PHP. Программы, написанные в соответствии с интерфейсом СGI, называются СGI-сценариями. Внешние программы взаимодействуют с сервером БД на языке SQL, преобразуя текст запроса в HTML-форме в SQL-запрос. После получения результатов запроса внешняя программа формирует требуемую HTML-страницу, передает ее Web-серверу, который пересылает ее Web-клиенту.
При доступе к БД на стороне клиента основным средством реализации механизма взаимодействия Web-клиента и сервера БД является язык Java, на котором пишутся программы (апплеты). Java - программы хранятся на Web-сервере. В тексте HTML-документа ставятся в нужных местах ссылки на соответствующие апплеты, при обнаружении которых в процессе работы с гипертекстом происходит автоматическая пересылка Java - программы с сервера в среду выполнения браузера и загрузка на выполнение. В диалоговом режиме с пользователем уточняются характеристики запроса. Получив управление Java - апплет взаимодействует с сервером БД, в результате чего, полученная из БД информация предоставляется пользователю. Для обращения к серверам баз данных разработан стандарт JDBC (Java DataBase Connectivity - соединение с базами данных на Java) - платформенно-независимый промышленный стандарт взаимодействия Java - приложений с различными СУБД.