LINTER от 04.02.15

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

create table object_history(id int, dt date, value varchar(64), status char(1));

alter table object_history add primary key(id, dt);

Дополнительными атрибутами здесь являются dt – дата изменения, и status – статус изменения – одна из букв ‘I’, ‘U’ или ‘D’.

Чтобы обеспечить занесение в эту таблицу записей после успешного изменения таблицы OBJECT, можно создать триггеры на различные виды DML-запросов аналогично следующему:

create trigger INS_OBJECT_HIST after insert on object for each row execute for debug

code

execute direct

"insert into OBJECT_HISTORY(id, dt, value, status) values(“ +

itoa(new.id) + “, sysdate, '” + new.value + “',

'I');"; // end;

В файле obj_hist.sql содержатся запросы на создание таблицы OBJECT_HISTORY и двух триггеров на добавление и на изменение данных.

Прогоните этот файл в inl и попробуйте добавить и обновить несколько записей в таблице OBJECT. Затем сделайте SELECT из таблицы OBJECT_HISTORY. Вы должны увидеть историю сделанных изменений.

Теперь не хватает только триггера на DELETE. Создайте его самостоятельно. В качестве упражнения используем для этого утилиту spman. Утилита spman включает диалоговое окно для упрощения создания триггера, также как и для хранимых процедур. Выберите пункт «Новый триггер» в меню «Файл». Введите все характеристики триггера в диалоговом окне. У вас должно открыться окно с шаблоном нового триггера, примерно такого содержания:

create trigger "DEL_OBJECT_HIST" after delete on OBJECT for each row execute for debug

code end;

Вставьте соответствующий оператор между code и end и сохраните триггер (как обычно, командой сохранения или клавишей <F2>).

Практическое занятие 4 32 Создание, исполнение и отладка хранимых процедур и триггеров

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

4.6. Модификация триггера

Для модификации триггера необходимо удалить старый триггер (запрос drop trigger), и затем пересоздать новый. spman автоматически делает эти операции при необходимости.

Модифицируем наш самый первый триггер (INS_OBJECT) так, чтобы он запрещал добавление в таблицу OBJECTS строк, у которых значение value равно NULL (простейшая проверка, которая может быть выполнена и декларативным способом, но потенциально триггер может реализовать любой алгоритм проверки).

Выбираем в spman команду «Открыть триггер» меню «Файл». В результате откроется окно существующего триггера.

В начало тела триггера добавим проверку:

if new.value = NULL then

return false; endif

Возврат false из триггера означает запрет текущей операции. Сохраняем триггер, и пробуем теперь выполнить в inl такой запрос:

insert into object(id) values(0);

Получаем сообщение о том, что добавлено 0 строк – это результат работы триггера.

4.7. Отладка триггера

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

Откроем в spman триггер INS_OBJECT. Включим отладочную сессию (клавиша <F4>) и режим ожидания (клавиши <Alt>-<F9>). Теперь перейдем в inl и подадим запрос:

insert into object(id) values(0);

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

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

33

Практическое занятие 5 Разграничение доступа в СУБД ЛИНТЕР. Дискреционный доступ

Практика 2 часа (Лекция 5)

Целью занятия является освоение способов разграничения доступа к базе данных на основе дискреционного доступа. При выполнении задания будет использовано приложение «Интерактивный SQL» (INL).

5.1. Создание нового пользователя. Полномочия пользователей

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

Задача: Создать двух пользователей A и B, создать от имени пользователя A таблицу для хранения телефонной книги, предоставить пользователю B доступ для чтения и добавления данных.

Решение:

Запускаем утилиту INL, вводим имя и пароль администратора базы данных или пользователя обладающего привилегией администратора базы данных (DBA).

1.Создаем пользователей A и B с паролями ‘1’ и ’2’: create user A identified by ‘1’;

create user B identified by ‘2’;

2.Даем пользователю A привилегию RESOURCE: grant resource to A;

3.Выходим из утилиты INL командой exit и запускаем утилиту повторно с именем пользователя ‘A’ и паролем ‘1':

4.Создаем таблицу для хранения телефонов:

create table PHONES(ID integer autoinc,NAME char(20), PHONE char(12));

5.Передаем привилегии на чтение и вставку пользователю “B’: grant select,insert on PHONES to B;

6.Выходим из утилиты INL командой exit и запускаем утилиту повторно с именем пользователя ‘B’ и паролем ‘2':

7.Осуществляем вставку данных:

insert into A.PHONES(NAME,PHONE) values(‘Иванов’,’8-095-167-34-80’);

8. Осуществляем выборку данных: select * from A.PHONES;

Задачи для самостоятельной работы:

1.Создать пользователя с привилегией DBA, создать от имени этого пользователя таблицы для хранения почтовых адресов предприятий (название, почтовый индекс, город, улица, дом, а/я). Созданным ранее пользователям A,B предоставить возможность заполнения, модификации, удаления и просмотра данных из этой таблицы. Всем остальным пользователям предоставить возможность только чтения данных из созданной таблицы.

