【问题标题】:Entity relashionship with 1-to-1 relation on both sides实体关系,双方1对1关系
【发布时间】:2019-11-13 02:14:31
【问题描述】:

当使用实体关联图建模时,我发现这种关系很奇怪,我想知道这个模型是否允许。

+----------+      =-------=         +-------------+  
+ Driver   +--1,1-=  HAS  =---1,1---+ performance +  
+----------+      =-------=         +-------------+  

Vehicle 和性能和关系有两个实体。

因此,驱动程序必须具有唯一的性能,反之亦然。
我想知道我是否必须将这两个实体合并为一个实体,但从语义上讲这似乎是错误的,驱动程序不是性能。
在应用程序级别,Performance 允许给驱动程序打分以便对驱动程序进行分类。

【问题讨论】:

  • 性能的属性是什么?
  • 这只是一个例子,实际的方案是我有Driver而不是Vehicule,而Performance,Performance的属性是work_days,missed_days,errors_number......它提供了计算Driver性能的信息.
  • 我修改了我的问题。

标签: entity-relationship


【解决方案1】:

这有点类似于桥接表,用于表示多对多关系:

drivers ----- many / many ----- performance

转化为:

driver ----- 1 / many ----- bridge table ----- many / 1 ----- performance

但这并不是这里发生的事情。

在这种情况下,中间表似乎没有任何用处,可能应该被删除。假设performancedriver 的子表(所以performance 记录包括一个引用driver 的外键),那么可能可以完全删除performance 并将这些列直接添加到driver .

如果有其他表引用performance,这样删除该表会很麻烦,您可以将其保留为单独的表,但只需将引用直接指向driver

【讨论】:

  • 在实体关系模型中,属性必须与实体保持一致,它们应该指示相同的抽象或对象......这就是让我感到困惑的原因,所以我明白没关系尽管代表不同的概念,但要加入这两个实体。
  • 但它们真的代表不同的概念吗? Performance 是一个弱实体——它依赖于 Driver 并且它本身没有意义。这是一对一的关系,所以我们知道performance 记录和driver 记录是唯一关联的。除非Performance中有某些属性由于某种原因无法添加到Driver,否则性能似乎只是属于强Driver实体的另一组数据点,可以合理地组合。跨度>
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-12-24
  • 1970-01-01
  • 1970-01-01
  • 2011-11-11
  • 1970-01-01
相关资源
最近更新 更多