Нормальная форма бойса

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

of Wikipedia

Advertizing ▼

Wikipedia

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

Перейти к: ,

Основная статья: Нормальная форма

Нормальная форма Бойса-Кодда (BCNF) — одна из возможных нормальных форм отношения в реляционной модели данных.

Иногда нормальную форму Бойса-Кодда называют усиленной третьей нормальной формой, поскольку она во всех отношениях сильнее (строже) по сравнению с ранее определённой ЗНФ.

Названа в честь Рэя Бойса и Эдгара Кодда, хотя К. Дейт указывает, что на самом деле строгое определение «третьей» нормальной формы, эквивалентное определению нормальной формы Бойса-Кодда, впервые было дано Хитом (Heath) в 1971 году, поэтому данную форму следовало бы называть «нормальной формой Хита».

Определение

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

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

Для определения BCNF следует понимать понятие функциональной зависимости атрибутов отношения.

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

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

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

Первый пример

Пример приведения таблицы к нормальной форме Бойса — Кодда

Исходная таблица:

Номер клиента	Дата собеседования	Время собеседования	Номер комнаты	Номер сотрудника
С345	13.10.03	13.00	103	А138
С355	13.10.03	13.05	103	А136
С368	13.09.03	13.00	102	А154
С366	13.09.03	13.30	105	А207

В результате приведения к форме Бойса—Кодда получаются две таблицы:

Номер клиента	Дата собеседования	Время собеседования	Номер Сотрудника
С345	13.10.03	13.00	А138
С355	13.10.03	13.05	А136
С368	13.09.03	13.00	А154
С366	13.09.03	13.30	А207

Дата собеседования	Номер сотрудника	Номер комнаты
13.10.03	А138	103
13.10.03	А136	103
13.09.03	А154	102
13.09.03	А207	105

Второй пример

Предположим, создаётся таблица бронирования для теннисных кортов на день: {Номер корта, Время начала, Время окончания, Тариф, Член клуба}. Тариф зависит от выбранного корта и членства в клубе.

Таким образом, возможны следующие составные первичные ключи: {Номер корта, Время начала}, {Номер корта, Время окончания}, {Тариф, Время начала}, {Тариф, Время окончания}.

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

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

Можно улучшить структуру, разбив таблицу на две: {Номер корта, Время начала, Время окончания, Член клуба} и {Тариф, Номер корта, Член клуба}. Данное отношение будет соответствовать BCNF.

Примечания

↑ Дейт К. Дж. Введение в системы баз данных. — 8-е изд. — М.: «Вильямс», 2006

Нормальные формы

Первая нормальная форма • Вторая нормальная форма • Третья нормальная форма • Нормальная форма Бойса — КоддаЧетвёртая нормальная форма • Пятая нормальная форма • Доменно-ключевая нормальная форма • Шестая нормальная форма

Файл:Computer template.gif

Это незавершённая статья о программировании. Вы можете помочь проекту, исправив и дополнив её.

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

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

