База данных

4.2 Модели архитектуры клиент-сервер

При построении распределенных ИС, работающих с БД, широко используется архитектура клиент-сервер. Ее основу составляют принципы организации взаимодействия клиента и сервера при управлении БД. Один из вариантов архитектуры клиент-сервер рассмотрен в подразделе 1.2. Чтобы охарактеризовать основные схемы взаимодействия процессов управления БД, воспользуемся Эталонной моделью Архитектуры открытых систем OSI. Согласно этой модели, функция управления БД относится к прикладному уровню.

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

Как поддерживающая интерфейс с пользователем программа, СУБД, в общем случае, реализует следующие основные функции:

управление данными, находящимися в базе;

обработка информации с помощью прикладных программ;

представление информации в удобном для пользователя виде.

Если система размещается на одной ЭВМ, то все функции собраны в одной программе и вызываются по схеме, подобной рассмотренной в разделе 1.

При размещении СУБД в сети возможны различные варианты распределение функций по узлам. В зависимости от числа узлов сети, между которыми выполняется распределение функций СУБД, можно выделить двухзвенные модели, трехзвенные модели и т. д. Место разрыва функций соединяется коммуникационными функциями (средой передачи информации в сети).

Двухзвенные модели распределения функций

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

Наиболее типичными вариантами разделения функций между компьютером-сервером и компьютером-клиентом являются следующие:

распределенное представление;

удаленное представление;

распределенная функция;

удаленный доступ к данным;

распределенная БД.

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

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

Рассмотрим сначала модели удаленного доступа к данным и удаленного представления (сервера БД) как наиболее широко распространенные.

В модели удаленного доступа к данным (Remote Data Access - RDA) программы, реализующие функции представления информации и логику прикладной обработки, совмещены и выполняются на компьютере-клиенте. Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовом функций специальной библиотеки API (Application Programming Interface - интерфейса прикладного программирования).

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

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

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

Модель сервера БД (DataBase Server - DBS) отличается от предыдущей модели тем, что функции компьютера-клиента ограничиваются функциями представления информации, в то время как прикладные функции обеспечиваются приложением, находящимся на компьютере-сервере. Эта модель является более технологичной, чем RDA-модель и применяется в таких СУБД, как Ingress, Sybase и Oracle. При этом приложения реализуются в виде хранимых процедур.

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

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

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

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

В модели распределенного представления имеется мощный компьютер-сервер, а клиентская часть системы практически вырождена. Функцией клиентской части является просто отображение информации на экране монитора и связь с основным компьютером через локальную сеть. СУБД подобного рода могут иметь место в сетях, поддерживающих работу так называемых Х-терминалов. В них основной компьютер (хост-машина) должен иметь достаточную мощность, чтобы обслуживать несколько Х-терминалов. X-терминал тоже должен обладать достаточно быстрым процессором и иметь достаточный объем оперативной памяти (дисковые накопители отсутствуют). Часто Х-терминалы создают на базе RISC-компьютеров (restricted [reduced] instruction set computer) - компьютеров с сокращенным набором команд. Все программное обеспечение находится на хост-машине. Программное обеспечение Х-терминала, выполняющее функции управления представлением и сетевые функции, загружается по сети с сервера при включении Х-терминала.

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

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

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

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

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

а) в локальной и удаленной базах хранятся отдельные части единой БД;

б) локальная и удаленная БД являются синхронизируемыми друг с другом копиями.

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

Трехзвенная модель распределения функций

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

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

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

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

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

Сложные схемы взаимодействия

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

При рассмотрении взаимодействия объектов в динамике получаются еще более сложные схемы взаимодействия.

Примером такой схемы является случай, когда в процессе работы роли объектов меняются: объект, являющийся в некоторый момент времени клиентом по отношению к другому объекту, в последующем становится сервером для другого объекта.

4.3 Управление распределенными данными

