admin / 01.03.2018

3 нормальная форма

Последний пост про нормальные формы, перевод книги PHP 6 and MySQL 5 for Dynamic Web Sites. Предыдущие три вынесены ссылками в конце поста.

Содержание

Третья нормальная форма.

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

Возьмём, как образец, одиночную таблицу, которая хранит некую информацию о бизнес клиентах: имя, фамилию, телефон, адрес, город, штат, почтовый индекс и все в этом духе.  Такая таблица не будет находится в 3НФ, поскольку тут много полей будет взаимозависимо — улица будет зависеть от города, город от штата, почтовый индекс тоже под вопросом. Все эти поля будут подчинены друг другу, а не человеку, к которому относится эта запись.

Чтобы нормализовать такую базу, нужно создать по таблице для штатов, городов (с внешним ключом, ведущим в таблицу штатов) и для почтовых кодов. Все они будут ссылаться назад на клиентскую таблицу.

Если вы чувствуете, что все эти действия могут быть излишними, вы правы.  Честно, в верхних уровнях нормализации часто нет необходимости.  Смысл в том, что нужно стараться нормализовать базу данных, но иногда приходиться идти на уступки ради того, чтобы не допустить чрезмерного усложнения. Потребности приложения и структура данных в базе подскажут, насколько потребуется проводить процесс нормализации.

Как уже говорилось,  пример с форумом уже достаточно нормализован, но все равно опишем шаги для нормализации для третьей нормальной формы, показав как исправить пример с клиентами.

Чтобы привести базу к третьей нормальной форме, надо:

1. Определить, в каких полях каких таблиц имеется взаимозависимость. Как только что говорилось, поля, которые зависят больше друг от друга (как город от штата), чем от ряда в целом. В базе форума такой проблемы нет. Взглянув на таблицу сообщений, увидите, что каждый заголовок, каждое тело сообщения относится к своему message ID.

2. Создайте соответствующие таблицы. Если есть проблемный столбец в шаге 1, создавайте раздельные таблицы для него. Как города и штаты, в примере с клиентами.

3. Создайте или выделите первичные ключи. Каждая таблица должна иметь первичный ключ. Для примера с клиентами это будут city ID и state ID.

4. Создайте необходимые внешние ключи, которые образуют любое из отношений. В нашем примере нужно добавить state ID в таблицу городов и city ID в таблицу клиентов. Это свяжет каждого клиента с городом и штатом, где они живут.

Рассмотренная в качестве примера база данных с записями о клиентах, созданы две новых таблицы для хранения информации о городах и штатах.

Подсказки:

Вообще, можно было бы и не нормализовывать базу с клиентами до такой степени. Если оставить города и штаты в таблице клиентов, самое страшное, что могло бы случиться — если бы город изменил название, нужно было бы менять его во всех записях о клиентах, которые живут в этом городе. Но города редко меняют свои имена.

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

Нарушения правил нормализации

Убедившись, что база данных в 3НФ поможет гарантировать надёжность и жизнеспособность, не нужно полностью нормализовывать все базу, с которыми вы работаете. Перед тем, как использовать эти методы, имейте ввиду, что это может иметь долгосрочные разрушающие последствия.

Две основных причины, чтобы нарушить правила нормализации — удобство и быстродействие. Меньшим число таблиц проще управлять, чем большим. Кроме того, из-за более сложного характера, нормализованные таблицы более медленные для обновления, изменения и выдачи данных. Вкратце, нормализация это сделка между целостностью/расширяемостью и простотой/скоростью. С другой стороны, есть достаточно способов чтобы улучшить производительность базы данных, но не так много способов чтобы исправить повреждённые данные, возникшие из-за плохого дизайна структуры.

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

Ссылки:

  1. Введение
  2. Первая нормальная форма
  3. Вторая нормальная форма
  4. Вики о нормализации
  5. Mysql Workbench — программа для проектирования баз данных



4.2.1.Функциональные зависимости.

Реляционная база данных содержит как структурную, так и семантическую информацию. Структура базы данных определяется числом и видом включенных в нее отношений, и связями типа «один ко многим», существующими между кортежами этих отношений. Семантическая часть описывает множество функциональных зависимостей, существующих между атрибутами этих отношений. Дадим определение функциональной зависимости.

Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения.

Можно сказать, что функциональные зависимости представляют собой связи типа «один ко многим», существующие внутри отношения.

Некоторые функциональные зависимости могут быть нежелательны.

