2008-10-29 5 views

ответ

152

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

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

Некоторые типичные ошибки нормализации:

(1) Имея более чем одно значение в ячейке. Пример:

UserId | Car 
--------------------- 
1  | Toyota 
2  | Ford,Cadillac 

Здесь столбец «Автомобиль» (который является строкой) имеет несколько значений. Это оскорбляет первую нормальную форму, в которой говорится, что каждая ячейка должна иметь только одно значение. Мы можем нормализовать эту проблему прочь иметь отдельную строку для каждого автомобиля:

UserId | Car 
--------------------- 
1  | Toyota 
2  | Ford 
2  | Cadillac 

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

(2) Имея избыточные неключевые данные (т. Е. Данные повторяются без необходимости в нескольких строках). Пример:

UserId | UserName | Car 
----------------------- 
1  | John  | Toyota 
2  | Sue  | Ford 
2  | Sue  | Cadillac 

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

UserId(FK) | Car    UserId(PK) | UserName 
---------------------   ----------------- 
1   | Toyota   1   | John 
2   | Ford    2   | Sue 
2   | Cadillac 

Теперь может показаться, что у нас еще есть избыточные данные, поскольку иденты повторяются; Однако ограничение PK/FK гарантирует, что значения не могут обновляться независимо, поэтому целостность является безопасной.

Важно ли это? Да, это очень важное. Имея базу данных с ошибками нормализации, вы открываете риск получения недопустимых или поврежденных данных в базе данных. Поскольку данные «живут вечно», очень сложно избавиться от поврежденных данных, когда они впервые вошли в базу данных.

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

Есть целый ряд заблуждений вокруг нормализации:

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

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

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

-9

Это помогает предотвратить дублирование (и, что еще хуже, противоречивых) данных.

Может иметь негативное влияние на производительность.

+0

Работая с нормализованными и ненормированными данными, я предпочитаю снижение скорости с нормализацией, а не потерять или с трудом поддерживать приложение или базу данных. – 2008-10-29 14:43:05

+1

В современных системах баз данных используется кэширование, что часто делает нормализованные базы данных более эффективными, чем ненормализованные. если есть сомнения, меры. – 2008-10-29 14:48:45

+1

Денормализованный дизайн может быть быстрее для конкретного запроса, но нормализованный дизайн предлагает компромисс, предоставляя разумную производительность для гораздо более широкого круга запросов. – 2008-11-04 06:17:37

19

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

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

Мой совет начать с хорошей степенью нормализации и делать только Денормализация, когда действительно необходимо

P.S. также проверьте эту статью: http://en.wikipedia.org/wiki/Database_normalization, чтобы узнать больше о предмете и о так называемых нормальных формах

2

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

В базах данных конкретно означает, что две (или более) таблицы не содержат одинаковых данных, то есть не имеют избыточности.

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

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

7

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

Существует несколько нормальных форм, обычно обозначаемых номером. Более высокое число означает меньшее количество увольнений и зависимостей. Любая таблица SQL находится в 1NF (первая нормальная форма, в значительной степени по определению). Нормализация означает изменение схемы (часто разделение таблиц) обратимым образом, давая модель, которая функционально идентична, за исключением меньшей избыточности и зависимостей.

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

5

Он предназначен для уменьшения избыточности данных.

Для более формального обсуждения см Википедия http://en.wikipedia.org/wiki/Database_normalization

Я дам несколько упрощенный пример.

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

id, name, address 
214 Mr. Chris 123 Main St. 
317 Mrs. Chris 123 Main St. 

может быть нормирована

id name familyID 
214 Mr. Chris 27 
317 Mrs. Chris 27 

и семейный стол

ID, address 
27 123 Main St. 

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

Идея состоит в том, что избыточная информация сводится к одной записи. Это особенно полезно в таких областях, как адреса, где г-н Крис представляет свой адрес в качестве Unit-7 123 Main St., а г-жа Крис перечисляет Suite-7 123 Main Street, которая будет отображаться в исходной таблице в виде двух разных адресов.

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

3

Цитирование CJ Дата: Теория практична.

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

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

Определение первой нормальной формы изменилось с 1970 года, но эти различия не должны касаться вас пока. Если вы создаете таблицы SQL с использованием модели реляционных данных, ваши таблицы будут автоматически находиться в 1NF.

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

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

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

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

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

1

Что такое нормализация?

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

Нормализация Процесс
enter image description here Courtesy

первой нормальной форме, если и только если область каждого атрибута содержит только атомарные значения (атомарное значение является значением, которое не может быть разделено), и значение каждого атрибута содержит только одно значение из этого домена (пример: - домен для столбца пола: «M», «F».).

Первая нормальная форма обеспечивает соблюдение этих критериев:

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

второй нормальной форме = 1NF + нет частичных зависимостей т.е. все не ключевые атрибуты полностью функциональной зависимости от первичного ключа.

Третья нормальная форма = 2NF + нет транзитивных зависимостей, то есть все неключевые атрибуты полностью зависят от работы ПРЯМО только на первичном ключе.