5.2. Использование представлений для разграничения доступа

Для «вертикального» разграничения доступа к таблице используются

Практическое занятие 5 34 Разграничение доступа в СУБД ЛИНТЕР. Дискреционный доступ

Задача: Добавить к таблице PHONES, созданной ранее, поле POSITION (занимаемая должность). Предоставить доступ пользователю B только к полям ID,NAME и PHONE.

Решение:

1. Добавить дополнительное поле в таблицу PHONES: alter table PHONES add(POSITION char(20));

2.Убрать доступ к таблице PHONES revoke all on PHONES from B;

3.Создать представление для доступа к необходимым столбцам таблицы PHONES: create view PH_VIEW as select ID,NAME from PHONES;

4.Передать доступ к созданному представлению:

grant select,insert on PH_VIEW to B;

Задачи для самостоятельной работы:

1.К таблице почтовых адресов добавить фамилии руководителей и сделать их недоступными для всех пользователей, кроме пользователей A и B.

5.3. Использование представлений для разграничения доступа

Для «горизонтального» разграничения доступа к таблице также могут использоваться представления. Рассмотрим это на следующей задаче.

Задача: Предоставить пользователям A и B доступ ко всем записям таблицы телефонов, а остальным пользователям доступ только к телефонам, номера которых начинаются с цифры ‘9’.

Решение:

1.Создать представление для доступа к необходимым столбцам таблицы PHONES: create view PH_VIEW2 as select ID,NAME from PHONES where PHONE like ‘9%’;

2.Передать доступ к созданному представлению:

grant select,insert on PH_VIEW2 to PUBLIC;

Задачи для самостоятельной работы:

1.Произвести разграничение доступа в таблице почтовых адресов для пользователей, кроме A и B, предоставив для просмотра только адреса в городе Москва.

5.4. Роли и их использование

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

Задача: Пользователь A создал в рамках приложения таблицы с телефонами физических лиц и адресами предприятий (см. задачи выше). Необходимо предоставить пользователям C1,C2,C3 доступ на чтение к информации в этих таблицах (используя доступ через представления).

Решение:

1. Работая под пользователем A, создаем роль ROLE_A:

Практическое занятие 5 Разграничение доступа в СУБД ЛИНТЕР. Дискреционный доступ 35

create role ROLE_A;

2. Передаем этой роли доступ к таблицам на чтение:

Grant select on PH_VIEW2 to ROLE_A;

Grant select on ADR_VIEW2 to ROLE_A; (* имя представления из предыдущей задачи *)

3.Создаем пользователей C1,C2,C3: grant connect to C1;

grant connect to C2; grant connect to C3;

4.Назначаем роль пользователям C1, C2, C3:

Grant role ROLE_A to C1; Grant role ROLE_A to C2; Grant role ROLE_A to C3;

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

Задачи для самостоятельной работы:

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

a.только чтение;

b.только вставка;

c.чтение, изменение, вставка;

d.чтение, вставка, удаление, изменение.

2.Назначить роли для пользователей (создать предварительно недостающих) соответственно:

a.C1, C2;

b.C3;

c.D1, D2, D3;

d.E.

5.5. Задачи для самостоятельной работы

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

Задача 1. База данных городской думы.

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

Практическое занятие 5 36 Разграничение доступа в СУБД ЛИНТЕР. Дискреционный доступ

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

Задача 2. База данных рыболовной фирмы.

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

Задача 3. База данных фирмы, проводящей аукционы.

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

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

37

Практическое занятие 6 Резервное копирование и восстановление данных

Практика 1 час (Лекция 5)

На занятии будут рассмотрен инструментарий пакета СУБД ЛИНТЕР, предназначенный для горячего резервирования и восстановления как всей базы данных, так и пообъектно.

6.1. Утилита Linter Hot Backup

Утилита Linter Hot Backup (lhb) предназначена для:

Предположим, что домашней директорией пользователя является /home/linter/ Для выполнения задач данной практики понадобится:

Данный скрипт создает «игрушечную» базу данных – три таблицы LIB_BOOKS, LIB_AUTHOR, LIB_WROTE пользователя SYSTEM, описывающие информацию о книгах и их авторах, а также представление, содержимое которого разрешено просматривать пользователю READER.

6.2. Сохранение базы данных

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

Задача 1. Создать полный архив базы данных. Использовать низкий приоритет процесса архивирования, чтобы не загружать ядро. Архив защитить паролем KBYNTH

lhb s –u SYSTEM/MANAGER –f /home/linter/prac4/db_backup/db_full.lhb –priority LOW –g KBYNTH

Задача 2. Создать полный архив базы данных, разбив его по томам – 1.2 Мб.

lhb s –u SYSTEM/MANAGER –f /home/linter/prac4/db_backup/db_vol.lhb –v 1200 –qc NVDF

Здесь команда NV в ключе –qc указывает, что следует игнорировать предупреждения о создании нового тома, а команда DF – предупреждения о существующих архивных файлах с теми же именами, что и у вновь создаваемых.

