В Entity Framework, как я могу создать ссылочное ограничение, используя подмножество первичного ключа?

Question

Моя модель данных содержит две таблицы с составными первичными ключами и ассоциативную таблицу. Часть составного первичного ключа является общей для таблиц.

SitePrivilege
-------------
SiteId
PrivilegeId

UserSite
--------
SiteId
UserId

UserSitePrivilege
-----------------
UserId
SiteId
PrivilegeId

Я создал сущность SitePrivilege и сущность UserSite. Я сопоставил связь между многими из них с UserSitePrivilege.

<Association Name="UserSiteSitePrivilege">
  <End Type="PrivilegeModel.UserSite" Multiplicity="*" Role="UserSite" />
  <End Type="PrivilegeModel.SitePrivilege" Multiplicity="*" Role="SitePrivilege" />
</Association>
...
<AssociationSetMapping Name="UserSiteSitePrivilege" TypeName="PrivilegeModel.UserSiteSitePrivilege" StoreEntitySet="UserSitePrivilege">
  <EndProperty Name="SitePrivilege">
    <ScalarProperty Name="PrivilegeId" ColumnName="PrivilegeId" />
    <ScalarProperty Name="SiteId" ColumnName="SiteId" />
  </EndProperty>
  <EndProperty Name="UserSite">
    <ScalarProperty Name="SiteId" ColumnName="SiteId" />
    <ScalarProperty Name="UserId" ColumnName="UserId" />
  </EndProperty>
</AssociationSetMapping>

Приведенный выше код выдает эту ошибку:

Каждый из следующих столбцов в таблице UserSitePrivilege сопоставлен с несколько концептуальных побочных свойств: UserSitePrivilege.SiteId сопоставлен с UserSiteSitePrivilegeSitePrivilege.SiteId, UserSiteSitePrivilege.UserSite.SiteId

Итак, я добавил ссылочное ограничение.

<Association Name="UserSiteSitePrivilege">
  <End Type="PrivilegeModel.UserSite" Multiplicity="*" Role="UserSite" />
  <End Type="PrivilegeModel.SitePrivilege" Multiplicity="*" Role="SitePrivilege" />
  <ReferentialConstraint>
    <Principal Role="UserSite">
      <PropertyRef Name="SiteId"/>
    </Principal>
    <Dependent Role="SitePrivilege">
      <PropertyRef Name="SiteId"/>
    </Dependent>
  </ReferentialConstraint>
</Association>
...
<AssociationSetMapping Name="UserSiteSitePrivilege" TypeName="PrivilegeModel.UserSiteSitePrivilege" StoreEntitySet="UserSitePrivilege">
  <EndProperty Name="SitePrivilege">
    <ScalarProperty Name="PrivilegeId" ColumnName="PrivilegeId" />
    <ScalarProperty Name="SiteId" ColumnName="SiteId" />
  </EndProperty>
  <EndProperty Name="UserSite">
    <ScalarProperty Name="SiteId" ColumnName="SiteId" />
    <ScalarProperty Name="UserId" ColumnName="UserId" />
  </EndProperty>
</AssociationSetMapping>

Теперь выдает эту ошибку:

Свойства, указанные Принципалом Роль UserSite должна быть точно идентичный ключу EntityType PrivilegeModel.UserSite, на который ссылается Основная роль в отношениях ограничение для отношений PrivilegeModel.UserSiteSitePrivilege. Убедитесь, что все ключевые свойства указано в основной роли.

Как правильно смоделировать эти отношения?

Answer 1

Перекрывающиеся FK, подобные этим, не поддерживаются в 3.5 SP1.

т.е.

UserSitePrivilege
----------
UserId 
SiteId
PrivilegeId

PK => UserId, SitedId, PrivilegeId
FK1 => UserId, SiteId
FK2 => SiteId, PrivilegeId

FK1 перекрывается с FK2. Это будет поддерживаться начиная с бета-версии 2 EF 4. Это связано с тем, что ассоциации FK (которые доступны в бета-версии 2) гораздо более гибки, чем независимые ассоциации (то, что имеется в 3.5 SP1 и 4.0 бета-версии 1).

См. Этот пост для более подробной информации о FK Ассоциации

Между тем, ваш единственный вариант - это, вероятно, скрыть все это за процедурами DefiningQueries, CUD и т. Д.

• Alex

Answer 2

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

Это, безусловно, одна из основных причин, по которой я бы предпочел использовать замещающий столбец в главной таблице для первичного ключа вместо составного ключа, составленного из фактических столбцов данных.

ОБНОВЛЕНИЕ: да, основываясь на вашем комментарии, вы абсолютно правы - дизайн БД надежный. Не совсем уверен, почему EF не может справиться с этим ....

Марк