Корректной считается такая схема базы данных, в которой отсутствуют избыточные функциональные зависимости. В противном случае приходится прибегать к процедуре декомпозиции (разложения) имеющегося множества отношений. При этом порождаемое множество содержит большее число отношений, которые являются проекциями отношений исходного множества. (Операция проекции описана в разделе, посвященном реляционной алгебре). Обратимый пошаговый процесс замены данной совокупности отношений другой схемой с устранением избыточных функциональных зависимостей называется нормализацией.

Условие обратимости требует, чтобы декомпозиция сохраняла эквивалентность схем при замене одной схемы на другую, т.е. в результирующих отношениях:

  • не должны появляться ранее отсутствовавшие кортежи;
  • на отношениях новой схемы должно выполняться исходное множество функциональных зависимостей.

4.2.2. 1NF — первая нормальная форма.

Для обсуждения первой нормальной формы необходимо дать два определения:

Теперь можно дать

 

Для приведения исходного отношения СЛУЖАЩИЙ к первой нормальной форме необходимо декомпозировать его на четыре отношения, так как это показано на следующем рисунке:
 

Здесь первичный ключ каждого отношения выделен синей рамкой, названия внешних ключей набраны шрифтом синего цвета. Напомним, что именно внешние ключи служат для представления функциональных зависимостей, существующих в исходном отношении. Эти функциональные зависимости обозначены линиями со стрелками.

Алгоритм нормализации описан Е.Ф.Коддом следующим образом:

  • Начиная с отношения, находящегося на верху дерева (рис. 4.3.), берется его первичный ключ, и каждое непосредственно подчиненное отношение расширяется путем вставки домена или комбинации доменов этого первичного ключа.
  • Первичный Ключ каждого расширенного таким образом отношения состоит из Первичного Ключа, который был у этого отношения до расширения и добавленного Первичного Ключа родительского отношения.
  • После этого из родительского отношения вычеркиваются все непростые домены, удаляется верхний узел дерева, и эта же процедура повторяется для каждого из оставшихся поддеревьев.

4.2.3. 2NF — вторая нормальная форма.

Очень часто первичный ключ отношения включает несколько атрибутов (в таком случае его называют составным) — см., например, отношение ДЕТИ, показанное на рис. 4.4. При этом вводится понятие полной функциональной зависимости.

 
Пример:

Пусть имеется отношение ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР,  ЦЕНА).
Поставщик может поставлять различные товары, а один и тот же товар может поставляться разными поставщиками. Тогда ключ отношения — «N_поставщика + товар». Пусть все поставщики поставляют товар по одной и той же цене. Тогда имеем следующие функциональные зависимости:

  • N_поставщика, товар -> цена
  • товар -> цена

Неполная функциональная зависимость атрибута «цена» от ключа приводит к следующей аномалии: при изменении цены товара необходим полный просмотр отношения для того, чтобы изменить все записи о его поставщиках.

Данная аномалия является следствием того факта, что в одной структуре данных объединены два семантических факта. Следующее разложение дает отношения во 2НФ:

  • ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР)
  • ЦЕНА_ТОВАРА (ТОВАР, ЦЕНА)

Таким образом, можно дать


4.2.4. 3NF — третья нормальная форма.

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

 
Пусть имеется отношение ХРАНЕНИЕ (ФИРМА, СКЛАД, ОБЪЕМ), которое содержит информацию о фирмах, получающих товары со складов, и объемах этих складов. Ключевой атрибут — «фирма». Если каждая фирма может получать товар только с одного склада, то в данном отношении имеются следующие функциональные зависимости:

  • фирма -> склад
  • склад -> объем

При этом возникают аномалии:

  • если в данный момент ни одна фирма не получает товар со склада, то в базу данных нельзя ввести данные о его объеме (т.к. не определен ключевой атрибут)
  • если объем склада изменяется, необходим просмотр всего отношения и изменение кортежей для всех фирм, связанных с данным складом.

Для устранения этих аномалий необходимо декомпозировать исходное отношение на два:

  • ХРАНЕНИЕ (ФИРМА, СКЛАД)
  • ОБЪЕМ_СКЛАДА (СКЛАД, ОБЪЕМ)

 


4.2.5. BCNF — нормальная форма Бойса-Кодда.

Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ.

Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.


4.2.6. Многозначные зависимости и четвертая нормальная форма (4NF).

Четвертая нормальная форма касается отношений, в которых имеются повторяющиеся наборы данных. Декомпозиция, основанная на функциональных зависимостях, не приводит к исключению такой избыточности. В этом случае используют декомпозицию, основанную на многозначных зависимостях.

Многозначная зависимость является обобщением функциональной зависимости и рассматривает соответствия между множествами значений атрибутов.