С управлением данными в распределенных системах связаны следующие две группы проблем: поддержка соответствия БД вносимым изменениям и обеспечение совместного доступа нескольких пользователей к общим данным.

Поддержка соответствия БД вносимым изменениям

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

Существуют две основные технологии децентрализованного управления БД:

распределенных БД (Distributed Database)

тиражирования, или репликации, БД (Data Replication).

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

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

Основным достоинством модели распределенной БД является то, что пользователи всех узлов (при исправных коммуникационных средствах) получают информацию с учетом всех последних изменений. Второе достоинство состоит в экономном использовании внешней памяти компьютеров, что позволяет организовывать БД больших объемов.

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

Модель тиражирования данных, в отличие от технологии распределенных БД, предполагает дублирование данных (создание точных копий) в узлах сети. Данные всегда обрабатываются как обычные локальные. Поддержку идентичности копий друг другу в асинхронном режиме обеспечивает компонент системы, называемый репликатором (replicator). При этом между узлами сети могут передаваться как отдельные изменения, так и группы изменений. В течение некоторого времени копии БД могут отличаться друг от друга.

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

Основной недостаток модели тиражирования БД заключается в том, что на некотором интервале времени возможно "расхождение" копий БД. Если отмеченный недостаток некритичен для прикладных задач, то предпочтительно иметь схему с тиражированием БД.

Доступ к общим данным

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

Монопольный доступ обычно используется в двух случаях:

во-первых, когда требуется исключить доступ к объектам со стороны других пользователей (например, при работе с конфиденциальной информацией);

во-вторых, когда производятся ответственные операции с БД, не допускающие других действий, например, изменение структуры БД.

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

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

Рассмотрим некоторый типичный набор блокировок. В конкретных программах схемы блокирования объектов могут отличаться от описываемой. Выделим четыре вида блокировок, перечисленные в порядке убывания строгости ограничений на возможные действия:

полная блокировка;

блокировка от записи;

предохраняющая блокировка от записи;

предохраняющая полная блокировка.

Полная блокировка. Означает полное запрещение всяких операций над основными объектами (таблицами, отчетами и экранными формами). Этот вид блокировки обычно применяется при изменении структуры таблицы.

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

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

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

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

В отношении перечисленных выше четырех блокировок действуют следующие правила совмещения:

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

блокировка от записи совместима с аналогичной блокировкой и предохраняющей полной блокировкой;

предохраняющая блокировка от записи совместима с обеими видами предохраняющих блокировок;

предохраняющая полная блокировка совместима со всеми блокировками, кроме полной.

Обычно в СУБД каждой из выполняемых с БД операций соответствует определенный вид блокировки, которую эта операция накладывает на объект. Пользователям современных СУБД, работающим в интерактивном режиме, не нужно помнить все тонкости механизма блокировки, поскольку система достаточно "разумно" осуществляет автоматическое блокирование во всех случаях, когда это требуется. При этом система сама стремится предоставить всем пользователям наиболее свободный доступ к объектам. При необходимости пользователь и программист может воспользоваться командными или языковыми средствами явного определения блокировок. Например, в СУБД Paradox для явного блокирования отдельной записи во время редактирования таблицы используется команда Record | Lock.

Тупики

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

взаимные (deadlock)

односторонние (livelock).

Простейшим случаем взаимного тупика является ситуация, когда каждый из двух пользователей стремится захватить данные, уже захваченные другим пользователем. В этой ситуации пользователь-1 ждет освобождения ресурса N, в то время как пользователь-2 ожидает освобождения от захвата ресурса М. Следовательно, никто из них не может продолжить работу.

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

Односторонний тупик возникает в случае требования получить монопольный доступ к некоторому ресурсу как только он станет доступным и невозможности удовлетворить это требование.

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

Пользователи и разработчики приложений в распределенной среде должны предусматривать обработку сигналов о тупиках.

4.4 Информационные системы в локальных сетях

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

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

