Нормализация объектов в MySQL
Источник: webadequate.ru
Итак, сервер установили, минимальные его настройки произвели, теперь необходимо познакомиться с основными понятиями и принципами проектирования баз данных. Сразу хочу отметить, что в этом цикле статей мы не будем рассматривать PHP и Apache. А все потому, что для разработки каких-либо (да почти любых) web-проектов база данных используется повсеместно.
Это раньше, лет десять тому назад, вебмастера часто любили использовать на своих сайтах скрипты не использующие БД: отдельная плата за нее, незнание методик работы с БД и прочее. А этих скриптов было тогда пруд пруди, весь интернет был завален ими. Надо заметить, что все пароли, все данные, вся личная информация пользователя и даже данные администратора(!) в таких скриптах содержалась в обычных txt файлах, 
получить доступ к которым не составляло никакого труда. О последствиях думаю можно и не говорить. 
Поэтому, отсутствие базы данных - нарушение элементарной политики безопасности проекта и сейчас же без нее уже сложно представить работу любого сайта.
Нормализация БД
Нормализация БД - один из важнейших этапов при проектировании базы данных. Простыми словами можно сказать, что нормализация - это проектирование базы данных так, чтобы она была компактной (может даже не корректно немного сказано) и не несла логическую избыточность. Это своего рода правила проектировки БД. Всего несколько разновидностей нормализации, так называемые нормальные формы, их порядка ~6-7. Все они идут в порядке усложнения от простого. Все рассматривать конечно же не будем ибо это целая эпопея. 
Да и для проектировки web-приложений достаточно, чтобы база данных отвечала второй нормальной форме, максимум третьей. Дальше - это уже: "Я круче всех, Я умею вот так". 
Первая нормальная форма:
Объект базы данных находится в первой нормальной форме тогда, когда каждый ее атрибут атомарен. Атрибут атомарен тогда, когда его значение теряет смысл при перестановке любой его частей или при любом разбиении его на части. Если по простому, то данное правило говорит: одно поле - одно значение.
Вот пример таблицы, которая не атамарна, а значит и не отвечает правилам первой нормальной формы:
1. Если у нескольких товаров одинаковая цена, то для каждого товара должна быть отдельная запись.
2. Если у одного товара несколько складов, то для такого случая аналогично должна быть каждая запись. С одним складом и с другим.
3. Часто операторы БД (домохозяйки) любят писать цену с пробелом в качестве разделения числового разряда. Это не правильно, потому что для базы это совершенно два разных значения, причем если поле будет с типом int, то база вообще ошибку выкинет.
А вот пример той же таблицы, которая атомарна, а значит и отвечает правилам первой нормальной формы:
Вторая нормальная форма:
Объект базы данных находится во второй нормальной форме тогда, когда он находится в первой нормальной форме и при этом любой его атрибут, не входящий в состав потенциального ключа, функционально полно зависит от каждого потенциального ключа. 
На самом деле все проще. Это правило говорит об отделении функционально полных зависимостей на отдельные структуры.
Вот пример таблицы, вышеупомянутой таблицы, находящийся во второй нормальной форме:
1. Таким образом, в таблице для каждого товара мы пишем не названия склада, а указываем его первичный ключ именуемый как ID. А сами названия складов выносим в отдельную таблицу.
2. Исходя из пункта №1 можно сделать вывод, что наличие первичного ключа, у всех таблиц обязательно.
Это самый популярный способ проектирования БД для web-проектов. И он действительно удобен. Условно предположим, что у Вас на предприятии поменялось название склада, Вам необходимо будет сделать всего лишь одно исправление в таблице "Склады", а не править несколько тысяч записей. А это пришлось бы делать, если бы в каждом поле "Склад", название его было бы прописано руками. Вот таким образом мы и произвели отделение полной функциональной зависимости (складов) в отдельную таблицу.
Третья нормальная форма:
Объект базы данных находится в третьей нормальной форме тогда, когда он находится во второй нормальной форме и отсутствуют транзитивные зависимости не ключевых объектов от ключевых. 
Транзитивная зависимость - это очевидная зависимость между полями. Если поле А равно "чему то", то поле Б обязательно будет равно "вот этому" и никак иначе. А если поле Б равно "вот этому", то тогда поле "С" будет равно "другому" и никак иначе. Вот такой зависимости между объектами быть не должно. Сейчас на примере будет понятно.
Итак, предположим, что в таблице "Склады" добавилась информация об их адресах (добавлены столбцы "Город" и "Почтовый индекс"):
В данном примере есть транзитивная зависимость, а именно это поля "Город" и "Индекс". Если индекс равен 630423, то мы уже знаем, что это явно Новосибирск и никак иначе, других городов с таким индексом нет. Вот это и есть транзитивная зависимость от которой необходимо избавляться, путем разбиения ее на отдельные таблицы.
В конечном итоге, наша таблица складов разбилась на 2 таблицы и полностью отвечает правилам третьей нормальной формы:
Если Вы заметили, в таблице "Индексы" в качестве первичного ключа используется не ID (суррогатный ключ генерируемый самой системой), а сам номер индекса т.к. он уникален, не может повторяться и не изменяется с течением времени.