| | В качестве примера рассмотрим таблицу ПРОДАЖИ, которая содержит: · сведения о покупателях; · дату заказа и количество заказанного товара; · дату выполнения заказа и количество проданного товара; · характеристику проданного товара (наименование, стоимость, категория). Таблицу ПРОДАЖИ можно рассматривать как однотабличную базу данных. |
| |  Рис.1.1. Однотабличная база данных ПРОДАЖИ. |
| Проблемы избыточности данных | Основной недостаток однотабличной базы данных состоит в том, что в ней содержится значительное количество повторяющейся информации. Такая избыточность данных ведет к возникновению следующих проблем: 1. Потребуется значительное время на ввод повторяющихся данных. 2. Наличие повторяющейся информации приведет к неоправданному увеличению базы данных. В результате снизится скорость выполнения запросов. 3. При многократном вводе повторяющихся данных возрастает вероятность ошибки. При больших размерах таблиц поиск ошибок будет занимать значительное время. Процесс уменьшения избыточности информации в БД называется нормализацией. В теории нормализации разработаны достаточно формализованные подходы к разбиению данных на несколько таблиц и организации между ними взаимосвязей. |
| Теория нормализации | Теория нормализации оперирует с пятью нормальными формами отношений (от 1НФ до 5НФ включительно). Эти формы предназначены для уменьшения избыточной информации, при этом каждая последующая нормальная форма должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются, поэтому ограничимся рассмотрением первых трех нормальных форм. |
| Первичный ключ | В таблице ПРОДАЖИ поле КодПокуп может быть выбран в качестве первичного ключа (primary key, РК). Значению поля КодПокуп соответствуют: · единственные значения полей Фамилия, Имя, Отчество, Телефон, Индекс, Страна, Область, Город, Адрес, Предпр, Руководит, Кредит; · N значений полей КодТов, ДатаЗаказ, Заказано, ДатаПрод, Продано, Цена, Категория, НаимТов (где N - количество заказов у данного покупателя). |
| 1НФ | Отношение имеет первую нормальную форму (1НФ), если оно удовлетворяет следующим требованиям: 1) отношение должно иметь уникальный первичный ключ; 2) должна иметься однозначная зависимость каждого атрибута отношения от первичного ключа; 3) должны отсутствовать повторяющиеся группы атрибутов. Для устранения повторяющихся групп (каждый покупатель может иметь N заказов) разобьем таблицу ПРОДАЖИ на две таблицы (Рис.1.2): · таблицу ПОКУПАТЕЛЬ, каждая строка которой содержит сведения об одном из покупателей; · таблицу ЗАКАЗ, каждая строка которой содержит сведения об одном из N заказов каждого из покупателей. |
| N | Рис.1.2. База данных "Продажи" в 1НФ |
| | Для таблицы ПОКУПАТЕЛЬ создается простой первичный ключ, основанный на поле КодПокуп. Для исключения повторяющихся записей в таблице ЗАКАЗ следует образовать составной первичный ключ, содержащий поля КодПокуп, КодТовара и ДатаЗаказ. |
| 2НФ | Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и не содержит неполных функциональных зависимостей (ФЗ). Неполная ФЗ - это две зависимости: 1) ключ таблицы определяет некоторый ее неключевой атрибут; 2) часть ключа определяет этот же неключевой атрибут. Из определения следует, что понятие 2НФ применимо только к отношениям, имеющим составной ключ. Таблица ЗАКАЗ, имеющая составной ключ, не находится в 2НФ, поскольку неключевые поля НаимТов, Цена и Категория однозначно определяются частью составного ключа КодТовара (рис. 2.3). Т.е. имеется неполная ФЗ. Для приведения таблицы к 2НФ выделим из таблицы ЗАКАЗ таблицу ТОВАРЫ, которая будет содержать информацию о товарах каждого типа. |
 Рис.1.3. База данных "Продажи" в 2НФ |
3НФ
| Отношение имеет третью нормальную форму (3НФ), если оно соответствует 2НФ и среди его атрибутов отсутствуют транзитивные ФЗ. Транзитивные ФЗ - это две зависимости: 1) ключ отношения определяет некоторый неключевой атрибут; 2) этот неключевой атрибут определяет другой неключевой атрибут. В таблице ПОКУПАТЕЛЬ (рис. 2.4) неключевое поле Руководит содержит имена руководителей компаний, которые однозначно определяются другим неключевым полем Предпр. Т.е. существует транзитивная ФЗ. Для приведения таблицы ПОКУПАТЕЛЬ к 3НФ создается новая таблица КОМПАНИЯ. |
| Рис.1.4. База данных "Продажи" в 3НФ |
| | Требование нормализации всех таблиц в реляционной базе данных не является обязательным. Разбить таблицу на более мелкие (теоретически - свести ее к 3НФ) практически может потребоваться в следующих случаях: · некоторая информация из этой таблицы используется не очень часто; · нельзя давать доступ к некоторым данным любым желающим |
| | Внешний ключ (foreign key, FK) - это поле в таблице, которое соответствует первичному ключу в другой таблице. Поскольку у каждого клиента может быть несколько заказов, а каждый заказ принадлежит только одному клиенту, то между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ устанавливается связь один-ко-многим. Поскольку каждый товар может присутствовать в нескольких заказах, а каждый заказ связан только с одним товаром, то между таблицами ТОВАРЫ и ЗАКАЗ также устанавливается связь один-ко-многим. Между таблицами ПОКУПАТЕЛЬ и КОМПАНИЯ существует связь один-к-одному, поскольку компания, в которой работает покупатель, имеет одно определенное руководство. |
| | Использование внешних ключей обеспечивает эффективность работы приложений: 1. Поддержка соответствующих значений первичного и внешнего ключа обеспечивает целостность данных: · реляционная база данных не позволит добавить в таблицу строку, если заданное в ней значение внешнего ключа не совпадает ни с одним значением соответствующего первичного ключа, например, в таблицу ЗАКАЗ нельзя ввести строку с неправильным полем КодПокуп - т.е. хранить заказы для несуществующих покупателей; · реляционная база данных не позволит удалить из таблицы строку с первичным ключом, если в базе с этим же значением имеется соответствующий внешний ключ, например, в таблице ПОКУПАТЕЛЬ нельзя удалить запись о покупателе, у которого имеются заказы - т.е. имеются соответствующие ему строки в таблице ЗАКАЗ. 2. Задаваемые при создании таблиц связи первичных ключей с внешними ключами используются для объединения данных из нескольких таблиц. Внешний ключ позволяет реализовать операцию поиска парных строк между таблицами. Например, объединяя таблицы ПОКУПАТЕЛЬ и КОМПАНИЯ с помощью внешнего ключа Предпр, можно получить полную информацию о покупателе. |
