
- •9.1. Сравнение этапов логического и физического проектирования баз данных
- •9.2. Общий обзор методологии физического проектирования баз данных
- •9.3. Методология физического проектирования баз данных реляционного типа
- •Этап 4. Перенос глобальной логической модели данных в среду целевой субд Цель Создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.
- •Этап 4.1. Проектирование таблиц базы данных в среде целевой субд Цель Определение способа представления в целевой субд отношений, выделенных в глобальной логической модели данных.
- •1. Описание на языке sql стандарта is01992 (sql2)
- •2. Реализация с использованием триггеров
- •3. Реализация в среде субд ingres 6.4
- •4.Реализация с использованием уникальных индексов
- •Документирование проекта таблиц базы данных
- •Этап 4.2. Реализация бизнес-правил предприятия в среде целевой субд Цель Реализация бизнес-правил в среде целевой субд.
- •Документирование проекта реализации бизнес-правил
- •Понятие о системных ресурсах
- •Этап 5.1. Анализ транзакций Цель Определение функциональных характеристик транзакций, которые будут выполняться в проектируемой базе данных, и выделение наиболее важных из них.
- •Карты выполнения транзакций
- •Этап 5.2. Выбор файловой структуры Цель - Определение наиболее эффективного файлового представления для каждой из таблиц базы данных.
- •Последовательные файлы
1. Описание на языке sql стандарта is01992 (sql2)
Если целевая СУБД поддерживает язык SQL в пределах стандарта ISO 1992, обсуждению которого посвящены главы 13 и 14 этой книги, то реализация таблиц базы данных будет представлять собой относительно простую задачу. Например, реализация таблицы Property_for_Rent осуществляется с помощью серии операторов языка SQL, показанной в листинге 9.2.
Д
анная
таблица имеет те же имена атрибутов и
типы доменов, которые были использованы
в описании таблицы на языке DLBL, приведенном
в листинге 9.1. Первичным ключом таблицы
объявлен атрибут номера объекта - Pno.
Средства SQL будут автоматически
поддерживать уникальность значений
этого атрибута. В таблице определены
три внешних ключа, для каждого из которых
указаны требуемые ограничения поддержки
ссылочной целостности. Например, атрибут
номера работника - Sno -
является внешним ключом таблицы,
представляющим ее связь с таблицей
Staff. Для этого ключа
установлено правило удаления (on
delete SET NULL),
указывающее, что в случае удаления
некоторого номера работника из таблицы
Staff, соответствующие
значения в атрибуте Sno таблицы
Property_for_Rent
должны быть заменены значением NULL.
Атрибут номера владельца — Ono
— является внешним ключом таблицы,
представляющим ее связь с таблицей
Owner. Для этого ключа
установлено правило обновления (on
update CASCADE),
указывающее, что в случае изменения
некоторого номера владельца в таблице
Staff соответствующие
значения в атрибуте Ono таблицы
Property_for_Rent
должны быть заменены новым значением
(т.е. обновлены каскадно). Кроме того,
при описании таблицы указано несколько
значений, присваиваемых некоторым
атрибутам по умолчанию — например,
атрибуту Type по умолчанию
будет присваиваться значение 'F''
(означающее "Flat" —
"квартира").
2. Реализация с использованием триггеров
Некоторые СУБД, например Oracle, позволяют использовать триггеры. Триггером называют действие, связанное с событием, вызвавшим изменение в содержимом таблицы. В СУБД Oracle три типа событий вызывают запуск триггеров — это попытки вставить (INSERT), обновить (UPDATE) или удалить (DELETE) один из кортежей (записей, строк) таблицы. Триггеры могут использоваться для организации или расширения поддержки ссылочной целостности данных, для реализации сложных бизнес-правил и контроля за внесением в данные изменений. Приведенный ниже пример демонстрирует, как в среде СУБД Oracle можно организовать контроль за внесением в атрибут Rent таблицы Property_for_Rent изменений, превышающих десять процентов исходного значения.
CREATE TRIGGER property_before_update
BEFORE UPDATE ON property_for_rent
FOR EACH ROW
WHEN (NEW.rent/OLD.rent>l.l)
BEGIN
INSERT INTO property_for_rent_audit
VALUES (:OLD.pno, :OLD.street, :OLD.area, :OLD.city, :OLD.pcode,
:OLD.type, :OLD.rooms, :OLD.rent, :OLD.ono, :OLD.sno, :OLD.bno)
END
В этом примере для таблицы Property_for_Rent создается триггер типа before update (Перед обновлением). Как следует из его названия, предусмотренные этим триггером действия, будут выполняться до фиксации в базе данных результатов выполнения транзакций обновления. Команды между ключевыми словами BEGIN и END будут выполняться при каждом обновлении строки в таблице Property_for Rent, которое удовлетворяет условию, указанному в предложении WHEN. Этот триггер предполагает существование таблицы с именем Property_for_Rent_Audit, в которую будут помещаться копии обновленных записей, удовлетворяющих условиям отбора.