Эти возможности примерно в равной мере предоставляются сетевыми ОС такими, как Novell NetWare З.х (4.х), Windows NT и Windows 95/98. Более слабые сетевые пакеты и утилиты могут предоставлять доступ к информации без автоматического запуска программ. В этом случае пользователь должен сначала скопировать программы и файлы с другого компьютера на свой, после чего запустить программу.

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

типа файл-сервер;

типа клиент-сервер;

основанные на технологии intranet.

Информационные системы типа файл-сервер можно строить двумя способами:

с использованием несетевых СУБД, предназначенных для применения на отдельной машине;

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

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

Запуск и функционирование несетевой СУБД, хранящейся на КК и работающей с локальными данными не отличается от обычного режима работы на отдельной ПЭВМ. Если используемые данные хранятся на КС, файловая система сетевой ОС "незаметно" для СУБД выполняет подгрузку нужного файла с удаленного компьютера. Заметим, что не каждая несетевая СУБД без проблем работает в среде любой сетевой ОС.

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

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

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

В сетевых СУБД с коллективным использованием файлов БД по-прежнему вся обработка информации производится на КК, а функции КС сводятся к предоставлению большой дисковой памяти. Такой подход нельзя считать эффективным, так как для обеспечения приемлемой скорости процесса обработки информации КК должен обладать высоким быстродействием и иметь большую емкость оперативной памяти. Кроме того, пересылка копий файлов БД и команд управления блокировками по линиям связи существенно увеличивает нагрузку на подсистему передачи данных, что снижает общую производительность сети. Примерами сетевых СУБД являются: FoxPro 2.5 для Windows, dBase IY, Paradox. 3.5 для DOS.

Информационные системы типа клиент-сервер отличаются от систем типа файл-сервер прежде всего тем, что программы СУБД функционально разделены на две части, называемые сервером и клиентом. Между клиентской и серверной частями системы возможны различные варианты распределения функций (подраздел 4.2).

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

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

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

В качестве сервера может использоваться ядро профессиональной реляционной СУБД (например, Informix 7.x и Sybase System 10) или некоторый SQL-сервер (например, Novell NetWare SQL и Microsoft SQL Server).

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

Рассмотренные схемы функционирования СУБД и внешних приложений касаются наиболее типичных вариантов их построения.

4.5 Информационные системы в Internet и Intranet

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

1. Большая протяженность коммуникационных линий, что сказывается на временных характеристиках обмена. Кроме того, большая удаленность лишает смысла загрузку программ с одного компьютера на другой и не позволяет выполнять пересылку больших объемов данных в реальном масштабе времени, как в сетевых СУБД локальных сетей.

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

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

Перед рассмотрением моделей и механизмов использования БД дадим краткую характеристику Internet.

Характеристика Internet

Основными видами услуг (сервиса), предоставляемых пользователям при подключении к Internet, являются:

электронная почта (E-mail);

телеконференции (UseNet);

система эмуляции удаленных терминалов (TelNet);

поиск и передача двоичных файлов (FTP);

поиск и передача текстовых файлов с помощью системы меню (Gopher);

поиск и передача документов с помощью гипертекстовых ссылок (WWW или "Всемирная паутина").

Создание и развитие этих способов связано с историей Internet. Каждый из них характеризуется своими возможностями и различием в организации протоколов обмена информацией. Под протоколом, в общем случае, понимается набор инструкций, регламентирующих работу взаимосвязанных систем или объектов в сети.

Электронная почта (E-mail) - наиболее простой и доступный способ доступа в сети Internet. Позволяет выполнять пересылку любых типов файлов (включая тексты, изображения, звуковые файлы) по адресам электронной почты в любую точку планеты за короткий промежуток времени в любое время суток. Для передачи сообщения необходимо знать электронный адрес получателя. Работа электронной почты основана на последовательной передаче информации по сети от одного почтового сервера к другому, пока сообщение не достигнет адресата. К достоинствам электронной почты относятся высокая оперативность и низкая стоимость. Недостаток электронной почты состоит в ограниченности объема пересылаемых файлов.

