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

Почему ребята из базы данных продолжают нормализацию?

Что это? Как это помогает?

Используется ли это для чего-либо за пределами баз данных?

Ответ 1

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

Существует ряд уровней нормализации от 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

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

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

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

Существует ряд неправильных представлений о нормализации:

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

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

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

Ответ 2

Правила нормализация (источник: неизвестен)

  • Ключ (1NF)
  • Весь ключ (2NF)
  • и ничего, кроме ключа (3NF)

... Так помогите мне Codd.

Ответ 3

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

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

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

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

Ответ 4

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

Существует несколько нормальных форм, обычно обозначаемых числом. Более высокое число означает меньшее количество увольнений и зависимостей. Любая 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.

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

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

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

Ответ 6

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

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

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

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

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

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

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

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

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

Ответ 7

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

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

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

Пример:

введите описание изображения здесь

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

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

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

Пример:

введите описание изображения здесь

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

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

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

Пример:

введите описание изображения здесь

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

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

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

Пример:

введите описание изображения здесь

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

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

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

Пример:

введите описание изображения здесь

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

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

Данные зависят от ключа [1NF], всего ключа [2NF] и ничего, кроме ключ [3NF]

Таблица без нормализации

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

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

Пример:

введите описание изображения здесь

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

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

Шаг 1:

введите описание изображения здесь

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

Шаг 2: Теперь приведенные ниже таблицы соответствуют Правилу 1, Правилу 2 и Правилу 3 1NF.

введите описание изображения здесь

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

Правила:

  • Таблицы должны удовлетворять первой нормальной форме (1NF)
  • В таблицах не должно быть частичной зависимости

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

введите описание изображения здесь

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

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

Правила:

  • Таблицы должны удовлетворять второй нормальной форме (2NF)
  • В таблицах не должно быть транзитивных функциональных зависимостей

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

введите описание изображения здесь

* Атрибут:

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

=============================================== ========================= Простые примеры - нормализация базы данных

Ответ 8

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

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

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

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

Ответ 9

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

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

Процесс нормализации
введите описание изображения здесь Предоставлено

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

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

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

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

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

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

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

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

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

Ответ 10

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

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