Зачем записи нужен собственный идентификатор, как заказ ссылается на клиента и какие ошибки помогают предотвратить ключи. Объяснение без SQL-запросов.
Почему имени клиента недостаточно
Представим условный сервис доставки. В нём зарегистрировались две Анны Смирновы, и обе заказывают продукты. Если отличать покупателей только по имени, заказ легко связать не с тем человеком. Номер телефона тоже неудобен как постоянная опора: человек может его поменять. Нужен признак, по которому система однозначно находит конкретную запись.
Такой признак называют идентификатором. Он не обязан быть понятным покупателю: его задача — помогать системе не путать записи. При этом идентификатор записи и реальный человек не одно и то же. Если Анна зарегистрировалась дважды, две разные записи сами по себе не доказывают, что перед нами два разных человека.
Первичный ключ отличает одну запись от другой
Первичный ключ — выбранный уникальный идентификатор строки таблицы. Согласно документации PostgreSQL, его значения должны быть уникальными и не пустыми. Ключ может состоять из одного поля или сочетания нескольких. Это правило базы данных, а не просто договорённость сотрудников внимательно вводить сведения.
В нашем условном сервисе каждый клиент получает внутренний номер. Два клиента не могут иметь один и тот же первичный ключ. В отдельной таблице заказы получают свои номера: номер покупателя и номер заказа отвечают на разные вопросы. Первый помогает понять, кто покупает, второй — о какой именно покупке идёт речь. Даже у постоянного клиента каждый новый заказ остаётся отдельным событием.
Источник: PostgreSQL: ограничения и ключи.
Внешний ключ показывает, к кому относится запись
В заказе можно хранить ссылку на клиента через его идентификатор. Такое поле при заданном ограничении внешнего ключа связывает записи и помогает поддерживать ссылочную целостность: непустая ссылка должна вести на допустимую существующую запись. Внешний ключ может ссылаться не только на первичный ключ, но и на подходящее уникальное ограничение.
В примере Microsoft с таблицами клиентов и заказов именно ссылка из заказа позволяет установить эту связь. Информация о покупателе хранится отдельно от списка его покупок. В учебной модели это удобно: смена контактных данных не требует исправлять имя во всех заказах. В реальной системе некоторые сведения заказа могут специально сохранять в историческом виде — например, адрес, на который доставляли конкретную покупку.
Источник: Microsoft: таблицы и связи между ними.
Повторяющийся номер здесь не обязательно ошибка
Пусть у первого клиента три заказа, а у второго — один. В таблице клиентов будет две записи, в таблице заказов — четыре. Идентификатор первого клиента встретится в заказах три раза: это ожидаемо, потому что один человек может покупать неоднократно. Уникальными должны оставаться собственные номера заказов.
Отсюда частая ловушка при чтении отчётов. После объединения клиентов с заказами строк становится больше, чем людей. Четыре строки не означают четырёх покупателей. Сначала нужно понять, что представляет одна строка результата: человека, покупку или товар внутри покупки. Ключи помогают описать связи, но не выбирают за аналитика правильный смысл показателя.
Что произойдёт при удалении клиента
Если удалить запись клиента, на которую ссылаются заказы, возникает вопрос: что делать со связями? Базы данных позволяют задать разные правила — например, запретить удаление при наличии ссылок или распространить удаление на зависимые записи. Конкретное поведение определяется настройкой и требованиями системы.
В нашем примере нельзя просто выбрать самый удобный вариант для разработчика: история заказов может быть нужна службе поддержки. Сначала команда решает, какие сведения должна сохранять система, затем закрепляет это в модели. Само наличие ключей не означает, что любое удаление безопасно или что все бизнес-правила уже учтены.
Как читать незнакомую таблицу
Начните с трёх вопросов: что означает одна строка, чем она отличается от остальных и на какие сущности ссылается. Затем уточните, действительно ли правила проверяются базой, или идентификаторы лишь записаны в выгрузке. Две колонки с одинаковыми названиями ещё не гарантируют правильной связи.
Для новичка полезнее сначала нарисовать на бумаге несколько клиентов и заказов, чем запоминать технические термины отдельно. Проверьте, удаётся ли связать каждый заказ с покупателем и объяснить повторения. Это подготовит к осмысленному чтению отчётов и изучению SQL — языка работы с данными, где понимание связей важнее механического объединения таблиц.
Читайте также
Следующий шаг
Если хотите изучить направление системно, посмотрите программу «SQL инженер» в NovaData. Сопоставьте темы курса со своими задачами и уровнем подготовки.