Boyce-Codd нормальная форма (или BCNF или 3.5NF) является чуть более мощной версией третьей нормальной формы (3NF).

Примечание: - Нормальные формы Second, Third и Boyce-Codd связаны с функциональными зависимостями. Examples

Четвертая нормальная форма = 3NF + удалить многозначных зависимостей

Пятая нормальная форма = 4НФ + удалить присоединиться зависимости

1

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

Что такое избыточность данных и аномалия обновления/модификации?

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

Пример:

enter image description here

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

Что такое аномалия вставки?

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

Пример:

enter image description here

Здесь «student_name» и «exam_registered» считаются составной первичный ключ (первичный ключ, который содержит несколько столбцов). Первичный ключ должен быть всегда уникальным, не должен содержать значения NULL и должен однозначно идентифицировать каждую строку в таблице. Теперь предположим, что средняя школа пытается представить новый экзамен под названием «Химия». Вначале на этом курсе не было зарегистрировано ни одного студента. Так как приведенная выше таблица не принимает значение NULL в столбце «имя_учреждения», нам нужно подождать, пока хотя бы один студент не будет зарегистрирован, чтобы сделать запись для экзамена «Химия» в приведенной выше таблице.

Что такое аномалия удаления?

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

Пример:

enter image description here

Здесь «student_name» и «exam_registered» считаются составной первичный ключ (первичный ключ, который содержит несколько столбцов). Первичный ключ должен быть всегда уникальным и не должен содержать значения NULL и должен однозначно идентифицировать каждую строку в таблице. Теперь предположим, что студент по имени Джон отменил свою регистрацию для экзамена по английскому. Поскольку столбец «имя_учреждения» не может содержать значение NULL, мы будем вынуждены удалить всю строку, которая стоила нам потери экзамена по английскому языку из нашей таблицы. Но все же средняя школа предлагает возможность сдавать экзамен по английскому языку своим ученикам.

Что такое частичная зависимость?

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

Пример:

enter image description here

Рассмотрим таблицу, которая имеет 3 колонки под названием «student_name», «student_age» и «exam_registered», как указано выше. Здесь 'student_name' и 'exam_registered' могут вместе формировать составной первичный ключ. Обычно каждый столбец не первичного ключа в хорошо нормированной таблице всегда должен зависеть от полного набора составного первичного ключа. Здесь «student_age» зависит только от «student_name» и не относится к «exam_registered», что заставляет эту таблицу находиться в частичной зависимости.

Что такое транзитивная функциональная зависимость?

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

Пример:

enter image description here

В приведенной выше таблице соотношение между не первичным ключом атрибутом «postal_code», а другим, не основным атрибутом ключа «City» является гораздо более сильным, чем отношение между первичным ключом атрибут 'student_id' и атрибут non primary key 'postal_code'. Это приводит к тому, что вышеуказанная таблица имеет транзитивную функциональную зависимость.

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

данных зависит от ключа [1nf], весь ключевой [2НФ] и ничего, кроме ключа [3NF]

таблицы без нормализации

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

В приведенном ниже примере для student_id = 2 есть 2 записи из-за разных родительских идентификаторов. Здесь мы можем предположить, что Parent_id = 1 представляет отца, а Parent_id = 3 представляет мать этого студента, чей student_id = 2.

Пример:

enter image description here

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

Правила: 1. Атрибуты должны содержать только атомарные значения 2. Нет две строки данных должны содержать повторяющиеся группа информации 3. Каждая таблица должна иметь первичный ключ

Шаг 1:

enter image description here

Правило 1 выполнен в предыдущем шаге, но до сих пор она не удовлетворяет правило 2 и правило 3.

Шаг 2: В таблицах ниже в настоящее время удовлетворяет правило 1, Правило 2 и Правило 3 1NF.

enter image description here

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

Правила:

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

За исключением первой таблицы, все остальные таблицы из 1NF удовлетворяют требованиям 2NF. В первой таблице столбец «возраст» зависит только от столбца «student_id». Это нарушает Правило 2 2NF. Поскольку все столбцы без ключа должны полностью зависеть от столбцов первичного ключа. Таким образом, нормированные таблицы согласно 2NF приведены ниже.

enter image description here

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

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

Правила:

  1. Таблицы должны удовлетворять второй нормальной форме (2НФ)
  2. Там не должно быть каких-либо переходных функциональных зависимостей в таблицах

За исключением последней таблицы все остальные таблицы из 2NF удовлетворяют 3NF. Это связано с тем, что столбец «город» сильнее зависит от столбца «postal_code», чем первичный ключ «student_id», который делает транзитный функционал столбца «городом» зависимым от столбца «student_id». Таким образом, окончательные нормализованные таблицы согласно 3NF приведены ниже.

enter image description here

* Атрибут:

- Рассмотрим таблицу студентов. Здесь student_name, age и т. Д. Считаются атрибутами, которые будут заголовком для соответствующих столбцов.

================================================================================================================================== ==================================== Simple examples - database normalization

Смежные вопросы