Информационные системы
Шрифт:
В основе процесса проектирования лежит метод нормализации – декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение которого однозначно определяется значением другого атрибута. Функционально зависимые атрибуты обозначаются следующим образом: X —> Y. Эта запись означает, что если два кортежа в таблице имеют одно и то же значение
Примечание.
Первичный ключ таблицы является детерминантом, так как его значение однозначно определяет значение любого атрибута таблицы.
Первая нормальная форма
Ограничение первой нормальной формы – значения всех атрибутов отношения должны быть атомарными. Данное требование является базовым требованием классической реляционной модели данных, поэтому любая реляционная таблица (в том числе и таблица, структура которой изображена на рис. 4.2), по определению, уже находится в первой нормальной форме.
Вторая нормальная форма
Отношение находится во второй нормальной форме в том и только в том случае, если это отношение находится в первой нормальной форме и каждый неключевой атрибут полностью зависит от первичного ключа.
Примечание.
Неключевым называется любой атрибут отношения, не входящий в состав первичного ключа.
Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги.
1. Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (причем эти части могут содержать несколько атрибутов).
2. Создать новую таблицу для каждой такой части ключа и группы зависящих от нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа станет при этом первичным ключом новой таблицы.
3. Удалить из исходной таблицы поля, перемещенные в другие таблицы, кроме тех из них, которые станут внешними ключами.
В нашем примере для приведения таблицы СОТРУДНИКИ ко второй нормальной форме ее следует разделить на две таблицы. Первичный ключ исходной таблицы состоит из двух атрибутов – Код сотрудника и Должность. Все же личные данные о сотрудниках зависят только от атрибута Код сотрудника. Атрибуты, соответствующие этим данным, мы и выделим в качестве одной из таблиц, которую назовем ФИЗИЧЕСКИЕ ЛИЦА. Информацию же о должностях и их оплате вынесем в другую таблицу, которой присвоим имя СОТРУДНИКИ. Схема приведения таблицы ко второй нормальной форме приведена на рис. 4.3.
Рис. 4.3. Приведение таблицы ко второй нормальной форме.
Полученные две таблицы связаны между собой по полю Код физического лица, которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом для таблицы СОТРУДНИКИ. Данное поле отсутствовало в исходной таблице и было добавлено при проведении нормализации.
Третья нормальная форма
Рассмотрим таблицу СОТРУДНИКИ, полученную после приведения исходной таблицы ко второй нормальной форме. Для этой таблицы существует функциональная связь между полями Код сотрудника и Зарплата. Однако эта функциональная связь является транзитивной.
Примечание.
Функциональная зависимость атрибутов X и Y отношения R называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости X -> Z и Z -> Y, но отсутствует функциональная зависимость Z -> X.
Транзитивность
Отношение R находится в третьей нормальной форме в том и только том случае, если оно находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги.
1. Определить все поля (или группы полей), от которых зависят другие поля.
2. Создать новую таблицу для каждого такого поля (или группы полей) и группы зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей), от которого зависят все остальные перемещенные поля, станет при этом первичным ключом новой таблицы.
3. Удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешними ключами.
Приведем рассматриваемую в качестве примера базу данных к третьей нормальной форме. Для этого разделим таблицу СОТРУДНИКИ на две – СОТРУДНИКИ и ДОЛЖНОСТИ (рис. 4.4).
Рис. 4.4. Приведение базы данных к третьей нормальной форме.
Примечание.
Обратите внимание, что мы опять добавили новый атрибут Код должности, который является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отношения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет получить таблицы с простыми первичными ключами, что облегчает выполнение операции связывания таблиц. Такие первичные ключи, как правило, являются искусственными.
На практике третья нормальная форма схем отношений в большинстве случаев достаточна, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Поэтому мы не будем рассматривать другие нормальные формы, тем более что в работе они используются сравнительно редко.
В заключение приведем схему базы данных, рассматриваемой в качестве примера и приведенной к третьей нормальной форме (рис. 4.5).
Рис. 4.5. Структура базы данных, приведенной к третьей нормальной форме.
Глава 5Управление реляционными базами данных
Использование реляционных баз данных возможно только при наличии эффективных средств управления ими. Поэтому после публикаций статей Кодда, предлагающих реляционную модель данных, стали активно проводиться исследования по созданию языков управления реляционными данными. В результате этих исследований был предложен ряд таких языков, среди которых следует отметить три:
• SQL (Structured Query Language – структурированный язык запросов);