· upd(coaches) – при выполнении этой операции может измениться тип вагона, в т. ч. и вагона, в котором более 36 мест.
Перечисленные операции являются триггерными событиями в таблицах seats и coaches. Необходимо создать по одному триггеру для каждой из этих таблиц. Оставшиеся операции – del(seats), ins(coaches) и del(coaches) не нарушают истинности условия требования.
Триггеру, создаваемому для таблицы seats, зададим имя tr_seat_num. Он должен запускаться после вставки или обновления строк таблицы. Алгоритм его работы следующий:
· выполняется выборка ;
· если выборка не пуста, значит, истинность условия нарушена, - требуется откатить транзакцию.
Ниже представлен исходный текст триггера tr_seat_num и тестовые примеры для демонстрации его работы.
--триггер на добавление и модификацию в таблице мест
create trigger tr_seat_num
on seats
for insert, update
as
if exists (select * from coaches, seats
where coach_type = 'Купе'
and seat_number > 36
and coaches.id_coach = seats.id_coach)
rollback tran
--проверка триггера
insert into seats values(37, 'в', 1)
insert into seats values(0, 'в', 1)
insert into seats values(-36, 'в', 1)
update seats set seat_number = 38 where seat_number = 36
select * from seats
Имя второго триггера – tr_coach_seat_num. Он реагирует на обновление записей в таблице coaches и запускается после выполнения этой операции. Алгоритм его работы аналогичен алгоритму tr_seat_num.
create trigger tr_coach_seat_num
on coaches
for update
as
if exists (select * from coaches, seats
where coach_type = 'Купе'
and seat_number > 36
and coaches.id_coach = seats.id_coach)
rollback tran
--проверка триггера
--меняем тип вагона с купе на плацкарт
update coaches set coach_type = 'Плацкарт' where id_train = 1 and coach_number = 18
--добавляем место, которое раньше нельзя было добавить
insert into seats values(37, 'нб', 18)
-- в ответ на следующий запрос срабатывает триггер: мест стало больше 36, поэтому тип вагона нельзя менять на купейный.
update coaches set coach_type = 'Купе' where id_train = 1 and coach_number = 18
4. Программа работы
1. Моделирование требований целостности, заданных преподавателем, с применением формальных описателей.
2. Программная реализация требований целостности в БД.
3. Проверка правильности функционирования разработанных объектов-ограничений.
1. Изучить основные сведения из теории.
2. Составить формальные описатели требований целостности, предложенных в индивидуальном задании.
3. Разработать программную реализацию требований целостности в БД.
4. Проверить работоспособность разработанных объектов-ограничений.
6. Литература
1. Дейт К. Дж. Введение в системы баз данных; пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. – 848 с.: ил. – Парал. тит. лист. англ., уч. пос. – ISBN 5-8459-0019-0.
2. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс; пер. с англ. – М.: Издательский дом «Вильямс», 2004. – 1088 с. – ISBN 5-8459-0384-X.
3. Применение формальных описателей для логико-алгебраического моделирования требований целостности информации в реляционных базах данных: статья/ М. Л. Глухарев //Петербургский государственный университет путей сообщения. Известия/ гл. ред. В. И. Ковалев. - СПб: ПГУПС, 2010. - Вып. 4 (25). - с. 78-88.
4. Михеев Р. Н. MS SQL Server 2005 для администраторов. – СПб.: БХВ-Петербург, 2006. – 544 с.: ил.
5. Мамаев Е. В. Microsoft ® SQL Server 2000. – СПб.: БХВ-Петербург, 2004. – 1280 с.: ил.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.