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

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

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

Эти возможности примерно в равной мере предоставляются сетевыми ОС такими, как 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-операторы серверу СУБД. Результаты выполнения запросов на сервере передаются обратно в приложение.

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