Построение базы данных

Содержание

Введение.

С каждым днем роль и значение информационных технологий возрастает. Человечество находит применение ему все в разных сферах деятельности. Вместе с ним возрастает и роль баз данных.  Информационные системы немыслимы без баз данных (далее БД). Если задуматься, то приходишь выводу, что мы имеем дело с БД  каждый день по несколько раз. К примеру, только в самой операционной системе несколько сотен, даже тысяч разных БД, также в магазинах, банках, любых предприятиях. Не говоря уже о сети Интернет – в ней же их неисчислимое количество.  С ростом числа БД увеличивается и число пользователей баз данных. Соответственно увеличивается нагрузка на сами БД.  Существенный прирост производительности позволяет достичь параллельная работа. Но как правило, «нет худа без добра». При использовании параллельной обработки данных появляются различные проблемы, нарушающие правильность выполнения транзакций.

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

В данной курсовой работе затронуты проблемы, возникающие при параллельной работе, т.е. при выполнении логических единиц работы -транзакций.

Кроме этого рассмотрены современные методы и подходы для исправления и избегания данных проблем.

В практической части (Глава 3  Построение базы данных)  описывается создание  базы данных на примере футбольных матчей (БД «Футбольные матчи»).  Данная база была построена с нуля, и в ней отображены все шаги  при строительстве БД, начиная от создания таблиц и кончая сложными многотабличными формами и макросами. Имеется подробная иллюстрация различных шагов при создании этой базы данных.

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

Глава 1.  Управление транзакциями

1.1.         Понятие и сущность транзакций

Транза́кция (англ. transaction) — в информатике, группа последовательных операций, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена целиком либо успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще и тогда она не должна произвести никакого эффекта. Транзакции обрабатываются транзакционными системами, в процессе работы которых создаётся история транзакций[1].

Пример: Необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:

Начать транзакцию

прочесть баланс на счету номер 5

уменьшить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 5

прочесть баланс на счету номер 7

увеличить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 7

Окончить транзакцию

Эти действия представляют из себя логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.

Транзакционная система — в информатике, система, реализующая транзакции над хранилищем данных. Задача транзакционной системы — обработать как можно больше транзакций в минимальное время с гарантией безошибочных результатов.

Типичным примером транзакционной системы является система ведения счетов в банках.

Различают транзакции:

                 обычные

                 распределённые

Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол подтверждения успеха). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.

Характеристики транзакций. Акроним ACID описывает требуемые свойства транзакции в СУБД или распределённых системах:

                 Atomicity (атомарность): определяет, что транзакция является наименьшим, неделимым блоком алгоритма изменения данных. Другими словами, любые части (подоперации) транзакции либо выполняются все, либо не выполняется ни одной такой части. Поскольку на самом деле невозможно одновременно и атомарно выполнить последовательность команд внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех до сих пор произведённых действий должны быть отменены и система возвращается в исходное состояние.

                 Consistency (непротиворечивость): по окончанию транзакция оставляет данные в непротиворечивом состоянии. Скажем, если поле в базе данных описано как имеющее только уникальные значения строк, то при любом исходе транзакции строк-дубликатов появиться не может.

                 Isolation (изоляция): во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии. Например, если транзакция изменяет сразу несколько полей в базе данных, то другой запрос, выполненный во время выполнения транзакции, не должен вернуть одни из этих полей с новыми значениями, а другие с исходными.

                 Durability (долговечность): независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, останутся сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он должен быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.

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

В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Уровни описаны в порядке увеличения изоляции транзакций и надёжности работы с данными:

     0 — Неподтверждённое чтение (Read Uncommited, Dirty Read, грязное чтение) — чтение незафиксированных изменений своей транзакции и конкурирующих транзакций, возможны нечистые, неповторяемые чтения и фантомы

     1 — Подтверждённое чтение (Read Commited) — чтение всех изменений своей транзакции и зафиксированных изменений конкурирующих транзакций, нечистые чтения невозможны, возможны неповторяемые чтения и фантомы

     2 — Повторяемое чтение (Repeatable Read ,Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые конкурирующими транзакциями после начала своей недоступны, нечистые и неповторяемые чтения невозможны, возможны фантомы

     3 — Упорядоченный — (Serializable, сериализуемый) — упорядоченные (cериализуемые) транзакции. Идентичен ситуации при которой транзакции выполняются строго последовательно одна после другой. То есть транзакции, результат действия которых не зависит от порядка выполнения шагов транзакции (запрещено чтение всех данных изменённых с начала транзакции, в том числе и своей транзакцией). Фантомы невозможны.

Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать.

В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Commited). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редкоизменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.