Система телеконференций UseNet разработана как система обмена текстовой информацией. Она позволяет всем пользователям Internet участвовать в групповых дискуссиях, называемых телеконференциями, в которых обсуждаются всевозможные проблемы. Сейчас в мире насчитывается более 10 тысяч телеконференций. Информация, посылаемая в телеконференции, становится доступной любому пользователю Internet, обратившемуся в данную телеконференцию. В настоящее время телеконференции позволяют передавать файлы любых типов. Для работы с телеконференциями наиболее часто используются средства программ просмотра и редактирования Web-документов.

TelNet - это протокол, позволяющий одному компьютеру использовать ресурсы другого (удаленного) компьютера. Другими словами - это протокол удаленного терминального доступа в сети.

FTP (File Transfer Protocol) - это протокол, позволяющий передавать файлы произвольного формата между двумя компьютерами сети. Программное обеспечение FTP разработано по архитектуре "клиент-сервер" и разделено на две части: серверную (FTP-сервер) и клиентскую. FTP-клиент, в общем случае, позволяет пользователям просматривать файловую систему FTP-сервера и производить с ней обмен файлами (выгружать файлы своего компьютера, загружать, переименовывать и удалять файлы удаленного компьютера). Достоинством данного протокола является возможность передачи файлов любого типа, в том числе исполняемых программ. К недостатку протокола FTP следует отнести необходимость априорного знания местоположения отыскиваемой информации (FTP-адреса).

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

WWW (World Wide Web - всемирная паутина) представляет собой самое популярное и современное средство организации сетевых ресурсов. Она строится на основе гипертекстового представления информации.

Гипертекстовый документ {гипертекст) представляет собой текст, содержащий ссылки на другие фрагменты текстов произвольных документов, в том числе и этого документа. Гипертекстовый документ подготавливается на стандартизованном языке HTML (HyperText Markup Language - язык разметки гипертекста). Он состоит из страниц (web-страниц), доступ к которым основан на протоколе передачи гипертекста (HyperText Transfer Prococol, HTTP).

HTML-документ представляет собой ASCII-файл, доступный для просмотра и редактирования в любом редакторе текстов. В отличие от обычного текстового файла, в нем присутствуют специальные команды - тэги, которые указывают правила форматирования документа. С помощью тэгов описываются различные элементы документа: заголовки, абзацы (параграфы), списки, ссылки, формы и т. д.

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

Фрагмент документа может включать в себя информацию в виде обычного текста, графического изображения, звука и движущегося изображения (анимации). Гипертекст с нетекстовыми документами часто называют гипермедиа.

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

Работа сети Internet основана на использовании протокола TCP/IP (Transmission Control Protocol/Internet Protocol - Протокол управления передачей данных/Протокол Internet), который используется для передачи данных в глобальной сети и во многих локальных сетях. TCP/IP в основном реализует функции транспортного и сетевого уровней модели OSI (подраздел 4.1). Он представляет собой семейство коммуникационных протоколов, которые по назначению можно разделить на следующие группы:

транспортные протоколы, служащие для управления передачей данных между двумя компьютерами;

протоколы маршрутизации, обрабатывающие адресацию данных и определяющие кратчайшие доступные пути к адресату;

протоколы поддержки сетевого адреса, предназначенные для идентификации компьютера по его уникальному номеру или имени;

прикладные протоколы, обеспечивающие получение доступа к всевозможным сетевым услугам;

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

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

Доступ пользователей к ресурсам Internet обычно производится с помощью программ-навигаторов, или броузеров (от англ. browser). В настоящее время к числу наиболее популярных программ этого класса относятся следующие: Netscape Navigator/ Communicator (Netscape) и MS Explorer (Microsoft). Хотя эти программы основаны на использовании протокола HTTP, они предоставляют простой доступ к другим сервисам Internet: электронной почте, новостям и т. д.

