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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для более формального обсуждения см. Википедию 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, которые будут отображаться в исходной таблице как два разных адреса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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