Entity Framework не будет разрешать отношения PK-FK с составным первичным ключом?

Question

Я пытаюсь настроить EDM на существующую инфраструктуру SQL Server и столкнулся с проблемой.

EDM будет не разрешить отношение PK-FK к составному внешнему ключу.

Моя структура БД таблица выглядит следующим образом (имена изменены, чтобы защитить невинных):

• У меня есть таблица ЛИЦ, содержащую столбец INT под названием PerID (PK)
• У меня есть таблица OFFICE, содержащий столбец INT, называемый OffID (PK)
• Я связываю эти таблицы вместе, используя таблицу под названием OFFICEPERSONS, создавая отношения между многими и многими людьми между ОНЛАЙН И ПЕРСОНАЛАМИ. Эта таблица имеет два столбца INT, PerID и OffID, которые вместе образуют составной первичный ключ.
• У меня есть таблица под названием OFFICELOCATION, которая содержит два столбца INT, LocID и OffID. Эти два столбца содержат составной первичный ключ. Кроме того, OffID также является FK в таблице OFFICE.
• Наконец, у меня есть таблица под названием OFFICEPERSONSLOCATION. В этой таблице три столбца INT: PerID, OffID и LocID. Все три столбца содержат составной первичный ключ. LocID и OffID предоставляют FK отношения к ОФИЦИАЛЬНОМУ ОТЛОЖЕНИЮ, а OffID и PerID обеспечивают отношение FK к ОФИЦИАЛЬНЫМ ЛИЦАМ.

Со мной до сих пор? Надеюсь, я еще не потерял тебя. Когда все сказано и сделано, моя структура выглядит так:

Эта структура отлично работает на SQL Server. В EDM? Не так много. Это НЕ позволит мне установить связь между OFFICEPERSONSLOCATION и OFFICEPERSONS. Я получаю следующую ошибку:

Error 6037: Foreign key constraint 'FK_OFFICEPERSONSLOCATION_OFFICEPERSONS' has been omitted from the storage model. Column 'OffID' of table 'Model.Store.OFFICEPERSONSLOCATION' is a foreign key participating in multiple relationships. A one-to-one Entity Model will not validate since data inconsistency is possible.

Да? Непоследовательность данных?!? Как?

Как я могу получить свою инфраструктуру сущности, чтобы распознать это?

Answer 1

Я согласен, что это проблема структуры сущности, и проблема глупа. Даже если у вас UPDATE CASCADE «нет действий», это не похоже на то, что вы можете создать несогласованность, но нет, он утверждает, что вы можете каким-то образом.

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

В этом случае OffID может быть «непоследовательным», но используя идентификаторы в таблицах OFFICEPERSONS и OFFICELOCATIONS (и, следовательно, ссылку в OFFICEPERSONSLOCATION), вы вынуждены управлять OffId в своей основной таблице.