Записи могут зависеть только от первичного ключа таблицы (составного ключа, если необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.

Ссылки

Кодд, EF «Недавние исследования реляционной базы данных» в Proc. Конгресс 1974 г. (Стокгольм, Швеция, 1974 г.). Нью-Йорк, штат Нью-Йорк: Северная Голландия (1974).
Silberschatz, Abraham (2006). Концепции системы баз данных (6-е изд.). Макгроу-Хилл. С. . ISBN 978-0-07-352332-3.
Винсент, М. В. и Б. Сринивасан. «Примечание о схемах Рэнди, которые входят в 3NF, но не входят в BCNF». Письма об обработке информации 48 (6), 1993, стр. 281–283.
Бери, Катриэль и Бернштейн, Филип А. «Вычислительные проблемы, связанные с проектированием реляционных схем нормальной формы». Транзакции ACM в системах баз данных 4 (1), март 1979 г., стр. 50.
Заниоло, Карло. «Новая нормальная форма для проектирования схем реляционных баз данных». Транзакции ACM в системах баз данных 7 (3), сентябрь 1982 г., стр. 493.
Бернштейн, П. А. «Синтез отношений третьей нормальной формы из функциональных зависимостей». Транзакции ACM по системам баз данных 1 (4), декабрь 1976 г., стр. 277–298.
Бири, Catriel; Бернштейн, Филип А. (1979). «Вычислительные проблемы, связанные с проектированием реляционных схем нормальной формы». ACM-транзакции в системах баз данных . 4 : 30–59. DOI10.1145 / 320064.320066 . S2CID ., Следствие 3.
Хит, I. «Недопустимые файловые операции в реляционной базе данных». Proc. 1971 г. Семинар ACM SIGFIDET по описанию, доступу и управлению данными , Сан-Диего, Калифорния (11–12 ноября 1971 г.).
Дата, C.J. База данных в глубине: реляционная теория для практиков . О’Рейли (2005), стр. 142.

Описание нормализации

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

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

Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.

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

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

В описаниях ниже приведены соответствующие примеры.

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

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

Чтобы привести таблицу к 1НФ, нужно соблюсти два правила:

Атомарность или неделимость. Каждая колонка должна содержать одно неделимое значение.
Таблица не должна содержать повторяющихся колонок или групп данных.

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

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

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

Найти все поля, которые содержат многосоставные части информации. На рисунке выше, поле message date содержит день, месяц, год и время, которое можно разбить на составные части, но в данном примере такая детализация даты не нужна. Mysql может работать и с таким форматом — благодаря типу DATETIME. В этом примере разбито имя пользователя на имя и фамилию. Еще примерами неудачных решений могут быть поля, в которых хранятся сразу все телефоны человека (мобильный, рабочий) или его интересы (готовка, танцы).
Те данные, которые можно разбить на составные части, нужно выносить в отдельные поля. На рисунке выше так разнесено полное имя на имя и фамилию.
Выносите повторяющиеся данные в отдельную таблицу. В примере с форумом такой проблемы нет, поэтому возьмем в качестве примера таблицу, содержащую информацию о фильмах. Там есть несколько полей actor, которые являются повторяемыми. Повторяемые поля тут несут две проблемы. Если хранить информацию об актерах таким образом, то их число будет лимитировано числом таблиц. Даже если их будет 100, то все равно это будет пределом для некоторых фильмов. И вторая проблема — будет большое количество пустых(NULL) ячеек для большинства остальных записей, чего также следует избегать. Решением этой проблемы станет создание отдельной таблицы для актеров, куда будет заносится информация обо всех необходимых фильмах. Имена актеров также разбиты, чтобы соблюсти атомарность. Также в этой таблице присутствует свой первичный ключ, что является необходимым условием для нормализации.
Дважды проверьте, все ли таблицы подходят под условия первой нормальной формы.

Подсказки

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

Происхождение Бойса-Кодда нормальной формы

Следуя ряду рекомендаций, убедитесь, что базы данных нормализованы. Эти рекомендации называются нормальными формами и пронумерованы от одного до пяти. Реляционная база данных описывается как нормализованная, если она соответствует первым трем формам: 1NF, 2NF и 3NF.

BCNF был создан как расширение к третьей нормальной форме, или 3NF, в 1974 году Раймондом Бойсом и Эдгаром Коддом. Мужчины работали над созданием схем базы данных, которые минимизируют избыточность с целью сокращения времени вычислений. Третья нормальная форма удаляет столбцы, которые не зависят от первичного ключа, в дополнение к соответствию рекомендациям в первой и второй нормальных формах. BCNF, который иногда называют 3.5NF, отвечает всем требованиям 3NF и требует, чтобы ключи-кандидаты не зависели от других атрибутов в таблице.

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

Используя свое понимание реляционной базы данных, Кодд определил руководящие принципы 1NF, 2NF и 3NF. Он объединился с Бойсом, чтобы определить BCNF.

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

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

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

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

Ссылки на оригинал:

Введение
Первая нормальная форма
Вторая нормальная форма
Третья нормальная форма

Достижимость BCNF [ править ]

В некоторых случаях таблица, не относящаяся к BCNF, не может быть разложена на таблицы, которые удовлетворяют BCNF и сохраняют зависимости, которые содержались в исходной таблице. Бери и Бернштейн показали в 1979 году, что, например, набор функциональных зависимостей {AB → C, C → B} не может быть представлен схемой BCNF.

Рассмотрим следующую таблицу, не относящуюся к BCNF, функциональные зависимости которой следуют шаблону {AB → C, C → B}:

Ближайшие магазины
Человек	Тип магазина	Ближайший магазин
Дэвидсон	Оптик	орлиный глаз
Дэвидсон	Парикмахер	Фрагменты
Райт	Книжный магазин	Книги Мерлина
Фуллер	Пекарня	Doughy’s
Фуллер	Парикмахер	Суини Тодд
Фуллер	Оптик	орлиный глаз

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

Возможные ключи таблицы:

{Человек, Тип магазина},
{Человек, ближайший магазин}.

Поскольку все три атрибута являются основными атрибутами (т. Е. Принадлежат ключам-кандидатам), таблица находится в 3NF. Однако таблица отсутствует в BCNF, поскольку атрибут типа Shop функционально зависит от не суперключи: ближайший магазин.

Нарушение BCNF означает, что таблица подвержена аномалиям. Например, для Eagle Eye тип магазина может быть изменен на «Оптометрист» в записи «Фуллера», при этом сохранен тип магазина «Оптик» в записи «Дэвидсон». Это означало бы противоречивые ответы на вопрос: «Что такое тип магазина Eagle Eye?» Было бы предпочтительнее удерживать тип магазина каждого магазина только один раз, так как это предотвратит возникновение таких аномалий:

Магазин рядом с человеком
Человек	Магазин
Дэвидсон	орлиный глаз
Дэвидсон	Фрагменты
Райт	Книги Мерлина
Фуллер	Doughy’s
Фуллер	Суини Тодд
Фуллер	орлиный глаз

Магазин
Магазин	Тип магазина
орлиный глаз	Оптик
Фрагменты	Парикмахер
Книги Мерлина	Книжный магазин
Doughy’s	Пекарня
Суини Тодд	Парикмахер

В этом пересмотренном дизайне таблица «Магазин рядом с человеком» имеет ключ-кандидат {Person, Shop}, а таблица «Магазин» — ключ-кандидат {Shop}. К сожалению, хотя этот дизайн соответствует BCNF, он неприемлем по разным причинам: он позволяет нам регистрировать несколько магазинов одного типа против одного и того же человека. Другими словами, его ключи-кандидаты не гарантируют, что функциональная зависимость {Person, Shop type} → {Shop} будет соблюдаться.

Возможна конструкция, которая устраняет все эти аномалии (но не соответствует BCNF). Этот дизайн представляет новую нормальную форму, известную как нормальная форма элементарного ключа . Этот дизайн состоит из оригинальной таблицы «Ближайшие магазины», дополненной таблицей «Магазин», описанной выше. Структура таблицы, сгенерированная алгоритмом генерации схемы Бернштейна , на самом деле является EKNF, хотя это усовершенствование 3NF не было распознано во время разработки алгоритма:

Ближайшие магазины
Человек	Тип магазина	Ближайший магазин
Дэвидсон	Оптик	орлиный глаз
Дэвидсон	Парикмахер	Фрагменты
Райт	Книжный магазин	Книги Мерлина
Фуллер	Пекарня	Doughy’s
Фуллер	Парикмахер	Суини Тодд
Фуллер	Оптик	орлиный глаз

Магазин
Магазин	Тип магазина
орлиный глаз	Оптик
Фрагменты	Парикмахер
Книги Мерлина	Книжный магазин
Doughy’s	Пекарня
Суини Тодд	Парикмахер

Если ограничение ссылочной целостности определено таким образом, что {Тип магазина, Ближайший магазин} из первой таблицы должен ссылаться на {Тип магазина, Магазин} из второй таблицы, то аномалии данных, описанные ранее, предотвращаются.

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

Отношение находится во 2-й нормальной форме, если оно находится в 1-й нормальной форме и каждый неключевой атрибут функционально полно зависит от ключа. Например, имеем составной ключ: сотрудник и должность. Должность имеет такой параметр, как категория. Соответственно, все это, допустим, сохранили в одной таблице. Но Иванов сам по себе не может иметь просто 3-ю категорию, такую категорию имеет должность. Значит, надо вывести должности с их категориями в отдельное отношение. Появится справочник должностей, и мы исключим избыточность. Основным признаком того, что данные не находятся во 2-й нормальной форме, является наличие множества повторяемых значений в таблице. Если таковые есть в огромных количествах, следует задуматься: а не сгруппировать ли и не вынести ли их в отдельный справочник.

Литература

Российская

Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.

Переводная

Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: Вильямс, 2005. — 1328 с. — ISBN 5-8459-0788-8 (рус.) 0-321-19784-4 (англ.).
Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: Вильямс, 2003. — 1436 с. — ISBN 0-201-70857-4.
Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс = Database Systems: The Complete Book. — Вильямс, 2003. — 1088 с. — ISBN 5-8459-0384-X.

Иностранная

C. J. Date. Date on Database: Writings 2000–2006. — Apress, 2006. — 566 с. — ISBN 978-1-59059-746-0, 1-59059-746-X.

Таблица 3NF всегда соответствует BCNF (нормальная форма Бойса – Кодда) [ править ]

Только в редких случаях таблица 3NF не соответствует требованиям BCNF. Таблица 3NF, которая не имеет нескольких перекрывающихся ключей-кандидатов, гарантированно находится в BCNF. В зависимости от функциональных зависимостей таблица 3NF с двумя или более перекрывающимися ключами-кандидатами может находиться или не входить в BCNF.

Примером таблицы 3NF, которая не соответствует BCNF, является:

Судебные заказы сегодня
Суд	Начальное время	Время окончания	Тип ставки
1	09:30	10:30	ЭКОНОМИЯ
1	11:00	12:00	ЭКОНОМИЯ
1	14:00	15:30	СТАНДАРТНЫЙ
2	10:00	11:30	ПРЕМИУМ-Б
2	11:30	13:30	ПРЕМИУМ-Б
2	15:00	16:30	ПРЕМИУМ-А

Каждая строка в таблице представляет бронирование корта в теннисном клубе. В этом клубе есть одна площадка с твердым покрытием (Корт 1) и одна площадка с травяным покрытием (Корт 2)
Бронирование определяется его судом и периодом, на который зарезервирован суд.
Кроме того, с каждым бронированием связан тип тарифа. Существует четыре различных типа ставок:
- SAVER, для заказов Court 1, сделанных участниками
- СТАНДАРТ, для заказов Корт 1, сделанных не членами
- PREMIUM-A, для заказов Court 2, сделанных участниками
- PREMIUM-B, для заказов Court 2, сделанных не членами

Суперключи таблицы :

S ₁ = {Суд, время начала}
S ₂ = {Суд, время окончания}
S ₃ = {Тип ставки, время начала}
S ₄ = {Тип ставки, Время окончания}
S ₅ = {Суд, время начала, время окончания}
S ₆ = {Тип ставки, время начала, время окончания}
S ₇ = {Корт, Тип ставки, Время начала}
S ₈ = {Суд, Тип ставки, Время окончания}
S _T = {Суд, Тип ставки, Время начала, Время окончания}, простая супер-клавиша

Обратите внимание , что даже если в приведенной выше таблице Время начала и Время окончания атрибуты не имеют повторяющиеся значения для каждого из них, мы все равно должны признать , что в некоторых других дней две различные заказы на суда 1 и суд 2 может начаться в то же время или конец в то же время. По этой причине {Время начала} и {Время окончания} нельзя рассматривать как суперключи таблицы.. Однако только S 1 , S 2 , S 3 и S 4 являются ключами-кандидатами (то есть минимальными суперключами для этого отношения), поскольку, например, S 1 ⊂ S 5 , поэтому S 5 не может быть ключом-кандидатом.

Однако только S ₁ , S ₂ , S ₃ и S ₄ являются ключами-кандидатами (то есть минимальными суперключами для этого отношения), поскольку, например, S ₁ ⊂ S ₅ , поэтому S ₅ не может быть ключом-кандидатом.

Напомним, что 2NF запрещает частичные функциональные зависимости непервичных атрибутов (т. Е. Атрибут, который не встречается ни в одном из ключей-кандидатов. См. Ключи-кандидаты ) от ключей-кандидатов, и что 3NF запрещает транзитивные функциональные зависимости непервичных атрибутов от ключей-кандидатов.

В сегодняшней таблице судебных заказов нет неосновных атрибутов: то есть все атрибуты принадлежат некоторому ключу-кандидату. Таким образом, таблица соответствует как 2NF, так и 3NF.

Таблица не соответствует BCNF. Это связано с зависимостью Тип ставки → Суд, в которой определяющий атрибут Тип ставки — от которого зависит Суд — (1) не является ни кандидатным ключом, ни надмножеством кандидата-ключа и (2) Суд не является подмножеством типа ставки.

Тип ставки зависимости → Суд соблюдается, поскольку тип ставки должен применяться только к одному суду.

Конструкцию можно изменить, чтобы она соответствовала BCNF:

Типы ставок
Тип ставки	Суд	Флаг участника
ЭКОНОМИЯ	1	да
СТАНДАРТНЫЙ	1	Нет
ПРЕМИУМ-А	2	да
ПРЕМИУМ-Б	2	Нет

Сегодняшние бронирования
Флаг участника	Суд	Начальное время	Время окончания
да	1	09:30	10:30
да	1	11:00	12:00
Нет	1	14:00	15:30
Нет	2	10:00	11:30
Нет	2	11:30	13:30
да	2	15:00	16:30

Возможные ключи для таблицы типов ставок: {Тип ставки} и {Суд, флаг члена}; возможные ключи для таблицы сегодняшних бронирований: {Суд, Время начала} и {Суд, Время окончания}. Обе таблицы находятся в BCNF. Когда {Тип ставки} является ключевым в таблице типов ставок, невозможно связать один тип ставки с двумя разными судами, поэтому при использовании {Тип ставки} в качестве ключа в таблице типов ставок аномалия, влияющая на исходную таблицу, была устранена. устранено.

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

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

Например, в таблицу Employee Recruitment (наем сотрудников) можно включить адрес кандидата и название университета, в котором он получил образование. Однако для организации групповой почтовой рассылки необходим полный список университетов. Если сведения об университетах будут храниться в таблице Candidates, составить список университетов при отсутствии кандидатов не получится. Таким образом, создайте вместо этого отдельную таблицу Universities и свяжите ее с таблицей Candidates при помощи ключа — кода университета.

ИСКЛЮЧЕНИЕ: выполнять нормализацию баз данных до третьей нормальной формы теоретически желательно, но не всегда практично. Например, для устранения всех возможных зависимостей между полями таблицы Customers придется создать отдельные таблицы для хранения сведений о городах, почтовых индексах, торговых представителях, категориях клиентов и любых других сведений, которые могут дублироваться в нескольких записях. С теоретической точки зрения нормализация желательна. Однако значительное увеличение числа маленьких таблиц может привести к снижению производительности СУБД или исчерпанию памяти и числа дескрипторов открытых файлов.

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