Мы рассмотрели несколько аспектов нормализации таблицы базы данных. Во-первых, мы обсудили основные принципы нормализации базы данных. В прошлый раз мы исследовали основные требования, установленные первой нормальной формой (1NF). Теперь давайте продолжим наше путешествие и рассмотрим принципы второй нормальной формы (2NF).
Общие требования 2NF
- Удалите подмножества данных, которые применяются к нескольким строкам таблицы, и поместите их в отдельные таблицы.
- Создавайте отношения между этими новыми таблицами и их предшественниками с помощью внешних ключей.
Эти правила можно суммировать в простом заявлении: 2NF пытается уменьшить количество избыточных данных в таблице, извлекая его, помещая в новые таблицы и создавая отношения между этими таблицами.
Давайте посмотрим на пример. Представьте себе интернет-магазин, который поддерживает информацию о клиентах в базе данных. У них может быть одна таблица под названием «Клиенты» со следующими элементами:
- CustNum
- Имя
- Фамилия
- Адрес
- город
- государственный
- ZIP
Краткий обзор этой таблицы показывает небольшое количество избыточных данных. Мы храним записи «Sea Cliff, NY 11579» и «Miami, FL 33157» дважды в каждом. Теперь на нашем простом примере это может показаться слишком большим, но представьте себе пустое пространство, если в нашей таблице было тысячи строк. Кроме того, если бы код ZIP для Sea Cliff изменился, нам нужно было бы сделать это изменение во многих местах всей базы данных.
В структуре базы данных, совместимой с 2NF, эта избыточная информация извлекается и сохраняется в отдельной таблице. Наша новая таблица (назовем ее ZIP) может иметь следующие поля:
- ZIP
- город
- государственный
Если мы хотим быть суперэффективными, мы можем даже заполнить эту таблицу заранее - почтовое отделение предоставляет каталог всех действительных почтовых индексов и их отношений с городом / государством. Несомненно, вы столкнулись с ситуацией, когда этот тип базы данных был использован. Кто-то, принимающий заказ, мог бы сначала спросить вас о вашем почтовом индексе, а затем знал город и страну, из которой вы звонили. Этот тип компоновки уменьшает ошибку оператора и повышает эффективность.
Теперь, когда мы удалили дублирующие данные из таблицы Customers, мы выполнили первое правило второй нормальной формы. Нам все еще нужно использовать внешний ключ, чтобы связать эти две таблицы вместе. Мы будем использовать почтовый индекс (первичный ключ из таблицы ZIPs), чтобы создать эти отношения. Вот таблица наших новых клиентов:
- CustNum
- Имя
- Фамилия
- Адрес
- ZIP
Теперь мы минимизировали объем избыточной информации, хранящейся в базе данных, и наша структура находится во второй нормальной форме.
