Что такое нормализация (или нормализация)?
Почему ребята из базы данных говорят о нормализации?
Что это? Как это поможет?
применяется ли это к чему-либо за пределами баз данных?
10 ответов
нормализация в основном заключается в разработке схемы базы данных, чтобы избежать дублирования и избыточных данных. Если некоторая часть данных дублируется в нескольких местах базы данных, существует риск того, что она обновляется в одном месте, но не в другом, что приводит к повреждению данных.
существует ряд уровней нормализации от 1. нормальная форма через 5. нормальная форма. Каждая нормальная форма описывает, как избавиться от какой-то конкретной проблемы, обычно связанной с избыточность.
некоторые типичные ошибки нормировки:
(1) с более чем одним значением в ячейке. Пример:
UserId | Car
---------------------
1 | Toyota
2 | Ford,Cadillac
здесь столбец "Car" (который является строкой) имеет несколько значений. Это оскорбляет первую нормальную форму, которая говорит, что каждая ячейка должна иметь только одно значение. Мы можем нормализовать эту проблему, имея отдельную строку на автомобиль:
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
проблема с несколькими значениями в одной ячейке заключается в том, что сложно обновить, сложно запрос против, и вы не можете применять индексы, ограничения и так далее.
(2) наличие избыточных неключевых данных (т. е. данные повторяются без необходимости в несколько строк). Пример:
UserId | UserName | Car
-----------------------
1 | John | Toyota
2 | Sue | Ford
2 | Sue | Cadillac
этот дизайн является проблемой, потому что имя повторяется в каждом столбце, даже если имя всегда определяется идентификатором пользователя. Это теоретически позволяет изменить имя Sue в одной строке, а не в другой, что является повреждением данных. Задача решается путем разбиения таблицы во-вторых, и создание отношения первичный ключ / внешний ключ:
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
теперь может показаться, что у нас все еще есть избыточные данные, потому что UserId повторяются; однако ограничение PK/FK гарантирует, что значения не могут быть обновлены независимо, поэтому целостность безопасна.
это важно? Да, это очень важно. Имея базу данных с ошибками нормализации, вы открываете риск получения недействительных или поврежденных данных в базу данных. Поскольку данные "живут вечно", очень трудно избавиться от поврежденных данных, когда они впервые вошли в базу данных.
не бойтесь нормализации. Официальные технические определения уровней нормализации довольно тупы. Это звучит так, как будто нормализация-сложный математический процесс. Однако нормализация-это в основном просто здравый смысл, и вы обнаружите, что если вы создадите схему базы данных с использованием здравого смысла, она обычно будет полностью нормированный.
существует ряд неправильных представлений о нормализации:
некоторые считают, что нормализованные базы данных медленнее, а денормализация повышает производительность. Однако это справедливо только в особых случаях. Обычно нормализованная база данных также является самой быстрой.
иногда нормализация описывается как постепенный процесс проектирования, и вы должны решить, "когда остановиться". Но на самом деле нормализация уровни просто описывают различные специфические проблемы. Проблема, решаемая обычными формами выше 3rd NF, в первую очередь довольно редкие проблемы, поэтому есть вероятность, что ваша схема уже находится в 5NF.
применяется ли это к чему-либо за пределами баз данных? не напрямую, нет. Принципы нормализации достаточно специфичны для реляционных баз данных. Однако общая основная тема - что у вас не должно быть дубликатов данных, если разные экземпляры могут get out of sync - может применяться широко. Это в основном сухой принцип.
правила нормализация (источник: неизвестный)
... Так помоги мне Codd.
самое главное, он служит для удаления дублирования из записей базы данных. Например, если у вас есть несколько мест (таблиц), где может появиться имя человека, вы перемещаете имя в отдельную таблицу и ссылаетесь на нее везде. Таким образом, если вам нужно изменить имя человека позже, вам нужно изменить его только в одном месте.
очень важно для правильного проектирования баз данных и теоретически вы должны использовать его как можно больше, чтобы сохранить целостность данных. Однако, когда получение информации из многих таблиц вы теряете некоторую производительность, и поэтому иногда вы можете видеть денормализованные таблицы базы данных (также называемые сплющенными), используемые в критически важных приложениях.
мой совет-начать с хорошей степени нормализации и только делать де-нормализацию, когда это действительно необходимо
P. S. также проверить эту статью: 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, следующим шагом обычно является денормализация это логический способ ускорить запросы и уменьшить сложность некоторых общих вставок. Однако вы не можете сделать это хорошо, не нормализовав его сначала.
идея заключается в том, что избыточная информация сводится к одной записи. Это особенно полезно в таких областях, как адреса, где г-н Крис подает его адрес-Мэйн-Стрит, 7123, а миссис Крис-Мэйн-Стрит, 7123, указан в таблице как два разных адреса.
обычно используется метод поиска повторяющихся элементов и изоляции этих полей в другую таблицу с уникальными идентификаторами и замены повторяющихся элементов первичным ключом, ссылающимся на новую таблицу.
цитирование даты CJ: теория практична.
отклонения от нормализации приведут к определенным аномалиям в вашей базе данных.
отклонения от первой нормальной формы вызовут аномалии доступа, что означает, что вам нужно разложить и сканировать отдельные значения, чтобы найти то, что вы ищете. Например, если одним из значений является строка "Ford, Cadillac", как указано в предыдущем ответе, и вы ищете все ocurrences "Ford", вы придется взломать строку и посмотреть на подстроки. Это в некоторой степени противоречит цели хранения данных в реляционной базе данных.
определение первой нормальной формы изменилось с 1970 года, но эти различия не должны касаться вас сейчас. Если вы разрабатываете свои таблицы SQL с использованием реляционной модели данных, ваши таблицы будут автоматически находиться в 1NF.
отклонения от второй нормальной формы и за ее пределами вызовут аномалии обновления, потому что один и тот же факт хранится в нескольких местах. Эти проблемы делают невозможным хранение некоторых фактов без хранения других фактов, которые могут не существовать и поэтому должны быть изобретены. Или когда факты меняются, вам может потребоваться найти все plces, где хранится факт, и обновить все эти места, чтобы вы не получили базу данных, которая противоречит сама себе. И, когда вы идете, чтобы удалить строку из базы данных, вы можете обнаружить, что если вы делаете, вы удаляете единственное место, где что еще необходимое хранится.
это логические проблемы, а не проблемы с производительностью или пространством. Иногда вы можете обойти эти аномалии обновления путем тщательного программирования. Иногда (часто) лучше предотвратить проблемы в первую очередь, придерживаясь нормальных форм.
несмотря на ценность в том, что уже было сказано, следует отметить, что нормализация-это подход снизу вверх, а не сверху вниз. Если вы следуете определенным методологиям в своей анализ данных, и в вашей внутренней конструкции, вы можете быть гарантированы что конструкция будет соответствовать к 3NF по крайней мере. Во многих случаях конструкция будет полностью нормализована.
где вы действительно можете захотеть применить концепции, преподаваемые при нормализации, - это когда вам дают устаревшие данные, из устаревшей базы данных или из файлов, состоящих из записей, и данные были разработаны в полном незнании нормальных форм и последствий отхода от них. В этих случаях вы возможно, потребуется обнаружить отклонения от нормализации и исправить конструкцию.
предупреждение: нормализация часто преподается с религиозными обертонами, как будто каждый отход от полной нормализации является грехом, преступлением против Codd. (маленький каламбур). Не покупайся на это. Когда вы по-настоящему изучите дизайн баз данных, вы будете не только знать, как следовать правилам, но и знать, когда их безопасно нарушать.
прежде чем перейти непосредственно к теме "нормализация базы данных и ее типы", нам нужно понять избыточность данных, аномалии вставки/обновления/удаления, частичную зависимость и транзитивную функциональную зависимость.
что такое избыточность данных и аномалия обновления/модификации?
избыточность данных-это ненужное дублирование данных в нескольких таблицах в базе данных или даже в той же таблице. Это увеличивает размер базы данных излишне и снижает эффективность базы данных, вызывая несогласованность данных.
пример:
здесь "student_age" для студента Alex повторяется без необходимости, что, естественно, увеличивает избыточность данных. Когда столбец "student_age" должен быть изменен в будущем, обновление должно быть выполнено на обеих строках студента Alex, как в таблице выше. Этот сценарий известен как аномалия обновления. Если пользователь обновляет только одну строку и забывает обновить другую строку, что приведет к несогласованности данных.
что такое аномалия вставки?
аномалия вставки возникает, когда определенные значения атрибута* не могут быть вставлены в таблицу без наличия дополнительных данных, связанных с этим конкретным значением.
пример:
здесь предполагается, что "student_name" и " exam_registered’ являются составной первичный ключ (первичный ключ, содержащий несколько столбцов). Первичный ключ всегда должен быть уникальным, не должен содержать нулевых значений и должен однозначно идентифицировать каждую строку в таблице. Теперь предположим, что средняя школа пытается ввести новый экзамен под названием химия. Вначале ни один студент не был зарегистрирован на этом курсе. Поскольку приведенная выше таблица не будет принимать нулевое значение в столбце "student_name", нам нужно подождать, пока не будет зарегистрирован хотя бы один студент, чтобы сделать запись для экзамена Химия в приведенной выше таблице.
что такое аномалия удаления?
аномалия удаления возникает, когда некоторые важные значения атрибута * теряются из-за удаления других не обязательных значений.
пример:
здесь "student_name" и "exam_registered" считаются составным первичным ключом (первичный ключ, содержащий несколько столбцов). Первичный ключ должен быть всегда уникальный и не должен содержать нулевых значений, и он должен однозначно идентифицировать каждую строку в таблице. Теперь предположим, что студент по имени Джон отменил свою регистрацию на экзамен по английскому языку. Поскольку столбец "student_name" не может содержать нулевое значение, мы будем вынуждены удалить всю строку, которая стоила нам потери экзамена по английскому языку из нашей таблицы. Но все же средняя школа предлагает возможность сдачи экзамена по английскому языку своим ученикам.
что частично зависимость?
говорят, что таблица находится в частичной зависимости, когда атрибут не первичного ключа в этой таблице полностью зависит от части составного атрибута первичного ключа в этой таблице.
пример:
Рассмотрим таблицу, которая имеет 3 столбца с именем "student_name", "student_age" и "exam_registered", как указано выше. Здесь "student_name" и "exam_registered" могут вместе сформировать составной первичный ключ. Обычно каждый столбец первичного ключа в хорошо нормализованной таблице всегда должен зависеть от комплектации составного первичного ключа. Здесь "student_age" зависит только от "student_name" и не относится к "exam_registered", что приводит к частичной зависимости этой таблицы.
что такое транзитивная функциональная зависимость?
таблица находится в транзитивной функциональной зависимости, когда не атрибуты первичного ключа в этой таблице зависит от еще один атрибут non-primary key в этой таблице.
пример:
в приведенной выше таблице связь между атрибутом не первичного ключа "postal_code" и другим атрибутом не первичного ключа "City" намного сильнее, чем связь между атрибутом первичного ключа "student_id" и атрибутом не первичного ключа "postal_code". Это приводит к тому, что приведенная выше таблица находится в транзитивной функциональной зависимости.
с для лучшего понимания вышеперечисленных понятий теперь можно погрузиться в нормализацию таблиц в базах данных.
данные зависят от ключа [1NF], всего ключа [2NF] и ничего, кроме ключ [3НФ]
стол без нормализации
ниже приведен пример денормализованной таблицы, которая будет нормализована в инкрементных шагах в этой статье.
В приведенном ниже примере для student_id=2, есть 2 записи из-за разных родительских идентификаторов. Здесь мы можем предположить, что Parent_id=1 представляет отца, а Parent_id=3 представляет мать этого студента, чей student_id=2.
пример:
первая нормальная форма (1NF)
правила: 1. Атрибуты должны содержать только атомарные значения 2. Нет двух строк данных должна содержать повторяющуюся группу информации 3. Каждая таблица должна иметь первичный ключ
Шаг 1:
Правило 1 выполняется на вышеуказанном шаге, но все же оно не удовлетворяет правилу 2 и правилу 3.
Шаг 2: Приведенные ниже таблицы теперь удовлетворяют правилам 1, 2 и 3 1NF.
вторая нормальная форма (2NF)
правила:
- таблицы должны удовлетворять первому нормальному форма (1НФ)
- в таблицах не должно быть никакой частичной зависимости
кроме первой таблицы, все остальные таблицы из 1NF удовлетворяют 2NF. В первой таблице столбец ‘возраст’ зависит только от столбца ‘student_id’. Это нарушает правило 2 из 2NF. Поскольку все неключевые столбцы должны полностью зависеть от Столбцов первичного ключа. Таким образом, нормализованные таблицы в соответствии с 2NF приведены под.
третья нормальная форма (3NF)
обычно таблица реляционной базы данных часто описывается как "нормализованная", если она соответствует 3NF. Большинство таблиц 3NF свободны от вставки, обновления и удаления аномалий.
правила:
- таблицы должны удовлетворять второй нормальной форме (2NF)
- не должно быть транзитивных функциональных зависимостей в таблицы
кроме последней таблицы, все остальные таблицы из 2NF удовлетворяют 3NF. Это связано с тем, что столбец "город" более сильно зависит от столбца "postal_code", чем первичный ключ "student_id", который делает столбец "город" транзитивным функциональным в зависимости от столбца "student_id". Поэтому окончательное нормализованных таблиц в 3НФ приведены ниже.
*атрибутов:
– Рассмотрим таблицу студентов. Здесь student_name, возраст и т. д. рассматриваются как атрибуты, которые будут заголовок соответствующего столбца.
======================================================================== простые примеры - нормализация базы данных
нормализация является одним из основных понятий. Это означает, что две вещи не влияют друг на друга.
в базах данных конкретно означает, что две (или более) таблицы не содержат одинаковых данных, т. е. не имеют избыточности.
на первый взгляд, что это очень хорошо, потому что ваши шансы сделать некоторые проблемы синхронизации близки к нулю, вы всегда знает, где находятся данные, и т. д. Но, возможно, ваше количество столов будет расти и у вас возникнут проблемы пересечь данные и получить некоторые итоговые результаты.
Итак, в конце вы закончите с дизайном базы данных, который не является чистым нормализованным, с некоторой избыточностью (это будет на некоторых из возможных уровней нормализации).
что такое нормализация?
нормализация-это пошаговый формальный процесс, который позволяет разложить таблицы базы данных таким образом, чтобы оба резервное копирование данных и аномалии обновления есть.
Процесс Нормализации
вежливость
первая нормальная форма если и только если домен каждого атрибута содержит только атомарные значения(атомарное значение - это значение, которое нельзя разделить), а значение каждого атрибута содержит только одно значение из этого домена (пример: - домен для столбца gender: "M", "F". ).
первая нормальная форма обеспечивает соблюдение этих критериев:
- исключить повторяющиеся группы в отдельных таблицах.
- создать отдельную таблицу для каждого набора связанных данных.
- Идентифицируйте каждый набор связанных данные с первичным ключом
вторая нормальная форма = 1НФ + нет частичных зависимостей, т. е. все неключевые атрибуты полностью функционально зависят от первичного ключа.
третья нормальная форма = 2NF + нет транзитивных зависимостей, т. е. все неключевые атрибуты полностью функционально зависят напрямую только от первичного ключа.
Boyce-Codd нормальная форма (или BCNF или 3.5 NF) немножко более сильная версия третьего нормальная форма (3НФ).
Примечание:–вторая, третья и нормальные формы Boyce-Codd связаны с функциональными зависимостями. примеры
четвертая нормальная форма = 3NF + удалить многозначные зависимости
пятая нормальная форма = 4NF + удалить зависимости соединения
Это помогает предотвратить дублирование (и, что еще хуже, конфликтующие) данные.
может отрицательно повлиять на производительность.