Системы мобильных баз данных

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

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

Мобильные приложения

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

Функциональная архитектура

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

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

1. поддержку предусмотренных уровней представления данных

2. (концептуальный, внутренний и внешний уровни в терминах архитектуры ANSI/X3/SPARC) и междууровневых отображений данных, ·

3. управление средой хранения данных и методы доступа к ним; · управления транзакциями;

4. поддержку функций администратора системы;

5. физическую и логическую целостность базы данных;

6. разграничение доступа к данным в системе базы данных;

7. интерактивные пользовательские интерфейсы и интерфейсы прикладного программирования, и др.

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

Как уже отмечалось, важное место в функциональной архитектуре системы базы данных занимают механизмы поддержки различных уровней представления данных, в соответствии с архитектурной моделью ANSI/X3/SPARC, иначе говоря, механизмы уровней информационной архитектуры. Эти механизмы обладают внутренними и, возможно, внешними интерфейсами. Внутренние интерфейсы обеспечивают взаимодействие механизмов данного уровня с другими функциональными компонентами системы, а внешние (если они существуют) - с пользователями и/или с системным персоналом. Через эти интерфейсы механизмы уровней получают и передают команды, сигналы обратной связи и данные.

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

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

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

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

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

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