Когда мы используем один из этих терминов, мы должны говорить о данной таблице (переменная, значение или выражение). Суперключи, CK и PK таблицы не определяются ролями, которые ее атрибуты играют в других таблицах. Они определяются тем, какие допустимые значения могут возникать для таблицы в соответствии с заданными бизнес-правилами.
Когда у суперключа есть только один атрибут, мы можем небрежно говорить о том, что этот атрибут является суперключем.
Это правда, что каждый CK (ключ-кандидат) определенной таблицы является суперключом этой таблицы. Но вы имеете в виду, что набор атрибутов по определению является суперключем, если / если это и некоторые другие условия выполняются. Но вы явно не говорите, что когда вы пишете этот раздел.
Разница между суперключем и ключом-кандидатом в том, что подмножество ключа-кандидата сама по себе не может быть ключом-кандидатом. 1025 *
Нет. Набор является подмножеством самого себя, поэтому CK является подмножеством самого себя, поэтому у CK всегда есть подмножество, которое является самим CK. То, что вы имеете в виду, это не правильное / меньшее подмножество. Тогда ваше утверждение верно. Но также верно и более важно то, что ни одно правильное / меньшее подмножество CK не является суперключем.
Вы фактически не определяете "CK" в этом параграфе. CK данной таблицы может быть определен как суперключ этой таблицы, который не содержит надлежащего / меньшего подмножества, являющегося суперключом этой таблицы.
Первичный ключ - выбранный Ключ-кандидат, который становится атрибутом для уникальной идентификации строки.
Нет. PK (первичный ключ) данной таблицы определяется как один CK этой таблицы, который вы решили назвать PK. (Не атрибут.)
Обратите внимание, что CK & PK являются superkeys. PK не имеют значения для теории отношений.
Чтобы создать связь между обоими:
AuthorBook(authorID, BookID) -- together authorID and BookID are primary key
Что такое суперключи и CK и что такое PK определяется FD (функциональные зависимости), которые содержатся в таблице. Но если вы предполагаете, что это таблица «многие ко многим», то для уникальной идентификации строки требуется пара authorID-bookID, поэтому может быть только один CK, {authorID, bookID}. Так что это единственно возможный ПК. Таким образом, {authorID} & {bookID} не могут быть суперклавишами, CK или PK.
Это можно увидеть, посмотрев примеры и применив определения.
authorID bookID
1 a
1 b
Здесь authorID не уникально идентифицирует строка. Так что это не может быть суперключем. Так что это не может быть CK. Так что это не может быть PK.
учебники, которые я читал, похоже, определяют таблицы соединений таким образом и определяют первичные ключи таким образом
Нет, они не .
Однако они говорят, что определенные наборы атрибутов и подмножеств суперключей, CK и PK в соединительной таблице являются FK (внешними ключами) в соединительной таблице, ссылаясь на те другие таблицы, где они являются CK (которые могут быть PK) of / в этих других таблицах.
FK данной таблицы может быть определен как определенный набор атрибутов в таблице, значения подстрок которых должны отображаться как определенные подстроки CK в определенной другой таблице. .
Но поскольку вы говорите, что это соединительная таблица, предположительно, {authorID} является FK для таблицы автора, где ее значения отображаются в CK / PK, а {bookID} является FK для книги. таблица, где его значения отображаются под CK / PK. Таким образом, FK {authorID} в AuthorBook ссылается на {authorID} в Author & FK {bookID} в AuthorBook, ссылается на {bookID} в Book.
PS PK и другие термины означают что-то еще в SQL. Объявленный SQL PK может иметь меньший SQL UNIQUE, объявленный в нем. SQL Сама «уникальность» определяется в терминах SQL NULL. Разумно сказать, что SQL PK больше напоминает реляционный суперключ, чем он напоминает реляционный PK. Точно так же SQL FK больше напоминает то, что мы могли бы разумно назвать реляционным внешним суперключем, чем реляционным внешним ключом.