Транзакции и их роль в поддержании целостности данных

Министерство сельского хозяйства РФ

Воронежский государственный аграрный университет

имени императора Петра I

 

 

 

 

 

 

 

 

 

Центр ДОТ

 

 

 

КОНТРОЛЬНАЯ РАБОТА

по дисциплине: Базы данных

 

 

 

 

 

 

 

 

Выполнил студент заочной формы

обучения: Крячков А.А.

Шифр: ДИ/13004

Набор: Июнь 2013

Проверил:_______________

 

 

 

 

 

 

 

 

 

 

 

 

 

Россошь 2014

Оглавление

1. 4) Транзакции и их роль в поддержании целостности данных…………..2

2. Разработка информационно-логической  модели предметной области.....6

2.1. Описание предметной  области……………………………………………6

2.2. Построение информационно-логической  модели…………………….....7

Список использованной литературы……………………………………….....8

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. 4) Транзакции и их роль в поддержании целостности данных.

Понятие транзакции имеет непосредственную связь с понятием целостности  БД. Очень часто БД может обладать такими ограничениями целостности, которые просто невозможно не нарушить, выполняя только один оператор изменения БД. Например, в базе данных СОТРУДНИКИ-ОТДЕЛЫ естественным ограничением целостности является совпадения значения атрибута ОТД_РАЗМЕР в кортеже отношения ОТДЕЛЫ, описывающем данный отдел (например, отдел 320), с числом кортежей отношения СОТРУДНИКИ таких, что значение атрибута СОТР_ОТД_НОМЕР равно 320. Как в этом случае принять на работу в отдел 320 нового сотрудника? Независимо от того, какая операция будет выполнена первой, вставка нового кортежа в отношение СОТРУДНИКИ или модификация существующего кортежа в отношении ОТДЕЛЫ, после выполнения операции база данных окажется в нецелостном состоянии.

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

Если  быть немного более точным, различаются  два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым ограничениям целостности относятся такие  ограничения, проверку которых бессмысленно или даже невозможно откладывать. Примером ограничения, проверку которого откладывать  бессмысленно, являются ограничения  домена (возраст сотрудника не может  превышать 150 лет). Более сложным  ограничением, проверку которого невозможно отложить, является следующее: зарплата сотрудника не может быть увеличена  за одну операцию более, чем на 100,000 рублей. Немедленно проверяемые ограничения целостности соответствуют уровню отдельных операторов языкового уровня СУБД. При их нарушениях не производится откат транзакции, а лишь отвергается соответствующий оператор.

Откладываемые ограничения целостности - это ограничения  на базу данных, а не на какие-либо отдельные  операции. По умолчанию такие ограничения  проверяются при конце транзакции, и их нарушение вызывает автоматическую замену оператора COMMIT на оператор ROLLBACK. Однако в некоторых системах поддерживается специальный оператор насильственной проверки ограничений целостности внутри транзакции. Если после выполнения такого оператора обнаруживается, что условия целостности не выполнены, пользователь может сам выполнить оператор ROLLBACK или постараться устранить причины нецелостного состояния базы данных внутри транзакции (видимо, это осмысленно только при использовании интерактивного режима работы).

И еще  одно замечание. С точки зрения внешнего представления в момент завершения транзакции проверяются все откладываемые  ограничения целостности, определенные в этой базе данных. Однако при реализации стремятся при выполнении транзакции динамически выделить те ограничения  целостности, которые действительно  могли бы быть нарушены. Например, если при выполнении транзакции над базой  данных СОТРУДНИКИ-ОТДЕЛЫ в ней не выполнялись операторы вставки  или удаления кортежей из отношения  СОТРУДНИКИ, то проверять упоминавшееся  выше ограничение целостности не требуется (а проверка подобных ограничений  вызывает достаточно большую работу).

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

Транзакция  обладает следующими свойствами:

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

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

Согласованность:  транзакция начинается на согласованном  множестве данных и после её  завершения множество данных  также согласовано.

Изолированность,  т.е. отсутствие влияния транзакций  друг на друга. (На самом деле это влияние существует и регламентируется стандартом: см. раздел 7.2. "Взаимовлияние транзакций").

Продолжительность:  результаты зафиксированной транзакции  не могут быть потеряны. Возврат  БД в предыдущее состояние может быть достигнут только путём запуска компенсирующей транзакции.

Для управлением транзакциями в системах, поддерживающих механизм транзакций и язык SQL, используются следующие операторы:

– фиксация транзакции:         COMMIT [WORK];

– откат  транзакции:                ROLLBACK [WORK];

– точка  сохранения:                SAVEPOINT <имя_точки_сохранения>;

(Ключевое  слово WORK необязательно). Предложение  SAVEPOINT запоминает промежуточную  "текущую копию" состояния  базы данных для того, чтобы  впоследствии, при необходимости,  можно было вернуться к состоянию  БД в точке сохранения: откатить  работу от текущего момента  до точки сохранения (rollback to <имя_точки>) или зафиксировать работу от начала транзакции до точки сохранения (commit to <имя_точки>).

