 |
Рис29. Окно Администратора источников данных ODBC
|
|
|
|
Задание ODBC-источника данных (DSN - data source name) является действием, которое осуществляется средствами операционной системы, управляющей компьютером. В частности, в операционных средах Windows 95/Windows 98 для этого в Панели управления предусмотрен пункт Источники Данных ODBC (32 разр), из которого вызывается Администратор источников данных ODBC. С его помощью могут быть заданы:
- пользовательский DSN - источник данных, доступный только текущему пользователю на текущем компьютере;
- файловый DSN - источник данных, которые могут применять совместно различные пользователи, у которых установлены одинаковые ODBC-драйверы;
- системный DSN - источник данных, доступный всем пользователям и службам текущего компьютера.
Окно Администратор источников данных ODBC показано на рис. 29.
Доступ из MS Access к источникам данных в формате других программных приложений
В MS Access предусмотрены две принципиальные возможности работы с внешними данными. Это импорт данных и связь с внешними таблицами данных. Оба режима доступны из меню главного окна базы данных: Файл > Внешние данные.
В случае импорта происходит создание дубликата внешних данных во вновь создаваемой таблице. Среди преимуществ такого решения могут быть названы:
- доступность всего арсенала средств СУБД Access при манипуляциях импортированными данными;
- высокое быстродействие при обращении к ним;
- независимость от исходного источника данных.
Однако, приобретая указанные преимущества, мы одновременно получаем и потенциальные проблемы, связанные с поддержанием актуальности и соответствия друг другу двух параллельных копий одной и той же информации. Очень часто подобные проблемы оказываются неразрешимыми. Актуальность данных является для нас критичным фактором, то необходимо использовать другой способ работы с внешними данными - связь. В этом случае в базе данных добавляется лишь ссылка на внешние источники данных и работа с ними происходит с помощью специальных драйверов. В поставку MS Access традиционно входят драйверы для работы с данными, созданными в форматах Paradox" Excel, dBase, FoxPRO, а также в текстовом (*.txt) и гипертекстовом (*.htm) форматах. Базы данных Paradox, Excel, dBase, FoxPRO и некоторых других форматов также называют базами данных с индексно-оследовательной организацией (англ. - ISAM - Indexed Sequential Access Method). Специфические IS AM-драйверы, учитывающие конкретные особенности перечисленных форматов организации данных, как правило, обеспечивают высокую эффективность и быстродействие при работе с ними. Одновременно в Access существует возможность работы с обширным множеством универсальных источников данных, для которых установлены ODBC-драйверы. Для этого при указании типа файла, с которым устанавливается связь, необходимо выбрать Базы данных ODBCQ (рис. 30).
|
|
|
Рис. 30. Выбор типа внешнего источника данных
"Платой" за применение технологии связывания с внешними данными являются ограничения возможностей по управлению структурой добавляемых таблиц, а также зависимость от состояния самого внешнего источника, к которому мы подключаемся.
7.3.3. Технологические решения по организации доступа к данным.
Рассмотрим чуть подробнее архитектуру доступа к данным в Access. Схематично она представлена на рис. 31. В представленной схеме блок пользовательского интерфейса олицетворяет видимую часть СУБД, то есть то, с чем пользователь взаимодействует непосредственно (формы, отчеты и другие объекты). Под хранилищем данных понимаются файл (файлы), содержащие таблицы данных (например, в Access это mdb-файлы). Хранилище - это некоторый пассивный элемент, в нем данные просто содержатся. Осуществлять манипуляции с ними - это задача процессора базы данных (или, как еще говорят, ядра базы данных). Он транслирует команды приложения в физические операции, непосредственно меняющие файл (файлы) хранилища данных. Основным достоинством описанной схемы является независимость приложения от типа базы данных, к которой она обращается: будут ли это данные во внутреннем формате Access или данные какой-то другой структуры - в приложении используются одни и те же объекты и методы доступа к ним.
|
|
|
Рис. 31. Архитектура доступа к данным в Access
В СУБД MS Access используется процессор, получивший название Jet (Join* Engine Technology). Он реализован в виде набора файлов динамически компонуемых библиотек (DLL), которые связываются с прикладной программой Access в период ее выполнения. В состав процессора Jet входят процессор запросов SQL и процессор обработки результатов, возвращаемых этими запросами. Рассмотренная ранее модель объектного интерфейса доступа к данным ОАО представляет собой программную надстройку над процессором Jet. Jet также реализует описанные в.3.1 возможности по доступу к внешним данным в формате ISAM и источникам данных ODBC. Для работы СУБД MS Access 97 был использован процессор Jet версии 3.5 для 32-разрядных приложений. Среди принципиальных преимуществ новой версии могут быть названы:
- ODBCDirect - альтернативный режим DAO, который предоставляет возможности прямого обращения к источникам данных ODBC в обход ядра Jet. Это позволяет в некоторых случаях оптимизировать процесс работы с данными за счет использования специфических характеристик удаленных ODBC-источников;
- для баз данных, управляемых процессором Jet, определены новые объекты, свойства и методы, позволяющие использовать новые возможности частичной репликаций.
Также следует отметить, что в Jet реализована технология Rushmore - специальная методика управления запросами, которая позволяет очень эффективно отбирать Наборы записей при использовании в их критериях определенных типов выражений.
4. Организация многопользовательского доступа к данным
4.1. Проблема многопользовательского доступа и параллельной обработки данных в автоматизированных информационных системах.
Естественным следствием развития СУБД является проблема организации совместной работы нескольких пользователей с одной и той же совокупностью данных, или, кратко, проблемы многопользовательского доступа к данным. Остановимся более подробно на основных аспектах этой проблемы. Прежде всего ситуация разделения одной и той же совокупности данных между несколькими пользователями может приводить к возникновению конфликтов (попытка единовременного изменения одной и той же записи, совпадение операций чтения и удаления информации и т. д.). Отдельное место при работе с СУБД занимают вопросы предотвращения коллизий, которые могут возникнуть в случае несогласованных изменений структуры таблиц, форм дли отчетов одним пользователем, когда с ними работают другие. С точки зрения организации совместного доступа к данным со стороны нескольких пользователей режимы работы с ними делятся на режим монопольного (эксклюзивного) доступа и режим общего (разделенного) доступа. Режим монопольного доступа к базе данных предусматривает, что только один из пользователей (программных процессов) может работать с ней, а возможность ее открытия другими пользователями (процессами) блокируется. Открытие базы данных в монопольном режиме, как правило, используется для выполнения операций по изменению структуры таблиц и связей между ними, экспорта большого количества информации, выполнения служебных операций с данными (сохранение, восстановление, сжатие) и т. п.
Соответственно, в режиме разделенного доступа сразу несколько пользователей могут работать с базой данных. Для предотвращения возможных конфликтов при попытках со стороны различных пользователей изменить одни и те же записи в СУБД используется механизм блокировок. Блокировка того или иного объекта в случае работы с ним какого-либо пользователя означает предотвращение любых других попыток изменить этот объект, но при этом сохраняется возможность его чтения. Таким образом, механизм блокировок предоставляет более гибкие возможности для манипуляций с данными по сравнению с режимом монопольного доступа. Для различных СУБД конкретные технические решения по реализации аппарата блокировок существенно различаются. В MS Access, в частности, при изменении записи одним пользователем по умолчанию происходит ее автоматическая блокировка вплоть до момента завершения операции. При создании форм, отчетов или запросов в Access предусмотрены возможности задания параметров режима блокировки. На рис. 32 показан процесс изменения свойства Блокировка записей для формы.
|
|
|
|
|
|
Рис. 32. Задание режима блокировки для данных, доступных из формы
Как видно из рисунка, свойство Блокировка записей может принимать значения:
- Отсутствует - допускается одновременное изменение записей со стороны нескольких пользователей. При этом если два пользователя пытаются сохранись произведенные изменения в одной и той же записи, то второму пользователю выводится предупреждающее сообщение, на основе которого он может либо отказаться от дальнейших действий, либо заместить изменения, сделанные первым пользователем, сохранив собственный вариант. Очевидно, что в таком режиме сохраняется максимальная свобода действий пользователей, "платой" за которую являются возможные конфликты ввиду несогласованности их действий.
- Всех записей - происходит блокировка всех записей в источнике данных при его открытии одним из пользователей, в результате чего он может беспрепятственно изменять его. Другие пользователи имеют доступ только на чтение (просмотр).
- Изменяемой записи - один из пользователей получает доступ на изменение нужной ему записи, а другие пользователи могут только читать содержащиеся в ней данные. Данный режим накладывает минимальные ограничения на совместную работу. Следует добавить, что технически в Access блокируются не записи как таковые, а так называемые страницы - блоки файла базы данных размером 2048 байт, содержащие нужные записи.
- Отмена блокировки в Access происходит тогда, когда пользователь, ранее блокировавший запись, либо сохранит произведенные изменения, либо откажется от них. Для того чтобы изменения, производимые одним пользователем, становились видны другим, через определенные интервалы времени предусмотрено автоматическое обновление содержания таблиц, форм и отчетов. Значение периода обновления задается из меню Сервис > Параметры, вкладка Другие, поле Период обновления.
Другим существенным вопросом, который должен быть решен для обеспечения нормального функционирования многопользовательских СУБД, является организация системы администрирования данных. Среди задач администрирования могут быть названы:
|
|
|
- создание системы пользователей и разделение прав доступа различных пользователей к объектам СУБД;
- организация и поддержание системы резервного хранения информации и ее восстановления в случае программных и аппаратных сбоев;
- мониторинг программных и аппаратных ресурсов, задействованных для обеспечения работы СУБД, и принятие на его основе решений по оптимизации их использования.
Некоторые вопросы, связанные с организацией системы пользователей СУБД, будут рассмотрены в 4.3.
Первые многопользовательские СУБД имели централизованную архитектуру и базировались на больших компьютерах или мини-ЭВМ. Рабочие места пользователей располагались на терминалах, подключенных к центральному компьютеру, ria котором выполнялись все процессы по манипуляции с данными. Однако с распространением персональных компьютеров особую актуальность приобрели СУБД, реализующие технологии распределенной обработки данных, то есть такие технологии, которые позволяют вести одновременную работу с нескольких относительно ограниченных по аппаратным возможностям машин, объединенных в ceть. В этом случае одна часть функций СУБД выполняется на компьютере-клиенте, а другая - на компьютере-сервере, причем их взаимодействие осуществляется через некоторый согласованный протокол. Исторически первая технология распределенной работы с данными получила название файл-сервер (FS-модель). В ее рамках предполагается, что один из компьютеров в сети является файловым сервером и предоставляет свои ресурсы по обработке файлов другим компьютерам, на нем также располагается хранилище данных. На других компьютерах имеется прикладное программное обеспечение, реализующее функции пользовательского интерфейса доступа к данным, и копия процессора базы данных (СУБД). Всякий раз, когда прикладная программа обращается к базе, процессор данных обращается к файловому серверу. В ответ файловый сервер направляет по сети требуемый блок данных, получив который, СУБД осуществляет действия, декларированные в прикладной программе. Протокол обмена между серверным и клиентскими компьютерами представляет собой набор низкоуровневых вызовов, обеспечивающих интерфейсному приложению доступ к файловой системе сервера.
Технологические недостатки FS-модели вытекают из внутренне присущих ей ограничений. Среди них в первую очередь следует назвать:
- высокий сетевой трафик, обусловливаемый необходимостью передавать большое количество файловых блоков от сервера к приложениям;
- ограниченный набор допустимых действий по обработке данных на файловом сервере, который не способен "понимать" внутреннюю логическую структуру базы данных и воспринимает эту базу так же, как и любой другой файл;
- отсутствие надежных средств обеспечения безопасности работы с данными - допускается защита только на уровне функций сетевой операционной системы.
Перечисленные проблемы определяют то, что СУБД, основанные на технологии файл-сервер, могут применяться только в очень ограниченных масштабах. Например, при создании коллективных информационных систем, рассчитанных на небольшое количество пользователей и ограниченные информационные потоки. Одновременно следует отметить, что FS-модель положена в основу архитектур подавляющего большинства настольных СУБД, таких как FoxPRO, Clipper, Clarion, Paradox, Access, завоевавших широкую популярность среди отечественных разработчиков.
|
|
|
