В теории баз данных наиболее критичные ограничения для таблицы называются ключами-кандидатами . Значения в столбце (столбцах) ключа-кандидата однозначно определяют значения, хранящиеся в других столбцах строки таблицы - это функциональная зависимость и ключевой аспект теории нормализации. (Строго говоря, зависимости соединения являются ключевыми; функциональная зависимость является частным случаем зависимости соединения.) Таблица может иметь несколько ключей-кандидатов. Из этих возможных ключей максимум один может быть обозначен как первичный ключ; другие становятся «альтернативными» ключами (но не по каким-то причинам «вторичными ключами», хотя для них это кажется очевидным названием).
Моя любимая иллюстрация нескольких ключей-кандидатов - это таблица элементов из химии и физики (и тот факт, что она называется «таблицей» - это хорошо):
CREATE TABLE elements
(
atomic_number INTEGER NOT NULL UNIQUE
CHECK (atomic_number > 0 AND atomic_number < 120),
symbol CHAR(3) NOT NULL UNIQUE,
name CHAR(20) NOT NULL UNIQUE,
atomic_weight DECIMAL(8,4) NOT NULL,
stable CHAR(1) DEFAULT 'Y' NOT NULL
CHECK (stable IN ('Y', 'N'))
);
Он имеет 3 ключа-кандидата - атомный номер, символ и имя (и эмпирически, вы, вероятно, могли бы использовать атомный вес в качестве четвертого, но он не уникален так же, как остальные три) , Любой из них может быть обозначен как первичный ключ, но обычно используется либо атомный номер, либо символ. Какой из них предпочтителен, зависит в значительной степени от того, имеете ли вы дело с химией (в этом случае символ является победителем), или (под) ядерной физикой, и в этом случае атомный номер, вероятно, более важен. Ваши вторичные таблицы, такие как таблица изотопов , будут иметь перекрестную ссылку на атомный номер; Ваши вторичные таблицы, относящиеся к химическим соединениям, скорее всего, дадут перекрестную ссылку на символ. (Кстати, знаете ли вы, что «пока неизолированные» элементы с атомными номерами свыше 100 имеют трехсимвольные сокращения?)