15. Проектирование реляционных баз данных. Цели проектирования, основные этапы.

Цели проектирования:

• понизить избыточность данных,

• повысить надежность и достоверность данных (т.е. устранить некоторые аномалии).

Применительно к реляционным базам данных это сводится к решению следующих вопросов:

• какие отношения включать в состав базы данных,

• сколько отношений включить в состав базы данных.

1 этап Проектирование концептуальной модели данных	Выявление информационных потребностей пользователя и их классификация (анализ запросов)
	Анализ предметной области, определение объектов, связей между ними, а также свойств объектов и связей
	Анализ существующих и будущих прикладных программ
	Построение диаграммы объектов-связей
2 этап Проектирование логической модели данных	Построение логической модели данных в соответствии с концептуальной моделью ПО и выбранной реляционной моделью данных СУБД
	Проверка логической модели с помощью правил нормализации
	Выявление и описание ограничений целостности данных
	Построение диаграммы объектов-связей
3 этап Проектирование физической модели данных	Построение физической модели данных в соответствии с логической моделью и выбранной реляционной СУБД
	Определение первичных, альтернативных и внешних ключей
	Реализация ограничений целостности данных
	Построение схемы связей

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

Пример. ПОСТАВКА ИЗДЕЛИЙ (S#, SNAME, CITY, P#, PNAME, PRICE, QTY).

Аномалии при выполнении операций:

• Проблема обновления: если информация дублируется, то при модификации строк возможны ошибки: например, в одной строке изменили стоимость товара, а в другой, где также присутствует информация об этом же товаре, забыли.

• Проблема добавления данных: часть PK может быть = NULL. Пример: если нужно хранить информацию, например, о товаре, который еще никто не поставляет, то ее нельзя включить в данное отношение, так как первичный ключ отношения состоит из двух атрибутов – S# и P#, и атрибуты первичного ключа не могут иметь пустое значение.

• Проблема удаления: возможна потеря данных. Пример: если, например, удаляется информация о некотором товаре, и некоторый поставщик поставляет только один этот товар, вместе с информацией о товаре удалится и информация о поставщике.

Главное требование: гарантированное поддержание целостного состояния БД. В узком смысле, практически полностью проблемы решаются декомпозицией (разбиением таблицы на несколько взаимосвязанных). В широком: приведением БД к нормальным формам. Первые 3 нормальные формы практически полностью решают аномалии представленные выше.

Типы ограничений целостности:

• Внутренние ограничения:

  • Категорная целостность - кортеж не может записываться в БД до тех пор, пока значения его ключевых атрибутов не будут полностью определены. Иными словами: никакой ключевой атрибут любого кортежа отношения не может содержать отсутствующего значения, обозначаемого определителем NULL.

  • Ссылочная целостность - При построении отношений для связывания строк одной таблицы со строками другой таблицы используются внешние ключи. Значение внешнего ключа дочернего отношения должно быть равно одному из текущих значений первичного ключа родительского отношения.

• Явные ограничения:

  • Семантические зависимости: зависимости между атрибутами отношения, определяемые предметной областью, например: сумма бюджетов всех отделов не должна превышать бюджет предприятия;

  • Функциональная зависимость: дополнительные ограничения, накладываемые на реляционную схему; ограничения на значения одних атрибутов в зависимости от значений других атрибутов, например: во всех кортежах, где встречается один и тот же номер товара, название и цена товара также должны быть одними и теми же.

Пример: Если для некоторой схемы R кроме функциональной зависимости PK → R существуют еще и другие, типа A → B, где A → R и B → R, то, вообще говоря, схема отношения R будет характеризоваться некоторой избыточностью.