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

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

Нормализация баз данных заключается в приведении структуры хранения данных к нормальным формам (NF). Всего таких форм существует 8, но часто достаточным является соблюдение первых трех. Рассмотрим их более подробно на примере учебной базы данных. Примеры будут строится по принципу «что было бы, если было иначе, чем сейчас».

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

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

Рассмотрим таблицы сотрудников и телефонных линий.

Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:

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

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

Помимо атомарности к первой нормальной форме относятся следующие правила:

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

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

Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.

Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.

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

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

Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.

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

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

На приведенном примере таблицы сотрудников видно, что столбец «Супервайзер» имеет зависимость от столбца «Группа», а это значит, что при изменении значения поля группы, потребуется изменить значение поля супервайзера.

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

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

Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.

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

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы мы могли развивать его дальше.

У Вас недостаточно прав для комментирования.

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

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

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

В некоторых СУБД, например Access, предусмотрен мастер анализа таблиц, который позволяет нормализовать таблицы базы данных. При использовании мастера пользователь имеет возможность самостоятельно определить создаваемые таблицы или позволить мастеру провести нормализацию таблиц.

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

Универсальное отношение порождает ряд проблем.

· Избыточность

· Аномалии обновления (потенциальная противоречивость)

· Аномалии включения

· Аномалии удаления

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

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

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

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

Дадим определение первых трех нормальных форм.

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

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

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

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

Автор книги «Эффективная работа с Microsoft Access 2000» Д. Вейскас считает, что практически таблицы реляционной базы данных должны удовлетворять следующим требованиям:

· Каждое поле таблицы должно быть уникальным.

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

· Для каждого значения первичного ключа должно быть одно и только одно значение любого из столбцов данных и это значение должно относится к объекту таблицы.

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

Связывание таблиц

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

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

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

Рис. 1.2. Фрагмент схемы данных базы данных Товарная база

Типы связей между таблицами

Тип связи определяет правила сопоставления строк между двумя таблицами. Существуют следующие виды связей или отношений.

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

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

Многие — ко — многим. При такой связи каждой строке первой таблицы может соответствовать несколько строк во второй таблице и наоборот. Примером такой связи является связь между таблицами ЗаказыиКаталог. Один заказ может содержать много моделей мебели и каждая конкретная модель может быть включена во множество заказов. Такая связь может быть реализована только через третью таблицу, с которой исходные таблицы будут иметь связи один ‑ ко ‑ многим.

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

Дата добавления: 2016-01-03; просмотров: 1182;

ПОСМОТРЕТЬ ЕЩЕ:

демонтаж сооружений

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

Процесс нормализации данных заключается в устранении избыточности данных в таблицах.

Существует несколько нормальных форм, но для практических целей интерес представляют только первые три нормальные формы.

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

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

Под понятием повторяющиеся группы подразумевают поля, содержащие одинаковые по смыслу значения. Взгляните на рисунок:

	Студент 1	Студент 2	Студент 3
	Иванов И.И.	Петров П.П.	Сидоров С.С.

Рис. 1.6. Повторяющиеся группы

Верно, такую таблицу можно сделать, однако она нарушает правило первой нормальной формы. Поля «Студент 1», «Студент 2» и «Студент 3» содержат одинаковые по смыслу объекты, их требуется поместить в одно поле «Студент», как в рисунке 1.4. Ведь в группе не бывает по три студента, правда? Представляете, как будет выглядеть таблица, содержащая данные на тридцать студентов? Это тридцать одинаковых полей! В приведенном выше рисунке поля описывают студентов в формате «Фамилия И.О.». Однако если оператор будет вводить эти описания в формате «Фамилия Имя Отчество», то нарушается также правило неделимости. В этом случае каждое такое поле следует разбить на три отдельных поля, так как поиск может вестись не только по фамилии, но и по имени или по отчеству.

Вторая нормальная форма (2НФ) требует, чтобы таблица удовлетворяла всем требованиям первой нормальной формы, и чтобы любое не ключевое поле однозначно идентифицировалось полным набором ключевых полей. Рассмотрим пример: некоторые студенты посещают спортивные платные секции, и ВУЗ взял на себя оплату этих секций. Взгляните на рисунок:

№ студента	Секция	Плата
	Плавание
	Скейтборд
	Теннис
	Плавание
	Теннис

Рис. 1.7. Нарушение второй нормальной формы

В чем здесь нарушение? Ключом этой таблицы служат поля «№ студента» — «Секция». Однако данная таблица также содержит отношение «Секция» — «Плата». Если мы удалим запись студента № 110, то потеряем данные о стоимости секции по скейтборду. А после этого мы не сможем ввести информацию об этой секции, пока в нее не запишется хотя бы один студент. Говорят, что такое отношение подвержено как аномалии удаления, так и аномалии вставки.

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

Ла студента	Секция
	Плавание
	Скейтборд
	Теннис
	Плавание
	Тенине

Секция	Плата
Плавание
Скейтборд
Теннис

Ключ: Секции

Ключ: № студента Рис. 1.8. Правильная вторая нормальная форма

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

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

Секция	Плата	Кол-во	Общая
		студентов	стоимость
Плавание
Скейтборд
Теннис

Рис. 1.9. Нарушение третьей нормальной формы

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

Поле «Общая стоимость» в данном примере можно спокойно убрать из таблицы, ведь если потребуется вывести такие данные, нетрудно будет перемножить значения полей «Плата» и «Кол-во студентов», и создать для вывода вычисляемое поле.

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

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

Лекция 2. ADO. Связь с таблицей MS Access.

С самого появления технологии баз данных программисты испытывали потребность в механизмах доступа к этим самым данным. Различные компании по-своему пытались предоставить им такую возможность. Например, для работы с таблицами типа dBase была создана Система Управления Базами Данных (СУБД) Clipper. Для времен операционной системы MS-DOS — превосходное решение. Однако Clipper не мог работать ни с какими другими типами таблиц. И чем больше типов данных появлялось, тем острее вставала необходимость разработать универсальный инструмент доступа, который мог бы работать с любым типом данных.

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

⇐Ссылочная целостность || Оглавление || Сравнение BDE и ADO⇒

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

Перед началом…

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

Избыточность

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

Таблица с данными о сотрудниках из разных отделов, содержит избыточные данные

Обратите внимание, что данные в полях DNAME и DNO неоднократно повторяются в таблице. Такой вид избыточности данных приводит к аномалиям обновления, вставки и удаления.

Аномалии вставки

Если нам понадобится добавить в таблицу информацию о новом сотруднике, который не «привязан» к какому-либо отделу, данные об отделе в добавляемой записи окажутся пустыми, а это явно неоправданная трата пространства. Кроме того, при вставке данных нового сотрудника, скажем, в отдел с идентификатором ‘4’, другие поля, относящиеся к отделу, также должны будут повториться. Пример: отдел 4, поле DNAME должно содержать значение ‘Administrator’, а поле MGR_SSN — содержимое должно быть равно ‘234567890’.

Аномалии обновления

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

Аномалии удаления

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

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

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

{SSN} → {ADDRESS}

Аналогично,

{SSN} → {ENAME, ADDRESS}
{SSN, DNO} → {MGR_SSN}

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

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

Правила нормализации, применяемые к таблице, уменьшают проблемные области, «поднимая» таблицы на более высокий уровень согласованности данных, особенно в процессе добавления, обновления и удаления записей. Первая нормальная форма (1NF) — является первым правилом, вторая — вторым и тд. Давайте рассмотрим эти правила подробнее.

Первая нормальная форма (1NF)

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

Вместо этого, мы должны разместить данные в таблице следующим образом:

В результате мы получили много записей со значением NULL, более того, мы не можем добавить другой номер телефона. Лучше разделим эту таблицу на 2, так, как показано ниже.

Вторая нормальная форма (2NF)

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

В таблице выше, существуют следующие зависимости:

{SSN} → {EMPLOYEE_NAME}
{SSN} → {PROJ_HOURS}

Также,

{PROJECT_NO} → {PROJECT_NAME}
{PROJECT_NO} → {PROJECT_HOURS}

