这是我的问题。
在经历过OOP和UML的经验之后，ER建模似乎有些混乱...
在设计ER模型时，我面临的最大障碍之一是我对实现的外观一无所知：
让我举例说明：
如果我绘制一个实体“ Students”，我想我会在SQL中有一个名为“ Students”的表格，其中带有students属性。
但是，如果我通过“已注册”关系将“学生”实体与“课程”实体相连，那么SQL方面将是什么？
我正在为每个实体猜测一张桌子，但是我该如何表达这种关系呢？我是否需要像对待实体一样为某些关系创建表？还是该关系在“学生”和“课程”两个表中都存在，具体取决于我为每个表选择的属性？
与UML相比，这似乎有点含糊。 （我知道这似乎是一种不好的做法，担心实现细节，但是我想有一个更好的线索，特别是在SQL中关系会变成什么样）
谢谢。
答案 0 :(得分：0)
多对多关系也存储为表。 Enrolled将是一个表，其中包含诸如：
可能还会有其他信息，例如注册日期，方法，也许还有付款信息。
与对象建模的比较比较棘手。 ER建模通常从主要实体开始。通常，一种关系变成一个实体，因为除了实体之间的连接之外，还有其他信息可用。