Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Управление транзакциями. Основные стратегии.



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

Стандарт SQL-92 определяет следующие четыре уровня изоляции, установка которых предотвращает определенные конфликтные ситуации («+» – предотвращает, «–» – не предотвращает):

 

Уровень Запрет читать измененные данные Запрет изменять прочитанные данные Запрет добавления Примечание
read uncommitted (чтение незафиксированных данных) Низший уровень изоляции. Гарантирует только отсутствие потерянных обновлений.
read committed (чтение фиксированных данных) + Принятый по умолчанию уровень для Microsoft SQL Server. Отсутствует черновое, «грязное» чтение. Тем не менее в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы (не решена проблема неповторяемого чтения)
repeatable read (повторяемость чтения) + + Уровень, при котором чтение одной и той же строки или строк в транзакции дает одинаковый результат
Serializable (упорядочиваемость) + + + Самый высокий уровень изолированности; транзакции полностью изолируются друг от друга

 

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

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

Существует несколько базовых алгоритмов сериализации транзакций.

1) Последовательное исполнение: выполняется только одна транзакция, остальные ждут ее завершения. Приводит к большим задержкам времени ожидания. Для ускорения следует разрешить любую работу с различными данными и одновременное чтение одних и тех же данных;

2) Использование синхронизационных блокировок: транзакция при обращении к данным накладывает блокировку (захват). Обычно используется два типа блокировок: на чтение и на запись. Если транзакции требуются данные и они свободны, то выполняется работа с данными; если они заблокированы, проверяется возможность совместимости: при совместимости работаем с данными, при несовместимости – ожидаем их освобождения. Блокировки снимаются при завершении транзакции. Для поддержки захватов используется двухфазный протокол синхронизации (двухфазное блокирование).

- 1 фаза – транзакция захватывает данные по мере обращения к ним:

 

- 2 фаза – одновременное освобождение всех данных по завершению транзакции.

Основной недостаток: возможность взаимоблокировок (тупиков):

 

При наличии тупика (deadlock) ожидание будет бесконечным, поэтому необходимо нестандартное разрешение. Конфликты блокировок решаются следующими методами:

полуавтоматический вариант: при обнаружении конфликта посылается запрос пользователю. Пользователь принимает решение – продолжить ожидание или произвести откат транзакции;

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

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

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

─ вершины типа T, соответствующие транзакциям или выполняющимся потокам. Они образуют первую долю графа;

─ вершины типа R, соответствующие ресурсам и объектам, которые могут быть захвачены транзакциями. Они образуют вторую долю графа.

Дуги графа ожидания также имеют двоякий смысл:

─ дуги (T, R), идущие из вершины-транзакции T в вершину-ресурс R, обозначают, что данный ресурс уже захвачен транзакцией

─ дуги (R, T), идущие из вершины-ресурса R в вершину-транзакцию T обозначают, что транзакция T ожидает, пока ресурс R будет освобождён.

Простейшие свойства:

1. Ресурс, не имеющий ни одной входящей дуги, является свободным.

2. Если вершина-транзакция имеет некоторое ненулевое количество входящих дуг, то соответствующая транзакция находится в состоянии ожидания.

3. Если между двумя транзакциями T1 ® T2 существует путь, то транзакция T1 должна быть выполнена (завершена) раньше, чем начнётся выполнение T2, поскольку последняя требует освобождения некоторых ресурсов, захваченных транзакцией T1.

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

Для обнаружения цикла используется редукция графа. При этом поочередно выполняются два шага:

─ удаление дуг от неожидающих транзакций;

─ удаление дуг от свободных данных к транзакциям.

Если не удается удалить некоторый набор дуг, то это - цикл. Для разрешения тупика откатывается одна из транзакций.

3) Временные метки – транзакция при инициализации получает метку – это время начала. При обращении к данным, транзакция помечает его своей меткой. При обнаружении конфликта, метки сравниваются. Более молодая транзакция откатывается

 

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

─ многоуровневое блокирование: для записи, ячейки, массива записей, или всей таблицы (обычно при мелкой блокировке – много меток, при высокой – сразу блокируется большой кусок);

─ многоверсионная организация. Применена в InterBase.. Сущность её состоит в том, что все изменения, проводимые над конкретными записями, производятся не над самой записью, а над ее версией. Версия записи - это копия записи, которая создается при попытке ее изменить. Если какой-то транзакции нужно работать с какой-либо записью, транзакция обращается к последней зафиксированной версии записи;

