それが優れた設計手法であるかどうかはわかりませんが、他のテーブルの複合主キーの一部である1つのテーブルの複合外部キーを持つことは確かに可能です。
複合主キー(A、B)を持つテーブルtest1があるとします。
これで、主キー(P、Q、R)を持つtest2というテーブルを作成できます。ここで、test2の(P、Q)は、test2の(A、B)を参照しています。
MySqlデータベースで次のスクリプトを実行しましたが、問題なく動作します。
CREATE TABLE `test1` (
`A` INT NOT NULL,
`B` VARCHAR(2) NOT NULL,
`C` DATETIME NULL,
`D` VARCHAR(45) NULL,
PRIMARY KEY (`A`, `B`));
CREATE TABLE `test2` (
`P` INT NOT NULL,
`Q` VARCHAR(2) NOT NULL,
`R` INT NOT NULL,
`S` DATETIME NULL,
`T` VARCHAR(8) NULL,
PRIMARY KEY (`P`, `Q`, `R`),
INDEX `PQ_idx` (`P`,`Q` ASC),
CONSTRAINT `PQ`
FOREIGN KEY (`P`, `Q`)
REFERENCES `test1` (`A`,`B`)
ON DELETE CASCADE
ON UPDATE CASCADE);
上記の場合、データベースは(A、B)の組み合わせが一意であり、test1テーブルの主キーであることを期待しています。
しかし、次のようなことをしようとすると、スクリプトは失敗します。データベースでは、test2テーブルを作成できません。
CREATE TABLE `test2` (
`P` INT NOT NULL,
`Q` VARCHAR(2) NULL,
`R` DATETIME NULL,
`S` VARCHAR(8) NULL,
`T` VARCHAR(45) NULL,
INDEX `P_idx` (`P` ASC),
INDEX `Q_idx` (`Q` ASC),
CONSTRAINT `P`
FOREIGN KEY (`P`)
REFERENCES `test1` (`A`)
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT `Q`
FOREIGN KEY (`Q`)
REFERENCES `test1` (`B`)
ON DELETE CASCADE
ON UPDATE CASCADE);
上記の場合、データベースは列Aが個別に一意であると想定し、列Bについても同じことが続きます。(A、B)の組み合わせが一意であるかどうかは関係ありません。