Это грубое нарушение 2NF, потому что значение полей PROJECT_HOURS и PROJECT_NAME в каждой записи функционально зависимы от PROJECT_NO. Кроме того, EMPLOYEE_NAME и PROJ_HOURS однозначно определяются значением поля SSN. Чтобы привести данные к 2NF в данном случае мы можем «разложить» таблицу EMPLOYEE_PROJECT на несколько таблиц:

Третья нормальная форма (3NF)

Чтобы привести таблицу в третью нормальную форму (3NF), она должна находится во второй нормальной форме (2NF) и, самое главное, не должна содержать данные с транзитивными зависимостями. Транзитивная зависимость — это случай, когда X→Y, Y→Z, X→Z. Это значит, что любое не ключевое поле не должно быть зависимо от поля, которое не является первичным ключом таблицы. Например:

Здесь, существуют зависимости:

{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}
{SSN} → {DEPT_NAME}
{SSN} → {DEPT_ADDRESS}

Однако, аномальной является следующая зависимость:

{DEPT_NAME} → {DEPT_ADDRESS}

потому что DEPT_NAME не является ключом. Мы можем устранить эту проблему, разделив таблицу на 2 таблицы.

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

В большинстве случаев, BCNF — это эквивалент 3NF. Правда эта форма строже, чем третья нормальная форма. Любая таблица, находящаяся в BCNF, находится в 3NF, но не наоборот.

BCNF — это нетривиальная функциональная зависимость X→Y в которой X, находящийся в ее левой части, является первичным ключом.

Давайте разберемся в этом на примере нескольких таблиц. Некоторые из них находятся одновременно и в 3NF и в BCNF, другие же находятся в3NF, но не в BCNF.

{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}

В таблице EMPLOYEE первичным ключом является поле SSN. Это нетривиальная функциональная зависимость, таблицы EMPLOYEE, в левой части которой находится атрибут SSN. Так как SSN является первичным ключом, функциональная зависимость не нарушает условий BCNF.

{PROJECT_NO} → {PROJECT_NAME}
{PROJECT_NO} → {PROJECT_DURATION}

Таблица PROJECT также находится в BCNF.

{DEPT_NO, SSN} → {PROJECT_NO, DURATION}
{PROJECT_NO} → {DURATION, DEPT_NO}

Однако, PROJECT_INFO не находится в BCNF, потому что PROJECT_NO не является первичным ключом. Не может быть пары строк, представляющих 2 разных SSN, работающих в том же PROJECT_NO и DEPT_NO. Например:

Функциональная зависимость PROJECT_NO → DURATION нетривиальна. Таким образом, таблица не удовлетворяет определению BCNF. Мы можем устранить эту проблему, если перепроектируем эту таблицу таким образом, чтобы все полученные в результате таблицы приняли BCNF. Например:

Заключение

Продолжать заниматься нормализацией можно и дальше: существуют 4NF, 5NF и DKNF (Domain Key Normal Form). Использование четырех уровней нормализации, рассмотренных в этой статье, является вполне достаточным в большинстве случаев проектирования баз данных. Таблицы могут быть нормализованы и до более высоких типов, но на практике это бывает не всегда возможно. Недостатком при стремлении к более высоким уровням нормализации является то, что таблицы могут быть разложены на более меньшие, чтобы отразить все возможные зависимости.

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

Источник статьи — Источник статьи —

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

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

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

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

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

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

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

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

Нормализация баз данных: основные правила

Стоит сформулировать набор правил, которых следует придерживать в работе по нормализации. В первую очередь стоит исключать повторяющиеся группы. Необходимо формировать отдельную таблицу, хранящую каждый набор связанных атрибутов, в которой и создать отдельный ключ. Далее обязательно исключить избыточные данные. В случаях, когда зависимость атрибута наблюдается только от части ключа, то его необходимо выставить в отдельную таблицу. Третье правило состоит в обязательном исключении столбцов, не зависящих от ключа. Атрибуты следует поместить в изолированную таблицу, если они не оказывают должного влияния на ключ. Обязательно следует изолировать независимые множественные отношения. В данном случае речь идет о том, что между несколькими отношениями не просматривается конкретная связь. И последнее, стоит изолировать множественные отношения, связанные семантически. На этом нормализация БД завершается, после чего наступает процесс разработки.