6.3. Пообъектное сохранение

Пообъектное сохранение базы данных включается одним из следущих ключей: -ou, - ot, -otwd, -ov, -os, -or, -osr, -oa, -otr, -op, -oall, -d, -takeforeign. После ключа указывается маска объектов, которые подлежат сохранению в формате * -- любое количество любых символов, ? –любой символ. Если маска не указана, то сохраняются все объекты.

lhb s –u SYSTEM/MANAGER –ot LIB_* –f /home/linter/prac4/db_backup/db_lib.lhb

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

lhb s –u SYSTEM/MANAGER –ot LIB_* –ov –oa –f /home/linter/prac4/db_backup/db_lib.lhb

Здесь ключ –ov без маски указывает необходимость сохранения всех представлений; –oa указывает необходимость сохранения привилегий доступа.

6.4. Создание инкрементных архивов

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

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

Задача 5. Создать инкрементный архив всей базы данных.

lhb s –u SYSTEM/MANAGER –startinc –f /home/linter/prac4/db_backup/db_inc.lhb

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

Задача 6. Добавить изменения в инкрементный архив.

lhb s –u SYSTEM/MANAGER –inc –f /home/linter/prac4/db_backup/db_inc.lhb

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

Для работы с контрольными точками предназначена команда cp. Задача 7. Просмотреть список контрольных точек.

lhb cp –u SYSTEM/MANAGER –list –f /home/linter/prac4/db_backup/db_inc.lhb

Задача 8. Удалить контрольную точку с номером 0.

lhb cp –u SYSTEM/MANAGER –clear 0 –f /home/linter/prac4/db_backup/db_inc.lhb

Задача 9. Остановить формирование инкрементного архива.

lhb s –u SYSTEM/MANAGER –stopinc –f /home/linter/prac4/db_backup/db_inc.lhb

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

6.5. Восстановление базы данных

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

Задача 10. Восстановить базу данных из полного архива, созданного в задаче 1. Директорией назначения использовать:

/home/linter/prac4/db_restored.

lhb r –f /home/linter/prac4/db_backup/db_full.lhb –g KBYNTH

–p /home/linter/prac4/db_backup

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

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

/home/linter/prac4/db_restored_inc.

6.6. Пообъектное восстановление

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

Задача 11. Восстановить таблицу LIB_WROTE из архива, созданного в задаче 3.

lhb r –u SYSTEM/MANAGER –f /home/linter/prac4/db_backup/db_lib.lhb –ot LIB_WROTE

Задача 12. (студенты выполняют самостоятельно) Восстановить представление PUPKINS_BOOKS из инкрементного архива, созданного в задаче 4.

6.7. Тестирование архивов

Для проверки правильности архива на резервных носителях, рекомендуется регулярно устраивать тестирование архива. Проверка осуществляется подачей команды t.

Задача 13. Протестировать архив, созданный в задаче 3.

lhb t–f /home/linter/prac4/db_backup/db_lib.lhb

Задача 12. (студенты выполняют самостоятельно) Протестировать архив,

созданный в задаче 1.

40

Практическое занятие 7 Разграничение доступа в СУБД ЛИНТЕР. Мандатный доступ

Практика 2 часа (Лекция 6)

Целью занятия является освоение способов разграничения доступа к базе данных на основе мандатного принципа. Основным инструментом для выполнения задания будет «Интерактивный SQL» (INL). Это позволит лучше разобраться со способами использования КСЗ на уровне запросов. Средства для работы с мандатным доступом есть и в утилитах администрирования lindesk (lindeskx), но их использование более прозрачно.

7.1. Инициализация расширенного КСЗ

Задача: Создать новую БД и инициализировать в ней расширенный КСЗ.

Указания:

1.Создайте новую базу данных.

2.Запустите на ней СУБД ЛИНТЕР.

3.Проинициализируйте поддержку расширенного КСЗ и хранимых процедур/триггеров. Для этого прогоните файлы systab.sql и secutiry.sql (для ЛИНТЕР 5.9 еще необходимо прогнать файл extsec.sql) из директории dict дистрибутива ЛИНТЕР. Для ЛИНТЕР 5.7 после этого необходимо остановить и снова перезапустить ядро, чтобы СУБД «увидела» соответствующие системные таблицы.

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

GRANT ACCESS ON UNLISTED STATION TO ALL;

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

7.2. Создание уровней доступа

Задача: Создать четыре уровня доступа: “НЕСЕКРЕТНО”, “ДСП”, “СЕКРЕТНО”,”СОВ.СЕКРТЕНО”.

Пример запроса:

CREATE LEVEL “ДСП”=2;

7.3. Создание пользователей и назначение им уровней доступа

Задача: Создать следующих пользователей (пароли можно пока оставить пустыми):

Пример:

GRANT DBA TO B;

ALTER USER B LEVEL(“СЕКРЕТНО”,”НЕСЕКРЕТНО”);

Проверьте информацию о созданных пользователях и их уровнях:

SELECT * FROM USER_SECURITY;