Если таблица с суррогатным ключом имеет столбец, который, как известно, имеет уникальные ненулевые значения (например, SSN), нарушает ли он 3NF?

Как я понимаю, третья нормальная форма (3NF) в основном означает, что должен быть ровно один ключ.

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

Игнорирование практических / бизнес-проблем (например, риск безопасности / конфиденциальности при передаче SSN в качестве ключа / FK) с точки зрения строгой схемы, не будет ли такая таблица в 3NF, поскольку фактически существует 2 ключа?

Будет ли зависеть ответ от того, был ли уникальный ключ в другом столбце? Если так, то почему?

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

EFCodd, 1971, Дальнейшая нормализация реляционной модели базы данных

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

К сожалению, в книгах по проектированию и нормализации баз данных есть множество примеров отношений только с одним ключом и довольно мало примеров с более чем одним ключом. Это кажется мне странным, учитывая, что множественные клавиши в наши дни кажутся очень распространенной практикой. Недостаток практических примеров в неакадемической литературе, кажется, является одной из причин путаницы в отношении роли ключей в проектировании баз данных. Другой причиной путаницы является популярное мнемоническое выражение «ничего, кроме ключа». Эта фраза обычно приписывается Биллу Кенту, но это не точное определение 3NF.

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

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

Я думаю, что путаница является результатом неправильного толкования термина «ключи-кандидаты». В таблице может быть несколько ключей-кандидатов. Вот почему у нас есть термины-модификаторы для дальнейшего определения среди этой группы: первичные и альтернативные. Если бы таблицы могли иметь один и только один ключ, то термин «первичный» ключ вводил бы в заблуждение и вместо этого должен был бы называться чем-то другим (может быть, «Родитель» или «Источник» или «Идентификация» и т. Д.). Но «Первичный» подразумевает, что могут быть «вторичные» ключи, и они называются «Альтернативными» ключами.

Альтернативные ключи указываются в физических моделях посредством уникального ограничения или уникального индекса. Следует также отметить , что оба типа ключей - кандидатов (первичный и альтернативный), можно ссылаться на внешних ключей (даже если один вообще не будет / не должны делать такие вещи без очень уважительной причине!).

Будет ли зависеть ответ от того, был ли уникальный ключ в другом столбце? Если так, то почему?

Нет, потому что это вопрос физического против логического моделирования. У вас может быть таблица, в которой есть IDENTITYполе, но еще не определен первичный ключ. Таблица и ее данные могут легко быть в 3NF, даже если физическая модель не обеспечивает это. Это различие похоже на то, определены ли внешние ключи. Вы, конечно, можете присоединиться к таблицам и не иметь потерянных записей, независимо от того, были ли определены PK или FK. И данные могут быть на 100% правильными без этих конструкций. Но определение PK и FK - это разница между ссылочной целостностью (логической) и декларативной ссылочной целостностью (физической). Наличие ограничений в физической модели просто помогает обеспечить соблюдение правил логической модели.

Что касается SSN (« Номер социального страхования » для тех, кто не знаком с этой аббревиатурой), а также того, что он является альтернативным ключом и имеет уникальный индекс / ограничение:

Я рекомендовал бы против рассмотрения SSN будучи альтернативный ключ и положить ограничение уникальности или индекс на нем, даже если он является общим для этого (ПНУЛ часто рассматривается как «естественный» ключ - тот , который существует в реальном мире) , Есть две основные причины:

1. Точность. В большинстве случаев эти значения вводятся в систему кем-то, кто заполняет форму на бумаге или в Интернете. Люди постоянно делают ошибки при вводе данных, особенно если источником был бумажный бланк, который вводится кем-то, кто читает чужой небрежный почерк (например, мой, который едва читаем).

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