В качестве примера рассмотрим отношение ПРЕПОДАВАТЕЛЬ (ИМЯ, КУРС, УЧЕБНОЕ_ПОСОБИЕ), хранящее сведения о курсах, читаемых преодавателем, и написанных им учебниках. Пусть профессор N читает курсы «Теория упругости» и «Теория колебаний» и имеет соответствующие учебные пособия, а профессор K читает курс «Теория удара» и является автором учебников «Теория удара» и «Теоретическая механика». Тогда наше отношение будет иметь вид:

—————————————————- | ИМЯ | КУРС | УЧЕБНОЕ_ПОСОБИЕ | —————————————————- | N | Теория упругости | Теория упругости | | N | Теория колебаний | Теория упругости | | N | Теория упругости | Теория колебаний | | N | Теория колебаний | Теория колебаний | | K | Теория удара | Теория удара | | K | Теория удара | Теоретическая механика | —————————————————- добавляем: —————————————————- | K | Теория упругости | Теория удара | | K | Теория упругости | Теоретическая механика | —————————————————- Это отношение имеет значительную избыточность и его использование приводит к возникновению аномалии обновления.

Например, добавление информации о том, что профессор K будет также читать лекции по курсу «Теория упругости» приводит к необходимости добавить два кортежа (по одному для каждого написанного им учебника) вместо одного. Тем не менее, отношение ПРЕПОДАВАТЕЛЬ находится в NFBC (ключевой атрибут — ИМЯ).

Заметим, что указанные аномалии исчезают при замене отношения ПРЕПОДАВАТЕЛЬ его проекциями:

————————— ——————————- | ИМЯ | КУРС | | ИМЯ | УЧЕБНОЕ_ПОСОБИЕ | ————————— ——————————- | N | Теория упругости | | N |Теория упругости | | N | Теория колебаний | | N |Теория колебаний | | K | Теория удара | | K |Теоретическая механика | | K | Теория упругости | | K |Теория удара | ————————— ——————————- Аномалия обновления возникает в данном случае потому, что в отношении ПРЕПОДАВАТЕЛЬ имеются:

  1. зависимость множества значений атрибута КУРС от множества значений атрибута ИМЯ
  2. зависимость множества значений атрибута УЧЕБНОЕ_ПОСОБИЕ от множества значений атрибута ИМЯ.

Такие зависимости и называются многозначными и обозначаются как

ИМЯ ->> КУРС ИМЯ ->> УЧЕБНОЕ_ПОСОБИЕ Нетрудно показать, что многозначные зависимости всегда образуют связанные пары, поэтому их часто обозначают ИМЯ ->> КУРС | УЧЕБНОЕ_ПОСОБИЕ Очевидно, что каждая функциональная зависимость является многозначной, но не каждая многозначная зависимость является функциональной.


4.2.7. Зависимости по соединению и пятая нормальная форма (5NF).

До сих пор мы предполагали, что единственной операцией, необходимой для устранения избыточности в отношении, была декомпозиция его на две проекции. Однако, существуют отношения, для которых нельзя выполнить декомпозицию без потерь на две проекции, но которые можно подвергнуть декомпозиции без потерь на три (или более) проекций. Этот факт получил название зависимости по соединению, а такие отношения называют 3-декомпозируемые отношения (ясно, что любое отношение можно назвать «n-декомпозируемым», где n >= 2).

Детально этот вопрос здесь мы не обсуждаем (полное изложение см. в книге К.Дейта), заметим лишь, что зависимость по соединению является обощением многозначной зависимости. Отношения, в которых имеются зависимости по соединению, не являющиеся одновременно ни многозначными, ни функциональными, также характеризуются аномалиями обновления.

Система управления базами данных SQLite. Изучаем язык запросов SQL на примере библиотекой SQLite3

Поэтому, вводится понятие пятой нормальной формы.

Другими словами, каждая проекция такого отношения содержит не менее одного возможного ключа и не менее одного неключевого атрибута.


Следующая глава: 4.3.Ограничения целостности.



Нормализация таблиц базы данных — первый шаг на пути проектирования структуры реляционной базы данных. Строго говоря, конечно, не самый первый — сначала надо решить, что же мы вообще будем хранить в базе, то есть определиться со структурой полей, их типами и размерностью, смыслом хранимой в них информации. Но это, как говорится, подразумевается по умолчанию:).

Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.

База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме (вернее сказать, сознательного приведения их к пятой нормальной форме) в реальных базах данных я лично не встречал.

Главная цель нормализации базы данных — устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе.

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

Первая нормальная форма

Первая нормальная форма:

  • запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию)
  • запрещает множественные столбцы (содержащие значения типа списка и т.п.)
  • требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку

