Использование триггеров

Триггер представляет собой процедуру, которая находится на сервере БД и вызывается автоматически при модификации записей БД, т. е. при изменении столбцов или при их удалении и добавлении. В отличие от хранимых процедур, триггеры нельзя вызывать из приложения клиента, а также передавать им параметры и получать от них результаты.
Триггер цо своей сути похож на обработчики событий BeforeEdit, AfterEdit, Beforelnsert, Afterlnsert, BeforeDelete и AfterDelete, связанных с модификацией таблиц. Триггер может вызываться при редактировании, добавлении или удалении записей до и/или после этих событий.

 

 

 

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

  • «Ссылочная целостность в реляционной базе данных – это согласованность между связанными таблицами. Ссылочная целостность обычно поддерживается путем комбинирования первичного ключа и внешнего ключа. Для соблюдения ссылочной целостности требуется, чтобы любое поле в таблице, объявленное внешним ключом, могло содержать только значения из поля первичного ключа родительской таблицы …» [5]
  • «[Ссылочная целостность – это] свойство, обеспечиваемое реляционными системами управления базами данных (РСУБД), которое предотвращает ввод несогласованных данных пользователями или приложениями. В большинстве РСУБД имеются различные правила ссылочной целостности, которые можно применить при создании связи между двумя таблицами.» [6]
  • «[Ссылочная целостность – это] предохранительное устройство системы управления базами данных, гарантирующее, что каждый внешний ключ соответствует первичному ключу. Например, номера заказчиков являются первичными ключами в файле заказчиков и внешними ключами в файле заказов. При удалении записи заказчика должны быть удалены соответствующие записи заказов; в противном случае они останутся без исходной связи. Если СУБД не проверяет этого, соответствующий механизм должен программироваться в приложении.» [7]

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

  • Улучшенное качество данных. Очевидным преимуществом является поддержка качества данных, хранимых в базе данных. Ошибки могут по-прежнему существовать, но, по крайней мере, ссылки будут подлинными и неповрежденными.
  • Убыстрение разработки. Ссылочная целостность объявляется. Это гораздо продуктивнее (на один или два порядка), чем написание специального программного кода.
  • Меньшее число ошибок. Объявления ссылочной целостности являются гораздо более лаконичными, чем эквивалентный программный код. По существу, такие объявления приводят к повторному использованию проверенного и оттестированного кода общего назначения в сервере баз данных, а не к новой реализации одной и той же логики от случая к случаю.
  • Согласованность между приложениями. Ссылочная целостность обеспечивает качество данных для нескольких прикладных программ, которые могут обращаться к базе данных.

Методические основы проектирования серверной части приложения

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

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

Концептуальное проектирование базы данных включает в себя следующие этапы:
1)Создание локальной концептуальной модели данных.
2)Определение типов сущностей.
3)Определение атрибутов.
4)Определение типов связей.
5)Проверка модели на избыточность.
6)Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.
7)Обсуждение локальных концептуальных моделей данных с конечными пользователями.
8)Создание локальной концептуальной модели данных. Целью дан­ного этапа является определение предметной области и состава пользователей разрабатываемой базы данных.

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

Логическое проектирование базы данных (для реляционной модели) включает в себя следующие этапы.
1)Создание и проверка локальной логической модели данных на основе представления предметной области каждого из типов пользователей
2)Устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап).
3)Определение набора отношений исходя из структуры локаль­ ной логической модели данных.
4)Проверка отношений с помощью правил нормализации таб­ лиц.
5)Проверка соответствия отношений требованиям пользова­ тельских транзакций.
6)Определение требований поддержки целостности данных.
7)Обсуждение разработанных локальных логических моделей данных с конечными пользователями.
8)Создание и проверка глобальной логической модели данных.
9)Слияние локальных логических моделей данных в единую глобальную модель данных.
10)Проверка глобальной логической модели данных.
11)Проверка возможностей расширения модели в будущем
12)Обсуждение глобальной логической модели данных с пользователями.

Физическое проектирование базы данных предусматривает при­нятие разработчиками окончательного решения о способах реа­лизации создаваемой базы данных в условиях применения конк­ретной СУБД.

Физическое проектирование базы данных (для реляционной модели) включает в себя следующие этапы.
1)Перенос глобальной логической модели данных в среду целевой СУБД.
2)Проектирование базовых отношений в среде целевой СУБД.
3)Проектирование отношений, содержащих производные данные.
4)Реализация ограничений предметной области.
5)Проектирование физического представления базы данных.
6)Анализ транзакций.
7)Выбор файловой структуры.
8)Определение индексов.
9)Определение требований к дисковой памяти.
10)Разработка пользовательских представлений.
11)Разработка механизмов защиты.
12)Анализ необходимости введения контролируемой избыточ­ности.
13)Организация мониторинга и настройка функционирования операционной системы.