2. Уникальность: даже если главная Администрация социального обеспечения никогда не выдает дубликат ID, это не означает, что дублирование не произошло. Помимо проблем с кражей личных данных, я помню, как кто-то много лет назад работал в качестве администратора баз данных в Департаменте доходов штата (я полагаю) и кто имел дело с пособиями по социальному обеспечению, как у них возникали «проблемы», связанные с тем, что было старая практика переназначения номера SSN умершего лица оставшемуся в живых супругу (обычно вдове), чтобы выжившему супругу было легче продолжать собирать выплаты пособия. Я уверен, что эта практика была положена конец некоторое время назад, но «дубликаты» данных все еще были в системе.

Как я понимаю, третья нормальная форма (3NF) в основном означает, что должен быть ровно один ключ.

№ 2NF, 3NF и Нормальная форма Бойса Кодда (BCNF) имеют дело с функциональными зависимостями . Таблица в 2NF означает, что нет частичных ключевых зависимостей, где неключевой столбец зависит от некоторого правильного подмножества многостолбцового ключа. Таблицы, подобные той, что в нашем примере, уже находятся в 2NF, поскольку каждый ключ-кандидат представляет собой один столбец. Таблица в 3NF означает, что каждый неключевой столбец также не является функционально зависимым от некоторого другого неключевого столбца, что создает транзитивную зависимость., Неважно, есть ли один или сто возможных ключей. На самом деле это BCNF, а не 3NF, который является «конечной» нормальной формой в отношении функциональных зависимостей. Это связано с тем, что таблица может быть в 3NF, но не в BCNF, поскольку может быть несколько ключей-кандидатов, которые перекрываются. Таким образом, когда мы используем термин 3NF для обозначения «полностью нормализованного» в отношении функциональных зависимостей, мы действительно имеем в виду BCNF.

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

Мало того, что это может быть, это должно быть, если мы хотим, чтобы данные, хранящиеся в базе данных, оставались в соответствии с правилами, которые мы определили в реальном мире!

Игнорирование практических / бизнес-проблем (например, риск безопасности / конфиденциальности при передаче SSN в качестве ключа / FK) с точки зрения строгой схемы, не будет ли такая таблица в 3NF, поскольку фактически существует 2 ключа?

Как объяснено выше, находится ли таблица в 3NF (или, что более важно, BCNF), ортогонально тому, сколько ключей-кандидатов она содержит.

Будет ли зависеть ответ от того, был ли уникальный ключ в другом столбце? Если так, то почему?

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

Но это действительно принесет интересный момент. Обратите внимание, что уникальный ключ, когда он определен как ограничение в СУБД, не совпадает с уникальным идентификатором, определенным как бизнес-правило в концептуальной бизнес-модели. Возможно, в нашем мире мы всегда знаем SSN человека, и поэтому он служит ключом-кандидатом для человека, и, возможно, мы также вводим суррогатный ключ в логическую схему, которую мы называем Person Id . Наша бизнес-модель включает правило, согласно которому SSN является уникальным идентификатором человека в нашем мире. Это подразумевает функциональную зависимостьиз всех описательных атрибутов на этом атрибуте идентичности. Это правило не меняется только потому, что мы либо забыли, либо решили не информировать СУБД. Именно поэтому важно объявить ограничение - чтобы СУБД могла обеспечить соответствие хранимых данных правилам бизнес-модели! Если мы не создали это уникальное ограничение для SSN, то теперь мы можем случайно создать более одной строки для одного человека с одним и тем же SSN; каждый ряд имеет свой идентификатор личности!

Отличный учебник по этим темам - серия практических баз данных Фабиана Паскаля и теория проектирования баз данных и реляционной теории Криса Дейта , из которой вытекает этот ответ. В то время как каждая статья Фабиана является обязательной для прочтения, статья № 1 (которая четко определяет разницу между концептуальным, логическим и физическим уровнями) и статья № 4 (которая четко определяет различные виды ключей) специально посвящены этому вопросу. Точно так же вся книга Криса является обязательной для прочтения, а часть II - это раздел, посвященный нормализации в отношении функциональной зависимости.