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

104

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

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

Применимо ли это к чему-либо за пределами баз данных?

AJ.
источник

Ответы:

171

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

Существует ряд уровней нормализации от 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. Это дает теоретическую возможность изменить имя Сью в одной строке, а не в другой, что является повреждением данных. Проблема решается путем разделения таблицы на две и создания отношения первичный ключ / внешний ключ:

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

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

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

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

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

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

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

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

JacquesB
источник
4
Пример, который вы привели для первого нормального, не совсем верен. Я всегда помню первые три нормальные формы по терминам повторяющийся, избыточный, независимый. Повторение данных относится к тому, когда начинающие разработчики баз данных пишут определения таблиц, которые включают в себя такие столбцы, как DogName1, DogName2, DogName3 и т. Д.
Bill
2
@ Билл: Как вы думаете, почему приведенный мной пример неверен? Вы знаете определение 1NF, где пример подойдет?
JacquesB
Почему нормализация не нужна в объектно-ориентированном программировании - а только когда дело касается баз данных? Я думаю, что уже есть процесс нормализации, встроенный в ядро ​​объектно-ориентированного программирования, не так ли?
Lealo
@Lealo Нет, совсем нет. Вы всегда можете тривиально отобразить состояние объектно-ориентированного проекта на «реляционную» базу данных / дизайн с таблицами - вот что такое ORM, - но база данных / дизайн, которые вы получаете, является реляционным представлением объектно-ориентированного дизайна, а не реляционным представлением бизнес , а не только реляционное представление дизайна OO явно при условии обновления аномалий и избыточность , что нормализация управляет , но методы OO должны обеспечить соблюдение соответствующего (незарегистрированное) (комплексное) ограничение ( «представление инвариантным») вручную.
Филипси
@Lealo: этот принцип применим к ООП в том смысле, что вы никогда не должны иметь одну и ту же информацию (в изменяемой форме) в двух разных объектах, поскольку в этом случае они могут рассинхронизироваться.
JacquesB
45

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

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

... Так помоги мне, Кодд.

ОбеспокоенныйTunbridgeWells
источник
12
Я думаю, что это немного расплывчато без надлежащего контекста, не так ли?
Rik
3
Это может быть немного расплывчато, но это отличное напоминание для тех, кто разбирается в контексте. Я знаю, что такое нормализация и как с ней работать, но никогда не могу вспомнить, что собой представляет каждая из форм.
Бенджамин Атин,
1
Википедия объясняет это здесь: «Требование наличия« ключа »гарантирует, что таблица находится в 1NF; требование, чтобы неключевые атрибуты зависели от« всего ключа », обеспечивает 2NF; кроме того, требование, чтобы неключевые атрибуты не зависели« ни от чего » но ключ «обеспечивает 3НФ».
Kcats Wolfrevo
Согласно википедии, источником является Билл Кент: «[Каждый] неключевой [атрибут] должен предоставлять факт о ключе, весь ключ и ничего, кроме ключа».
apteryx 06
19

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

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

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

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

Илья Кочетов
источник
Вы также будете весьма удивлены, насколько в транзакционных приложениях действительно требуется небольшая денормализация. В одном приложении-монстре, для которого я создавал модель данных, схема с 560 таблицами содержала только 4 элемента денормализованных данных.
ConcernedOfTunbridgeWells,
Это предотвращает «аномалии обновления». Это достигается путем устранения определенных видов дублирования.
S.Lott
«Я советую начинать с хорошей степени нормализации и делать денормализацию только тогда, когда это действительно необходимо». Это очень плохой совет! Я до сих пор не видел надлежащей иллюстрации этой «псевдотеории». Минус 1.
Philippe Grondier
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.

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

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

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

Крис Кадмор
источник
1
BCNF не «идеален». Существуют более высокие нормальные формы, вплоть до 6NF, где все ваши таблицы являются просто ключом и значением данных. Однако его редко используют
Рик
Я не согласен с тем, что BCNF используется редко и обычно денормализован. Фактически, ваш нормализованный пример уже находится в BCNF, и если вы денормализуете его, вы вернетесь к исходной точке.
JacquesB
3

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

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

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

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

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

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

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

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

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

Уолтер Митти
источник
2

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

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

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

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

Ненад Добрилович
источник
2

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

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

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

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

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

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

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

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

Нормальная форма Бойса – Кодда (или BCNF или 3.5NF) является немного более сильной версией третьей нормальной формы (3NF).

Примечание: - Вторая, Третья и нормальные формы Бойса – Кодда связаны с функциональными зависимостями. Примеры

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

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

Премрадж
источник
0

Как говорит Мартин Клеппман в своей книге Designing Data Intensive Applications:

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

Арун
источник
-10

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

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

Брайан Кноблаух
источник
Работая как с нормализованными, так и с ненормализованными данными, я предпочитаю снижение скорости с нормализацией, а не потерю или трудности с обслуживанием приложения или базы данных.
Шалк Верстег,
1
современные механизмы баз данных используют кэширование, которое часто делает нормализованные базы данных более эффективными, чем ненормализованные. если сомневаетесь, измерьте.
Стивен А. Лоу,
1
Денормализованный дизайн может быть быстрее для конкретного запроса, но нормализованный дизайн предлагает компромисс, обеспечивая разумную производительность для гораздо более широкого спектра запросов.
Билл Карвин,
@ Билл, я бы немного не согласился. Единственный способ, которым полностью нормализованная база данных способствует повышению производительности, - это не допустить, чтобы система имела дело с избыточными данными. В остальном это наихудшая ситуация с точки зрения производительности.
Брайан Кноблауч
Этот ответ не добавляет ничего ценного по сравнению с существующими ответами.
cimmanon