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

Тупики

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

Существует два основных вида тупиков: взаимные (deadlock) и односторонние (livelock).

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

Рис. 8.8. Примеры взаимных тупиков в распределенных БД

 

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

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

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

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

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

Рассмотрим основные схемы организации работы с данными в ЛВС.

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

В локальной сети выделяют следующие три варианта создания информационной системы.

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

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

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

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

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

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

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

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

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

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

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

 

Рис. 8.9. Система типа файл-сервер с несетевой СУБД

В качестве примеров несетевых СУБД можно назвать первые версии системы dBase III Plus, d Base IY и FoxBase.

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

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

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

 

Рис. 8.10. Система типа файл-сервер с сетевой СУБД

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

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

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

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

Структуру информационных систем типа клиент-сервер упрощенно можно представить как показано на рис 8.11.

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

 

Рис. 8.11. Информационная система типа клиент-сepвep

 

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

Хранимые на компьютере-сервере программы (процедуры) обработки данных называют хранимыми процедурами.

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

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

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

· идентификатор сеанса связи пользователя с СУБД;

· идентификатор хранимых команд и процедур;

· идентификатор результирующего множества;

· указатель текущей строки в результирующем множестве, обрабатываемом клиентским приложением.

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

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

· Delphi (Borland),

· Роwег Builder (Powersoft),

· ERwin (LogicWorks)

· Visual Basic (Microsoft),

· CA-Visual Objects (Computer Associates),

· SQL Windows (Gupta) и другие.

Кроме того, существуют средства разработки в рамках определенных СУБД. Все подобные средства, как правило, относятся к CASE-системам.

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

Схема доступа приложений к базам данных с помощью ОDВС показана на рис. 8.12. Доступ приложения к данным происходит путем вызова на языке SQL стандартных функций интерфейса ODBC. На компьютере-клиенте при этом должна функционировать операционная система MS Windows с интерфейсом ОDВС.

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

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

 

 

Рис. 8.12. Схема доступа к БД с помощью ODBC