Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.
Пример: Необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:
прочесть баланс на счету номер 5
уменьшить баланс на 10 денежных единиц
сохранить новый баланс счёта номер 5
прочесть баланс на счету номер 7
увеличить баланс на 10 денежных единиц
сохранить новый баланс счёта номер 7
Эти действия представляют собой логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.
В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций. Уровни описаны в порядке увеличения изоляции транзакций и надёжности работы с данными
Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать.
В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Commited). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редкоизменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.
Полноценная реализация уровней изоляции и свойств ACID представляет собой нетривиальную задачу. Обработка поступающих данных приводит к большому количеству маленьких изменений, включая обновление как самих таблиц, так и индексов. Эти изменения потенциально могут потерпеть неудачу: закончилось место на диске, операция занимает слишком много времени (timeout) и т. д. Система должна в случае неудачи корректно вернуть базу данных в состояние до транзакции.
Первые коммерческие СУБД (к примеру, IBM DB2), пользовались исключительно блокировкой доступа к данным для обеспечения свойств ACID. Но большое количество блокировок приводит к существенному уменьшению производительности. Есть два популярных семейства решений этой проблемы, которые снижают количество блокировок: Журнализация изменений (write ahead logging, WAL) и механизм теневых страниц (shadow paging)[2]. В обоих случаях, блокировки должны быть расставлены на всю информацию, которая обновляется. В зависимости от уровня изоляции и имплементации, блокировки записи также расставляются на информацию, которая была прочитана транзакцией.
При упреждающей журнализации, используемой в Sybase и MS SQL Server до версии 2005, все изменения записываются в журнал, и только после успешного завершения — в базу данных. Это позволяет СУБД вернуться в рабочее состояние после неожиданного падения системы. Теневые страницы содержат копии тех страниц базы данных на начало транзакции, в которых происходят изменения. Эти копии активизируются после успешного завершения. Хотя теневые страницы легче реализуются, упреждающая журнализация более эффективна.
Дальнейшее развитие технологий управления базами данных привело к появлению безблокировочных технологий. Идея контроля за параллельным доступом с помощью временных меток (timestamp-based concurrency control) была развита и привела к появлению многоверсионной архитектуры MVCC. Эти технологии не нуждаются ни в журнализации изменений, ни в теневых страницах. Архитектура, реализованная в Oracle 7.х и выше, записывает старые версии страниц в специальный сегмент отката, но они все ещё доступны для чтения. Если транзакция при чтении попадает на страницу, временная метка которой новее начала чтения, данные берутся из сегмента отката (то есть используется «старая» версия). Для поддержки такой работы ведётся журнал транзакций, но в отличие от «упреждающей журнализации», он не содержит данных. Работа с ним состоит из трёх логических шагов:
Журнал транзакций в сочетании с сегментом отката (область, в которой хранится копия всех изменяемых в ходе транзакции данных) гарантирует целостность данных. В случае сбоя запускается процедура восстановления, которая просматривает отдельные его записи следующим образом:
Firebird вообще не имеет ни журнала изменений, ни сегмента отката, а реализует MVCC, записывая новые версии строк прямо в активное пространство данных. Также поступает MS SQL 2005. Теоретически это даёт максимальную эффективность при параллельной работе с данными, но ценой является необходимость «сборки мусора», то есть удаления старых и уже не нужных версий строк.
Для реализации самой программы мне необходимо было изучить язык программирования Delphi, так как раньше мне не приходилось с ним работать. Я выбрала именно этот язык, потому что считаю, что в настоящее время он очень востребован, и изучить его будет для меня очень полезно. Среда разработки - Borland Developer Studio 2006. Изучением языка я занималась в течение года, и продолжаю этим заниматься до сих пор. Также я изучила такие программы как PowerDesigner, Firebird и IBExpert.
Следующим шагом в моей работе после сбора информации стало составление общей картины из собранных данных. Эта часть работы оказалась очень кропотливой, ведь процесс составления расписания включает в себя множество нюансов. Итак, я разобралась, что должна представлять собой итоговая программа.
Во-первых, программа должна включать в себя следующие таблицы: учителя, предметы, методические дни, классное руководство, школьное полугодие, нагрузка учителя, список классов, список кабинетов, балловая оценка предметов, учебный план и само расписание. Эти таблицы и связи между ними решено было реализовывать в программе PowerDesigner. Для всех таблиц должна быть реализована возможность вносить изменения в имеющиеся данные, удалять их и добавлять новые. Необходимо создать справочную систему, доступную для неопытного пользователя, по эксплуатации данной программы. Для таблиц должна быть реализована возможность изменять данные, удалять и добавлять новые. Также необходима проверка вводимых данных на соответствие типу данных. Замечание по поводу начальных классов: для них предполагается прописывание только тех предметов, которые ведут другие учителя (не классный руководитель).
Во-вторых, программа должна включать реализацию следующих запросов: получение информации по каждому учителю, по каждому классу, по каждому кабинету.
В рабочем окне должна быть реализована возможность выбора учебного года. Также мне бы хотелось, чтобы в этом же окошке была реализована возможность вписывания пожеланий учителей: предпочтение методического дня и рабочего времени (предпочтение работы с самого утра или нет, с окнами или без).
Расписание должно создаваться для каждого класса отдельно. Нужно учесть следующие параметры:
- начальная школа не учится по субботам
- максимальное количество уроков в день (начальное звено – 5 уроков, среднее и старшее звено – 6 уроков)
- балловая система предметов
- отсутствие сдвоенных уроков в начальной и средней школе
- чередование предметов точного и гуманитарного характера
- ход дневной и недельной умственной работоспособности
- пожелания учителей, у каждого должен быть методический день
- основная учебная нагрузка должна приходиться на 2,3,4 уроки (по балловой системе)
- необходимо учитывать что в каждом классе на уроках английского, трудов и физкультуры (в старших классах) класс делится на 2 подгруппы
Вид расписания предполагается представить в таком же виде, как показано в приложении 1.
Я планирую реализовать формирование таблиц с расписанием и балловой системой для каждого класса (приложение 6), а также зарисовку соответствующих схем (приложение 7).