─ использование оптимистического буферирования. При этом данные храниться в буфере до тех пор, пока принудительно не выполняется запись в базу. Различают пессимистическое (запись в БД при записи в буфер) и оптимистическое буферирование (запись выполняется после завершения транзакции, но потом проверяется - были ли изменения в данных. Если изменения были, то пользователь получает сообщение об этом.


15. Защита от несанкционированного доступа

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

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

Защита данных от несанкционированного доступа предполагает:

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

─ обеспечение защиты конкретных данных: определение прав доступа групп пользователей и отдельных пользователей, определение допустимых операций над данными для отдельных пользователей, выбор/создание программно-технологических средств защиты данных, шифрование информации в целях защиты данных от несанкционированного использования;

─ фиксация попыток несанкционированного доступа к информации;

─ аудит действий пользователей в базе данных;

─ исследование возникающих случаев нарушения защиты данных и проведение мероприятий по их предотвращению.

 

Безопасность базы данных можно разделить на две части:

1) Безопасность системы, которая охватывает доступ к базе данных на системном уровне. Безопасность системы включает в себя:

─ проверка правильности комбинации имени и пароля пользователя;

─ контроль системных операций, которые пользователю разрешено выполнять.

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

─ к каким объектам базы данных имеет доступ пользователь;

─ какие действия пользователь может выполнять с объектами базы данных (извлечение, вставка, обновление, удаление).

 

Защита может выполняться на разных уровнях:

1. Защита от непосредственного доступа к базе данных. Применяются следующие методы:

1) Использование закрытого (сложного для чтения, уникального) формата данных.

2) Шифрование данных. Могут шифроваться как файлы целиком, так и отдельные поля.

Методика введения полного шифрования – шифрование в конце, расшифровка в начале программы.

Важнейшими характеристиками алгоритмов шифрования являются криптостойкость, длина ключа и скорость шифрования.

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

3) Самый популярный метод защиты – перенос базы на защищенный носитель (защищённый сервер).

 

Защита на уровне СУБД

Сервер баз данных управляет секретностью базы данных, используя различные средства:

─ управление пользователями базы данных;

─ управление привилегиями и ролями;

─ аудит базы данных;

─ шифрование хранимых программных единиц.

Распознавание пользователя предполагает:

─ идентификацию пользователя – пользователь указывает свой идентификатор (не секретный – логин);

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

После распознавания пользователя система производит следующие действия:

─ выделяет соответствующие пользователю ресурсы (трафик, расписание доступа, выделение памяти и т.д.);

─ устанавливает права доступа пользователя.

─ выполняет мониторинг (оперативное наблюдение) и аудит (подведение итогов, определение статистики) за пользователем;

Основное средство защиты – контроль доступа – использует два основных подхода:

─ обязательный;

─ избирательный.

Избирательный подход – дает меньшую степень защиты, но более просто реализуется. Дл этого пользователям назначаются привилегии.

Привилегия – право на выполнение некоторой операции. Разделяются на системные и объектные привилегии.

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

Объектные привилегии – разрешают выполнять действия над заданным объектом базы данных (таблицей, представлением и т.д.). Стандартизированы в SQL системах.

Основные объектные привилегии для внешних пользователей:

ALTER – разрешает изменение определения заданных таблиц, представлений

DELETE – разрешает удаление строк из заданных таблиц, представлений

EXECUTE – разрешает выполнение заданных хранимых процедур, функций, пакетов

INSERT – разрешает вставка строк в заданные таблицы, представления

SELECT – разрешает чтение данных из заданных таблиц, представлений

UPDATE – разрешает изменение данных в заданных таблицах, представлениях

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

Для задания привилегий заполняется матрица доступа:

 

Привелегии (права) задаются с помощью команды:

GRANT < привилегия[, привилегия …] | ALL> ON < Объект> TO < Субъект>

(" ALL" предоставляет все привилегии на объект)

Например, чтобы позволить пользователю Ivanov выполнять запросы к таблице Sotrudnik, нужно ввести команду

GRANT SELECT ON Sotrudnik TO Ivanov;

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

Привилегии может назначать администратор, владелец объекта или уполномоченное (доверенное) лицо – тот, кому поручили перераспределение привилегий.

Доверенное лицо получает разрешение на выдачу привилегий добавлением GRANT опции:

GRANT < привилегия> ON < Объект> TO < Субъект> WITH GRANT OPTION

При этом конструкция " WITH ADMIN OPTION" разрешает предоставлять полученную привилегию другим пользователям

Напрмер, команда

“GRANT SELECT ON Sotrudnik TO Ivanov WITH GRANT OPTION”

предоставляет возможность пользователю Ivanov пере­давать право назначать привилегии работы с таблицей Sotrudnik другим пользователям.

 

Для отмены привилегии используется оператор

“REVOKE < привилегия> ON < объект> FROM < субъект> ”.

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

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

Каждый пользователь в среде SQL имеет специальное идентифи­кационное имя (или номер).

Для пользователя таблицы могут быть назначены следующие типы привилегий:

─ SELECT - разрешение выполнять запросы в таблице.

─ INSERT - разрешение выполнять оператор INSERT (вставка но­вой строки) в таблице.

