78__Понятие транзакций. Свойства, обработка, блокировки транзакций

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

Свойства транзакций

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

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

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

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

Варианты работы транзакций:

1. Обращаться к СУБД интерактивно (заполняем данные сами с помощью команд)

• COMMIT – все данные введены и транзакция завершилась успешно

• ROLLBACK – нарушены какие-либо ограничения или имеются ошибки в синтаксисе – транзакция откатывается

2. Обращается к СУБД из программы (тоже самое).

Чтобы избежать проблем, нужно выполнить след. правила:

1. Блокировка объектов – если транзакция обращается к какому-либо объекту, то для другой тр-ии этот объект д/б заблокирован

2. Блокировка м/б на уровне таблиц, страниц, части таблицы

3. Блокировка на уровне записей (ORACLE)

79__Субд. Понятие, основные функции, требования к серверу баз данных

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

Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):

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

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

Система управления базами обеспечивает выполнение следую­щих основных функций:

• введение в базу новых файлов и записей,

• обновление содержимого, находящегося в базе,

• удаление (уничтожение) знаний, программ и данных, ока­завшихся далее ненужными,

• поиск информации,

• выдача информации на терминалы пользователей,

• объединение и разделение файлов, — копирование и восстановление файлов.

• Эти средства не обладают высокими графическими способностями (приходится ставить модули)

Модель сервера базы данных. Наряду с RDA-моделью все большую популярность приобретает перспективная DBS-модель. Последняя реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер.

+:

• Снижаются требования к сети

• Данные организованы

• Унифицированный интерфейс, получение данных если знаете SQL

• К одной СУБД одновременно может обращаться несколько клиентов

-:

• Логика ПО выполняется клиентом

• Загрузка сети из-за взаимодействия сервера и клиента с помощью SQL запросов

Модель сервера приложений. В AS-модели (рис.5) процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за интерфейс с пользователем (то есть осуществляет функции первой

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

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

Требования к СУБД (12 правил Кодда):

1. Информационное правило. Вся информация, хранящаяся в БД, должна быть представлена единым образом, например в виде таблиц.

2. Правило гарантированного доступа. К любому значению, хранящемуся в БД должен обеспечиваться доступ путем указания таблицы, атрибута и PK.

3. Правило наличия значения. В любой СУБД имеется специальный индикатор для обозначения пустых (null) значений – значения не введены или не могут храниться по какой-то причине.

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

5. Правило модификации таблиц представлений. Если имеются таблицы представлений, являющиеся подмножеством основных таблиц, то изменение значений в них приводит к изменениям значений в основных таблицах.

6. Правило физической независимости. Внешние прикладные программы не должны страдать от изменений правил доступа к данным. Это касается физического уровня.

7. Правило логической независимости. Внешние программы не должны страдать от изменений в структуре данных.

8. Правило сохранения целостности. При изменении правил целостности внешние программы не должны изменяться.

9. Правило привилегии реляционного языка. Если СУБД имеет свой собственный внутренний язык работы с данными, то вначале выполняются команды реляционного языка (SQL), а потом команды внутреннего языка СУБД. Полная состыкованность всех СУБД реляционного типа.

10. Правило динамического каталога. Все объекты БД должны отображаться как объекты обычного каталога.

11. Независимость распространения – СУБД не должна зависеть от потребностей конкретного клиента.

Термин "сервер баз данных" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных. Общая база данных доступна для всех пользователей локальной сети. Термин "сервер баз данных" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных. Общая база данных доступна для всех пользователей локальной сети.

Рассмотрим физическую организацию сервера базы данных. Как правило, он включает следующие компоненты:

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

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

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

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

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

Требования к защите данных:

• Данные в любой таблице должны быть доступны не всем пользователям (СУБД назначает привилегии при помощи команды GRANT).

• Некоторым пользователям можно обновлять данные в таблицах, остальным – только смотреть.

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

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