1.2.        Двухфазная фиксация транзакций

В этом разделе рассматривается очень важное усовершенствование основной концепции фиксации/отката транзакций, а именно — метод двухфазной фиксации транзакций (метод синхронного внесения изменений в несколько БД). Использование этого протокола оказывается важным всякий раз, когда определенная транзакция может взаимодействовать с несколькими независимыми менеджерами ре­сурсов, каждый из которых распоряжается собственным набором восстанавливаемых ре­сурсов и поддерживает собственный журнал регистрации. Например, пусть транзакция, выполняемая на мэйнфрейме IBM, модифицирует как базу данных СУБД IMS, так и базу данных СУБД DB2. Если тран­закция завершается успешно, то все выполненные ею обновления, как в базе данных СУБД IMS, так и в базе данных СУБД DB2, должны быть зафиксированы. В противном случае для всех внесенных обновлений должен быть выполнен откат. Иначе говоря, не­допустима ситуация, когда обновления информации в базе данных СУБД IMS зафикси­рованы, а для обновлений информации в базе данных СУБД DB2 выполнен откат, или наоборот. Суть в том, что в подобном случае транзакция перестанет быть атомарной.

Отсюда следует, что для транзакции не имеет смысла выполнять оператор COMMIT в СУБД IMS и оператор ROLLBACK в СУБД DB2. Даже если один и тот же оператор будет выдан для обеих СУБД, система все равно может дать сбой между завершением этих двух операций и полученные результаты окажутся неудовлетворительными. Вместо это­го транзакция должна выдать общесистемную команду COMMIT (или ROLLBACK). Выпол­нением таких глобальных операций фиксации или отката управляет системный компо­нент, называемый координатором. Его задача состоит в получении гарантий, что оба менеджера ресурсов (т.е. СУБД IMS и СУБД DB2 в нашем примере) согласованно вы­полнят фиксацию или откат тех обновлений, за которые они ответственны. Более того, он должен обеспечивать такую гарантию даже в том случае, если отказ системы про­изошел до завершения всего процесса. Все это достигается за счет использования прото­кола двухфазной фиксации.

Ниже приведена последовательность работы координатора. Для простоты примем, что транзакция в базе данных выполнена успешно, а значит, выдана общесистемная ко­манда COMMIT, а не ROLLBACK. После получения запроса на выполнение команды COMMIT координатор осуществляет следующий двухфазный процесс.

1.                 Первая фаза начинается с выдачи координатором всем менеджерам ресурсов указания подготовиться к завершению транзакции "тем или иным способом". На практике это означает, что каждый участник процесса, т.е. каждый менеджер ресурсов, должен принудительно выгрузить все записи журнала регистрации для используемых транзакцией локальных ресурсов в собственный физический жур­нал регистрации (т.е. из первичной во вторичную энергонезависимую память).  Теперь, что бы ни случилось, менеджер ресурсов будет иметь постоянную запись о работе, выполненной им в процессе обработки данной транзакции, а значит, в случае необходимости сможет зафиксировать выполненные обновления или от­менить их. Если принудительная разгрузка прошла успешно, менеджер ресурсов отвечает координатору, что все "ОК". В противном случае он посылает противо­положное сообщение — "Not OK".

2.                 Вторая фаза наступает после того, как координатор получит соответствующие ответы от всех участников. Сначала он принудительно выгружает записи о за­вершаемой транзакции в собственный физический журнал регистрации, фикси­руя свое решение относительно этой транзакции. Если все поступившие ответы были "ОК", то координатор принимает решение глобально зафиксировать дан­ную транзакцию. Если же поступил хотя бы один ответ "Not ОК", то для тран­закции будет выполнен глобальный откат. Затем координатор каким-либо спосо­бом информирует каждого из участников транзакции о своем решении и каждый участник согласно поступившей инструкции должен или локально зафиксиро­вать транзакцию, или выполнить ее откат. Обратите внимание, что каждый участник должен делать то, что ему велел координатор в ходе выполнения вто­рой фазы; в этом и состоит суть данного протокола. Обратите также внимание, что именно появление записи этого решения в физическом журнале регистрации координатора и отмечает переход от фазы 1 к фазе 2.

Теперь, если система дает сбой в какой-либо точке всего этого процесса в целом, процедура перезагрузки будет искать запись о принятом решении в журнале регистрации координатора. Если она будет обнаружена, то можно будет установить, какое решение было принято до остановки, и продолжить обработку. Если подобная запись не будет об­наружена, будет принято решение об откате данной транзакции и, следовательно, про­цесс так или иначе завершится.

