Михаил Голованов
Внедрение информационных систем для автоматизации деятельности бизнеса требует от разработчиков баз данных реализации все новых возможностей в разрабатываемых ими приложениях. Создание программного обеспечения, позволяющего пользователям работать лишь в пределах офиса, на сегодняшний день становится явно недостаточно. Сотрудникам офиса требуется обеспечить доступ к информационным массивам фирмы в командировке, из дома, из офиса клиента. При этом пользователи хотят не только просматривать данные, но и иметь возможность вносить в них изменения. Немаловажным требованием со стороны администраторов информационных систем является простота установки и настройки клиентских приложений.
Подводя итог вышесказанного, можно выделить основные требования заказчиков к программному обеспечению для мобильных клиентов информационной системы:
Возможность получения данных, сотрудниками вне пределов офиса фирмы.
Возможность внесения мобильным клиентом изменений в данные, которые затем должны быть синхронизированы с центральной БД.
Возможность работы мобильного клиента при отсутствии постоянного канала связи с офисом.
Простота установки, настройки и эксплуатации созданных приложений.
При реализации вышеописанных требований заказчиков возникают следующие технические проблемы:
Обеспечение хранения полученной пользователем информации в перерывах между сеансами связи с центральным офисом с возможностью продолжения работы мобильного пользователя. Другими словами пользователь не должен замечать различий в работе приложения в режимах on-line и off-line.
Синхронизация сделанных пользователем изменений с центральной базой. Поскольку время между редактированием записи мобильным пользователем и внесением ее в центральную базу может составлять дни, недели и даже месяцы применение обычного для модели клиент-сервер механизма блокировок записей не имеет смысла. При этом несколько мобильных пользователей могут одновременно редактировать каждый свою копию данных с сервера, тогда при попытке синхронизации данных неизбежно возникновение конфликтов изменений внесенных в одну и ту же запись различными пользователями. Данные конфликты – это конфликты синхронизации. Обеспечение средств разрешения конфликтов синхронизации– это одно из главных требований к технической реализации такого ПО.
Далее мы кратко рассмотрим наиболее часто применяющиеся варианты решения задачи доступа мобильных пользователей к центральной базе данных.
Web изначально проектировалась как территориально распределенная сеть, позволяющая осуществлять доступ к различным информационным ресурсам в режиме on-line. Основным недостатком данного подхода является необходимость быть все время подключенным к сети. Данный недостаток практически не позволяет применять данный подход для работы мобильных пользователей.
Репликация – это процесс синхронизации данных между несколькими серверами БД. При применении данного способа работы архитектура системы выглядит следующим образом:
Рисунок 1
Большинство современных серверов БД имеют встроенные средства для поддержки репликации, позволяющие обмениваться данными между несколькими серверами. Клиентское приложение при этом не требует особых модификаций. Главным недостатком такого метода является необходимость установки и обслуживания сервера БД на машине клиента.
Модель работы briefcase
Briefcase модель подразумевает работу клиента с базой данных без поддержки постоянного соединения. Клиент подключается к БД, скачивает требуемые данные, передает сделанные им изменения, и тут же отключается. В Delphi данная модель может быть реализована с использованием возможностей ADO или MIDAS.
При создании приложения, реализующего модель briefcase можно выделить несколько подзадач:
Получение данных с центрального сервера;
Сохранение данных в локальный кэш;
Загрузка данных из локального кэша;
Синхронизация данных с центральным сервером и обработка ошибок синхронизации.
Для наших примеров в качестве сервера БД я использовал MS SQL сервер. На нем была создана база данных ParamsHolder, содержащая всего одну таблицу Params со следующими полями:
Поле
