Действительно ли внешний ключ может сослаться на групповой индекс?

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

Да, можно создать внешние ключи к в основном любому столбцу (столбцам) в любой таблице. Большинство раз Вы создадите их к первичному ключу, все же.

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

Зависит от RDBMS, который Вы используете. Я думаю, что некоторые делают это для Вас неявно или используют некоторые другие приемы. RTM.

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

Пример: Две таблицы, КОЛЛЕДЖИ и СТУДЕНТЫ, оба содержат столбец под названием ИНДЕКС.

, Если мы делаем быструю проверку по телефону

SELECT * FROM COLLEGES JOIN STUDENTS ON COLLEGES.ZIPCODE = STUDENTS.ZIPCODE

, Мы могли бы обнаружить, что отношения - многие многим. Если бы наша схема имела таблицу под названием ИНДЕКСЫ с ИНДЕКСОМ первичного ключа, то было бы очевидно, что действительно продолжается.

, Но наша схема не имеет такой таблицы. Просто, потому что наша схема не имеет такой таблицы, не означает, что такие данные не существуют, как бы то ни было. где-нибудь, на земле USPO, существует только такая таблица. И и COLLEGES.ZIPCODE и STUDENTS.ZIPCODE являются ссылками на ту таблицу, даже если мы не подтверждаем это.

Это больше имеет отношение к философии данных, чем практика создания баз данных, но это аккуратно иллюстрирует что-то фундаментальное: данные имеют характеристики, которые мы обнаруживаем, и не только характеристики, которые мы изобретаем. Конечно, то, что мы обнаруживаем, могло быть тем, что кто-то еще изобрел. Это, конечно, имеет место с ИНДЕКСОМ.

PostgreSQL также отказывается от этого (так или иначе, даже если это возможно , это не означает, что это - хорошая идея):

essais=> CREATE TABLE Cities (name TEXT, country TEXT);
CREATE TABLE
essais=> INSERT INTO Cities VALUES ('Syracuse', 'USA');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Syracuse', 'Greece');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Paris', 'France');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Aramits', 'France');
INSERT 0 1
essais=> INSERT INTO Cities VALUES ('Paris', 'USA');
INSERT 0 1

essais=> CREATE TABLE People (name TEXT, city TEXT REFERENCES Cities(name));
ERROR:  there is no unique constraint matching given keys for referenced table "cities"

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

create table t1
(
  id int identity,
  fk int
);

create table t2
(
  id int identity,
);

CREATE NONCLUSTERED INDEX [IX_t2] ON [t2] 
(
    [id] ASC
);
ALTER TABLE t1 with NOCHECK
ADD CONSTRAINT FK_t2 FOREIGN KEY (fk)
    REFERENCES t2 (id) ;


Msg 1776, Level 16, State 0, Line 1
There are no primary or candidate keys in the referenced table 't2' 
that match the referencing column list in the foreign key 'FK_t2'.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.

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

См. этот связанный вопрос и ответы также.