Броузер, обеспечивая доступ пользователя к ресурсам сети, по существу является программой-клиентом (или Web-клиентом). Программой, предоставляющей информационные ресурсы, является Web-сервер. Именно он осуществляет основную работу по сбору и получению информации из разных источников, после чего в стандартном виде предоставляет ее Web-клиенту. Рассмотрим организацию выбора информации для пользователя, если она находится в базах данных.

Базы данных в Internet и Intranet

Технология intranet по существу представляет собой технологию Internet, перенесенную в среду корпоративных ИС. Архитектура информационных систем в Internet и intranet является результатом эволюционного перехода от первых многопользовательских централизованных вычислительных систем (мэйнфреймов) через системы типа клиент-сервер к распределенным системам с централизованной обработкой и подготовкой информации к непосредственному потреблению. Рассмотрим кратко указанные этапы эволюции.

1. В мэйнфреймах вычислительные ресурсы, хранимые данные и программы обработки информации сконцентрированы в одной ЭВМ. Основным средством доступа был алфавитно-цифровой терминал (дисплей), управляемый ЭВМ. Вся обработка информации и подготовка ее к выдаче выполнялись на центральной ЭВМ. С терминалов, как правило, в машину передавались коды нажатия клавиш или содержимое буфера экрана, а обратно на терминал - пересылались отображаемые экраны с соответствующими кодами управления отображением.

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

2. Исторически следующим решением в области информационных систем была архитектура клиент-сервер.

В этих системах место терминала заняла ПЭВМ, а мэйнфрейма - компьютер-сервер. Ранее мы рассматривали спектр моделей подобных систем с различным распределением функций между компонентами. Если не брать во внимание модель "распределенного представления" (по сути повторяет модель централизованной многопользовательской системы), то можно заключить, что системы типа клиент-сервер имеют следующие достоинства:

высокая живучесть и надежность

легкость масштабирования

качественный пользовательский интерфейс

возможность одновременной работы с несколькими приложениями

высокие характеристики оперативности обработки информации.

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

3. Корпоративные системы Intranet, в отличие от систем клиент-сервер, ориентированы не на данные, а на информацию в ее окончательном и пригодном для использования неквалифицированным пользователем виде.

Новые системы объединяют в себе преимущества централизованных многопользовательских систем и систем типа клиент-сервер. Им присущи следующие черты:

на сервере порождается информация, пригодная для использования, а не данные (например, в случае СУБД - записи БД);

при обмене между клиентской и серверной частями используется протокол открытого стандарта, а не какой-то конкретной фирмы;

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

В случае, когда источником информации в Internet и intranet являются БД, имеет место взаимодействие компонентов WWW и традиционных СУБД. Различают два следующих варианта функционирования программного обеспечения WWW по доступу к БД: на стороне Web-сервера и на стороне Web-клиента. В модели доступа к БД на стороне сервера обращение к серверу БД обычно производится путем вызова программами Web-сервера внешних по отношению к ним программ в соответствии с соглашениями одного из интерфейсов: CGI (Common Gateway Interface - общий шлюзовый интерфейс), FastCGI или API (Application Program Interface - интерфейс прикладного программирования).

Внешние программы взаимодействуют с сервером БД на языке SQL, непосредственно обращаясь к конкретному серверу или используя драйвер ODBC (см. подраздел 9.3). Внешние программы пишутся на обычных языках программирования типа Си, Си++ и Паскаль или специализированных языках типа Peri или РНР. Программы, разработанные в соответствии с интерфейсом CGI, называются CGI-сценариями или CGI-скриптами. Для поддержки этого механизма на стороне клиента в языке HTML имеется средство включения в документ форм (тэг <FORM> языка HTML) представления запросов к БД.

Процедура доступа к БД с использованием интерфейса CGI включает в себя следующие этапы:

1. Запрос Web-клиентом у Web-сервера страницы, содержащей форму обращения к БД, если при просмотре документа пользователем Web-клиент встречает ссылку на такую страницу.