Замечание. Стоит подчеркнуть, что если координатор и участники выполняют свою ра­боту на различных компьютерах, что типично для распределенной системы то ошибка в работе координатора может привести к тому, что некий участник достаточно дол­го будет ожидать поступления сведений о принятом координатором решении. В течение всего времени ожидания любое из обновлений, произведенное транзакцией в базе данных этого участника, должно быть скрыто от других транзакций[2].

Отметим, что менеджер передачи данных также может рассматривать­ся как менеджер ресурсов в описанном выше смысле. Это означает, что сообщения можно считать такими же восстанавливаемыми ресурсами, как и саму базу данных, а менеджер передачи данных должен быть способен участвовать в процессе двухфазной фиксации.

Глава 2.  Проблемы параллельности и их  решение

2.1.         Проблемы параллельности

Современные СУБД являются многопользовательскими системами, т.е. допускают параллельную одновременную работу большого количества пользователей. При этом пользователи не должны мешать друг другу. Т.к. логической единицей работы для пользователя является транзакция, то работа СУБД должна быть организована так, чтобы у пользователя складывалось впечатление, что их транзакции выполняются независимо от транзакций других пользователей. Простейший и очевидный способ обеспечить такую иллюзию у пользователя состоит в том, чтобы все поступающие транзакции выстраивать в единую очередь и выполнять строго по очереди. Такой способ не годится по очевидным причинам - теряется преимущество параллельной работы. Таким образом, транзакции необходимо выполнять одновременно, но так, чтобы результат был бы такой же, как если бы транзакции выполнялись по очереди. Трудность состоит в том, что если не предпринимать никаких специальных мер, то данные измененные одним пользователем могут быть изменены транзакцией другого пользователя раньше, чем закончится транзакция первого пользователя[3].

Одним из способов (не единственным) обеспечить независимую параллельную работу нескольких транзакций является метод блокировок.

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

      Эта операция будет выполнена целиком или не выполнена вовсе (атомарность - все или ничего).

      Во время выполнения этой операции не выполняются никакие другие операции других транзакций (строгая очередность элементарных операций).

Например, элементарными операциями транзакции будут считывание страницы данных с диска или запись страницы данных на диск (страница данных - это минимальная единица для дисковых операций СУБД). Условие 2 на самом деле является именно логическим условием, т.к. реально система может выполнять несколько различных элементарных операций в один и тот же момент. Например, данные могут храниться на нескольких физически различных дисках и операции чтения-записи на эти диски могут выполняться одновременно. Элементарные операции различных транзакций могут выполняться в произвольной очередности (конечно, внутри каждой транзакции последовательность элементарных операций этой транзакции является строго определенной). Например, если есть несколько транзакций, состоящих из последовательности операций элементарных:

,

,

то реальная последовательность, в которой СУБД выполняет эти транзакции может быть, например, такой:

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

Каким образом транзакции различных пользователей могут мешать друг другу?

Различают три основные проблемы параллелизма:

      Проблема потери результатов обновления.

      Проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание).

      Проблема несовместимого анализа.

Рассмотрим подробно эти проблемы.

Рассмотрим две транзакции, A и B, запускающиеся в соответствии с некоторыми графиками. Пусть транзакции работают с некоторыми объектами базы данных, например со строками таблицы. Операцию чтение строки будем обозначать , где - прочитанное значение. Операцию записи значения в строку будем обозначать .

Проблема потери результатов обновления.

Две транзакции по очереди записывают некоторые данные в одну и ту же строку и фиксируют изменения.

Таблица 1.  Пример потери результатов обновления.

Результат. После окончания обеих транзакций, строка содержит значение , занесенное более поздней транзакцией B. Транзакция A ничего не знает о существовании транзакции B, и естественно ожидает, что в строке содержится значение . Таким образом, транзакция A потеряла результаты своей работы. Транзакция A дважды выполняет выборку строк с одним и тем же условием. Между выборками вклинивается транзакция B, которая добавляет новую строку, удовлетворяющую условию отбора.

Таблица 2. Пример проблемы незафиксированной зависимости.

Транзакция A ничего не знает о существовании транзакции B, и, т.к. сама она не меняет ничего в базе данных, то ожидает, что после повторного отбора будут отобраны те же самые строки.

Результат. Транзакция A в двух одинаковых выборках строк получила разные результаты.

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

Пусть на всех счетах находятся одинаковые суммы, например, по 100 условных единиц. Короткая транзакция в этот момент выполняет перевод 50 у.е. с одного счета на другой так, что общая сумма по всем счетам не меняется.

Таблица 3. Пример ошибки собственно-несовместимый анализа.