Вторая нормальная форма

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

Третья нормальная форма

Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы неключевые столбцы в ней не зависели от других неключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте — это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц надо удалить.

Нормальная форма Бойса-Кодда

Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ.

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

Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.

Четвертая нормальная форма

Для приведения таблицы, находящейся в нормальной форме Бойса-Кодда, к четвертой нормальной форме необходимо устранить имеющиеся в ней многозначные зависимости. То есть обеспечить, чтобы вставка / удаление любой строки таблицы не требовала бы вставки / удаления / модификации других строк этой же таблицы.

Пятая нормальная форма

Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается.

Такая вот теория… Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике же толковый проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро набросает структуру, в которой большинство таблиц находятся в четвертой нормальной форме:).

Краткие итоги. Зачем нужна нормализация.

Главное, чего мы добьемся, проведя нормализацию базы данных — это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства.

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

Главная, не первая и не десятая по счету, если создана база для прочных отношений между мужчиной и женщиной то можно спокойно оформлять официально эти отношения и жить, любить друг друга ни когда не разрушать эти отношения.

(base 1) Стадия первая — французский поцелуй ( с языком).

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

Меня то сразу смутило — а что если вы просто целовались, то отношениями это назвать нельзя? Ну в данной систему всё что идёт до французского поцелуя (держаться за руки, обниматься, просто целоваться) входит в описание первой стадии. (base 2) стадия вторая — трогать друг друга в одежде. В этой стадии порой встречаются разные мнения — одни считают, что потрогать женскую грудь без лифчика это стадия 2, другие, что это стадия 3. (base 3) Зализать в штаны руками. Хотя тут тоже есть разногласия — многие считают что стадия 3 всё, что ещё не настоящий секс. (base 4) HOMERUN — тут всё предсказуемо — секс

FIRST BASE. When you get to first base, you have been lucky enough to have been kissed. Some people only consider French kissing as getting to first base. SECOND BASE is direct physical contact, usually meaning his hands to her breast. It also includes other forms of petting, touching and groping. THIRD BASE. may include manual or oral sex for either partner. HOME RUN. Simply put, a home run is sexual intercourse GRAND SLAM. Those looking to excel at sexual baseball strive for the grand slam. A grand slam is sexual intercourse with the female having an orgasm. BALK. A balk is premature ejaculation. Some also refer to this as a ball. STRIKE OUT. A strike out is when you don’t get a kiss at the end of the evening. DOUBLE HEADER. A double header consists of two rounds of intercourse in one night. SACRIFICE FLY. A sacrifice fly is the buddy who «takes one for the team» to ensure you end up with the girl of your choice for the evening, akin to a «wingman.» PICKED OFF. When your sexual activity is interrupted by a third party (such as a parent, roommate or child), you are said to have been picked off. WALK. A walk is considered a sympathy base and is typically reserved for first base only. It occurs when your date allows kissing even though they are not attracted to you.

Войдите, чтобы написать ответ

Лекция№10 Нормализация реляционных баз данных

При проектировании базы данных в реляционной СУБД основной целью разра­ботки логической модели данных является создание точного представления дан­ных, связей между ними и требуемых ограничений. Для этого не­обходимо определить, прежде всего, подходящий набор отношений. Метод, используемый при этом, называется нормализацией (normalization). Нормализация представляет собой вариант восходящего подхода к проектированию базы данных, который начинается с установления связей между атрибутами.

Цель нормализации

Нормализация — метод создания набора отношений с заданными свойствами на основе требований к данным, установленным в некоторой орга­низации.

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

Процесс нормализации является формальным методом, который позволяет идентифицировать отношения на основе их первичных ключей (или потенциальных ключей, как в случае НФБК) и функциональных зависимостей, существующих между их атрибутов. Проектировщики баз данных могут использовать нормализацию в виде наборов тестов, применяемых к отдельным отношениям с целью нормализации реляционной схемы до заданной конкретной формы, что позволит предотвратить возможное возникновение аномалий обновления.

Основная цель проектирования реляционной базы данных заключается в группи­ровании атрибутов и отношения так, чтобы минимизировать избыточность данных и таким образом сократить объем памяти, необходимый для физического хранения от­ношений, представленных в виде таблиц.

Функциональные зависимости

Функциональная зависимость описывает связь между ат­рибутами и является одним из основных понятий нормализации. В этом разделе приводится определение данного понятия, а в следующих — описание его взаимосвя­зи с процессами нормализации отношений базы данных.

Функциональная зависимость — описывает связь между атрибутами отношения. Например, если в отношении. R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А (что обозначается как АВ), то каждое значение атрибута А связано только с одним значением атрибута В.

