Оперативная реорганизация баз данных Текст научной статьи по специальности «Компьютерные и информационные науки»

ТЕОРЕМА. Если 0 < а < п, то для © е п - у; —^| ёмкость Ро-

бена 8(А;С2) монотонно возрастает, а для © б ; убывает и справедливы следующие оценки:

монотонно

2(3 - R) • j^cos^ - j + 4^2(7? -1) • (R + (R - l)cos| - cos2

1 (Д + 1)2 "

, а 1 - cos—

<5(A;Q)<--2..

Л + 1

Если л < а < 2тг, то для 0 е я - ^; j ёмкость Робена 5(Л; Q)

монотонно убывает, а для © е (- л-yj — монотонно возрастает, и

справедливы оценки, аналогичные предыдущим.

В заключение заметим, что при R —> 1 неравенства обращаются в точные равенства.

СПИСОК ЛИТЕРАТУРЫ

1. Duren P., Schiffer М. Robin functions and energy functional of multiply connected domains // Pacific J. Math. 1991.Vol. 148. P. 251 -273.

2. Duren P., Pfaltzgraff J. Robin capacity and extremal length // J. Math, Anal. Appl. 1993. Vol. 17. P. 110-119.

3. Дубинин B.H. Симметризация в геометрической теории функций комплексного переменного // Успехи матем. наук. 1994. Т. 49. №1. С. 1 - 76.

УДК 681.3

А. Д. Ковалев, В. В. Мозжилкин ОПЕРАТИВНАЯ РЕОРГАНИЗАЦИЯ БАЗ ДАННЫХ

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

или автоматически модифицировано в соответствии с задачами обновления версии приложения.

В данной статье предлагается подход, основанный на построении универсального модуля реорганизации, управляемого данными. Подход реализуется с помощью типовых средств современных СУБД и позволяет автоматизировать процесс реорганизации при рассылке обновленных версий приложения по различным организациям, эксплуатирующим различные версии приложения. Описываемая ниже схема соответствует реорганизации «по месту», что актуально при больших объемах баз данных. Проведение реорганизации на специально заведенной копии хотя и возможно, но излишне, поскольку реализованный протокол реорганизации позволяет при любых сбоях системы (отключении питания, сбоях оборудования, нехватке памяти и т.п.) перевести базы данных в состояние, соответствующее старому или новому поколению.

Схема идентификации поколений и состояния реорганизации включает следующие элементы.

1. В директории баз данных:

1.1. _Generation_XX'_XX".id - идентификационный файл баз данных. При XX' = XX'' (= XX) базы данных относятся к поколению с номером XX (для номеров поколений должна быть фиксирована разрядность с тем, чтобы можно было легко проверять корректность данных). При XX' < XX'' базы данных находятся в переходном состоянии реорганизации.

1.2. _generation_ ХХ'_<имя файла>, ... - переименованные файлы баз данных, относящиеся к младшему поколению XX' и подлежащие удалению или замене на файлы старшего поколения XX''. Наличие переименованных файлов в директории возможно лишь в процессе реорганизации.

2. В корневой директории приложения:

2.1. _Reorganization_ZZ_ZZ. id - идентификационный файл приложения, определяющий номер ZZ требуемого поколения баз данных.

2.2. REORGANIZATION_XX_YY, ... - директории управляющих данных для различных пар младшего и старшего поколений {XX к YY). Каждая из этих директорий может содержать следующие элементы: 2.2.1 - 2.2.4.

2.2.1. reorganizationXXYY. <расширемие> - реорганизующий программный файл в откомпилированной форме. Наличие этого файла не обязательно. Если файл существует, то он автоматически вызывается из универсального модуля реорганизации, что позволяет провести доформирова-ние реорганизующих данных во временной рабочей директории (см. ниже).

2.2.2. _reorganization_<uMH файла>, ... - произвольные дополнительные файлы, ассоциированные с реорганизующим программным файлом и позволяющие упростить его структуру.

2.2.3. delete_р1е_<имя файла>, ... - файлы, в наименовании которых содержатся имена файлов поколения XX, подлежащих удалению в поколении YY.

2.2.4. <имя файла>, ... - файлы в структуре поколения YY, используемые при реорганизации соответствующих файлов баз данных из поколения XX в поколение YY.

2.3. REORGANIZATION_XX_YY.ТМР, ... - временная рабочая директория, предназначенная для формирования реорганизующих данных. Директория может содержать следующие элементы: 2.3.1 - 2.3.3.

2.3.1. ПОДГОТОВЛЕНОЛЛЯ_ПЕРЕСЫЛКИ_В_<путь к директории баз данных> - временная маркерная поддиректория.

2.3.2. _deleteJile_<UMH файла>, ... - файлы, копируемые из директории управляющих данных (см. 2.2.3).

2.3.3. <имя файла>, ... - файлы, которые первоначально копируются из директории управляющих данных и могут в дальнейшем модифицироваться реорганизующим программным файлом (см. 2.2.4).

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

1) контроль завершенности процесса реорганизации,

2) контроль соответствия требуемого и имеющегося поколения баз данных,

