Организация многопользовательского доступа к данным

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

Рис. 7.34. Задание режима блокировки для данных, доступных из формы

Как видно из рисунка, свойство Блокировка записей может принимать значения:
- Отсутствует - допускается одновременное изменение записей со стороны нескольких пользователей. При этом если два пользователя пытаются сохранись произведенные изменения в одной и той же записи, то второму пользователю выводится предупреждающее сообщение, на основе которого он может либо отказаться от дальнейших действий, либо заместить изменения, сделанные первым пользователем, сохранив собственный вариант. Очевидно, что в таком режиме сохраняется максимальная свобода действий пользователей, "платой" за которую являются возможные конфликты ввиду несогласованности их действий.
- Всех записей - происходит блокировка всех записей в источнике данных при его открытии одним из пользователей, в результате чего он может беспрепятственно изменять его. Другие пользователи имеют доступ только на чтение (просмотр).
- Изменяемой записи - один из пользователей получает доступ на изменение нужной ему записи, а другие пользователи могут только читать содержащиеся в ней данные. Данный режим накладывает минимальные ограничения на совместную работу. Следует добавить, что технически в Access блокируются не записи как таковые, а так называемые страницы - блоки файла базы данных размером 2048 байт, содержащие нужные записи.
Отмена блокировки в Access происходит тогда, когда пользователь, ранее блокировавший запись, либо сохранит произведенные изменения, либо откажется от них. Для того чтобы изменения, производимые одним пользователем, становились видны другим, через определенные интервалы времени предусмотрено автоматическое обновление содержания таблиц, форм и отчетов. Значение периода обновления задается из меню Сервис > Параметры, вкладка Другие, поле Период обновления.
Другим ^существенным вопросом, который должен быть решен для обеспечения нормального функционирования многопользовательских СУБД, является организация системы администрирования данных. Среди задач администрирования могут быть названы:
- создание системы пользователей и разделение прав доступа различных пользователей к объектам СУБД;
- организация и поддержание системы резервного хранения информации и ее восстановления в случае программных и аппаратных сбоев;
- мониторинг программных и аппаратных ресурсов, задействованных для обеспечения работы СУБД, и принятие на его основе решений по оптимизации их использования.
Некоторые вопросы, связанные с организацией системы пользователей СУБД, будут рассмотрены в 7.4.3.
Первые многопользовательские СУБД имели централизованную архитектуру и базировались на больших компьютерах или мини-ЭВМ. Рабочие места пользователей располагались на терминалах, подключенных к центральному компьютеру, ria котором выполнялись все процессы по манипуляции с данными. Однако с распространением персональных компьютеров особую актуальность приобрели СУБД, реализующие технологии распределенной обработки данных, то есть такие технологии, которые позволяют вести одновременную работу с нескольких относительно ограниченных по аппаратным возможностям машин, объединенных в ceть. В этом случае одна часть функций СУБД выполняется на компьютере-клиенте, а другая - на компьютере-сервере, причем их взаимодействие осуществляется через некоторый согласованный протокол.
Исторически первая технология распределенной работы с данными получила название файл-сервер (FS-модель). В ее рамках предполагается, что один из компьютеров в сети является файловым сервером и предоставляет свои ресурсы по обработке файлов другим компьютерам, на нем также располагается хранилище данных. На других компьютерах имеется прикладное программное обеспечение, реализующее функции пользовательского интерфейса доступа к данным, и копия процессора базы данных (СУБД). Всякий раз, когда прикладная программа обращается к базе, процессор данных обращается к файловому серверу. В ответ файловый сервер направляет по сети требуемый блок данных, получив который, СУБД осуществляет действия, декларированные в прикладной программе. Протокол обмена между серверным и клиентскими компьютерами представляет собой набор низкоуровневых вызовов, обеспечивающих интерфейсному приложению доступ к файловой системе сервера.
Технологические недостатки FS-модели вытекают из внутренне присущих ей ограничений. Среди них в первую очередь следует назвать:
- высокий сетевой трафик, обусловливаемый необходимостью передавать большое количество файловых блоков от сервера к приложениям;
- ограниченный набор допустимых действий по обработке данных на файловом сервере, который не способен "понимать" внутреннюю логическую структуру базы данных и воспринимает эту базу так же, как и любой другой файл;
- отсутствие надежных средств обеспечения безопасности работы с данными - допускается защита только на уровне функций сетевой операционной системы.
Перечисленные проблемы определяют то, что СУБД, основанные на технологии файл-сервер, могут применяться только в очень ограниченных масштабах. Например, при создании коллективных информационных систем, рассчитанных на небольшое количество пользователей и ограниченные информационные потоки. Одновременно следует отметить, что FS-модель положена в основу архитектур подавляющего большинства настольных СУБД, таких как FoxPRO, Clipper, Clarion, Paradox, Access, завоевавших широкую популярность среди отечественных разработчиков.

