Выделяются  четыре подхода, реализованные в  следующих моделях:

• модель файлового сервера (File Server - FS);
• модель доступа к удаленным данным (Remote Data Access - RDA);
• модель севера базы данных (DataBase Server - DBS);
• модель сервера приложений (Application Server - AS).

      FS-модель является базовой для локальных сетей персональных  компьютеров. Некоторое время назад она была исключительно популярной среди отечественных разработчиков, использовавших такие системы, как FoxPRO, Clipper, Clarion, Paradox и т. д. Суть модели проста и всем известна. Один из компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Файловый сервер работает под управлением сетевой операционной системы (например,  Novell NetWare) и играет роль компонента доступа к информационным ресурсам (то есть к файлам). На других компьютерах в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент Протокол обмена представляет собой набор низкоуровневых вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.

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

      Более технологичная RDA-модель существенно отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как  правило, SQL-сервер. В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Последний поддерживает  как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается операторами специального языка (SQL, например).

      Клиент  направляет запросы к информационным ресурсам (например, к базам данных) по сети удаленному компьютеру. На нем функционирует ядро СУБД, которое обрабатывает запросы, выполняя предписанные в них действия и возвращает клиенту результат, оформленный как блок данных. При этом инициатором манипуляций с данными выступают программы,  выполняющиеся на компьютерах-клиентах, в то время как ядру СУБД отводится пассивная роль - обслуживание запросов и обработка данных.

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

      RDA-модель  не лишена ряда недостатков.  Главный из них: удовлетворительное  администрирование приложений в  RDA-модели практически невозможно  из-за совмещения в одной программе  различных по своей природе  функций (функции представления и прикладные функции).

      Наряду  с RDA-моделью все большую популярность приобретает DBS-модель Она реализована в некоторых реляционных СУБД (Informix, Ingres,  Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. В DBS-модели компонент представления выполняется на компьютере-клиенте,  в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, то есть ядро СУБД.

      Достоинства DBS-модели: возможность централизованного  администрирования прикладных функций; снижение трафика  (вместо SQL-запросов по сети направляются вызовы хранимых процедур); возможность разделения процедуры между несколькими приложениями.

      В AS-модели процесс, выполняющийся на компьютере-клиенте, отвечает,  как обычно, за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client - AC). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции и называется  сервером приложения (Application Server - AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, реализуемом на отдельном сервере, по отношению к которому AS играет роль клиента.

      RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту,  в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом  представления, во-втором - интегрируется в компонент доступа к информационным ресурсам. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения,  для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций

      Активный  сервер

      Идея  активного сервера принципиально  изменяет представление о роли, масштабах и принципах использования СУБД,

      В базе, помимо собственно данных и непосредственных связей между ними, должны храниться  знания о данных, а она сама должна адекватно отражать динамические процессы, происходящие в реальном мире. Следовательно, необходимо иметь средства хранения и управления такой информацией.

      Указанные выше требования выливаются в решение  следующих задач. 

      Во-первых, необходимо, чтобы база данных в  любой момент времени правильно  отражала состояние предметной области - данные должны быть взаимно непротиворечивыми. Пусть, например,  база данных Кадры хранит сведения о рядовых сотрудниках, отделах, в которых они работают, и их руководителях. Нужно учесть следующие правила: каждый сотрудник должен быть подчинен реальному руководителю; если руководитель уволился, то все его сотрудники переходят в подчинение другому, а отдел реорганизуется; во главе каждого отдела должен стоять реальный руководитель и т. д.

      Во-вторых, база данных должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rules). Завод может нормально работать только в том случае, если на складе имеется достаточный запас деталей определенной номенклатуры. Следовательно, как только количество деталей некоторого типа станет меньше минимально допустимого, завод должен докупить их в нужном количестве.

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

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

      В-пятых, важная проблема СУБД - контроль типов данных.

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

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

      Другим  важным требованием реальной жизни  является синхронизация работы нескольких программ, обращающихся к базе данных. Рассмотрим пример. Финансовая система  завода должна отслеживать поступление платежей за продукцию на некоторый счет. Как только деньги поступили (все знают, насколько это важное событие - "пришли деньги"!), все прикладные программы, включенные в финансовую систему, должны быть оповещены об этом событии. После этого каждая из них может предпринять некоторые действия. Так, программа Отгрузка Продукции должна найти в базе данных соответствующий заказ, определить количество заказанной продукции, сроки поставки, сформировать и послать на склад готовой продукции заказ на отгрузку, распечатать сопроводительные документы - то есть подготовить продукцию к отправке. Программа Бухгалтерия, в частности, должна по дате поступления денег определить, просрочен ли платеж, и, если это так, начислить штраф. Все эти действия активизируются событием в базе данных - поступлением денег на счет (в терминах реляционной СУБД это означает добавление новой строки в таблицу Платежи). Работа всех программ синхронизируется этим событием.

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

      Общепринятый  способ преодоления ограничения на типы данных в СУБД заключается в приведении данных новых типов к стандартным. Но прямое приведение новых типов данных к стандартным чревато ошибками - необходимо их преобразование в данные стандартных типов. Функции преобразования данных должны взять на себя прикладные программы (больше некому). В результате получается весьма громоздкая схема. Программа извлекает из базы данные новых типов, представленные как стандартные, преобразует и обрабатывает их, затем вновь преобразует и передает серверу для хранения. Сервер в обработке данных новых типов при такой схеме участия не принимает.

      Другое  важнейшее требование к современным  СУБД состоит в возможности хранения неструктурированных объектов большого объема (Binary Large OBjects - BLOB). Отвечая на это требование, разработчики СУБД предусматривают такую возможность. Однако при этом сервер только хранит такие объекты, и не обладает возможностями их обработки. Например,  работая с графическим объектами, сервер не делает различий между изображением автомобиля BMW и структурой ДНК. Сервер вынужден передавать их для интерпретации прикладной программе, которая сможет разобраться, что есть что.

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

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