Реляционная база данных страховой компании «Росгосстрах – Аккорд» в среде СУБД MS Access

Автор работы: Пользователь скрыл имя, 19 Декабря 2011 в 13:22, курсовая работа

Описание

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

Содержание

Введение…………………………………………………………………………..4
Глава 1. . Управление транзакциями в системах баз данных
1.1 Понятие транзакции………………………………………………………6
1.2 Параллельное выполнение транзакций………………………………….9
1.3 Сериализация транзакций……………………………………………………..12
Глава 2. Реализация транзакций в Delphi
2.1 SQL – выражения для управления транзакциями………………...……22
2.2 Управление транзакциями в Delphi …………………………….………25
Глава 3. Проектирование реляционной базы данных страховой компании «Росгосстрах – Аккорд»
3.1. Анализ предметной области…………………………………………….28
3.2. Проектирование базы данных методом нормальных форм…………..31
3.3. Проектирование базы данных методом «сущность-связь»…………...35

Глава 4. Реализация базы данных страховой компании «Росгосстрах – Аккорд» в среде СУБД MS Access
4.1. Создание таблиц и связей между ними………………………………...44
4.2. Разработка запросов……………………………………………………..49
4.3 Разработка отчетов и форм………………………………...…………….54
4.4.Разработка макросов……………………………………………………..56
Заключение ………………………………………………………………………58
Список использованных источников……………………………...……………60
Приложения ……………………………………………..………………………61

Работа состоит из  1 файл

курсовая БД.docx

— 382.94 Кб (Скачать документ)

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

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

Метод временных меток.

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

    Основная  идея метода состоит в следующем: если транзакция Т1 началась раньше транзакции Т2, то система обеспечивает такой  режим выполнения, как если бы Т1 была целиком выполнена да начала Т2. 

    К недостаткам этого метода можно  отнести более частные откаты транзакций, чем в случае использования  синхронизационных захватов[6]. 

Уровни  изолированности  пользователей.

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

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

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

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

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

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

    В SQL2 существует оператор выбора уровня изолированности выполнения транзакции. В разных коммерческих СУБД могут  быть реализованы не все уровни изолированности, это необходимо уточнять в технической документации[7]. 

Мониторы  транзакций.

    Мониторы  транзакций - Transaction Processing Monitor (TPM) - программные системы (относится к категории программного обеспечения промежуточного слоя middlware), обеспечивающие эффективное управление информационно-вычислительными ресурсами в распределенной среде. они представляют собой гибкую открытую среду для разработки и управления мобильными приложениями, ориентированными на оперативную обработку распределенных транзакций. В числе важнейших характеристик мониторов транзакций - маштабируемость, поддержка функциональной полноты и целостности приложений, достижение максимальной производительности обработки данных в гетерогенной среде[11]. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Глава 2. Реализация транзакций в Delphi 

     2.1. SQL-выражения для управления транзакциями

     Все операции, выполняемые с данными  на SQL сервере, происходят в контексте  транзакций. Транзакция - это групповая операция, т.е. набор действий с базой данных; самым существенным для этих действий является правило либо все, либо ни чего. Если во время выполнения данного набора действий, на каком-то этапе невозможно произвести очередное действие, то нужно выполнить возврат базы данных к начальному состоянию (произвести откат транзакции).

     Для управления транзакциями имеется три  выражения:

SET TRANSACTION - Начинает транзакцию и определяет ее поведение.

COMMIT - Сохраняет изменения, внесенные транзакцией, в базе данных и завершает транзакцию.

ROLLBACK - Отменяет изменения, внесенные транзакцией, и завершает транзакцию.

     Запуск  транзакции

     Выполнять транзакции можно, например, из Windows Interactive SQL, из программы, из сохраненной процедуры или триггера. В общем виде, синтаксис команды SQL для запуска транзакции:

     SET TRANSACTION [Access mode] [Lock Resolution]

     [Isolation Level] [Table Reservation]

     Значения, принимаемые по-умолчанию: 