7.4.2. Основные направления развития технологии клиент-сервер
Работа по преодолению недостатков, органически присущих системам файл-ceрвер, привела к появлению более прогрессивной технологии, получившей название - сервер. Ее принципиальные отличия показаны на рис. 7.35.

Рис. 7.35. Принципиальная схема технологий файл-сервер(a) и клиент- сервер(b)

В системе клиент-сервер процессор базы данных размещается на центральном сервере умеете с хранилищем данных. Он может обслуживать одновременно несколько клиентских приложений, управляя хранилищем и возвращая запрошенную информацию после обработки запросившему ее локальному приложению. К настоящему моменту можно назвать ряд этапов, которые технология клиент-сервер прошла в своем развитии: RD А-модёль, DBS-модель и AS-модель. В RDA-модели клиентское приложение направляет запросы (как правило, на языке SQL) к информационным ресурсам сервера, на котором функционирует ядро СУБД. Ядро обрабатывает полученные запросы и возвращает клиенту результат, оформленный как блок данных. При такой схеме программы на компьютерах-клиетах являются инициаторами манипуляций с данными, а ядру СУБД отводится я роль. Основное достоинство RDA-модели состоит в унификации интерфейса взаимодействия с сервером с помощью стандартного языка запросов.
Унификация позволяет реализовывать дополнительные меры по защите хранимой информации на уровне задания системы прав по отношению к тем иди иным командам. В рассматриваемой модели также происходит существенная разгрузка трафика сети за счет того, что между станциями сети теперь передаются не части файла базы данных, а команды и ответы на них.
Основу DBS-модели составляет механизм хранимых процедур. Хранимые процедуры- это средство программирования сервера баз данных. Они хранятся в словаре базы данных, могут разделяться между различными клиентами и выполняются на том же компьютере, где запущен программный процесс сервера баз данных. Как правило, языки, на которых создаются хранимые процедуры, представляют собой процедурные расширения языка SQL На настоящий момент не существует единого стандарта для таких языковых средств; поэтому они являются специфичными для каждой конкретной СУБД. Среди достоинств DBS-модели могут быть названы возможность централизованного администрирования прикладных функций, дальнейшее снижение трафика (вместо SQL-запросов по сети передаются вызовы хранимых процедур), экономия ресурсов компьютера за счет использования однократно разработанного плана выполнения процедуры. К традиционным проблемам, связанным с DBS-моделью, относят трудности, сопутствующие процессам создания, отладки и тестирования хранимых процедур. О популярности и перспективности данной модели свидетельствует прежде всего то, что она реализована в таких широко используемых реляционных СУБД, как Oracle, Sybase, Informix, Ingres.
В AS-модели процесс, выполняющийся на компьютере-клиенте, называется клиентом приложения (Application Client - А С) и отвечает за интерфейс с пользователем. В случае необходимости выполнить те или иные прикладные операции он обращается к серверу приложения (Application Server - AS). Все операции над информационными ресурсами выполняются специальными программными компонентами, по отношению к которым AS играет роль клиента. В качестве примера прикладных компонентов могут быть названы ресурсы различных типов - базы данных, очереди, почтовые службы и др.
Само по себе ядро базы данных Jet, как уже упоминалось ранее, не является процессором, поддерживающим технологию клиент-сервер. Однако с помощью Access можно создавать соответствующие приложения, связываясь с клиент-серверными источниками данных через ODBC.

