Совокупность триггеров, реализующих одно требование целостности, будем называть триггерной связкой. Первый вопрос можно переформулировать следующим образом: сколько триггеров должна содержать связка, реализующая требование целостности?
Требование целостности характеризуется множеством контролируемых таблиц tables
tables = {T1, T2, …, Tn} (8)
и множеством операций operations, состав которого зависит от типа требования. Для требования к переходу все операции явно прописываются в описателе (см. (2)). Множество operations требования к состоянию, в принципе, имеет следующий вид:
operations = {ins(T1), upd(T1), del(T1), ins(T2), upd(T2), del(T2), …, ins(Tn), upd(Tn), del(Tn)} (9).
Выделим подмножество operations’, включающее только те операции, выполнение которых может повлечь нарушение требования; также выделим подмножество tables’ – таблицы, которые обрабатываются при выполнении операций из множества operations’. Тогда:
· количество триггеров в связке будет равно мощности множества tables’ – создается по одному триггеру для каждой таблицы;
· на основе анализа множества operations’ определяются наборы триггерных событий.
3. Примеры реализации требований целостности
3.1. Словесное описание требований целостности, реализуемых в БД учета пассажирских перевозок
В БД пассажирских перевозок должны соблюдаться следующие требования целостности:
1) Номер места всегда не меньше 1;
2) Если вагон является купейным, то номер любого места в нем не больше 36.
3.2. Формулирование требований целостности БД учета пассажирских перевозок с помощью описателей
Сущность «Место» отображается на логическую схему базы данных в виде таблицы seats, а атрибут «Номер места» - на столбец seat_number этой таблицы.
Сущность «Вагон» отображается на логическую схему базы данных в виде таблицы coaches, а атрибут «Тип вагона» - на столбец coach_type этой таблицы.
Определить описатель первого требования достаточно просто: если номер места не может быть меньше единицы, то выборка из таблицы seats по условию seat_number < 1 будет всегда пустой:
Второе требование является более сложным, поэтому его описатель лучше определять в несколько этапов. Для начала запишем описатель в общем виде:
Это утверждение о том, что выборка из некоторой таблицы R по условию C(x) является пустой. Теперь остается только раскрыть обозначения R и C(x).
Из словесной формулировки требования очевидно, что речь идет о естественном соединении таблиц seats и coaches. Поэтому:
Атрибут x – это составной атрибут (seat_number, coach_type) отношения R. Учитывая сказанное, переписываем описатель требования целостности в следующем виде:
Теперь необходимо определить условие C(seat_number, coach_type). Все строки таблицы должны удовлетворять условию: если тип вагона купейный, то номер места не больше (т. е. меньше либо равен) 36. Это условие имеет вид , что эквивалентно выражению . В таблице не должно быть ни одной строки, где это условие не соблюдается, т. е. где истинно противоположное условие: .
Полученное выражение есть не что иное, как искомое условие C(seat_number, coach_type), где:
В итоге описатель требования целостности выглядит следующим образом:
Оба требования целостности являются требованиями к состоянию.
3.3. Программная реализация требований целостности БД учета пассажирских перевозок
Первое требование легко реализуется с помощью ограничения целостности check, накладываемого на столбец seat_number таблицы seats. Условие целостности: seat_number >= 1.
Для реализации второго требования нужны триггеры. Требование связывает две таблицы. Нарушение условия требования может произойти при выполнении следующих операций:
· ins(seats) – так как место при добавлении может иметь значение больше 36 и привязываться к купейному вагону;
· upd(seats) – так как при обновлении строк в этой таблице могут измениться номера мест, в т. ч. и мест, закрепленных за купейными вагонами;
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.