我有两个名为“主办公室”和“分公司”的实体,属于某公司。主办公室可以有一个或多个分支机构。
但是,公司只能有一个主办公室,这是所有其他主要办事处的中心位置。我应该如何模拟这种情况?
Main
和Branch
,其中Main
将具有布尔属性Central
。我认为这很糟糕,因为它会导致传递依赖?Main
,Branch
和Central
,其中Central
办公桌只有一行?Main
和Branch
,其中Main
将与自身有关系。编辑: 公司可以拥有多个主要办事处。
答案 0 :(得分:1)
出于建模目的,您可能有三个实体:公司,总部,分支机构。公司与总公司有1对多的关系;总公司与分公司有0到多的关系。这似乎捕获了数据的逻辑结构。
我认为你也在询问物理结构。逻辑结构可以直接映射到物理结构上,但这不是必需的。问题在于如何使用数据。
逻辑模型的一个合理实现将具有公司表和单个办公室表,其中包含:
另一个合理的实施方案是将主要办事处和分支机构放在不同的表格中。这更接近于数据的逻辑模型。但是,我想很多查询都会联合这两个表,使得单表在实践中更有效(但不一定)。
不幸的是,关系数据库并没有很好地实现类继承的想法。
答案 1 :(得分:1)
创建实体Company
和Entity
Office。创建从Company
到Office
的1到M关系。 Office有一种类型 - Main
或Branch
。创建从Office
到自身的1到M关系。这种递归关系是分支机构与总部的关联。最后,将Office中的1对1关系添加回公司,并使用角色名称将该关系区分为标识Central
Office。
您还可以将Office设置为超类型并创建Main和Branch子类型。这将使您能够建模从主要到分支的1到M关系,并更明确地显示业务规则。
如果我可以在这里粘贴ER模型片段,那就太棒了!关键是Office是这里唯一的真实实体,main和branch是Office的子类型。中央根本不是一个实体,而是办公室和公司之间的关系角色。
答案 2 :(得分:0)
在Main office
和Company
之间建立一对一的关系,然后在Branch office
和Main office
之间建立多对一的关系。
Branch office
和Company
之间没有直接关系,但可以通过Main office
轻松推断出来。
答案 3 :(得分:0)
您可能希望在E-R模型中使用继承。您有一个通用的Office超类和Branch / Main子类。公司将与主办公室建立多对一关系,并与主办公室建立一对一的关系,以代表中央办公室。