你怎么知道使用什么关系？

Question

我知道实体之间可能存在关系，比如客户和订单，但我不明白1，m或n属于哪个表。我创建了自己的ERD ......是否有任何规则来理解我应该使用什么关系以及我应该按什么顺序放置符号（所以它是1：n还是n：1）？

在下图中，我知道每个订单都有1个客户，因为order_id是Order表的主键。这就是为什么1：n关系而不是n：1的原因？或者是因为同一个客户可以多次下订单，所以客户会多次保存在订单表中？

另一个例子：

这里也有同样的问题。为什么t_course和t_course_taken之间存在1：n的关系？为什么它是t_student en t_course_taken之间的1：n关系？

Answer 1

已经接受了这个问题的答案，但我想提请注意这个问题的一个方面，以造福未来的访客。这是分析主题和设计数据库之间的区别。

实体和实体之间的关系实际上是主题的特征，而不是数据库的特征。人们通过分析主题来发现这些特征，以了解事物在现实世界中的运作方式。了解这些功能是发现的，而非发明的，这一点非常重要。从这个意义上说，课程与学生之间的关系是多对多的，因为这就是它在现实世界中的运作方式（在我曾经看过的每所学校）。

一旦（某种程度上）理解了现实世界，就可以开始进行数据库设计了。数据库设计是发明的过程，但是本发明最好由先前完成的发现的结果来指导。

数据库的初始设计涉及表，键和外键。这是规范化发挥作用的地方，我是第二个jbutler的建议来调查它。另请注意，分析显示两个实体之间存在多对多关系，而设计结果为三个表，外部两个（实体）表与中间（关系）之间存在一对一对多关系）表。这是在关系模型中建模的多对多关系。

分析和设计之间的这种区别往往被人们忽略了加快数据库工作的速度。这里可能出错了。过分强调分析会导致分析瘫痪＆＃34;。重点可以导致准备好，开火，瞄准＆＃34;。

Answer 2

将其转为答案：

最后评论回答：简而言之，是的。

但是，在第一个没有意义的例子中。一个客户可能有很多订单，但单个订单不能属于许多客户。

在您的第二个示例中，

单个学生可以报名参加许多课程，单个课程可以招收很多学生。 （因此有多对多的关系）。为了解决这个问题，我们提供了一个子表。为简单起见，将其称为 studentsCourse 。

学生可以参加许多学生课程，但学生课程现在将针对他们。

课程可能包含许多 studentCourses ，但同样，单个学生课程将属于单个课程。

---

现在更有意义吗？

---

BTW ，我认为你可以利用数据库规范化（http://holowczak.com/database-normalization/）来阅读，这有望更好地解释如何分解表格（你的教科书甚至可能包含关于这一主题的一两章！）