Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

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

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

Двухуровневая модель

Рис. 5.1 иллюстрирует классическую двухуровневую модель клиент-сервер. Промежуточный уровень, который может присутствовать или отсутствовать, представляет собой драйвер, такой как ODBC, JDBC, PHP, или компонент доступа к данным, который интегрирован с программным кодом приложения. Возможны и другие уровни на клиентской стороне. Приложения также могут быть написаны с использованием прямого доступа к API без промежуточного уровня.

Рис. 5.1. Двухуровневая модель клиент-сервер

Многоуровневая модель

Увеличение возможностей масштабирования и требования большей функциональной совместимости приводят к модели с большим количеством уровней, как показано на рис. 5.2. Клиентский интерфейс перемещается в центр модели; он объединяется с одним или более уровнями сервера приложений. В этом центральном комплексе будут расположены средства промежуточного уровня и сетевые модули. Уровень приложения становится некоторым видом суперклиента базы данных - иногда обслуживая множество серверов баз данных - и сам становится Proxy-сервером (сервером-посредником) для запросов к базам данных от приложений. Он может быть размещен на том же аппаратном оборудовании, что и сервер базы данных, но также может выполняться и на своем оборудовании.

Рис. 5.2. Многоуровневая модель клиент-сервер

Стандартизация

Признанные стандарты функциональной совместимости аппаратного и программного обеспечения, и особенно языка запросов и описания метаданных, являются характерной чертой систем баз данных клиент-сервер. Развитие систем реляционных баз данных и консолидация стандартов SQL более двух десятилетий было и остается неразделимым. Абстрактная природа хорошо спроектированных систем реляционных баз данных вместе с их относительной нейтральностью по поводу выбора языка приложения для "предварительной обработки" гарантируют, что реляционные СУБД продолжают занимать свое место в качестве предпочтительной архитектуры систем клиент-сервер.

Тем не менее это не отменяет другие архитектуры. Хотя в настоящее время объекты систем баз данных продолжают оставаться тесно связанными с языками приложения, объектно-реляционные архитектуры становятся значительным посягательством на реляционные традиции. Самые последние стандарты SQL представляют некоторые положения по стандартизации объектно-реляционных методов и синтаксиса. Когда люди начинают требовать стандарты для технологий, обычно это хороший индикатор того, что технология может быть востребованной в скором времени.

Проектирование систем клиент-сервер

Факт, что системы клиент-сервер должны быть спроектированы для использования в сетях. Для новичков часто бывает потрясением открытие того, что "молниеносно выполняемая" задача, которая работала в приложении под Paradox или Access, занимает весь день после конвертирования в клиент-серверную реляционную СУБД.

"Что-то не так в Firebird, - говорят они. - Это не может быть код моего приложения - потому что я не изменял ничего! Это не может быть результатом моего проектирования базы данных - потому что то же проектирование было безупречным многие годы!" Знаменитые последние слова.

Основа проектирования клиентов для настольных систем резко отличается от проектирования удаленных клиентов в архитектуре клиент-сервер. Обязательный интерфейс просмотра в настольных системах, где отображаются "200 000 записей за один раз", создал крупную отрасль RAD разработки компонентов DBGrid, связанных с данными (data-aware components). Разработчику никогда не нужно думать о том, какое количество человек в состоянии просмотреть 200 000 записей в день, пусть только одним взглядом!

Эти компоненты в RAD, которые выполнили такую замечательную работу по представлению неограниченного объема данных в настольных системах в небольших контейнерах для произвольного просмотра, не являются дружественным интерфейсом для удаленных клиентов. Если ранее характерная клиентская операция цикла ("начать с первой записи и для каждой записи повторить"), казалась идеальной для обработки данных, которые размещались в памяти как локальные таблицы, то теперь удаленные пользователи клиентских компьютеров требуют принести им голову разработчиков на блюде.

Действительно, общим является то, что на проектирование базы данных наиболее сильно влияет восприятие клиентского интерфейса - "Мне нужна таблица, похожая на эту электронную таблицу!"- а не элегантная мудрость абстрактной модели данных.

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

Абстракция хранимых данных

Даже в современных системах клиент-сервер можно найти слишком много плохо выполняющихся, подверженных ошибкам приложений, которые были "спроектированы" с использованием отчетов и электронных таблиц в качестве основы для проектирования базы данных и пользовательского интерфейса. В итоге существует слишком много общего при переходе от настольных баз данных к Firebird с множеством следующих недружественных для платформ клиент-сервер "возможностей".

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

* Иерархические структуры первичных ключей (нужны во многих настольных системах баз данных для реализации зависимостей), что нарушает уточненную модель ограничений внешнего ключа в зрелых реляционных базах данных.

* Большие составные символьные ключи, составленные из столбцов реальных данных.

* Недостатки нормализации, приводящие к большому количеству записей содержащих много повторяющихся групп и редко требуемой информации.

* Большое количество частично совпадающих друг с другом индексов, не являющихся необходимыми.

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

Общей характеристикой приложений настольных баз данных является то, что они предоставляют интерфейс в виде таблицы: данные представляются в виде строк и столбцов с полосами прокрутки и другими элементами навигации для просмотра с первой строки до последней. Часто эти таблицы представляют собой визуальную структуру, которая в точности воспроизводит структуру метаданных исходных таблиц. Обычная ловушка- импортировать такие таблицы в систему клиент-сервер и считать, что задача миграции выполнена.

Перенос таких старых баз данных в систему клиент-сервер обычно требует большего, чем создание программы конвертирования данных. Выполните ваше конвертирование и будьте готовы рассматривать объекты вашей базы данных как основу для дальнейшей работы. Запланируйте выполнить заново анализ и новое проектирование полученного абстрактного стиля базы данных в структуры, которые будут хорошо работать в новом окружении. В Firebird очень просто создать новые таблицы и записать в них данные. Для хранения используйте простые ключи; преобразовывайте структуры больших таблиц в группу связанных нормализованных отношений; переносите группы повторяющихся столбцов в отдельные таблицы; изменяйте структуры ключей, которые уменьшают уровень зависимостей; устраняйте дублирование данных и т.д.