ER图设计问题

Question

我正在为社交网络设计 ER 图，最近我和同事争论这部分是对还是错

ER DIAGRAM PROBLEM

其中 Faqet(Pages) 使用 three 操作与 Shfrytezuesi(User) 相关联, pelqen 用于存储点赞数, krijon faqe 用于知道页面的创建者, udheheq 用于存储所有页面管理员，所以我的问题是

这个设计有问题吗？

是否可以将两个表与多个操作相关联，这是我不确定的地方

Answer 1

在任意数量的实体集之间拥有任意数量的关系是完全有效的。我对图表的唯一担心是 Shfrytezuesi 下面的多个角色行合并为一个 - 我建议保持它们不同。

请注意，在实体关系模型中，我们不 link table。这个想法来自旧的网络数据模型，其中行表示实体，tables 表示实体集，links 之间 rows/tables 表示关系。

该模型的一个缺点是它仅支持定向二元关系 - 多对多二元、三元和更高关系以及与属性的关系都需要引入关联实体。但是，三个二元关系并不等同于三元关系，并非所有关系都可以用二元数据模型表示。

ER 模型支持 n 元关系和关系的属性。实体集由它们的主键表示，关系由实体键的组合表示。实体集加属性构成实体关系，关系集加属性构成实体关系。这些关系被映射到 tables。实际上，将具有相同主键的 table 合并以减少 table 的数量，这意味着一对一和一对多关系合并为其中之一的关系他们的关联实体集。

无论 table 如何组合，属性和关系都由列集表示。例如，根据您的图表，Pelqen 将表示为 (FID PK, SID)（假设 SID 是 Shfrytezuesi 的主键）。这些列可能有不同的名称，例如SID 可能会重命名为 AdminSID，特别是如果关系合并为 Faqet。旧的网络数据模型会将 FID FK -> FID PK 视为一种关系，如上文和下文所述，这是一种非常有限的关系，而不是 ER 模型采用的方法。

网络数据模型的另一个缺点是预先确定的访问路径，这意味着我们必须使用预先定义的关系从 table 导航到 table。这大大复杂了查询和数据处理。这种限制是 ER 模型映射到的关系模型开发的主要驱动力之一。将 tables 理解为 RM 中的关系使我们能够使用连接来构造和导航任意访问路径。因此，我们在 RM 中执行 link tables，但在查询时和根据需要而不是在设计时。 ER 模型仅用于概念设计，不描述 table 之间的关系，仅描述实体集之间的关系。

现在，ER 模型不像 RM 那样是一个完整且一致的逻辑模型，但它是对网络数据模型的重大改进。比 ER 更严格的方法是对象角色建模，但那是另一个话题。