Явные транзакции требуют, чтобы пользователь указал начало и конец транзакции:
1) BEGIN TRAN[SACTION] [имя_транзакции | @имя_переменной_транзакции] - начало транзакции. В журнале транзакций регистрируются первоначальные значения изменяемых данных и момент начала транзакции.
2) END TRAN[SACTION] - конец транзакции. Если в теле транзакции не было ошибок, то эта команда предписывает серверу зафиксировать все изменения, сделанные в транзакции, после чего в журнале транзакций помечается, что изменения зафиксированы и транзакция завершена.
3) COMMIT [TRAN[SACTION] [имя_транзакции | @имя_переменной_транзакции]] - фиксация изменений.
4) SAVE TRAN[SACTION] {имя точки сохранения | имя переменной точки сохранения} - создание внутри транзакции точки сохранения. Сервер сохраняет состояние БД в текущей точке и присваивает сохраненному состоянию имя точки сохранения;
5) ROLLBACK [TRAN[SACTION] [имя_транзакции | @имя_переменной_транзакции
| имя точки сохранения | @имя переменной точки сохранения]] - прерывание транзакции. При приеме сервером этой команды осуществляется откат транзакции, восстанавливается первоначальное состояние системы и в журнале транзакций отмечается, что транзакция была отменена. Отменяются все изменения, сделанные в БД после оператора BEGIN TRANSACTION, или отменяются изменения, сделанные в БД после точки сохранения, возвращая транзакцию к позиции выполнения оператора SAVE TRANSACTION.
Транзакции могут быть вложенными. В этом случае только если транзакции на всех уровнях вложенной транзакции завершены успешно, происходит фиксация всех сделанных изменений при успешном завершении транзакции верхнего уровня.
При программировании транзакций можно управлять уровнем их изолирования. Стандартом ANSI определены четыре уровня изолирования, которые задаются командой:
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
READ UNCOMMITED – чтение данных незавершенной транзакции, или допустимо "грязное" чтение. Изолирование соответствует уровню 0. Гарантируется только физическая целостность данных: если несколько пользователей одновременно изменяют одну и ту же строку, то в окончательном варианте строка будет иметь значение, определенное пользователем, последним изменившим запись. По сути, для транзакции не устанавливается никакой блокировки, которая гарантировала бы целостность данных.
READ COMMITTED – чтение данных завершённой, зафиксированной в журнале транзакции, при котором отсутствует "грязное" чтение. Но в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция может работать с несогласованными данными (неповторяемое чтение).
REPEATABLE READ – повторяемое чтение. При повторном чтении строки обеспечиваются первоначально считанные данные, несмотря на какие-либо обновления, произведенные другими пользователями до завершения транзакции.
SERIALIZABLE – сериализуемая транзакция. Чтение запрещено до завершения транзакции.
В каждый момент времени возможен только один уровень изолирования.
Блокировки курсоров
Курсор является объектом, которому в памяти базы данных соответствует область, содержащая результирующий набор строк исполнявшегося оператора SQL. Если оператором является запрос к базе данных, в памяти сохраняется и строка данных запроса, называемая текущим значением, или текущей строкой курсора. Область курсора в памяти поименована и доступна для прикладных программ
В соответствии со стандартом SQL при работе с курсорами можно выделить следующие основные действия:
• создание или объявление курсора;
• открытие курсора, т.е. наполнение его данными, которые сохраняются в многоуровневой памяти;
• выборка из курсора и изменение с его помощью строк данных;
• закрытие курсора, после чего он становится недоступным для пользовательских программ;
• освобождение курсора, т.е. удаление курсора как объекта, поскольку его закрытие необязательно освобождает ассоциированную с ним память.
Курсоры делятся на две категории: последовательные и прокручиваемые. На время открытия курсора сервер устанавливает блокировку на все строки, включенные в его полный результирующий набор. Статический курсор не изменяется после создания и всегда отображает тот набор данных, который существовал на момент его открытия. Динамический курсор отражает изменения соответствующих данных, производимые, пока он открыт.
Последовательные курсоры не разрешают выполнять выборку данных в обратном направлении. Можно выбирать строки только от начала к концу курсора. Последовательный курсор не храни т набор всех строк.
Пример синтаксиса команды создания курсора в MS SQL:
<создание_курсора>::=
DECLARE имя_курсора CURSOR [LOCAL | GLOBAL]
[FORWARD_ONLY | SCROLL]
[STATIC | KEYSET | DYNAMIC | FAST_FORWARD]
[READ_ONLY | SCROLL_LOCKS | OPTIMISTIC]
[TYPE_WARNING]
FOR SELECT_оператор
[FOR UPDATE [OF имя_столбца[,...n]]]
6.5. Вопросы и литература
1. Что означает конкуренция процессов за ресурсы.
2. Что понимается под синхронизацией процессов.
3. Когда необходимо решать задачу взаимного исключения.
4. В каких случаях возникают тупики.
5. Каково назначение объектов семафор и мьютекс.
6. Зачем необходима блокировка процессов и что она означает.
7. Что означает изолированность транзпкции.
8. Поясните различие блокировок Exclusive (X), Shared (S);
| Учебник / Учебное пособие | Раздел | Страницы |
| Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001.- 304 с.; ил. | Глава 11 | 216-247 |
7. Информационно-логическое моделирование в разработке баз данных
7.1. Цель практического занятия
Целью практического занятия является более подробное ознакомление с логическим моделированием базы данных на примере диаграммы сущность-связь (Entity Relationship Diagram, ERD).
7.2. План занятия
В рамках занятия рассматриваются следующие вопросы:
· Реляционная и IDEF1X нотации модели данных;
· Представление сущностей и атрибутов сущностей;
· Представление связей и атрибутов связей; нотации идентифицирующих и идентифицирующих связей;
· Построение модели данных на основе существующей базы данных.
7.3. Используемые технологии
Для лучшего усвоения материала желательно проведение занятия с использованием компьютера с установленным продуктом Microsoft Visio..
7.4. Примеры для анализа
Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и связи между ними, отражающие основные бизнес-правила предметной области. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.
При этом различают следующие виды моделей.
Модель данных, основанная на ключах - подробное представление данных, включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей.
Полная атрибутная модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Сущности и атрибуты. Основные компоненты ER диаграммы - это сущности, атрибуты и связи. Каждая сущность являет множество сходных по структуре индивидуальных объектов, называемых экземплярами. Атрибут соответствует конкретному свойству моделируемого объекта.
На уровне физической модели сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - столбец таблицы.
Нотация IDEF1X различает зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Зависимая сущность изображается прямоугольником со скругленными углами (сущности Студент, Лабораторная на Рис. 7.1). При идентифицирующей связи атрибуты первичного ключа родительской сущности находятся в составе первичного ключа дочерней сущности. Эта называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK).
Для неидентифицирующей связи можно указывать обязательность связи (Nulls). В случае обязательной связи (No Nulls) атрибут внешнего ключа получит характеристику NOT NULL, несмотря на то что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности.
На Рис. 7.1 показана модель данных в нотации IDEF1X.
Рис. 7.1. Модель предметной области в нотации IDEF1X
Для сравнения фрагмент этой модели в реляционной нотации показан на Рис.7.2.
Рис. 7.2. Фрагмент модели предметной области в реляционной нотации
Атрибуты, указываемыев реляционной нотации полужирным шрифтом, соответствуют обязательным атрибутам ( No Nulls).
Выбор нотации модели в Microsoft Visio показан на Рис. 7.3.
. 
На Рис. 7.4 показаны атрибуты объекта СтудентЛабораторная модели предметной области в нотации IDEF1X.
Рис. 7.4. Атрибуты объекта СтудентЛабораторная
Атрибут связи «Cardinality » (мощность связи) задает характеристику отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
На Рис.7.5. показано представление идентифицирующей связи между объектами Группа и СтудентГруппа и ее атрибут Cardinality.
Обозначение u:R и d:R используется для указания поддержки целостности. При этом u означает операцию update, d – delete, R – ограничение операции (no action), С – каскадное обновление/удаление.
Рис.7.4. Представление идентифицирующей связи Группа и СтудентГруппа
Внимание следует обратить на положение внешних ключей в изображении сущности.
На Рис. 7..5 показано представление неидентифицирующей связи.
Рис. 7..5. Неидентифицирующая связь Студент и СтудентЛабораторная
На Рис. 7.1. внизу слева показана для примера виртуальная таблица (View) Дипломники. Она иллюстрирует один способ формирования представления информации о студентах-дипломниках. На Рис. 7.6 показан формат, в котором СУБД сохраняет «виртуальную таблицу».
Рис. 7.6. Виртуальная таблица Дипломники и предложение SQL для ее формирования
Рядом с виртуальной таблицей Дипломники показана другая сущность Дипломник. Она иллюстрирует иерархию наследования (или иерархия категорий) и представляет собой особый тип объединения сущностей, которые имеют общие характеристики и некоторый атрибут- дискриминатор, т.е., атрибут родового предка, на основе которого возможно отличать одну категориальную сущность от другой.
7.5. Вопросы и литература
1. Что понимают под ограничениями целостности.
2. Какие ограничения поддерживаются в SQL сервере.
3. Поясните термин ключи-кандидаты.
4. Зачем используются. NULL-значения и когда они могут появляться.
5. Что означает каскадное обновление.
6. Приведите пример нарушения ссылочной целостности.
7.. Чем различаются зависимые и независимые сущности.
8. Поясните термины внешний ключ и первичный ключ.
| Учебник / Учебное пособие | Раздел | Страницы |
| Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001.- 304 с.; ил. | Глава 7 | 121-134 |
8. Работа с данными. Язык баз данных
8.1. Цель практического занятия
Данное занятие проводится интерактивно в форме дискуссийпо возможным путям решения задач, построению схемы базы данных и по постановке и конкретизации запросов к базе данных.
Данное занятие ориентировано на разборе решений задач по построению запросов к базе данных и основывается на материале предшествующих занятий 5,7, а также на материале, изложенном в Методических указаниях к лабораторным и практическим занятиям по дисциплине «Операционные системы и базы данных».
Занятие предназначено для содействия выполнения заданий по лабораторным занятиям 3 и 4..
8.2. План занятия
Для подготовки к занятию требуется изучить материал к лабораторным и практическим занятиям №3 и №4.
8.3. Используемые технологии
Для лучшего усвоения материала желательно проведение занятия с использованием компьютера.
8.4. Примеры для анализа
Первая группа примеров основывается на схеме данных, показанной на Рис. 5.1.
8.4.1. Пример параметрического запроса с групповой обработкой
Конкретный запрос - «Сколько всего куплено машин цвета [параметр] ».
Необходимые таблицы: «цвета автомобилей», «экземпляры автомобилей» и таблица с фактами покупки «покупатель-автомобиль».
Рис. 8.1 Конструктор запроса «Сколько всего машин [цвета] куплено»
Запрос использует группировку по ключевому полю vin, чтобы подсчитать количество купленных автомобилей. Условием выборки является параметр [цвет].
В форме SQL запрос имеет вид:
SELECT Count(customer_automobile.vin) AS [Count-vin], colors.color_name_sale
FROM colors
INNER JOIN (automobile INNER JOIN customer_automobile
ON automobile.vin = customer_automobile.vin)
ON colors.color_id = automobile.color_id
GROUP BY colors.color_name_sale
HAVING (((colors.color_name_sale)=[Цвет]));
Рис. 8.2 Исполнение и результат «Сколько всего машин [цвета] куплено»
8.4.2 Пример запроса на поиск максимального/минимального значения
Конкретный запрос - поиск самого дешевого «седана». Для реализации запроса потребуются таблица «модели автомобилей», где хранится значение стоимости для базовой комплектации, и таблица «исполнений кузова», где хранится символьное имя кузова.
Рис. 8.3 Запрос «Найти самый дешевый седан»
Запрос использует групповую операцию Min. В форме SQL запрос имеет вид:
SELECT Min (models.cost_basis) AS [Min-cost_basis], bodywork.bodywork_name
FROM bodywork INNER JOIN models ON bodywork.bodywork_id = models.bodywork_id
GROUP BY bodywork.bodywork_name
HAVING (((bodywork.bodywork_name)="Седан"));
Рис. 8.4 Результат работы запроса «Найти самый дешевый седан»
8.4.3 Пример запроса с предварительно определяемым условием выбора
Конкретный запрос - «В какой группе средний рейтинг не превышает среднюю оценку за практику». Соответствующая схема данных показана на Рис. 5.2.
Поскольку условие выбора (средняя оценка за практику и рейтинг по группам) не является известным значением, то сначала потребуется найти:
· значения среднего рейтинга для каждой группы (значений столько, сколько групп;
· среднюю оценку за практику по всем группам (1 значение).
Это выполняется с помощью запроса на групповую обработку.
Рис. 8.5 Запрос «Средний рейтинг в группе»
В форме SQL запрос имеет вид:
SELECT Avg (stud.raiting) AS [Avg-raiting], stud.gruppa
FROM stud
GROUP BY stud.gruppa;
Рис. 8.6 Запрос «Средняя оценка за практику»
В форме SQL запрос имеет вид:
SELECT Avg (Stud_prak.ocenka) AS [Avg-ocenka]
FROM Stud_prak;
Рис. 8.7 Запрос на получение конечного результата
В последнем запросе в качестве условия отбора используется операция отношения <= для сравнения предварительно вычисленных значений.
В форме SQL запрос имеет вид:
SELECT [9_средний рейтинг].gruppa, [9_средний рейтинг].[Avg-raiting]
FROM [9_средний рейтинг], 9_под_З_ср_оценка
WHERE ((([9_средний рейтинг].[Avg-raiting]) <= [9_под_З_ср_оценка]![Avg-ocenka]));
8.5. Вопросы и литература
1. Чем различаются низкоуровневые и высокоуровневые языки для работы с базами данных.
2. Каково назначение языка DDL.
3 Приведите примеры предложений языка DDL.
4. Какие функциональные группы операторов определены в SQL.
5. Что дает стандартизация SQL.
6. Что должно учитываться при выполнении операций INSERT, DELETE, UPDATE.
7. Каковы особенности выполнения операций групповой обработки.
8. Что такое «подзапрос».
| Учебник / Учебное пособие | Раздел | Страницы |
| 1. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001.- 304 с.; ил. | Глава 12 | 248-275 |
| 2. Хомоненко А.Д, Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / под ред. проф. Хомоненко А.Д., 6-ое изд. – М.:Бином-Пресс; СПб.:Корона-Век, 2007.-736с. | Гл.13 | 476-524 |
9. Язык баз данных
9.1. Цель практического занятия
Данное занятие ориентировано на самостоятельное решение студентами задач и служит итоговым для вопросов, изученных на занятиях 5,7 и 8.
9.2. План занятия
Студент получает задачу, в которой представлена схема данных.
В соответствии с задачей требуется:
· Конкретизировать бизнес-правила, задать свойства полей и связей;
· Представить в форме операторов SQL реализацию запросов к базе данных.
9.3. Используемые технологии
Для лучшего контроля правильности решенных задач желательно проведение занятия с использованием компьютера.
9.4. Варианты задач
1)
| Сотрудник | СотрудникОтдел | Отдел | Профиль | |||
| ИД_сотр | ИД_сотр | ИД_отдела | ИД_профиля | |||
| Фио | ИД_отдела | Наименование | Наименование | |||
| Телефон | Дата зачисления | ИД_профиля | ||||
| Адрес |
Профиль отдела: основной/вспомогательный
Запросы:
Найти сотрудников, которые работают по основному профилю
Сколько сотрудников не имеют телефона
Сколько всего сотрудников в отделе «плановый»
Сколько сотрудников заняты на вспомогательных работах
Найти телефон сотрудника(ов), который позже всех начал работать в отделе программирования
Удалить отделы вспомогательного профиля
Изменить профиль отдела Х на вспомогательный
Зачислить нового сотрудника в «плановый» отдел
2)
| Исполнитель | ИсполнитПрограмма | Программа | Тематика | |||
| ИД_исполн | ИД_исполн | ИД_прогр | ИД_тематики | |||
| Фио | ИД_прогр | Наименование | Наименование | |||
| Телефон | Индивид ставка | Дата | Финансирование | |||
| Адрес | ИД_тематики |
Финансирование программ: частное/государственное
Тематика концертов: детский концерт/классика)
Запросы:
Найти исполнителей, которые приняты по минимальной ставке
Найти исполнителей, которые приняты по ставке больше средней государственной
Сколько всего исполнителей заняты в программе(ах) 31.12.13
Найти телефоны исполнителей, которые заняты в программе с государственным финансированием
Удалить исполнителей со ставками меньше 1000
Изменить финансирование детского концерта 31.12.13 на частное
Ввести новую программу «классика»
3)
| Исполнитель | ИсполнитПрограмма | Программа | Тематика | |||
| ИД_исполн | ИД_исполн | ИД_прогр | ИД_тематики | |||
| Фио | ИД_прогр | Наименование | Наименование | |||
| Телефон | Дата | Финансирование | ||||
| Адрес | ИД_тематики | Ставка |
Финансирование: частное/государственное
Тематика: детский концерт/классика
Запросы:
Найти исполнителей детских концертов
Найти исполнителей, которые приняты по ставкам частного финансирования
Сколько детских концертов будет 31.12.13
Найти телефоны исполнителей, которые заняты в программе с государственным финансированием
Удалить детские концерты с частным финансированием
Ввести нового исполнителя в программу Х
Изменить дату Д концерта Х на У
4)
| Исполнитель | ИсполнитПрограмма | Программа | Тематика | |||
| ИД_исполн | ИД_исполн | ИД_прогр | ИД_тематики | |||
| Фио | ИД_прогр | Наименование | Наименование | |||
| Телефон | Дата записи | Дата эфира | ||||
| Адрес | Ставка | ИД_тематики |
Запросы:
Найти исполнителей классики эфира 31.12.13
Сколько исполнителей записывалось 31.12.13
Сколько всего программ будет в эфире 31.12.13
Кто не сделал запись для эфира 31.12.13
Удалить исполнителя Х
Ввести новую программу Х
5)
| Исполнитель | ИсполнитПрограмма | Программа | Финансирование | |||
| ИД_исполн | ИД_исполн | ИД_прогр | Код_финасир | |||
| Фио | ИД_прогр | Наименование | Наименование | |||
| Телефон | Дата записи | Дата эфира | Ставка | |||
| Адрес | Финансирование |
Запросы:
Найти исполнителей со ставками больше 10000
Когда записывались исполнители на эфир 31.12.13
Сколько всего исполнителей будет в эфире 31.12.13
Найти, кто не сделал запись для эфира 31.12.13
Удалить программу Х
Изменить дату эфира программы Х
6)
| Исполнитель | ИсполнитРабота | Работа | Финансирование | |||
| ИД_исполн | ИД_исполн | ИД_работы | Код_финасир | |||
| Фио | ИД_работы | Наименование | Наименование | |||
| Телефон | Срок окончания контракта | Вид финансирования | Ставка | |||
| Адрес | Дата окончания |
Финансирование рпабот: бюджетное/частное/..
Запросы:
Найти всех исполнителей работы Х
Найти исполнителей работы Х, контракт которых закончился
Какие ставки в работах со сроком завершения Х
Когда записывались исполнители на эфир 31.12.13
Удалить исполнителя Х
Изменить финансирование работы Х на частное
7)
| Исполнитель | ИсполнитРабота | Работа | Тип объекта | |||
| ИД_исполн | ИД_исполн | ИД_работы | Код_типа | |||
| Фио | ИД_работы | Наименование | Наименование | |||
| Телефон | Индив. ставка | Вид работы | ||||
| Адрес | Тип объекта |
Вид работы: плановая/неплановая
Тип объекта: коттедж, квартира, школа
Запросы:
Найти всех исполнителей для работ на объекте «школа»
Найти среднюю ставку для «школ»
Найти среднюю ставку для плановых работ
Удалить объект Х
Изменить вид работы Х на плановую
Ввести новую работу У
8)
| Исполнитель | ИсполнитРабота | Работа | Тип объекта | |||
| ИД_исполн | ИД_исполн | ИД_работы | Код_типа | |||
| Фио | ИД_работы | Наименование | Наименование | |||
| Дата рождения | Ставка | |||||
| Адрес | Тип объекта |
Тип объекта: коттедж, квартира, школа
Запросы:
Сколько исполнителей для работ на объекте «школа»
Сколько среднюю ставку для «школ»
Найти самого молодого работника на объектах «школа»
Удалить работу Х
Изменить ставку работы Х на 50%
Назначить исполнителя Х на работу У
9.5. Вопросы и литература
1. Каково назначение и основная структура предложения SELECT..
2. Что такое вложенные запросы.
3. С какой целью указывается GROUP BY.
4. Что означает HAVING.
5. Когда строится план выполнения SELECT.
6 Что понимается под оптимизацией плана выполнения SELECT
| Учебник / Учебное пособие | Раздел | Страницы |
| 1. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001.- 304 с.; ил. | Глава 12 | 248-275 |
| 2. Хомоненко А.Д, Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / под ред. проф. Хомоненко А.Д., 6-ое изд. – М.:Бином-Пресс; СПб.:Корона-Век, 2007.-736с. | Гл.13 | 476-524 |
10. Защита и безопасность при доступе данным в многопользовательской среде
10.1. Цель практического занятия
Целью практического занятия является более подробное ознакомление с аспектами обеспечения безопасности в многопользовательских средах, которыми являются ОС и СУБД..
10.2. План занятия
В ходе занятия рассматриваются вопросы обеспечения безопасности
· в ОС;
· в СУБД.
10.3. Используемые технологии
Для лучшего усвоения материала желательно проведение занятия с использованием компьютера.
10.4. Примеры для анализа
В качестве примеров для анализа рассматриваются:
А) Модель Белла — Ла Падулы обеспечения безопасности для операционной системы, в соответствии с которой каждому пользователю назначается уровень безопасности, хранимый вместе с другими данными пользователя, например с UID и GID. После входа в систему пользовательская оболочка получает уровень безопасности пользователя, который будет унаследован всеми ее дочерними процессами. Если процесс, выполняющийся на уровне безопасности k, попытается открыть файл или другой объект, уровень безопасности которого выше k, то операционная система отклонит попытку открытия файла. Будут отклоняться и все попытки открыть для записи любой объект, уровень безопасности которого ниже, чем k.
Рис. 10.1. Модель Белла — Ла Падулы
Для гарантии целостности данных Биба в 1977г. ввел:
Простой принцип целостности (integrity): процесс, работающий на уровне безопасности k, может осуществлять запись только в объекты своего или более низкого уровня (никакой записи наверх);
Свойство целостности: процесс, работающий на уровне безопасности k, может осуществлять чтение из объектов своего или более высокого уровня (никакого чтения из нижних уровней).
Б) Организация обеспечения безопасности в СУБД на примере Microsoft SQL Server.
В подсистеме обеспечения безопасности определены участники и защищаемые объекты.
Участники — сущности, которые могут запрашивать ресурсы SQL Server.
· Участники уровня Windows
· Участник уровня SQL Server
· Участники уровня базы данных (пользователь базы данных, роль базы данных, роль приложения).
К защищаемым объектам помимо самого SQL Server относятся объекты БД. SQL Server.
Схема БД соответствует отдельному пространству имен, существующему независимо от пользователя базы данных, создавшего ее. Схема —контейнер объектов. Схема может принадлежать любому пользователю, и владение может передаваться.
Схема — это контейнер, который содержит таблицы, представления, процедуры и пр. Они находятся в базе данных, которая расположена на сервере.
| Защищаемые объекты внутри схемы (имеют уникальное имя) | Класс |
| Тип | TYPE |
| Коллекция XML-схем | XML SCHEMA COLLECTION |
| Таблица | OBJECT |
| Представление | OBJECT |
| Процедура | OBJECT |
| Функция | OBJECT |
| Статистическое вычисление | OBJECT |
| Ограничение | OBJECT |
| Синоним | OBJECT |
| Очередь | OBJECT |
| Статистика | OBJECT |
Примеры некоторых разрешений, применяемых к защищаемым объектам, приведены ниже.
| Разрешение | Область применения |
| SELECT | Таблицы и столбцы Представления и столбцы |
| VIEW CHANGE TRACKING | Таблицы Схемы |
| UPDATE | Синонимы Таблицы и столбцы Представления и столбцы |
| REFERENCES | Таблицы и столбцы Функции, возвращающие табличное значение Представления и столбцы |
| INSERT | Синонимы Таблицы и столбцы Представления и столбцы |
| DELETE | Синонимы Таблицы и столбцы Представления и столбцы |
| EXECUTE | Процедуры Скалярные и статистические функции |
| VIEW DEFINITION | Процедуры Скалярные и статистические функции Таблицы Функции, возвращающие табличное значение Возвращающие табличное значение функции Представления |
| ALTER | Процедуры Скалярные и статистические функции Таблицы Функции, возвращающие табличное значение Возвращающие табличное значение функции Представления |
| TAKE OWNERSHIP | Процедуры Скалярные и статистические функции Таблицы Функции, возвращающие табличное значение Возвращающие табличное значение функции Представления |
Упрощенный синтаксис предложения GRANT для предоставления разрешений имеет вид:
GRANT { ALL [ PRIVILEGES ] }
| permission [ (column [,...n ]) ] [,... n ]
[ ON [ class:: ] securable ] TO principal [,... n ]
[ WITH GRANT OPTION ] [ AS principal ]
Аргументы:
ALL, PRIVILEGES - для поддержки обратной совместимости и
обеспечения соответствия стандартам ISO.
permission
Имя разрешения.
column
Указывает имя столбца таблицы, на который предоставляется разрешение. Круглые скобки обязательны ().
class
Указывает класс защищаемого объекта.
securable
Указывает защищаемый объект.
TO principal
Имя участника. Состав участников, которым можно предоставлять разрешения, меняется в зависимости от защищаемого объекта.
GRANT OPTION
Показывает, что получающему разрешению будет также дана возможность предоставлять указанное разрешение другим участникам.
AS principal
Задает участника, от которого участник, выполняющий данный запрос, наследует право на предоставление разрешения.
Инструкция REVOKE используется для удаления уже выданных прав доступа, а инструкция DENY может использоваться, чтобы предотвратить получение участником определенного разрешения посредством инструкции GRANT.
Предоставление разрешения удаляет DENY или REVOKE для этого разрешения на данный защищаемый объект. Если то же разрешение запрещено для более высокой области действия, которая содержит данный защищаемый объект, то DENY имеет более высокий приоритет. Но отмена разрешения, выданного в более высокой области действия, не получает такого приоритета.
Разрешения уровня базы данных выдаются в пределах области указанной базы данных.
Лицо, предоставляющее разрешение (или участник, указанный параметром AS), должно иметь либо само разрешение, предоставленное с помощью GRANT OPTION, либо разрешение более высокого уровня, которое неявно включает предоставляемое разрешение.
Упрощенный синтаксис предложения DENY имеет вид:
DENY { ALL [ PRIVILEGES ] }
| permission [ (column [,... n ]) ] [,... n ]
[ ON [ class:: ] securable ] TO principal [,... n ]
[ CASCADE] [ AS principal ]
В нем CASCADE означает, что разрешение запрещается для указанного участника и всех других участников, которым этот участник предоставил разрешение. Требуется, если участник имеет разрешение с параметром GRANT OPTION.
Упрощенный синтаксис предложения DENY имеет вид
REVOKE [ GRANT OPTION FOR ]
{
[ ALL [PRIVILEGES]] | permission [(column [,... n ])] [,... n ]
}
[ ON [ class:: ] securable ]
{ TO | FROM } principal [,... n ]
[ CASCADE] [ AS principal ]
10.5. Вопросы и литература
1. С какой целью используются предопределенные роли базы данных.
2. Каковы возможности роли db_owner.
3. Каковы возможности роли db_ddladmin.
4. Каковы возможности роли securityadmin.
5. Какова функциональность предложений GRANT, REVOKE, DENY.
6. Что означает «инъекция SQL».
7. Что понимают под угрозой в ОС и СУБД.
8. Чем характеризуется Модель Белла — Ла Падулы обеспечения безопасности для ОС.
| Учебник / Учебное пособие | Раздел | Страницы |
| 1. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001.- 304 с.; ил. | Глава 13 | 276-285 |
| 2. Хомоненко А.Д, Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / под ред. проф. Хомоненко А.Д., 6-ое изд. – М.:Бином-Пресс; СПб.:Корона-Век, 2007.-736с. | Гл.8 | 221-242 |
| 3. Таненбаум Э. Современные операционные системы. 3-е изд. - СПб.: Питер, 2010. - 1120 е.: ил. | 9.1, 9.3 | 711-714, 721-741 |