Нормализация в MySQL
В мире Lisp это произошло несколько раз. конечно, язык является столь динамичным, что обычно эволюция просто удерживает от использования часть стандартной библиотеки и делает стандарт другой частью.
также, Lua 4 to 5 был довольно значительным; но ядро языка так минимально, что даже широко достигающие изменения документируются в несколько страниц.
6 ответов
Здесь я пытаюсь объяснить нормализацию в терминах непрофессионала. Во-первых, это то, что применимо к реляционным базам данных (Oracle, Access, MySQL), так что это не только для MySQL.
Нормализация - это обеспечение того, чтобы каждая таблица имела только минимальные поля, и избавление от зависимостей. Представьте, что у вас есть запись о сотруднике, и каждый сотрудник принадлежит к отделу. Если вы сохраняете отдел в виде поля вместе с другими данными сотрудника, у вас возникает проблема - что произойдет, если отдел будет удален? Вы должны обновить все поля отдела, и есть вероятность ошибки. А что делать, если у некоторых сотрудников нет отдела (может быть, вновь назначенного?). Теперь будут нулевые значения.
Короче говоря, нормализация состоит в том, чтобы избежать пустых полей, и убедитесь, что все поля в таблице принадлежат только одному домену описываемых данных. Например, в таблице сотрудников поля могут быть идентификатором, именем, номером социального страхования, но эти три поля не имеют ничего общего с отделом. Только идентификатор сотрудника описывает, к какому отделу принадлежит сотрудник. Таким образом, это означает, что отдел, в котором находится сотрудник, должен быть в другой таблице.
Вот простой процесс нормализации.
EMPLOYEE ( < employee_id >, name, social_security, department_name)
Это не нормализовано, как объяснялось. Нормализованная форма может выглядеть так:
EMPLOYEE ( < employee_id >, name, social_security)
Здесь таблица Employee отвечает только за один набор данных. Итак, где мы храним, к какому отделу принадлежит сотрудник? В другой таблице
EMPLOYEE_DEPARTMENT ( < employee_id >, department_name )
это не оптимально. Что делать, если название отдела изменится? (это происходит в правительстве США постоянно). Следовательно, лучше сделать это
EMPLOYEE_DEPARTMENT ( < employee_id >, department_id )
DEPARTMENT ( < department_id >, department_name )
Есть первая нормальная форма, вторая нормальная форма и третья нормальная форма. Но если вы не изучаете курс БД, я обычно выбираю наиболее нормализованную форму, которую могу понять.
Надеюсь, это поможет.
Нормализация предназначена не только для MYSql. Это общая концепция базы данных.
Нормализация - это процесс эффективно организовать данные в база данных. Есть две цели процесс нормализации: устранение избыточные данные (например, хранение одни и те же данные в более чем одной таблице) и обеспечение зависимости данных смысл (хранение только связанных данных в Таблица). И то, и другое - достойные цели поскольку они уменьшают объем пространства база данных потребляет и гарантирует, что данные логически сохраняется.
Нормальные формы в SQL приведены ниже.
Первая нормальная форма (1NF): Отношение считается, что он находится в 1НФ, если у него есть только однозначные атрибуты, ни повторение массивов и не допускается.
Вторая нормальная форма (2NF): отношение считается находящимся в 2НФ, если он находится в 1НФ и каждый неключевой атрибут полностью функционально зависит от первичного ключ.
Третья нормальная форма (3NF): Мы говорим, что отношение находится в 3НФ, если оно находится в 2НФ и не имеет транзитивных зависимостей.
Нормальная форма Бойса-Кодда (BCNF): A называется принадлежащим BCNF, если и только если каждый определитель в отношение - это кандидатный ключ.
Четвертая нормальная форма (4NF): отношение считается находящимся в 4НФ, если он находится в BCNF и не содержит многозначной зависимости.
Пятая нормальная форма (5NF): отношение считается, что он находится в 5NF тогда и только тогда, когда каждый подразумевается зависимость соединения в отношении ключами-кандидатами отношения.
Нормальная форма ключа домена (DKNF): мы говорим что отношение находится в DKNF, если оно без каких-либо аномалий модификации. Вставка, удаление и обновление аномалии модифицируются anomalies
Seel also
It's a technique for ensuring that your data remains consistent, by eliminating duplication. So a database in which the same information is stored in more than one table is not normalized.
See the Wikipedia article on Database normalization.
(It's a general technique for relational databases, not specific to MySQL.)
проверьте в этом сообщении есть полезные предложения
Учебник Барри по пониманию схемы базы данных
http://www.youtube.com/watch?v=KqvIGYjcLQ4
При создании схемы базы данных для вашего приложения вы должны убедиться, что вы избегаете хранения любой информации в более чем одном столбце в разных таблицах.
Как и каждая таблица в вашей БД, идентифицирует значимый объект в вашем приложении, уникальный идентификатор является обязательным столбцом для них.
Теперь, при выборе схемы хранилища, между этими объектами (таблицами) выявляются различные виды отношений, а именно , один-к-одному, один-ко-многим, многие-ко-многим.
- Для отношений один-к-одному (например, A Студент имеет уникальное звание в class), ту же таблицу можно использовать для сохранить столбцы (из обеих таблиц).
- Для отношения «один ко многим» (например, В семестре может быть несколько курсы), внешний ключ создается в родительской таблице.
- Для отношения «многие ко многим» (например, Профессор посещает многих студентов и наоборот), третья таблица должна быть создан (с первичным ключом из обе таблицы как составной ключ), и связанные данные обеих таблиц будут
После того, как вы выполните все эти сценарии, ваша схема базы данных будет нормализована до 4NF.
In the field of relational database design, normalization is a systematic way of ensuring that a database structure is suitable for general-purpose querying and free of certain undesirable characteristics—insertion, update, and deletion anomalies—that could lead to a loss of data integrity.[1] E.F. Codd, the inventor of the relational модель, ввела понятие нормализация и то, что мы теперь знаем как первая нормальная форма в 1970 году. [2] Кодд продолжил определение второго и третьего нормальные формы в 1971 г. [3], а Кодд и Раймонд Ф. Бойс определил Нормальная форма Бойса-Кодда в 1974 г. [4] Высшие нормальные формы были определены другие теоретики в последующие годы, последний был шестым нормальным форма введена Крисом Дейтом, Хью Дарвен и Никос Лоренцос в 2002. [5]
Неформально реляционная база данных. таблица (компьютеризированное представление отношения) часто описывается как "нормализованный", если он в третьем нормальная форма (3НФ). [6] Большинство столов 3NF свободны от вставки, обновления и аномалии удаления, т.е. в большинстве случаев Таблицы 3NF соответствуют BCNF, 4NF и 5NF (но обычно не 6NF).
Стандартный элемент дизайна базы данных руководство состоит в том, что дизайнер должен create a fully normalized design; selective denormalization can subsequently be performed for performance reasons.[7] However, some modeling disciplines, such as the dimensional modeling approach to data warehouse design, explicitly recommend non-normalized designs, i.e. designs that in large part do not adhere to 3NF.[8]
Edit: Source: http://en.wikipedia.org/wiki/Database_normalization