- •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, в которую будут помещаться копии обновленных записей, удовлетворяющих условиям отбора.