Question

我在最近的一个问题（Database design problem）上收到了很好的建议，我在DB中加入了超类型/子类型模式为MVC2应用程序构建。我将使用Entity Framework为MVC提供模型。

超级类型是出版物，而子类型是文章， BlogPosts等每个子类型表都有一个2列的复合主键（pub_id， pub_type），使用引用相应列的外键超类型表

出于数据完整性目的（请参阅有关已接受解决方案的冗长评论原始问题）超类型表不应包括 pub_type在其主键中（与子类型表不同），

这就是实体框架似乎没有发挥作用的地方。我从现有数据库生成.edmx文件时收到的警告：

关系'FK_Articles_Publications'的列不是在关系的priamry方面表的关键部分。这种关系被排除在外。

（等）

问题： 有没有办法哄骗实体框架映射给定的关系我想要的外键（或者我将不得不妥协数据库设计和在超类型表上设置一个复合键）？

如果没有，这就增加了要求加入任何内容的额外问题超级类型的其他非子类型表（我计划几个） table要求我有对应于pub_id和的列 pub_type。例如，我希望主题表能够关联通过超类型表发布任何类型 - 我需要将pub_type（冗余地）存储在主题表的列中。

我对EF（和ORM）很陌生，但它的力量很诱人，而且我不想放弃它。

Answer 1

在此表中，

CREATE TABLE publications (
  pub_id INTEGER NOT NULL PRIMARY KEY,
  pub_type CHAR(1) CHECK (pub_type IN ('A', 'B', 'P', 'S')),
  pub_url VARCHAR(64) NOT NULL UNIQUE,
  CONSTRAINT publications_superkey UNIQUE (pub_id, pub_type)
);

重要的是{pub_id}是唯一的，{pub_id，pub_type}是唯一的。（列pub_type也应该声明为NOT NULL。）在第一种情况下，唯一性保证了身份。在第二种情况下，唯一性保证子类型引用超类型中的正确行。但是对于数据库引擎来说并不重要，其中一个被声明为PRIMARY KEY，哪一个被声明为UNIQUE。两者都可以成为外键引用的目标。

如果dbms是围绕当前关系理论设计的，那么它可能只支持KEY声明而不是PRIMARY KEY和NOT NULL UNIQUE。

因此，如果您的ORM无法按照它们的编写方式处理约束，那么可以将{pub_id}作为所有这些表中的主键，并声明可简化的超级键{pub_id，pub_type}是唯一的所有这些表格。

我不知道这是否会使EF沉默。您应该测试引用子类型的表以及引用超类型的表。

Answer 2

尝试Table Per Hierarchy继承，看起来它很适合您的设计。

实体框架和超类型/子类型

2 个答案: