Триггер представляет собой процедуру, которая находится на сервере БД и вызывается автоматически при модификации записей БД, т. е. при изменении столбцов или при их удалении и добавлении. В отличие от хранимых процедур, триггеры нельзя вызывать из приложения клиента, а также передавать им параметры и получать от них результаты.
Триггер цо своей сути похож на обработчики событий 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)Организация мониторинга и настройка функционирования операционной системы.
|
|