В базах данных клиент-сервер клиенты - даже если они расположены на той же машине, что и сервер, - никогда не обращаются к физическим данным, кроме как отправляя сообщения серверу с указанием того, что они хотят сделать. Сервер самостоятельно обрабатывает эти сообщения и выполняет запросы, управляя обращениями к дискам и правами доступа. Сервер также выполняет все физические изменения метаданных и структур хранения данных, используя физическую структуру на диске (On-Disk Structure, ODS), которая независима от программ ввода/вывода файловой системы хоста.
Характеристики СУБД клиент-сервер
Масштабируемость
Появление сравнительно недорогих компьютерных сетей между 1980-ми и 1990-ми годами вызвало увеличенный спрос на масштабируемые информационные системы с дружественным пользователю интерфейсом. Программное обеспечение электронных таблиц и настольных баз данных, а также графический интерфейс дали пользователям, не являющимся специалистами, понимание мощности использования компьютеров. Когда совместное использование файлов в сетях и различного вида программного обеспечения стало стандартной практикой на больших предприятиях, заказчики запросили большего. Настольные и основанные на локальных сетях (Local Area Network, LAN ) системы управления данными также стали использоваться и в весьма малых бизнесах. Сегодня практически немыслимо проектировать информационную систему предприятия для монолитной модели на мэйнфрейме с текстовым терминалом.
Масштабируемость оценивается в двух размерностях: горизонтальной и вертикальной. Горизонтальная масштабируемость - способность системы добавлять дополнительных пользователей без воздействия на возможности программного обеспечения или используемые ресурсы. Вертикальная масштабируемость связана с тем, что будет сделано для переноса системы на более простые или более сложные платформы и конфигурации аппаратных средств в ответ на изменение требований нагрузки и доступа. Диапазон меняется от нижнего уровня - например, сделать систему доступной для пользователей мобильных устройств - до верхнего уровня, который не имеет концептуальных ограничений.
Функциональная совместимость
Архитектура клиент-сервер для систем баз данных развивалась как ответ на уязвимость, низкий уровень нагрузки и ограничения по скорости модели базы данных совместного доступа к файлам в компьютерных сетях при потребности увеличения количества пользователей. Острая необходимость в этом совпала с параллельной разработкой языка SQL. Оба направления отчасти были стратегиями нейтрализации зависимости аппаратного обеспечения мэйнфреймов и программного обеспечения, которая преобладала в 1980-x годах. Настоящая архитектура баз данных клиент- сервер является неоднородной и функционально совместимой (интероперабельной) - она не ограничивается одной платформой аппаратных средств или одной операционной системой. Эта модель позволяет клиентам и серверам независимо размещаться в узлах сети на аппаратных средствах и в операционных системах, соответствующих их функциям. Приложения клиентов могут одновременно связываться с множеством серверов, выполняющихся в различных операционных системах.
Защита данных
Огромный недостаток систем файл-серверных баз данных- незащищенность данных от ошибок, повреждений и разрушения по причине их физической доступности при совместном использовании файлов клиентами и установления над ними прямого контроля со стороны человека. В модели базы данных клиент-сервер приложения клиентов никогда не работают с физическими данными. Когда клиентский запрос изменяет состояние данных, сервер подвергает запрос строгой проверке. Он отвергает запросы, которые не соответствуют внутренним правилам или правилам метаданных. Когда выполняется успешный запрос на запись данных, фактическое изменение состояния базы данных полностью выполняется кодом, находящимся в модуле сервера, а структура диска находится под контролем сервера.
Распределение функций
Модель клиент-сервер позволяет отдельным фрагментам работы системы быть эффективно распределенными между компонентами аппаратуры и программного обеспечения. Сервер базы данных заботится о хранении, управлении и поиске данных, а через хранимые процедуры, триггеры и другие вызываемые процессы он обеспечивает большое количество возможностей обработки данных системы. Процесс клиента является "острием" приложений, транслируя их запросы в структуры коммуникации, которые формируют протоколы для доступа к базам данных и к данным.
Приложения являются динамическим уровнем в этой модели. Они обеспечивают потенциально бесконечное множество интерфейсов, через которые люди, машины и внешние программные процессы взаимодействуют с клиентским процессом. В этой части клиентский модуль представляется приложениям через понятный, предпочтительно стандартизованный, независимый от языка программирования интерфейс прикладного программирования (Application Programming Interface, API).
В некоторых системах приложения могут действовать почти полностью как поставщики информации и приемники ввода, виртуально делегируя все операции манипулирования данными серверу базы данных. Это является идеалом клиент-серверных систем, поскольку локализует задачи, интенсивно использующие центральный процессор, и позволяет приложениям использовать возможности рабочей станции для лучшей реализации интерфейса пользователя.
На другом конце шкалы находятся системы, в которых из-за плохого проектирования или из-за отсутствия функциональной совместимости вся обработка данных виртуально производится на клиентских рабочих станциях. Для таких систем часто бывает характерным плохо выполненный интерфейс пользователя, задержки при синхронизации состояния базы данных и ненадежность взаимодействия с сетью.
Между небесами и адом находятся хорошо выполненные системы баз данных клиент-сервер, которые прекрасно используют возможности обработки на серверах, сохраняя некоторые функции обработки данных на рабочих станциях, когда это оправдано сокращением сетевого трафика или повышением гибкости выполнения задач.
Двухуровневая модель
Рис. 5.1 иллюстрирует классическую двухуровневую модель клиент-сервер. Промежуточный уровень, который может присутствовать или отсутствовать, представляет собой драйвер, такой как ODBC, JDBC, PHP, или компонент доступа к данным, который интегрирован с программным кодом приложения. Возможны и другие уровни на клиентской стороне. Приложения также могут быть написаны с использованием прямого доступа к API без промежуточного уровня.
Рис. 5.1. Двухуровневая модель клиент-сервер
Многоуровневая модель
Увеличение возможностей масштабирования и требования большей функциональной совместимости приводят к модели с большим количеством уровней, как показано на рис. 5.2. Клиентский интерфейс перемещается в центр модели; он объединяется с одним или более уровнями сервера приложений. В этом центральном комплексе будут расположены средства промежуточного уровня и сетевые модули. Уровень приложения становится некоторым видом суперклиента базы данных - иногда обслуживая множество серверов баз данных - и сам становится Proxy-сервером (сервером-посредником) для запросов к базам данных от приложений. Он может быть размещен на том же аппаратном оборудовании, что и сервер базы данных, но также может выполняться и на своем оборудовании.
Рис. 5.2. Многоуровневая модель клиент-сервер
Стандартизация
Признанные стандарты функциональной совместимости аппаратного и программного обеспечения, и особенно языка запросов и описания метаданных, являются характерной чертой систем баз данных клиент-сервер. Развитие систем реляционных баз данных и консолидация стандартов SQL более двух десятилетий было и остается неразделимым. Абстрактная природа хорошо спроектированных систем реляционных баз данных вместе с их относительной нейтральностью по поводу выбора языка приложения для "предварительной обработки" гарантируют, что реляционные СУБД продолжают занимать свое место в качестве предпочтительной архитектуры систем клиент-сервер.