Лекция № 10. Нормальные формы

(Причем каждый из атрибутов А и В может состоять из одного или нескольких атрибутов.)

Функциональная зависимость является смысловым (или семантическим) свойст­вом атрибутов отношения. Семантика отношения указывает, как его атрибуты могут быть связаны друг с другом, а также определяет функциональные зависимости меж­ду атрибутами в виде ограничений, наложенных на некоторые атрибуты.

Зависимость между атрибу­тами А и В можно схематически представить в виде диаграммы, показанной на рисунке 5.

Детерминант — детерминантом функциональной зависимости называется атрибут или группа атрибутов, расположенная на диаграмме функциональ­ной зависимости слева от символа стрелки.

А

Атрибут В функционально

зависит от атрибута А

В

Рисунок 5 — Диаграмма функциональной за­висимости

При наличии функциональной зависимости атрибут или группа атрибутов, распо­ложенная на ее диаграмме слева от символа стрелки, называется детерминантом (determinant). Например, на рис. 6.1 атрибут А является детерминантом атрибута В.

Концепция функциональной зависимости является центральным понятием про­цесса нормализации.

НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информацион­ных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. мини­мизирующей дублирование данных и упрощающей процедуры их обработки и обновления. Определенный набор отношений обладает лучшими свойствами при включении, мо­дификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений [1].

Нормализация отношений— формальный аппарат ограничений на фор­мирование отношений (таблиц), который позволяет устранить дублирова­ние, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.

Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.

Таблицы реляционной БД должны отвечать требованиям нормализации отношений.

Пусть создана таблица Студент, содержащая следующие поля: (Номер, ФИО, Дата, Группа, название специальности, название факультета). Такая организация хранения информации будет иметь ряд недостатков:

· дублирование информации (наименование специальности и факультета повторяются для каждого студента), следовательно, увеличится объем БД;

· процедура обновления информации в таблице затрудняется из-за необходимости редактирования каждой записи таблицы.

Первая нормальная форма

Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нор­мальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.

Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) на­ходится в первой нормальной форме.

Вторая нормальная форма

Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.

Функциональная зависимостьреквизитов — зависимость, при которой в экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.

Такое определение функциональной зависимости позволяет при анализе всех взаи­мосвязей реквизитов предметной области выделить самостоятельные информационные объекты.

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

 

Рис.

14. Первая, вторая, третья нормальные формы. Нормальная форма Бойса-Кодда.

Графическое изображение функциональной зависимости реквизитов.

В случае составного ключа вводится понятие функционально полной зависимости.

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

Отношение будет находиться во второй нормальной форме, если оно находится в пер­вой нормальной форме, и каждый неключевой атрибут функционально полно зависит от составного ключа.

Пример.Отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой и во второй нормальной форме одновременно, так как описатель­ные реквизиты однозначно определены и функционально зависят от ключа Номер. Отношение Успеваемость = (Номер, Фамилия, Имя, Отчество, Дисциплина, оценка) находится в первой нормальной форме и имеет составной ключ Номер + Дисциплина. Это отношение не находится во второй нормальной форме, так как атрибуты Фами­лия, Имя, Отчество не находятся в полной функциональной зависимости с составным ключом отношения.

Третья нормальная форма

Понятие третьей нормальной формы основывается на понятии нетранзитивной зави­симости.

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

Отношение будет находиться в третьей нормальной форме, если оно находится во вто­рой нормальной форме, и каждый неключевой атрибут нетранзитивной зависит от первично­го ключа.

Пример.Если в состав описательных реквизитов информационного объекта Студент включить фамилию старосты

группы (Староста), которая определяется толь­ко номером группы, то одна и та же фамилия старосты будет многократно повторять­ся в разных экземплярах данного информационного объекта.

В этом случае наблюдаются затруднения в корректировке фамилии старосты в случае назначения нового старосты, а также неоправданный расход памяти для хранения дублированной информации.

Для устранения транзитивной зависимости описательных реквизитов необходимо про­вести "расщепление" исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.

Три поля — № зачетной книжки, № группы, Староста находятся в транзитивной зависимости, № группы зависит от № зачетной книжки, а Староста зависит от № группы. Для устранения транзитивной зависимости необходимо часть полей таблицы Студент перенести в другую таблицу Группа. Таблицы примут следующий вид:

Рис. Пример "расщепления" структуры информационного объекта.

⇐ Предыдущая12345Следующая ⇒


Дата добавления: 2013-12-13; Просмотров: 128; Нарушение авторских прав?;




Читайте также:

FILED UNDER : IT

Submit a Comment

Must be required * marked fields.

:*
:*