─ UPDATE - разрешение выполнять оператор UPDATE (обновле­ние значений полей) в таблице. Можно ограничить эту привилегию для определенных столбцов таблицы.

─ DELETE - разрешение выполнять оператор DELETE (удаление записей) в таблице.

─ REFERENCES - разрешение определить внешний ключ.

 

Недостатки избирательного подхода:

─ сложность назначения привилегий;

─ ошибки нарушения конфиденциальности из-за путаницы.

 

Для упрощения и большей наглядности назначений может быть реализовано группирование. Существуют две формы: пользователи объединяются в группы, привилегии в роли.

В первых системах создавались группы пользователей. При этом объявляются группы, пользователи причисляются к группам. Привилегии назначаются как отдельным пользователям, так и отдельным группам. Обычно существуют предопределенные группы (например, PUBLIC – в нее автоматически зачисляются все пользователи; этой группе определяют минимальные права).

Второй вариант, который в настоящее время чаще используется – управление привилегиями через роли. Роль – именованная группа привилегий, которая может быть предоставлена пользователю. Использование ролей позволяет группировать привилегии, необходимые для разных категорий пользователей и динамически управлять привилегиями (например, достаточно переопределить привилегии, назначенные роли, что немедленно отобразится на всех пользователях, которым назначена эта роль). Администратор базы данных создает роль, определяет набор привилегий для роли и присваивает роль пользователям:

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

 

Обязательный подход

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

При попытке доступа уровень субъекта сравнивается с классом объекта. Учитываются ограничения:

─ пользователь может читать данные объектов своего уровня и нижних;

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

Такая модель называется моделью Белла-Лападула.

В простой реализации модели метки назначаются записям.

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

В получаемых моделях секретные и несекретные данные хранятся в общих таблицах. При выводе засекреченные данные не предъявляются, если уровень секретности субъекта это не поддерживает. При этом возможна косвенная утечка информации, в зависимости от способа маскирования данных. Используются следующие варианты маскирования:

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

─ использование легенды для секретных данных. Для каждой ячейки хранится основной вариант и легенда. С легендой можно делать все что угодно. Например, данные " Иванов" и " бухгалтер" являются легендами соответствующих данных.

ФИО г.р. должность

С Иванов Н 1940 С бухгалтер

Д. Бонд агент 007

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

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

 

Защита на уровне приложения

На этом уровне могут реализовываться аналогичные механизмы, при отсутствии их в СУБД. Кроме того, на уровне приложения можно реализовать дополнительные возможности:

─ очистка буферов;

─ очистка swapping-файлов (один из механизмов виртуальной памяти, при котором отдельные фрагменты памяти, обычно неактивные, перемещаются из ОЗУ на внешний накопитель, освобождая ОЗУ для загрузки других активных фрагментов памяти);

─ очистка временного хранения;

─ контроль выдачи выходных документов;

─ протокол обращения к данным;

─ вывод на съемные носители;

─ контроль целостности системы защиты.

Достоинства:

1) возможности реализации нестандартных алгоритмов защиты.

2) большее быстродействие.

3) можно реализовать доступ не к объектам, а к пользовательским операциям.

Недостатки:

1) возможность обхода приложения.

2) легче взлом защиты.

 

Домен безопасности

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

 

 

Параметры домена безопасности задаются при создании пользователя базы данных, и могут быть изменены для существующего пользователя.

 


16. Физическая организация данных в БД

Чтобы правильно использовать вычислительную машину, необходимо хорошо представлять себе структурные отношения между данными, знать способы представления таких структур в памяти машины и методы работы с ними. Структура данных и представление этой структуры в памяти ЭВМ – два важных, но различных между собой понятия. Например, некоторая логическая структура данных типа «дерево» может быть представлена в памяти ЭВМ несколькими различными способами.

База данных представляет собой множество информационных объектов. Существует два основных способа их хранения:

1) Раздельное хранение. Характерно для простых персональных систем. При этом каждый объект БД (таблица, индекс, представление и т.д.) хранится в отдельном файле. Размещение файлов на носителе, управление размерностью файлов осуществляется средствами файловой системы. Пример подобной реализации – VisualFoxPro.

 

Достоинства:

– простота форматов – в каждом файле размещается информация одного типа. Упрощается анализ информации;

– упрощение СУБД за счет передачи размещения файловой системе.

Недостатки:

– проблемы хранения общих служебных данных;

– высока вероятность потери целостности базы;

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

2) Совместное хранение. Характерно для серверных СУБД. При создании базы данных сразу же отводится определенный размер на диске. Файл базы один. Распределение таблиц внутри файла производится специальными средствами самой СУБД, при этом память для таблиц выделяется с запасом.

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

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

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

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

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

Пример: InterBase в команде CREATE DATABASE.

 

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


Поделиться:



Популярное:

Последнее изменение этой страницы: 2017-03-03; Просмотров: 527; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.087 с.)
Главная | Случайная страница | Обратная связь