Первая нормальная форма — Основы реляционных баз данных

Возьмем для примера обычный интернет-магазин, в котором продается электроника. Каждый раз когда пользователь делает заказ, в базу данных заносится запись об этом (в таблицу order_items). В нее входит вся необходимая информация: какой товар купил пользователь, сколько он стоил, адрес доставки и другое. Затем эти данные используются всеми подразделениями интернет-магазина, начиная от бухгалтеров и заканчивая службой доставки.

Таблица order_items

В первой строке последнего столбца цена указана в долларах, в остальных записях — это рубли. Последняя запись повторяет предыдущую, потому что этот заказ выполнил тот же человек, но сделал это в другое время.

Невооруженным взглядом видно, что в этой табличке много повторяющейся информации. Попробуем привести ее к правильной структуре с точки зрения реляционной модели. Для этого пройдемся по нормальным формам.

Первая нормальная форма сводится к трем правилам:

• Каждая ячейка таблицы может хранить только одно значение
• Все данные в одной колонке могут быть только одного типа
• Каждая запись в таблице должна однозначно отличаться от других записей

Каждая ячейка – одно значение

Вернемся к примеру выше. У одной записи поля item и price содержат два значения через запятую. Такой способ организации данных имеет множество недостатков. Например, пропадает возможность делать обычную выборку по условиям:

-- Как найти записи о всех проданных утюгах?
SELECT * from order_items WHERE item = "?"

Другая проблема связана с типами данных. Поле price в таблице order_items имеет числовой тип (numeric). Если мы захотим хранить там более одного значения, то тип превратится в строковый, а все данные станут обычными строками. При такой организации невозможно проверить корректность данных и формат числа. Становится крайне проблематично выполнить агрегирующие запросы — например, считать выручку за определенный месяц одним запросом.

Избавиться от перечислений в ячейках можно через создание новых записей:

Данные одного типа

Снова вернемся к таблице. Верхняя запись в ней содержит цену в долларах, хотя все остальные цены указаны в рублях. Чисто технически база никак не укажет на это. И доллары, и рубли представлены числами, но с точки зрения программы эти числа имеют совершенно разную природу.

Как и в предыдущем случае, разные данные в рамках одного поля делают невозможным выполнение агрегирующих запросов (поиск сумм, максимального, минимального). Кроме того, усложняется обработка данных на уровне кода. В коде придется каким-то образом понимать, что из себя представляют данные.

Вот еще несколько примеров с похожей ситуацией:

• Хранение даты свадьбы в поле "день рождения"
• Хранение телефона вместо адреса в поле "адрес"

Исправленная версия таблицы:

Уникальные записи

Обратите внимание на последние две записи. Они выглядят идентично, хотя это два разных заказа, сделанных одним человеком в разное время. Вероятно, он купил ноутбук сначала для себя, а потом для супруги.

Реляционная модель требует от нас уникальности каждой записи. Для чего это нужно? Иначе невозможно понять, что к чему относится и с какой записью нужно работать при изменениях. Очень легко начать править не то и потерять важную информацию. Причем мы даже не можем полагаться на порядок данных внутри таблицы, ведь он не гарантирован.

Реализовать уникальность можно несколькими способами, например, добавить новое поле с датой заказа, которое сделает запись уникальной. Этот способ не очень надежный, а главное — не очень удобный в работе. Придется постоянно анализировать весь набор полей. Гораздо лучше добавить первичный ключ.

Первичный ключ это поле или набор полей, которое содержит уникальное значение для каждой записи. Первичный ключ не может меняться, его значение однозначно определяет любую запись в таблице.

В качестве первичного ключа можно использовать какое-то значение из окружающего мира, например email или ФИО, но нужно однозначно убедиться что ключ не будет повторяться. Такой первичный ключ называется естественным. Естественные ключи используют редко из-за их ненадежности. Почти наверняка они не уникальны и могут изменяться или повторяться. Например, номер паспорта меняется при смене паспорта.

Другой подход основан на использовании автоматически генерируемых уникальных значений. Такой первичный ключ называется суррогатным и поддерживается любой базой данных «из коробки». Иногда это просто числа, а иногда — сложные число-буквенные строки (хеши). Добавим в нашу таблицу первичный ключ:

Первичный ключ принято создавать первым полем с названием id. Для первичного ключа обязательно указывать PRIMARY KEY в описании таблицы:

-- Первичный ключ только один на таблицу
CREATE TABLE products (
    id bigint PRIMARY KEY,
    first_name varchar(255),
    last_name varchar(255),
    address varchar(255),
    item varchar(255),
    price numeric -- специальный тип данных, подходящий под работу с деньгами. Обеспечивает высокую точность при расчетах.
);

Такой ключ все еще нужно формировать самостоятельно, но теперь база данных сама следит за уникальностью. При попытке создать запись с повторяющимися первичными ключами возникнет ошибка.

Дополнительные материалы

1. Первичный ключ
2. Внешний ключ
3. Суррогатный ключ

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.