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

Содержание

Введение.

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

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

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

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

В практической части (Глава 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 в нашем примере) согласованно вы­полнят фиксацию или откат тех обновлений, за которые они ответственны. Более того, он должен обеспечивать такую гарантию даже в том случае, если отказ системы про­изошел до завершения всего процесса. Все это достигается за счет использования прото­кола двухфазной фиксации.