数据库设计或 ERD图建模如何在存在用户表的用户管理系统中工作,并且存在许多其他表,如订单,产品,客户,备注,评论等。其他表可以有 created_by (指向用户表)和 edited_by (以及指向用户表)属性
这让我很困惑,因为最后ERD图看起来与同一个表( users )有很多关联。该图表不可读,因为与一个地方有很多关联。
或者这是数据库设计问题吗? - 我的意思是,也许每个表都不应包含这两个属性,但是应该以其他方式处理它?</ p>
答案 0 :(得分:4)
简短的回答是,这没有任何问题。
重要的是要记住,出于不同的原因存在不同的设计。虽然我希望在物理模型上看到这些信息(即显示您的预期数据库的确切模式),但您可能会选择将这样的实现细节留在概念甚至逻辑模型中以便于阅读。可以说系统审计之类的东西只是一个实现细节 - 在更高级别的设计中,这些信息不会有用。
要记住的另一件事是模型并不总是需要一个图表。它们通常在单个图表中看起来过于庞大和混乱,并且根据主题区域将它们分开是一个非常合理的决定 - 关于订单的图表,关于客户的图表等等。这对可读性非常有帮助。
答案 1 :(得分:1)
在ER模型中,两个实体之间可能存在多个关系。您已经概述了这种情况。这是由主题本身驱动的,并且在项目的分析阶段被发现。 ERD中的线描述了这些发现的关系。如果这很复杂,那要么是因为主题很复杂,要么是因为分析师犯了错误。
在数据库设计(至少是关系设计)中,关系由引用给定表中给定行的外键实现。据推测,该设计与分析一致。在设计完成后绘制了许多ERD,并反映了设计者的关系模型而不是分析师的ER模型。
很多今天的开发人员只是在头脑中进行分析,然后直接进行设计。对于简单的情况,这可以节省时间。对于复杂的情况,这可以回来咬你。分析错误直到被埋在设计层之后才会被发现。