CC BY
52
Отсюда следует очевидное ограничение на а< 3 + у и на возможное количество пропусков
n < Xi ni/3+Y в исходной обучающей выборке.
Заключение
Непараметрические алгоритмы распознавания образов, синтез которых осуществляется на основе обучающих выборок с пропусками данных, обладают свойством асимптотической сходимости. При конечной дисперсии погрешности метода заполнения пропусков данных существуют условия асимптотической несмещенности и состоятельности непараметрической оценки уравнения разделяющей поверхности, основанной на ядерной оценке плотности вероятности типа Розенблатта-Парзена. Снижение дисперсии с ростом объема обучающей выборки способствует повышению эффективности непараметрических алгоритмов классификации. Обосновано существование предела, равного 1, для отношения среднеквадратических критериев точности аппроксимации байесового уравнения разделяющей поверхности ее непараметрическими оценками, построенными по выборкам с заполненными пропусками данных и без них. С этих позиций определены условия, когда заполнение пропусков данных позволяет восполнить информацию обучающей выборки, достаточной для эффективного решения задачи классификации с помощью непараметрических методов.
Литература
1. Загоруйко, Н.Г. Алгоритм заполнения пропусков в эмпирических таблицах (алгоритм ZET) / Н.Г. Заго-руйко, В.Н. Елкина, В.С. Тимеркаев // Вычислительные системы «Эмпирическое предсказание и распознавание образов». - Новосибирск, 1975 - (Вып. 61). - С. 3-27.
2. Лапко, А.В. Синтез и анализ непараметрических моделей стохастических зависимостей и распознавания образов в условиях пропуска данных / А.В. Лапко, В.А. Лапко, Г.И. Цугленок // Вестн. КрасГАУ. - 2005. -№7. - С. 64-70.
3. Parzen, E. On the estimation of a probability density function and mode / E. Parzen // Ann. Mathem. Statis. -1962. - V.33. - С. 1065-1076.
4. Епанечников, В.А. Непараметрическая оценка многомерной плотности вероятности / В.А. Епанечников // Теория вероятности и ее применения. - 1969. - Т.14. - (Вып. 1). - С. 156-161.
5. Непараметрические системы классификации / А.В. Лапко [и др.]. - Новосибирск: Наука, 2000. - 240 с.
УДК 681.142.37 Р.Н. Амбросенко
ТРАНЗАКЦИОННЫЙ ПОДХОД К ПОВЫШЕНИЮ КАЧЕСТВА ОБРАБОТКИ ИНФОРМАЦИИ В ОБРАЗОВАТЕЛЬНЫХ СРЕДАХ ДИСТАНЦИОННОГО ОБУЧЕНИЯ
В статье рассмотрены вопросы целостности баз данных в многопользовательских образовательных средах, используемых в дистанционном обучении. Предложен алгоритм работы планировщика СУБД, основанный на временных метках (multiversion timestamp ordering, MVTO).
В настоящее время транзакционная обработка информации становится одним из важнейших аспектов, определяющих корректность производимых вычислений и целостность данных, а следовательно, и характеристики качества информационно-образовательных сред дистанционного обучения.
Возрастающая сложность образовательных сред, используемых в дистанционном обучении и предусматривающих транзакционную обработку информации, требует повышенного внимания к моделированию транзакций на протяжении всего процесса разработки и эксплуатации информационной образовательной среды.
Реализуемая в образовательной среде модель транзакционных вычислений, по сути, определяет, будет ли находиться среда в целостном состоянии и поддерживать требуемый уровень надежности. Учитывая
постоянный рост сложности и увеличение трудозатрат на создание сред, это приводит к объективной потребности моделирования транзакций на самых ранних этапах разработки, в том числе и в процессе моделирования их программно-информационной архитектуры.
Транзакция - это неделимая, с точки зрения воздействия на СУБД, последовательность операций манипулирования данными [2,3]. Для пользователя транзакция выполняется по принципу «все или ничего», т.е. либо транзакция выполняется целиком и переводит базу данных из одного целостного состояния в другое целостное состояние, либо, если по каким-либо причинам одно из действий транзакции невыполнимо, или произошло какое-либо нарушение работы системы, база данных возвращается в исходное состояние, которое было до начала транзакции (происходит откат транзакции).
С этой точки зрения, транзакции важны как в многопользовательских, так и в однопользовательских системах. В однопользовательских системах транзакции - это логические единицы работы, после выполнения которых база данных остается в целостном состоянии. Однако особое значение это имеет для многопользовательских систем и, в частности, информационно-образовательных сред, используемых в дистанционном обучении.
Транзакции также являются единицами восстановления данных после сбоев - восстанавливаясь, система ликвидирует следы транзакций, не успевших успешно завершиться в результате программного или аппаратного сбоя [1, 4]. Эти два свойства транзакций определяют атомарность (неделимость) транзакции.
В многопользовательских системах, кроме того, транзакции служат для обеспечения изолированной работы отдельных пользователей - пользователям, одновременно работающим с одной базой данных, кажется, что они работают как бы в однопользовательской системе и не мешают друг другу. Это преимущество также используется при дистанционном обучении.
Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД [3, 4]:
• (А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.
• (С) Согласованность. Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность базы данных может нарушаться.
• (И) Изоляция. Транзакции разных пользователей не должны мешать друг другу (например, как если бы они выполнялись строго по очереди).
• (Д) Долговечность. Если транзакция выполнена, то результаты ее работы должны сохраниться в базе данных, даже если в следующий момент произойдет сбой системы.
Транзакция обычно начинается автоматически с момента присоединения пользователя к СУБД и продолжается до тех пор, пока не произойдет одно из следующих событий:
• подана команда COMMIT WORK (зафиксировать транзакцию);
• подана команда ROLLBACK WORK (откатить транзакцию);
• произошло отсоединение пользователя от СУБД;
• произошел сбой системы.
Команда COMMIT WORK завершает текущую транзакцию и автоматически начинает новую транзакцию. При этом гарантируется, что результаты работы завершенной транзакции фиксируются, т.е. сохраняются в базе данных. Команда ROLLBACK WORK приводит к тому, что все изменения, сделанные текущей транзакцией, откатываются, т.е. отменяются так, как будто их вообще не было. При этом автоматически начинается новая транзакция.
При отсоединении пользователя от СУБД происходит автоматическая фиксация транзакций.
СУБД дистанционных образовательных сред являются многопользовательскими системами, т.е. допускают параллельную одновременную работу большого количества пользователей. При этом пользователи не должны мешать друг другу. Так как логической единицей работы для пользователя является транзакция, то работа СУБД должна быть организована так, чтобы у пользователя складывалось впечатление, что их транзакции выполняются независимо от транзакций других пользователей.
Простейший и очевидный способ обеспечить такую иллюзию у пользователя состоит в том, чтобы все поступающие транзакции выстраивать в единую очередь и выполнять строго по очереди. Такой способ не годится по очевидным причинам - теряется преимущество параллельной работы.
Таким образом, транзакции необходимо выполнять одновременно, но так, чтобы результат был бы такой же, как если бы транзакции выполнялись по очереди. Трудность состоит в том, что если не предпринимать никаких специальных мер, то данные, измененные одним пользователем, могут быть изменены
транзакцией другого пользователя раньше, чем закончится транзакция первого пользователя. В результате, в конце транзакции первый пользователь увидит не результаты своей работы, а неизвестно что.
Для управления параллельными транзакциями предлагается алгоритм работы планировщика СУБД, основанный на временных метках (multiversion timestamp ordering, MVTO). Этот планировщик обрабатывает операции таким образом, чтобы суммарный результат выполнения операций был эквивалентен последовательному выполнению транзакций. Порядок сериализации задается порядком временных меток, которые получают транзакции во время старта. Временные метки также используются для идентификации версий данных при чтении и модификации:
- каждая версия получает временную метку той транзакции, которая ее записала. Планировщик не только следит за порядком выполнения действий транзакций, но также отвечает за трансформацию операций над данными в операции над версиями;
- каждая операция вида «прочитать элемент данных х» должна быть преобразована планировщиком в операцию: «прочитать версию у элемента данных х».
Временную метку, полученную транзакцией ti в начале ее работы, будем обозначать как ts(ti), операцию чтения транзакцией ti элемента данных х как ri(x). Для обозначения того, что транзакция ti читает версию элемента данных х, созданную транзакцией tk, будем писать ri(xk), для обозначения того, что транзакция ti записывает версию элемента данных х, будем использовать запись wi(x). Опишем алгоритм работы планировщика MVTO.
Планировщик преобразует операцию п(х) в операцию п(хк), где хк - это версия элемента х, помеченная наибольшей временной меткой ts(tk), такой что ts(tk) <= ts(ti).
1. Операция wi(х) обрабатывается планировщиком следующим образом:
а) если планировщик уже обработал действие вида г](хк), такое, что ts(tk) < ts(ti) < ts(tj), то операция wi(х) отменяется, а ti откатывается;
б) в противном случае wi(х) преобразуется в wi(^).
2. Завершение транзакции ti (commit) откладывается до того момента, когда завершатся все транзакции, записавшие версии данных, прочитанные ti.
Последний шаг нужен только в том случае, когда хотят предотвратить «грязное» чтение.
На рисунке приведен пример работы планировщика MVTO. Взаимодействие транзакций ti и t2 отличным образом иллюстрирует плюсы использования версий. В случае подобного плана выполнения транзакций при отсутствии версионности получился бы классический случай чтения несогласованных данных. Однако в нашем примере эта ситуация вполне приемлема из-за того, что первая транзакция читает «старую» версию элемента данных у. Транзакция t3 ожидает окончания работы t2 перед собственным завершением. Это происходит потому, что t3 прочитала незавершенную версию х2.
Пример работ/ планировщика MVTO
Транзакция t4 является примером «поздней» транзакции изменения. Она создает версию у4, в то время как транзакция t5 (стартовавшая позднее) уже прочитала более раннюю версию у2. То есть транзакция t5 «не видит» некоторых изменений, внесенных t4. Таким образом, сериализация транзакций в порядке получения ими временных меток невозможна - необходим откат (пункт 2а алгоритма).
При реализации на практике вышерассмотренного алгоритма возникают проблемы двух типов. Во-первых, требуется так устроить физическую организацию данных, чтобы можно было обеспечить эффективное управление версиями. Здесь следует учесть и разрастание объема базы данных при добавлении версий. То есть в идеале при организации данных должны учитываться возможные ограничения на количество версий. Заметим, что на практике ограничение на число версий зачастую отсутствует - вместо этого система просто удаляет ненужные версии по мере завершения соответствующих транзакций. Таким образом, ответственность за поддержание умеренного количества версий ложится на пользователей СУБД, которые должны следить за тем, чтобы в системе не появлялись «длинные транзакции». В противном случае версии будут оставаться в базе данных, что приведет к нефункциональному увеличению ее объема.
Вторая проблема, возникающая при добавлении версий в архитектуру СУБД, имеет логический характер. Помимо планировщика наличие версий должно приниматься во внимание во многих компонентах СУБД. В связи с этим необходимо обеспечить корректное взаимодействие этих компонентов.
СУБД образовательных сред дистанционного обучения, являющиеся многопользовательскими системами, допускают параллельную одновременную работу большого количества пользователей, что в свою очередь порождает целый комплекс проблем. Анализ проблем параллелизма показывает, что если не предпринимать специальных мер, то при работе нарушается свойство изолированности транзакций. Транзакции мешают друг другу получать правильные результаты, что в свою очередь естественным образом сказывается на качестве управления хранением и обработкой информации.
Литература
1. Антамошкин, А.Н. Алгоритм расчета прогнозируемого трафика при проектировании распределенных систем обработки и хранения информации / А.Н. Антамошкин, В.В. Золотарев // Вестн. СибГАУ: сб. науч. тр. - Красноярск: Изд-во СибГАУ, 2005.
2. Дружинин, Г.В. Надежность автоматизированных производственных систем / Г.В. Дружинин. - М.: Энергоатомиздат, 1986. - 480 с.
3. Зиндер, Е.З. Новое системное проектирование: информационные технологии и бизнес-реинжиниринг. 2-я часть / Е.З. Зиндер // СУБД. - 1996. - № 1.
4. Avizeinis, A. The N-Version Approach to Fault-Tolerant Software / A. Avizeinis // IEEE Transactions of Software Engineering. - 1985. - Vol. SE-11. - No. 12. - P. 1491-1501.
