Требуется ли для таблицы с суррогатным ключом уникальное ограничение на естественный ключ в 1NF?

Question

Прагматики выиграли спор между суррогатом и естественными первичными ключами в пользу суррогатных ключей *. В своей работе я всегда использую столбцы идентификаторов SQL Server, не задумываясь. Но мне приходит в голову, что для того, чтобы таблица была в 1-й нормальной форме, я должен был иметь возможность идентифицировать естественный ключ и применять его с уникальным ограничением. Я не могу сделать это для всех таблиц в моей базе данных, поэтому моя база данных даже не соответствует самым низким критериям нормализации.

Согласны ли вы с тем, что таблица с суррогатным первичным ключом также должна иметь уникальное ограничение на натуральный ключ, чтобы быть в 1NF?

* Я думаю, Джо Селко все еще борется за хороший бой, см. последний абзац .

Отредактировано, чтобы добавить: Спасибо за ответы. У меня сложилось впечатление, что добавление уникального ограничения не является обычной практикой, поэтому я несколько удивлен тем, что ответы до сих пор были единодушными.

Answer 1

Да!

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

Answer 2

Позвольте мне перефразировать вопрос. Интересный момент не в том, находится ли таблица в 1NF или нет. Интересным моментом является наличие естественных данных в 1NF.

Если вы удалите столбец идентификатора, а затем уничтожите дубликаты, вы выполнили то, что называется «проекцией» в реляционном языке. Результат в 1НФ по определению.

Если вы удалите столбец идентификатора, но не удалите дубликаты, вы получите набор строк, а не набор. Если приложение каким-то образом не препятствует попаданию дубликатов в эту сумку, значит, сумка не в 1NF.

Мой ответ сводится к тому же, что и у Джонатана и Тома. В итоге вы переместили защиту целостности данных обратно из СУБД в приложение. Прикладные программисты, как правило, делают это, в этом случае и во многих других. Если они правильно пишут свои приложения, то это вопрос предпочтений. Если они этого не делают, то они возвращались к уровню техники до введения баз данных.

Answer 3

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

Answer 4

Я мог бы заполнить книгу всеми проблемами, которые столбцы IDENTITY вызвали для моих клиентов. С другой стороны, это заставляет меня работать. Если бы все спроектировали свои базы данных в первый раз правильно, мне бы никогда не пришлось заходить и исправлять их:)

Если вы собираетесь использовать IDENTITY для суррогатного ключа, вам нужно сделать именно это. Суррогатный ключ должен быть полностью за кадром. Пользователи никогда не должны видеть их в отчетах, они не должны иметь возможность просматривать строки с ними и т. Д. Кроме того, у вас должен быть естественный ключ, который по определению должен быть уникальным. Эта уникальность должна быть обеспечена в вашей модели данных.

Мой текущий клиент решил, что собирается объединить несколько объектов в своей базе данных. Они, конечно, везде использовали столбцы IDENTITY и отображали их во всех записях внешнего интерфейса. Теперь, когда строки должны быть объединены, возникают коллизии, что означает перенумерацию. Конечно, поскольку пользователи знают эти числа, когда объект перенумеровывается, он полностью бросает пользователя в цикл.