выражение

     SET TRANSACTION

     равносильно выражению

     SET TRANSACTION READ WRITE WAIT ISOLATION LEVEL SNAPSHOT

     Access Mode - определяет тип доступа к данным. Может принимать два значения:

  • READ ONLY - указывает, что транзакция может только читать данные и не может модифицировать их.
  • READ WRITE - указывает, что транзакция может читать и модифицировать данные. Это значение принимается по умолчанию.

     Пример:

     SET TRANSACTION READ WRITE

     Isolation Level - определяет порядок взаимодействия данной транзакции с другими в данной базе. Может принимать значения:

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

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

     READ COMMITTED - позволяет транзакции видеть  текущее состояние базы.

     Конфликты, связанные с блокировкой записей  происходят в двух случаях:

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

     Транзакция  пытается модифицировать таблицу, которая  заблокирована другой транзакцией  типа SNAPSHOT TABLE STABILITY.

     Lock Resolution - определяет ход событий при обнаружении конфликта блокировки. Может прин тимать два значения:

  • WAIT - значение по умолчанию. Ожидает разблокировки требуемой записи. После этого пытается продолжить работу.
  • NO WAIT - немедленно возвращает ошибку блокировки записи.

     Table Reservation - позволяет транзакции получить гарантированный доступ необходимого уровня к указанным таблицам. Существует четыре уровня доступа:

  • PROTECTED READ - запрещает обновление таблицы другими транзакциями, но позволяет им выбирать данные из таблицы.
  • PROTECTED WRITE - запрещает обновление таблицы другими транзакциями, читать данные из таблицы могут только транзакции типа SNAPSHOT или READ COMMITTED.
  • SHARED READ - самый либеральный уровень. Читать могут все, модифицировать - транзакции READ WRITE.
  • SHARED WRITE - транзакции SNAPSHOT или READ COMMITTED READ WRITE могут модифицировать таблицу, остальные - только выбирать данные.

     Завершение  транзакции

     Когда все действия, составляющие транзакцию успешно выполнены или возникла ошибка, транзакция должна быть завершена, для того, чтобы база данных находилась в непротиворечивом состоянии. Для  этого есть два SQL-выражения:

  • COMMIT - сохраняет внесенные транзакцией изменения в базу данных. Это означает, что транзакция завершена успешно.
  • ROLLBACK - откат транзакции. Транзакция завершается и никаких изменений в базу данных не вносится. Данная операция выполняется при возникновении ошибки при выполнении операции (например, при невозможности обновить запись).
 

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

Прежде  всего, транзакции в Delphi бывают явные и неявные.

     Явная транзакция - это транзакция, начатая и завершенная с помощью методов объекта DataBase:StartTransaction, Commit, RollBack. После начала явной транзакции, все изменения, вносимые в данные относятся к этой транзакции.

     Другого способа начать явную транзакцию, нежели с использованием DataBase, нет. (Точнее говоря, такая возможность есть, но это потребует обращения к функциям API InterBase. Однако, это уже достаточно низкоуровневое программирование.) Следовательно, в рамках одного соединения нельзя начать две транзакции.

     Неявная транзакция стартует при модификации данных, если в данный момент нет явной транзакции. Неявная транзакция возникает, например, при выполнении метода Post для объектов Table и Query. То есть, если Вы отредактировали запись, в DBGrid и переходите на другую запись, то это влечет за собой выполнение Post, что, в свою очередь, приводит к началу неявной транзакции, обновлению данных внутри транзакции и ее завершению. Важно отметить, что неявная транзакция, начатая с помощью методов Post, Delete, Insert, Append и т.д. заканчивается автоматически.

     Для модификации данных может использоваться и PassThrough SQL - SQL-выражение, выполняемое с помощью метода ExecSQL класса TQuery. Выполнение модификации через PassThrough SQL также приводит к старту неявной транзакции. Дальнейшее поведение транзакции, начатой таким путем, определяется значением параметра SQLPASSTHRU MODE для псевдонима базы данных (или тот-же параметр в св-ве Params объекта DataBase). Этот параметр может принимать три значения:

     - SHARED AUTOCOMMIT - слово SHARED указывает на то, что оба вида транзакций(через Passthrough SQL и через методы TTable и TQuery) разделяют одно и то же соединение к базе данных. Слово AUTOCOMMIT указывает на то, что неявная транзакция, начатая через Passthrough SQL, завершается после выполнения действия по модификации данных (автоматически выполняется COMMIT).

     - SHARED NOAUTOCOMMIT - отличается от предыдущего тем, что неявная транзакция, начатая через Passthrough SQL, не завершается после выполнения, ее нужно явно завершить, выполнив SQL-выражение "COMMIT".

     - NOT SHARED - транзакции разных типов работают через разные соединения с базой. Данное значение параметра подразумевает также NOAUTOCOMMIT. То есть все неявные PassthroughSQL-транзакции нужно завершать явно - выполняя SQL-выражение "COMMIT" для Passtrough SQL.

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

     В первом случае, если нет в данный момент начатой транзакции, то попытка  модификация данных методами TTable или TQuery, как и выполнение через Passtrough SQL какой-либо операции приведет к старту неявной транзакции. После выполнения, такая транзакция будет автоматически завершена (если не возникло ошибки по ходу транзакции). Если уже имеется начатая явно (метод StartTransaction объекта DataBase) транзакция, то изменения будут проходить в ее контексте. Все транзакции используют одно и то-же соединение.

Информация о работе Реляционная база данных страховой компании «Росгосстрах – Аккорд» в среде СУБД MS Access