2. Заполнение Web-клиентом содержащейся на полученной странице формы запроса к БД и отправка ее Web-серверу. Правильность заполнения формы можно контролировать с помощью несложной программы, непосредственно находящейся в области HTML-страницы, в которой описана форма (обычно для этого используют языки VBScript или JavaScript).

3. Web-сервер, получив эту форму, запускает соответствующую внешнюю CGI-программу, передавая ей параметры (адрес и имя этой программы указывается в атрибуте ACTION тэга <FORM>).

4. Внешняя программа преобразует описанный в форме запрос к БД в соответствующий текст запроса на языке SQL, с которым обращается к серверу БД.

5. После получения результатов запроса внешняя программа формирует требуемую HTML-страницу, передает ее Web-серверу и завершает свое выполнение.

6. Web-сервер передает сформированную HTML-страницу Web-клиенту.

Основными достоинствами применения спецификации CGI для организации доступа к данным базы являются следующие:

языковая независимость - сценарий может быть написан практически на любом языке программирования, содержащем средства обработки строк;

процессная изолированность - сценарий выполняется на сервере как отдельный процесс, не имеющий доступа к защищенной системной информации сервера;

широкая распространенность, так как CGI-стандарт применим на каждом Web-сервере;

архитектурная независимость - программы, разработанные в соответствии с CGI-стандартом, не зависят от архитектуры сервера.

К главным недостаткам применения спецификации CGI относятся следующие:

необходимость всякий раз устанавливать и разрывать соединение с базой данных, поскольку отсутствуют средства поддержания постоянного соединения Web-сервера и СУБД;

ограничения на обработку исходной информации для запросов и результатов выполнения запросов;

трудоемкость выполнения программ, связанная с запуском программы как отдельного процесса. Это замедляет обработку запросов к данным и снижает эффективность работы сервера.

Для устранения недостатков CGI-спецификации разработана спецификация API. Программы, разработанные по этой спецификации, быстрее и эффективнее выполняются, поскольку организованы в виде динамических библиотек. Наиболее известными являются два интерфейса этого вида: NSAPI (компания Netscape) и ISAPI (компания Microsoft).

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

языковая зависимость - программа может быть написана только на языке, поддерживаемом данным API. Чаще всего это языки С и C++ (язык Peri, широко применяемый при написании CGI-скриптов, не применяется);

слабая защита сервера от ошибок прикладных программ и от возможности несанкционированного доступа к системным ресурсам, поскольку API-программа выполняется в адресном пространстве основного процесса сервера;

программы, как правило, не переносимы на другие программно-аппаратные платформы, поскольку привязаны к интерфейсу и архитектуре сервера.

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

При доступе к БД на стороне клиента основным средством реализации механизмов взаимодействия Web-клиента и сервера БД является язык Java. Кроме того, может использоваться JavaScript, разработанный для расширения возможностей декларативного языка HTML (нет операторов присваивания, сравнения, математических функций и пр.) на основе добавления процедурных средств. Программы на языке JavaScript выполняются на компьютере Web-броузером в режиме интерпретации.

Если в HTML-документе, требуется получить данные из БД, то поступают следующим образом.

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

2. В тексте HTML-документа в нужных местах ставятся ссылки на соответствующие апплеты. Сами программы хранятся на сервере.

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

4. Получив управление, Java-апплет осуществляет взаимодействие с сервером БД, в результате чего полученная из базы информация представляется пользователю.

Для обращений к серверам БД разработан стандарт JDBC (Java DataBase Connectivity - совместимость баз данных для Java), основанный на концепции ODBC. Стандарт JDBC разработан фирмами Sun/JavaSoft и обеспечивает универсальный доступ к различным базам данных на языке Java.

Из двух рассмотренных схем однозначного предпочтения тому или иному варианту отдать нельзя. Все зависит от целей и условий разработки клиент-серверных программ (наиболее существенной оказывается зависимость от ОС, а также от вида Web-сервера).