Что такое Нормализация (или Нормализация)?
8 ответов
Нормализация должна в основном разработать схему базы данных, таким образом, что дублирующихся и избыточных данных избегают. Если некоторая часть данных дублирована несколько мест в базе данных, существует риск, что это обновляется в одном месте, но не другом, ведя к повреждению данных.
существует много уровней нормализации от 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
Этот дизайн является проблемой, потому что имя повторяется на каждый столбец, даже при том, что имя всегда определяется UserId. Это делает теоретически возможным изменить имя Sue в одной строке а не другом, который является повреждением данных. Проблема решена путем разделения таблицы в два и создания первичного ключа / отношения внешнего ключа:
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
Теперь может казаться, что у нас все еще есть избыточные данные, потому что UserId повторяются; Однако ограничение PK/FK гарантирует, что значения не могут быть обновлены независимо, таким образом, целостность безопасна.
действительно ли это важно? Да, это очень важно. При наличии базы данных с ошибками нормализации Вы открываете риск получения недопустимых или поврежденных данных в базу данных. Так как данные "живут навсегда", очень трудно избавиться от поврежденных данных, когда сначала это ввело базу данных.
не боятся нормализации . Официальные технические определения уровней нормализации являются довольно тупыми. Это заставляет его казаться, что нормализация является сложным математическим процессом. Однако нормализация является в основном просто здравым смыслом, и Вы найдете, что при разработке схемы базы данных с помощью здравого смысла это будет обычно полностью нормализоваться.
существует много неправильных представлений вокруг нормализации:
-
некоторые полагают, что нормализованные базы данных медленнее, и денормализация улучшает производительность. Это только верно в совершенно особых случаях как бы то ни было. Обычно нормализованная база данных является также самой быстрой.
-
иногда нормализация описана как постепенный процесс проектирования, и необходимо решить, "когда остановиться". Но на самом деле уровни нормализации просто описывают различные определенные проблемы. Проблемой, решенной нормальными формами выше 3-го NF, являются довольно редкие проблемы во-первых, таким образом, возможности состоят в том, что Ваша схема уже находится в 5 нФ.
это относится к чему-нибудь за пределами баз данных? Не непосредственно, нет. Принципы нормализации довольно специфичны для реляционных баз данных. Однако общая основная тема - что у Вас не должно быть дублирующихся данных, если различные экземпляры могут выйти из синхронизации - может быть применена широко. Это в основном принцип DRY .
Правила нормализация (источник: неизвестный)
... Поэтому помогите мне Codd.
Самое главное это служит для удаления дублирования из записей базы данных. Например, если у Вас есть больше чем одно место (таблицы), где имя человека могло подойти, Вы перемещаете имя к отдельной таблице и еще ссылаетесь на него везде. Таким образом, если необходимо изменить имя человека позже Вы только, должен изменить его в одном месте.
Это крайне важно для надлежащего проектирования баз данных, и в теории необходимо использовать его как можно больше для хранения целостности данных. Однако при получении информации от многих таблиц Вы теряете некоторую производительность, и вот почему иногда Вы видели денормализованные таблицы базы данных (также названный сглаженный) используемый в важных приложениях производительности.
Мой советовать должен запуститься с хорошей степени нормализации и только сделать de-нормализацию, когда действительно необходимый
P.S. также проверка эта статья: http://en.wikipedia.org/wiki/Database_normalization для чтения больше на предмете и о так называемом нормальные формы
Нормализация процедура раньше устраняла дублирование и функциональные зависимости между столбцами в таблице.
Там существуют несколько нормальных форм, обычно обозначаемых числом. Более высокое количество означает меньше дублирований и зависимостей. Любая таблица SQL находится в 1 нФ (первая нормальная форма, в значительной степени по определению), Нормализация означает изменять схему (часто делящий таблицы) обратимым способом, давая модель, которая функционально идентична, кроме с меньшим дублированием и зависимостями.
Дублирование и зависимость данных являются нежелательным, потому что это может привести к inconsisencies при изменении данных.
Заключение в кавычки главного судьи Date: Теория практична.
Отклонения от нормализации приведут к определенным аномалиям в Вашей базе данных.
Отклонения от Первой Нормальной формы вызовут аномалии доступа, означая, что необходимо анализировать и просканировать отдельные значения для нахождения то, что Вы ищете. Например, если одно из значений является строкой "Форд, Кадиллак", как дано более ранним ответом, и Вы ищете все случаи "Форда", Вы оказываетесь перед необходимостью раскрывать строку и смотреть на подстроки. Это, в некоторой степени, побеждает цель хранить данные в реляционной базе данных.
определение Первой Нормальной формы изменилось с 1970, но те различия не должны касаться Вас на данный момент. При разработке таблиц SQL с помощью реляционной модели данных таблицы автоматически будут в 1 нФ.
Отклонения от Второй Нормальной формы и вне вызовут аномалии обновления, потому что тот же факт хранится больше чем в одном месте. Эти проблемы лишают возможности хранить некоторые факты, не храня другие факты, которые не могут существовать, и поэтому должны быть изобретены. Или когда факты изменяются, Вам, вероятно, придется определить местоположение всех пайс, где факт хранится, и обновите все те места, чтобы Вы не заканчиваете с базой данных, которая противоречит себе. И, когда Вы идете для удаления строки из базы данных, можно найти, если Вы делаете, удаление единственного места, где факт, который все еще необходим, хранится.
Это логические проблемы, не проблемы производительности или проблемы свободного пространства. Иногда можно обойти эти аномалии обновления тщательным программированием. Иногда (часто) лучше предотвратить проблемы во-первых путем соблюдения нормальных форм.
Несмотря на значение в том, что было уже сказано, нужно упомянуть, что нормализация является восходящим подходом, не, вершина вниз приближается. Если Вы будете следовать за определенными методологиями в своем анализе данных, и в Вашем начальном дизайне, Вам можно гарантировать это, дизайн будет соответствовать 3 нФ по крайней мере. Во многих случаях дизайн будет полностью нормализован.
то, Где можно действительно хотеть применить понятия, преподававшие под нормализацией, - когда Вам дают данные прежней версии из унаследованной базы данных или из файлов, составленных из записей, и данные были разработаны в полном незнании нормальных форм и последствиях отступания от них. В этих случаях Вы, возможно, должны обнаружить отклонения от нормализации и исправить дизайн.
Предупреждение: нормализация часто преподается с религиозным подтекстом, как будто каждое отклонение от полной нормализации является грехом, преступлением против Codd. (мало игры слов там). Не покупайте это. Когда Вы действительно, действительно изучите проектирование баз данных, Вы будете не только знать, как следовать правилам, но также и знать, когда безопасно повредить их.
Это предназначается для сокращения дублирования данных.
Для более формального обсуждения, посмотрите Википедию 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, следующий шаг обычно к [1 113], Денормализовывают это логическим способом ускорить запросы и уменьшить сложность определенных общих вставок. Однако Вы не можете сделать этого хорошо, правильно не нормализуя его сначала.
идея, являющаяся, что избыточная информация уменьшается до однократного въезда. Это особенно полезно в полях как адреса, где г-н Chris отправляет свой адрес как Единицу, 7 123 Main St. и г-жа Chris перечисляют Комплект 7 123 Мэйн-Стрит, который обнаружился бы в исходной таблице как два отличных адреса.
Как правило, используемая техника должна найти повторенные элементы и изолировать те поля в другую таблицу с уникальными идентификаторами и заменять повторные элементы первичным ключом, ссылающимся на новую таблицу.
Нормализация является одним из фундаментальных понятий. Это означает, что две вещи не влияют друг на друге.
базы данных In конкретно означают, что два (или больше) таблицы не содержат те же данные, т.е. не имеют никакого дублирования.
На первом взгляде, который действительно хорош, потому что Ваши возможности сделать некоторые проблемы синхронизации близко к нулю, Вы всегда знаете, где Ваши данные, и т.д. Но, вероятно, Ваше количество таблиц вырастет, и у Вас будут проблемы пересечь данные и получить некоторые сводные результаты.
Так, в конце Вы закончите с проектированием баз данных, которое не является чисто нормализованный с некоторым дублированием (это будет на некоторых возможных уровнях нормализации).
Это помогает предотвратить дубликат (и хуже, конфликтуя) данные.
Может оказать негативное влияние на производительность все же.