Нормализация базы данных и ее необходимость — КиберПедия 

Индивидуальные и групповые автопоилки: для животных. Схемы и конструкции...

Таксономические единицы (категории) растений: Каждая система классификации состоит из определённых соподчиненных друг другу...

Нормализация базы данных и ее необходимость

2017-08-23 299
Нормализация базы данных и ее необходимость 0.00 из 5.00 0 оценок
Заказать работу

  В качестве примера рассмотрим таблицу ПРОДАЖИ, которая содержит: · сведения о покупателях; · дату заказа и количество заказанного товара; · дату выполнения заказа и количество проданного товара; · характеристику проданного товара (наименование, стоимость, категория). Таблицу ПРОДАЖИ можно рассматривать как однотабличную базу данных.
  Рис.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НФ) практически может потребоваться в следующих случаях: · некоторая информация из этой таблицы используется не очень часто; · нельзя давать доступ к некоторым данным любым желающим

 


Внешний ключ

Результатом нормализации является получение базы данных в виде набора отдельных таблиц. В схеме данных особенно важно определить, как будут взаимодействовать различные таблицы. В реляционной базе данных связь между таблицами устанавливается с помощью связующих полей (см. Рис.1.5).  
   
PK
FK
FK
PK
FK
PK

Рис.1.5. Многотабличная база данных с эффективной структурой

 

  Внешний ключ (foreign key, FK) - это поле в таблице, которое соответствует первичному ключу в другой таблице. Поскольку у каждого клиента может быть несколько заказов, а каждый заказ принадлежит только одному клиенту, то между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ устанавливается связь один-ко-многим. Поскольку каждый товар может присутствовать в нескольких заказах, а каждый заказ связан только с одним товаром, то между таблицами ТОВАРЫ и ЗАКАЗ также устанавливается связь один-ко-многим. Между таблицами ПОКУПАТЕЛЬ и КОМПАНИЯ существует связь один-к-одному, поскольку компания, в которой работает покупатель, имеет одно определенное руководство.  
  Использование внешних ключей обеспечивает эффективность работы приложений: 1. Поддержка соответствующих значений первичного и внешнего ключа обеспечивает целостность данных: · реляционная база данных не позволит добавить в таблицу строку, если заданное в ней значение внешнего ключа не совпадает ни с одним значением соответствующего первичного ключа, например, в таблицу ЗАКАЗ нельзя ввести строку с неправильным полем КодПокуп - т.е. хранить заказы для несуществующих покупателей; · реляционная база данных не позволит удалить из таблицы строку с первичным ключом, если в базе с этим же значением имеется соответствующий внешний ключ, например, в таблице ПОКУПАТЕЛЬ нельзя удалить запись о покупателе, у которого имеются заказы - т.е. имеются соответствующие ему строки в таблице ЗАКАЗ. 2. Задаваемые при создании таблиц связи первичных ключей с внешними ключами используются для объединения данных из нескольких таблиц. Внешний ключ позволяет реализовать операцию поиска парных строк между таблицами. Например, объединяя таблицы ПОКУПАТЕЛЬ и КОМПАНИЯ с помощью внешнего ключа Предпр, можно получить полную информацию о покупателе.  

 



Поделиться с друзьями:

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰)...

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

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого...

Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.007 с.