Категория
Информатика
Тип
реферат
Страницы
17 стр.
Дата
26.07.2013
Формат файла
.doc — Microsoft Word
Архив
832467.zip — 63.67 kb
  • baza-dannyx-access-osobennosti-raboty-v-mnogopolzovatelskom-rezhime_832467_1.doc — 183.5 Kb
  • Readme_docus.me.txt — 125 Bytes
Оцените работу
Хорошо  или  Плохо


Текст работы

<</table>


База данных
Access. Особенности работы в многопользовательском режиме






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

Конфликты доступа

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

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

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

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

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

Конфигурация

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

• Сетевое размещение. В данной конфигурации единый MDB-файл располагается на сетевом серве­ре, и пользователи получают доступ к базе данных при обращении к серверу. Данные и выполня­емые модули могут содержаться в едином MDB-файле либо размещаться на файловом сервере в виде нескольких отдельных файлов. Преимуществом данной конфигурации является простота поддержки, поскольку при необходимости в обновлении нуждается лишь выполняемый файл. Однако, поскольку все формы, отчеты, модули, запросы, ЕХЕ-файлы Access, а также все библиотеки DLL и т.п. должны передаваться по сети на рабочую станцию, сетевой трафик неоправданно возрастает, а производительность значительно снижается. Вероятно, в подобных конфигурациях следует исполь­зовать связанные формы. Далее рассматриваются проблемы связывания форм с данными и возни­кающие при этом конфликты доступа.

• Разделенная база данных с размещенными в сети данными. Такая конфигурация по традиции на­зывается конфигурацией удаленной базы данных (отметим, что значение слова "удаленная" в чрез­вычайно динамичную эпоху Internet постепенно меняется и вскоре может устареть), поскольку данные отделены от выполняемого модуля или программного кода, хотя механизм баз данных и остается локальным. В отличие от конфигурации клиент-сервер, механизм баз данных Access на пользовательском ПК получает, обрабатывает, блокирует и снимает блокировку с данных, находя­щихся в MDB-файле на сетевом сервере. Работа в такой конфигурации зависит от механизмов баз данных одновременно работающих пользователей, а также от возможностей файлового сервера, касающихся поддержания сетевого графика. До настоящего времени при размещении приложений баз данных Access предпочтение отдают именно этому методу. Его преимуществом является высо­кая производительность и управляемость при корректном использовании. Поскольку при размеще­нии данных в сети по каналам связи передаются только они, сетевой трафик значительно снижается. Основной недостаток данной конфигурации заключается в том, что на каждом клиентском ПК необходимо устанавливать Access и выполняемый MDE- (скомпилированный вариант базы данных MDB) либо MDB-файл, что осложняет поддержку приложения. Тем не менее, существуют спосо­бы решения подобной проблемы.

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

• Конфигурация клиент-сервер. В Access 2000 появилась новая возможность создания клиент-сервер­ных приложений на базе проекта Microsoft Access. В такой конфигурации удаленными являются как данные, так и механизм баз данных. Если данными управляет SQL Server, Oracle или какой-либо иной сервер баз данных, расположенный на центральном компьютере, он также решает вопросы блокировки и проблемы работы в многопользовательской среде. Это не означает, что разработчик избавлен от необходимости решения всех связанных с ними задач, просто ему приходится иметь дело с иными наборами свойств, возможностей и правил. Основными преимуществами такой конфигу­рации являются высокая производительность, стабильность, возможность обслуживания большого количества пользователей и выполнения множества задач. Наибольший недостаток данной конфи­гурации состоит в высокой стоимости и значительной сложности.

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

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

Access и способы блокировки в Jet

Механизм Jet имеет схему блокировки, которая позволяет эффективно обслуживать несколько пользо­вателей. При использовании Jet с Access, а не с VB или каким-либо иным инструментом разработки необходимо учитывать, что некоторые действия выполняются по умолчанию. Данный раздел посвящен изучению этих вопросов.

Основные сведения о блокировке

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

В диалоговом окне Options (Параметры), отображающемся при выполнении команд меню Tools Options (Сервис / Параметры), во вкладке Advanced (Другие) имеется параметр Default open mode (Режим откры­тия, определенный по умолчанию). Здесь можно определить режим открытия базы данных, т.е. должна ли она открываться для монопольного доступа (только для одного пользователя на весь сеанс работы) или для общего доступа.

Если выбран режим Exclusive (монопольный доступ), базу данных имеет право открывать только один пользователь. В этом случае Access изменяет заголовок LDB-файла, тем самым блокируя его (подробнее об этом см. в разделе "LDB-файл") и запрещая доступ к данным для всех других пользователей. Очевид­но, для многопользовательского приложения такая настройка использоваться не должна. Однако такие процедуры, как сжатие и восстановление, следует выполнять над базой данных, открытой для монополь­ного доступа.

