【问题标题】:Simple entity relationship redundancy error简单实体关系冗余错误
【发布时间】:2017-01-03 19:42:12
【问题描述】:

我正在使用 ER 助手创建我的第一个实体关系图。

我创建了一个名为 Users 的实体,其中包含以下属性

UserID (identity 1,1) PK 

UserName  (varchar, 50)

我创建了第二个名为 Logs 的实体,它的属性是

LogID (Identity 1,1) PK

LogEntry (varchar, 256)

UserID FK

我已经给它分配了如下断言,

  • 一个用户可以创建多个日志
  • 日志只能由一个用户创建

关系定义为一个用户对多个日志,用户是强制性的,日志是可选的

我得到的错误是:

"'Logs' 实体类型中的 'UserID' 属性与 “创造”关系。因为'UserID'是主键 “用户”不应该是“日志”的属性。

所以我的问题是,如果我不将 UserID 作为外键放在 Logs 表中,我如何正确地将两者关联起来?我以为我对它的工作原理有一个很好的理解,但目前这对我来说绝对没有意义。我不确定这是否是有效性检查中的错误,或者我实际上做错了。

【问题讨论】:

  • 虽然没有发现任何问题。看起来正确。你在哪里得到这个错误?

标签: sql entity-relationship redundancy


【解决方案1】:

由于 UserID 不是 Logs 表的属性(假设日志是由用户和系统创建的),良好的设计要求您将关系分离到第三个表中:

UserLogs
--------
UserID
LogID

这样,如果系统创建了一个日志,你可以创建另一个表:

SystemLogs
----------
SystemID
LogID

并为两种关系使用相同的实体日志

【讨论】:

  • 好的,所以这肯定修复了错误。通过创建附加实体并扩展关系,它不再报告错误。但是,我仍然对如何评估它感到困惑......或者最好说我不明白应用程序如何评估它。
  • 如果我错了请纠正我,但是 LogEntry 字段已从 Logs 中删除并添加到每个从属实体中?最后,我完全理解如何打破这一点使设计更加健壮,但是我仍然坚持理解 UserID 存在于一个而不是另一个之间的区别。
  • 不,LogEntry 是 Logs 表的属性,应该保留在那里。在我看来,您似乎正在尝试创建一个 ER 模型而不了解它的一些基础知识。我会先阅读规范化 - en.wikipedia.org/wiki/Database_normalization(包括高达 4NF)。
  • 绝对正确。我对此很陌生。知道这是我需要理解的规范化来解决我的误解,这正是我所需要的。谢谢
  • 我发现维基百科的文章和解释不是最容易理解的来源,所以货比三家。此外,如果您对此非常陌生,我建议您花一些时间查看您周围的事物和人,并为它们创建实体模型和它们之间的关系。例如,如果您在工作,“房间”可能是一个实体(房间的属性是什么?)而“经理”可能是另一个(经理和房间有什么关系?)一个好的 ER 建模者能够表示真实的世界实体及其关系在数据库中尽可能接近现实。
猜你喜欢
  • 2018-03-25
  • 2017-02-23
  • 2012-08-01
  • 1970-01-01
  • 1970-01-01
  • 2018-08-14
  • 2015-11-27
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多