Может ли суперключ включать вещи, которые не являются частью первичного ключа?

Может ли суперключ включать вещи, которые не являются частью первичного ключа?

2 ответа

Решение

Логически говоря, да. Если стол X имеет столбцы {A, B, C} а также A является первичным ключом, то {A}, {A, B}, {A, C} а также {A, B, C} все суперключи, потому что если у вас есть какой-либо из этих наборов, вы знаете все значения в строке (если он существует).

Однако для некоторых целей он не рассматривается как ключ в SQL, например, если таблица Y имеет A а также B вы обычно не можете определить внешний ключ Y(A, B) REFERENCES X(A, B), так как {A, B} не первичный ключ. Если вы хотите иметь возможность объявить этот внешний ключ, вы должны добавить еще один UNIQUE ограничение на X(A, B) что неэффективно, так как дублирует часть первичного ключа.

На мой взгляд, это один из многих недостатков SQL.

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

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

Предположим, что таблица сотрудников основана на США. У него может быть два кандидата - один может быть номером сотрудника, другой - номером социального страхования сотрудника. Если компания требует, чтобы сотрудники имели SSN..., это может произойти.

ОК, два кандидата - номер сотрудника и номер SSN.

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

В США, исходя из двух факторов, номер сотрудника, вероятно, будет выбран как PK, оставляя SSN в качестве дополнительного поля. Во-первых, существует юридическое ограничение на использование SSN, потому что это личная информация, способствующая краже личных данных. Во-вторых, возможно, что человек подал заявку на получение SSN, но еще не получил его. Таким образом, на SSN нельзя положиться, что делает его кандидатом недействительным.

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

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

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

"Количество элементов" просто говорит, когда я запрашиваю таблицу по одному значению ключа, каково среднее число возвращаемых записей. Для правильного простого ключа это всегда и только 1 для всех значений, которые вообще существуют в таблице. (Очевидно, он равен нулю для чисел, которых нет в таблице.) Количество элементов будет больше единицы для неуникальных ключей. Обычный пример для другого конца спектра для таблицы размера N, использование "Пола" в качестве ключа даст вам количество элементов N/2. Помните, так как это возвращаемый размер AVERAGE, распределение таблицы не обязательно должно быть идеальным.

Надеюсь, это поможет.

Другие вопросы по тегам