Начало  транзакции соответствует появлению  первого исполняемого SQL-оператора. Транзакция завершается при наступлении  одного из следующих событий:

Поступила команда COMMIT или ROLLBACK (результаты транзакции соответственно зафиксируются или  откатываются).

Выдана  и успешно проанализирована одна из команд языка описания данных (DDL, Data Definition Language), таких как CREATE, DROP или ALTER. При этом фиксируется предыдущая транзакция.

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

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

Процесс пользователя аварийно завершен (последняя  транзакция автоматически откатывается).

Фиксация  транзакции заключается в следующем:

1. Изменения,  внесённые  транзакцией, делаются  постоянными.

2. Уничтожаются  все точки  сохранения для данной  транзакции.

3. Завершается  транзакция (уничтожаются системные  записи  о транзакции в оперативной  памяти).

4. Если  выполнение транзакций  осуществляется  с помощью блокировок, то освобождаются  объекты, заблокированные  транзакцией.

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

2. Разработка информационно-логической модели предметной области

Предметная область: Производство

Минимальный список характеристик:

• название изделия, тип, оптовая цена, розничная цена, год начала выпуска изделия, примечание - для каких целей предназначено;

• название, адрес и телефон предприятий, выпускающих изделия;

• год выпуска, объем выпуска данного изделия предприятием.

2.1. Описание предметной области 

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

На схеме информационно-логической модели каждый объект изображается в виде прямоугольника. Каждый объект обязательно должен иметь имя (располагается вверху прямоугольника и отделяется горизонтальной линией).

Ниже этой линии перечисляются атрибуты объекта. Каждый объект обязательно должен иметь первичный ключ.

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

Каждый объект должен иметь хотя бы одну связь. Связи между объектами устанавливаются по аналогии со связями в реальной предметной области. Поля, по которым устанавливаются связи, называются внешним ключом.

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

Для установления типа связи можно руководствоваться анализом реальной предметной области. Например, один продавец может продавать различные товары, а также один товар может быть продан разными продавцами. Связь между объектами Модель товара и Сотрудник осуществляется через объект Продажа. Поэтому связь между объектами Модель товара и Продажа имеет тип «один – ко – многим» и связь между объектами Сотрудник и Продажа также имеет тип «один – ко – многим».

Для определения типа связи существуют следующие правила:

- если соединяются два  первичных ключа, то связь имеет  тип «один – к – одному»;

- если соединяется первичный  ключ с внешним, то связь имеет  тип «один – ко – многим», где «один» - на стороне первичного  ключа;

- если соединяется простой  первичный ключ с составным, то  связь имеет тип «один –  ко – многим», где «один» - на  стороне простого первичного  ключа;

- если соединяются два  составных первичных ключа, то  связь имеет тип «один –  ко – многим», где «один» - на  стороне того составного ключа, который состоит из меньшего  числа атрибутов.

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

Предметная область определена: оптовая база и автоматизация работы работника оптовой базы. Круг задач также определен.

2.2. Построение информационно-логической  модели [6]

Оптовая база:

• Изделие;
• Наличие изделия на складе;
• Стоимость единицы изделия;
• Склад;
• Поставщики;
• Производители;
• Форма расчетов с поставщиками;
• Сотрудники производства;
• Отделы производства;
• Купля-продажа изделия;
• Денежные средства.

 

 

 

 

 

 

Список использованной литературы

1. Голицына О.Л./Базы данных: Учебное пособие//О.Л. Голицина, Н.В. Максимов, И.И. Попов  – М.: ФОРУМ: ИНФРА-М, 2006. – 352 с: ил. – (Профессиональное образование);
2. Диго С.М./Базы данных: проектирование и использование. Учебник//С.М. Диго – М.: Финансы и статистика, 2005. – 592 с;
3. Диго С.М./Access: учебно-практ. пособие//С.М. Диго – М.: ТК Велби, Изд-во Пропект, 2006. – 240 с;
4. Карпова Т.С./Базы данных: модели, разработка, реализация//Т.С. Карпова – СПб: «Питер», 2001. – 304 с.: ил;
5. Кузнецов С.Д./Основы современных баз данных //www.citforum/ru/ 2002;
6. Куни Л.У./MS Access 2007//Л.У. Куни, К. Кух - Москва-СПб-Киев : Диалектика, 2007;
7. Лобова О.Е./Методическое пособие по проектированию баз данных//О.Е. Лобова, Г.Н. Вершинина, О.А. Бурунин - Сочи : б.н., 2008;
8. Лобова О.Е./Базы данных: методические указания по выполнению курсового проекта//О.Е. Лобова - Сочи : СГУТиКД, 2006;
9. Назаров С.В./Программирование в пакетах MS Office//С.В. Назаров - Москва : Финансы и статистика, 2007;
10. Советов Б.Я./Базы данных: теория и практика. Учебник для вузов//Б.Я. Советов, В.В. Цехановский, В.Д. Чертовской – М.: Высш. шк., 2005 – 463 с.