Проблема параллелизма  транзакций

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

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

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

3. несовместимый анализ – в результате модификации БД транзакцией, другая транзакция может внести в БД некую информацию, которая не будет соответствовать целостному состоянию БД.

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

В СУБД используют протокол доступа к данным, согласно которому:

ü транзакция, результатом которой является извлечение объекта БД, накладывает блокировку чтения;

ü транзакция, предназначенная для модификации объекта БД, обязана наложить блокировку записи на этот объект;

ü блокировка записи сохраняется до конца выполнения транзакции;

ü если на объект уже наложена блокировка, то другая транзакция ожидает момента, когда блокировка будет снята.

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

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

Классификация СУБД

К важным признакам классификации современных СУБД относятся:

ü среда функционирования – класс компьютеров и ОС (платформа), на которых работает СУБД, в том числе разрядность ОС;

ü тип поддерживаемой в СУБД модели данных.

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

ü возможности встроенного языка СУБД, его переносимость в другие приложения (SQL, Visual Basic и т.п.)

ü наличие развитых средств конструирования (таблиц, форм, отчетов, запросов) и средств работы с БД;

ü возможность работы с нетрадиционными данными (сообщения электронной почты, изображения, звуковые файлы, видео клипы)

ü используемая концепция управления и обработки данных (локальная, клиент-сервер).

ü и др.

Основные этапы разработки БД

Создание БД необходимо начинать с ее проектирования. В результате проектирования должна быть определена структура БД: состав объектов и логические связи между ними.

В основе методов проектировании БД могут использоваться два подхода:

ü сначала определяются основные задачи, для решения которых строится база и потребности задач в данных;

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

Наиболее рационально сочетание обоих подходов. Эти подходы лежат в основе SADT – моделирования. Методология DFD позволяет определить будущие подсистемы информационной системы предметной области.

Из рассмотренной ранее трехуровневой архитектуры СУБД вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:

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

ü обследование предметной области, изучение ее информационной структуры;

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

ü моделирование и интеграция всех представлений.

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

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

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

Далее осуществляется загрузка БД с документов источников.