3) планирование этапов реорганизации в соответствии с имеющимися управляющими данными,

4) проведение этапов реорганизации,

5) обнаружение и обработка исключительных (аварийных) ситуаций.

Поэтапная реорганизация баз данных проводится согласно следующему протоколу.

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

2. В цикле по всем этапам реорганизации до тех пор, пока базы данных не перейдут в требуемое поколение, выполнять шаги 2.1 - 2.13 (для реорганизации баз данных из поколения XX в поколение YY).

2.1. Создать временную рабочую директорию.

2.2. Скопировать во временную рабочую директорию все файлы директории управляющих данных за исключением Reorganization_*. *

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

2.4. Создать временную маркерную поддиректорию.

2.5. Переименовать идентификационный файл баз данных из _Generation_XX_XX.id в _Generation_XX_YY.id. Тем самым доступ к базам данных со стороны других пользователей приложения будет заблокирован.

2.6. Закрыть базы данных.

2.7. Переименовать файлы в директории баз данных с <имя файла> на _generation_ ХХ_<гшя файла> для всех файлов, встречающихся во временной рабочей директории в виде _delete_Jile_<wm файяа> или <имя файла>.

2.8. Скопировать в директорию баз данных все файлы временной рабочей директории за исключением _delete Jllej*. *

2.9. Удалить из директории баз данных все файлы _generation_*. * (за исключением идентификационного файла_Generation_XX_YY.id).

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

2.11. Переименовать идентификационный файл баз данных из _Generation_XX_YY. id в _Generation_YY_YY.id.

2.12. Удалить временную маркерную поддиректорию.

2.13. Удалить временную рабочую директорию.

3. Закрыть базы данных.

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

Рассматриваемый подход реализован в среде Visual FoxPro 5 при разработке АСУ вагоноремонтного депо «Магистраль-С» [1].

СПИСОК ЛИТЕРАТУРЫ

1. РФ. Роспатент. Свид. об офиц. per прогр. для ЭВМ№ 990930 от 20.12.1999.

УДК 517.972

А. Б. Коноплев

ФОРМУЛА СУБДИФФЕРЕНЦИАЛА ФУНКЦИИ РАССТОЯНИЯ ОТ ТОЧКИ ДО ОБРАЗА ВЫПУКЛОГО МУЛБТИОТОБРАЖЕНИЯ

Пусть X, Y - конечномерные действительные пространства, Z = X х Y - их декартово произведение и | • ||х, || • [|у, || ■ || - нормы в этих

пространствах. Символом || • || будем обозначать евклидову норму в X.

Рассмотрим мультиотображение F: X -> 2У, ставящее в соответствие каждому хеХ множество F(x) с Y. Множества

domF = {хеХ\ F{:с) * 0}, gr F = {(*,>>) е X х Y \ у е F(x)}