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

В соответствии с третьей нормальной формой нам нужно избегать зависимостей ни от одного ключевого атрибута.

Итак, если у меня есть база данных пользователей

User(username varchar, full_name varchar, country varchar, SSN varchar, UID varchar)

И для каждого пользователя у меня есть его имя пользователя, полное имя, страна и номер социального страхования (уникальный) и еще один номер, уникальный для каждого пользователя. Я хочу использовать имя пользователя в качестве ПЕРВИЧНОГО КЛЮЧА, однако, если вы знаете номер социального страхования человека, вы также можете получить всю информацию об этом пользователе, поскольку он также «УНИКАЛЬНЫЙ».

Не нарушает ли это третью нормальную форму? Я мог бы разделить его на две или более таблиц, например, удалить SSN из User и поместить его в другую таблицу.

SSN(ssn varchar, username varchar)

Однако теперь у меня та же проблема в этой таблице, поскольку два ключа могут использоваться как «ПЕРВИЧНЫЙ КЛЮЧ».

Это нормально? или это нарушает третью форму, и если это так, есть ли какой-нибудь умный способ решить это?


sql primary-key database-normalization candidate-key 3nf
person Eli Braginskiy    schedule 14.01.2018    source источник
comment
Почему это должно нарушать определение? Почему вы не можете определить, так ли это? Найдите определение в учебнике. Попытайся. Показать свою работу. Спросите, когда застряли. В определении будет говориться о CK. И это не будет упоминать ПК. Ваше избегание зависимостей ни от одного ключевого атрибута настолько неясно, что бесполезно. Но даже было ясно, что это определение будет неправильным, потому что в нем не упоминаются CK. Как вы можете правильно рассуждать, если вы не ясны и не понимаете правильных определений?   -  person philipxy    schedule 15.01.2018
comment
@philipxy Вам не нужно так негативно относиться к этому, я, очевидно, исследовал себя и не мог понять тему, верно? Если бы я знал, я бы не спрашивал здесь, И мое определение взято из моего исследования текста.   -  person Eli Braginskiy    schedule 19.01.2018
comment
Я написал кучу полезных вопросов и фактов. Я не знаю, как вы получаете негатив от этого. Что происходит, когда вы отвечаете/обращаетесь к ним? (Я не знаю, о каком определении вы говорите, потому что, как я уже указал, вы его не даете и не применяете, дважды вы просите нас об этом.) Ответ на ваш вопрос - это несколько глав из учебника, поэтому сошлитесь на один и покажите свою работу после него и скажите, где вы застряли. (Десятки учебников по информационному моделированию и проектированию баз данных находятся в свободном доступе в Интернете.)   -  person philipxy    schedule 19.01.2018

Ответы (2)


arrow_upward
2
arrow_downward

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

В таком случае каждый из этих столбцов должен быть явно объявлен как unique и not null. Однако первичным ключом может быть только один столбец.

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

person Gordon Linoff    schedule 14.01.2018
comment
Значит, это не нарушает третью форму? это правильно? - person Eli Braginskiy; 14.01.2018
comment
Добавление суррогата не меняет того, какие другие CK присутствуют или в каких NF находится таблица. Таким образом, это не имеет отношения к выявлению или устранению аномалий обновления, устраняемых нормализацией. - person philipxy; 15.01.2018

arrow_upward
1
arrow_downward

Вы не должны разбивать таблицы на две, потому что в схеме «Пользователь» есть три столбца (имя пользователя, SSN, UID), которые однозначно идентифицируются, и если вы берете «имя пользователя» в качестве первичного ключа, тогда два других столбца (SSN, UID) альтернативный первичный ключ, который называется «ключ-кандидат» в пользовательской схеме. и это не должно нарушать 3NF.

person Usman    schedule 14.01.2018