Режим Shared (Общий доступ) позволяет открывать базу данных нескольким пользователям одновре­менно. При этом Access в момент открытия базы данных заносит информацию о подключившихся
 к
 ней
 пользователях в LDB-файл и задействует механизм блокировки и освобождения страниц и строк.


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

Таблица 1 Параметры командной строки при запуске Access

Параметр

Описание

/Excl

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

/Ro

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

Отсутствует

Режим, определенный по умолчанию. Отсутствие параметра /Excl или /Ro позволяет открывать базу данных в режиме общего доступа либо в соответствии с определенным для нее режимом.

 СОВЕТ

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

Задавая параметры базы данных, разработчик может выбирать режим блокировки записи по умолча­нию: блокировку на уровне строки либо на уровне страницы.

Сравнение блокировки на уровне страницы с блокировкой на уровне строки

В прошлом Access были присущи недостатки, связанные с появлением конфликтов доступа при исполь­зовании несовершенного способа хранения и блокировки записей. Поскольку Access поддерживает пере­менную длину записей, простая реализация блокировки на уровне строки была затруднена. Обеспечивая преимущества такой структуры записей, Access был вынужден хранить записи в статической страничной структуре объемом 2 Кб (при использовании механизма баз данных Jet 4.0 для приложения Access 2000 объем страницы данных составляет 4 Кб). При умышленной либо случайной блокировке записи блокиро­валась вся страница, что приводит к недоступности всех ее записей. Несмотря на эффективность такого метода, его применение приводит к возникновению различных проблем, связанных с конфликтами до­ступа, а также сокращает число одновременно работающих пользователей приложения Access. Таким образом, при использовании Access возможности разработчика были ограниченны.

В Access 2000 механизм баз данных Jet 4.0 позволяет разработчикам выбирать метод блокировки по умолчанию: на уровне строки либо на уровне страницы. Теперь пользователь может блокировать только редактируемую запись, а не все записи на странице. Поскольку отдельная запись может блокироваться лишь на короткое время (например, при выполнении операторов SQL Delete, Update или Insert), вероятность конфликта двух пользователей во время ее редактирования ниже, чем при одновременной блокировке нескольких записей в схеме страничной блокировки. Ранее вероятность конфликта умножалась на число записей на странице, определение которого было затруднено. Количество записей на странице данных зависело от размера записей и от времени их ввода, поэтому предвидеть вероятность конфликта было затруднительно.

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

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

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

LDB-файл

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

Сравнение оптимистической, пессимистической блокировок и блокировки на уровне строки

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

Оптимистическая блокировка

Оптимистическая блокировка используется в Access по умолчанию, она проста в реализации, и обычно предпочтение отдают именно ей. При оптимистической блокировке записи предполагается, что конфликты доступа маловероятны и что запись блокируется лишь в момент ее фактического обновления. Это обес­печивает высокую степень доступности данных, поскольку право долговременного либо исключительно­го доступа к ним никому не предоставляется. В соответствии с вышесказанным при открытии записи для редактирования остальные пользователи также могут открывать ее для редактирования, причем преиму­щество сохранения внесенных изменений имеет первый пользователь. Хотя оптимистическая блокировка проста в реализации и обычно не порождает проблем доступа пользователей к своим данным, однако при ее использовании одним из наиболее важных вопросов работы с базами данных в многопользовательской среде является вопрос о том, чьи изменения следует сохранять. Когда пользователь 
А открывает запись для редактирования и накладывает на нее оптимистическую блокировку, ничто не мешает пользователю 
Б открыть эту же запись для внесения изменений. Если 
Б сохранит изменения раньше, чем это сделает 
А, пользователь 
А получит следующее сообщение:


"The Microsoft Jet database engine stopped the process because you and another user are attempting to change the same data at the same time."

 

("Механизм баз данных MicrosoftJet остановил процесс, поскольку вы и другой пользователь одновременно предприняли попытку доступа к тем же данным".)

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

Пессимистическая блокировка

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

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

Блокировка на уровне строки

Основным преимуществом блокировки на уровне строки является расширение доступа к базе данных для многих пользователей. При блокировке единственной редактируемой записи многим пользователям пре­доставляется доступ к большему объему данных без возникновения конфликтов блокировки или доступа к записям. Использование блокировки на уровне строки также позволяет разработчикам расширить гра­ницы использования пессимистической блокировки. Таким образом, пользователям предоставляются бо­лее знакомые и очевидные условия работы, в ходе которой они выполняют несложные операции открытия записи, ее редактирования и сохранения изменений. В предшествующих версиях Access пессимистическая блокировка не могла получить широкого распространения, поскольку страничный способ блокировки ог­раничивал количество одновременно работающих пользователей, которые должны были мириться с воз­можностью блокировки внесенных ими изменений другими пользователями. При этом разработчикам приходилось создавать схемы реализации привычных для пользователей условий работы (расширяющиеся записи, временные таблицы и т.п.). Блокировка на уровне строки является главным достижением в Jet 4.0. Она должна найти csoe применение в наиболее популярных и надежных приложениях.



Ваше мнение



CAPTCHA