краткий ответ: нет - не могу этого сделать. Все столбцы в PK (или другом альтернативном ключе) должны появиться в определении FK. Также помните, что таблица может иметь несколько ключей - называемых ключами-кандидатами (иногда альтернативными ключами). Первичный ключ - это просто «лучший» ключ для вашего дизайна / использования (обычно самый узкий - самый маленький в байтах). Мы называем имя этих других уникальных индексов как «AK_ {name}» - AK = Alternate Key.
То, что мы делаем в этих обстоятельствах, является одной из двух вещей:
- определите синтезированный PK как столбец «Идентичность», а затем добавьте уникальный индекс к составному ключу, таким образом имея два «ключа» в таблице. Затем все дочерние таблицы определяют FK как указывающий на синтетический столбец Identity PK.
- Оставьте составной ключ как есть. Определите его как PK в этой главной таблице и сделайте так, чтобы все FK имели одинаковое определение.
Как правило, не рекомендуется иметь несколько таблиц с одинаковым определением PK (то есть PK, которые также являются FK для другой таблицы). Я говорю «в целом» - важно понимать определение ваших сущностей.
Так зачем использовать # 1? Я задаю себе вопрос: действительно ли составной ключ - это данные, которые определяют строку? Является ли этот составной ключ действительно определением строки или это скорее FK для некоторых других данных? Если это больше FK, то я создаю синтезированный PK (Identity). Орден действительно книги, которыми владеет клиент? Заказ может привести к тому, что у клиента будет новая книга, но это может быть не одно и то же.
Наличие синтезированного ПК предлагает еще несколько вариантов в будущем. Если отношение должно измениться в вашей таблице Client_Books, вы можете изолировать изменения в других таблицах.
Например, что если клиент может владеть более чем одной копией книги, как вы это реализуете? С помощью синтезированного ключа вы можете просто удалить уникальный индекс на составном ключе и оставить его в виде простого FK, тогда таблица Order_Details будет просто представлять, когда клиент купил свою вторую копию. Однако, если вы взяли составной ключ на маршруте Orders, вам придется выяснить, как переопределить Order_Detail, а также Client_Books (и любые другие FK, которые указывали на Order_Detail).
Я бы также попросил вас оценить, действительно ли Order_Detail является Client_Book? Обычно Заказ заставляет клиента вступить во владение новой книгой. Я считаю, что Заказы независимы от инвентаря - поэтому PK на Order_Detail не должен быть PK на Client_Books, у Order_Detail, вероятно, должен быть свой собственный независимый PK.