7.4.3. Организация защиты данных в СУБД MS Access
Непременной функцией любой развитой СУБД является обеспечение защиты данных от несанкционированного доступа. Очевидно, что полноценный с точки зрения надежности и устойчивости режим защиты может быть обеспечен только в рамках промышленных систем управления при условии комплексной реализации мер программного, аппаратного и административного характера. Перед настоящим параграфом поставлена более скромная задача - на примере MS Access описать на принципиальном уровне те подходы, которые применяются в СУБД Для обеспечения программной защиты данных.
MS Access обеспечивает два традиционных способа защиты базы данных:
- установка пароля, требуемого при открытии базы данных;
- защита на уровне определения прав пользователей, которая позволяет ограничить возможность получения или изменения той или иной информации в базе данных для конкретного пользователя.
Кроме того, можно удалить изменяемую программу Visual Basic из базы данных, чтобы предотвратить изменения структуры форм, отчетов и модулей, сохранив базу данных как файл MDE.
Установка пароля на открытие базы данных представляет собой простейший способ защиты. После того как пароль установлен (функция меню Сервис > Защита > Задать пароль базы данных), при каждом открытии базы данных будет появляться диалоговое окно, в котором требуется ввести пароль. Открыть базу данных и получить доступ к ее ресурсам могут получить только те пользователи, которые введут правильный пароль. Этот способ достаточно надежен (MS Access шифрует пароль, так что к нему нет прямого доступа при чтении файла базы данных). Однако проверка проводится только при открытии базы данных, после чего все ее объекты становятся полностью доступными. В результате, установка пароля обычно оказывается достаточной мерой защиты для баз данных, которые совместно используются небольшой группой пользователей или установлены на автономном компьютере.
Гораздо более надежным и гибким способом организации защиты является защита на уровне пользователей. Он подобен способам, используемым в большинстве сетевых систем. Процесс задания защиты на уровне пользователей состоит из двух принципиальных этапов:
- создание системы пользователей, объединенных в группы (Сервис > Защита > Пользователи и группы);
- задание прав доступа различных пользователей и групп по отношению к объектам базы данных (Сервис > Защита > Разрешения).

Информация о системе пользователей сохраняется в специальном файле, называемом файлом рабочих групп. По умолчанию это файл System.mdw. Однако с помощью специальной программы, входящей в поставку Access, различные базы данных можно ассоциировать с различными файлами рабочих групп. При запуске Access от пользователей требуется идентифицировать себя и ввести пароль. Отдельные пользователи могут объединяться в группы, причем один и тот же пользователь может являться членом различных групп. Такая организация системы пользователей позволяет весьма гибко манипулировать набором их прав доступа, исходя из функциональной специфики предметной области. В файле рабочих групп Access по умолчанию создаются две группы: администраторы (группа Admins) и группа Users, в которую включаются все пользователи. Допускается также определение других групп. Процесс создания системы пользователей и определения их принадлежности к группам показан на рис. 7.36.

Как группам, так и пользователям предоставляются разрешения на доступ, определяющие допустимые для них действия по отношению к каждому объекту базы данных. Набор возможных прав, очевидно, определяется спецификой объекта. Так, к примеру, список градаций разрешений на работу с экранной формой показан на рис. 7.37.
По умолчанию члены группы Admins имеют все разрешения на доступ ко всем объектам базы данных. Поскольку группа Users объединяет всех пользователей то ей имеет смысл присваивать некоторый минимальный набор прав. Далее имеется возможность установить более разветвленную структуру управления, создавая собственные учетные записи групп, предоставляя этим группам соответствующие разрешения и добавляя в них пользователей. Процесс задания прав доступа пользователей по работе с формами базы данных TradeTest показан на рис. 7.37. Заканчивая разговор о системах защиты, еще раз подчеркнем, что ее эффективная реализация возможна только на основе подробного изучения функциональной структуры автоматизируемого объекта и тщательного проектирования системы управления данными.

Знаете ли Вы, что, как ни тужатся релятивисты, CMB (космическое микроволновое излучение) - прямое доказательство существования эфира, системы абсолютного отсчета в космосе, и, следовательно, опровержение Пуанкаре-эйнштейновского релятивизма, утверждающего, что все ИСО равноправны, а эфира нет. Это фоновое излучение пространства имеет свою абсолютную систему отсчета, а значит никакого релятивизма быть не может. Подробнее читайте в FAQ по эфирной физике.

Системы управления базами данных

Организация многопользовательского доступа к данным

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