我知道实体的客户和订单之间可能存在关系，但我不明白当我创建自己的ERD时，1，m或n属于哪个表...有没有规则来理解我应该使用什么关系，以什么顺序我应该把这些符号（所以它是1：n或n：1）？你如何知道使用什么关系？
在下图中我知道每个订单有1个顾客，因为order_id是Order表的主键。这就是为什么存在1：n关系而不是n：1的原因？或者是因为同一个客户可以多次下单，所以客户会多次被保存在订单表中？
又如：
同样在这里的问题。为什么t_course和t_course_taken之间存在1：n的关系？为什么它是t_student和t_course_taken之间的1：n关系？
这个问题已经有了一个可以接受的答案，但我想提请注意这个问题的一个方面，为未来的访问者带来好处。这是分析主题和设计数据库的区别。
实体和实体之间的关系实际上是主题的特征，而不是数据库的特征。通过分析主题来发现这些功能，以了解事物在现实世界中的工作方式。了解这些功能是发现的，而不是发明的，这一点很重要。从这个意义上说，课程与学生之间的关系是多对多的，因为这就是它在真实世界中的作用（在我看过的每所学校中）。
一旦真实世界（有点）被理解了，就可以开始数据库设计了。数据库设计是一个发明过程，但是本发明最好由早先完成的发现结果来指导。
数据库的初始设计涉及表，键和外键。这是正常化发挥作用的地方，我第二次jbutler的建议是研究它。还要注意的是，分析显示两个实体之间存在多对多关系，而设计结果在三个表中，外部两个（实体）表与中间（关系）之间存在一对多关系）表。这就是在关系模型中建模的多对多关系。
分析和设计之间的这种区别常常被人们忽略，只是为了加快数据库工作。这里可能会出错。过度强调分析可能导致“分析瘫痪”。重点不足可能导致“准备好，开火，瞄准”。
非常感谢！我一直在思考这个问题......你的回答真的让我从不同的角度思考这个问题。就像你说的那样，因为我们正在建模一个真实的生活场景，所以我认为我应该根据实体的内容定义一个关系，而不是试图根据属性和关键字来找出这种关系。每个实体。你能否确认这是否是找出这种关系的正确方法？举例来说，因为一家公司有很多员工，每位员工在同一家公司工作，其1：n关系。 – user1534664 2014-09-06 13:27:16
还是你真的看看属性是什么和钥匙，并尝试找出这些信息之间的关系是什么？ – user1534664 2014-09-06 13:27:49
这取决于。你可以从最上面开始，然后继续前进。将主题分析为实体，发现关系，然后发现描述它们的属性，并使用数据值存储在数据库中。或者你可以从底部开始，然后继续前进。您根据要存储的值分析需求，将它们分组为属性，然后使用这些来发现关系和实体。我倾向于两者都做一点。 – 2014-09-06 15:25:28
移动这一个答案：
最新的留言答案：简单地说，是的。
但是，在第一个例子中，这是没有意义的。一个客户可能有很多订单，但一个订单不能属于许多客户。
在你的第二个例子，
一个学生可报读许多课程，一门课程可能有许多学生。 （因此是多对多的关系）。为了解决这个问题，我们加入了子表。为了简单起见，请拨打studentsCourse。
一个学生可以有很多学生课程，但是一个学生课程现在将是他们特定的。
一门课程可能会有很多学生课程，但同样，单个学生课程将属于同一课程。
现在还有什么意义？
BTW，我觉得你可以做的对数据库规范化（http://holowczak.com/database-normalization/），希望这将更好地解释如何分解表阅读了使用（教科书甚至可能包含在一个或两个章节主题！）
我喜欢这个答案。它最初是被接受的答案，而且足够好。 – 2014-09-06 18:21:01
** 1位顾客**可以有**许多订单**。想想那样！ – jbutler483 2014-09-05 12:15:16
1名学生可以参加很多课程，许多学生可以选修课程。在这种情况下，需要引入'中间''孩子'表来阻止多对多的关系。由于它是一张儿童桌子，所以它们将继续保持一致。 – jbutler483 2014-09-05 12:17:46
这样的东西：http://code.tutsplus.com/articles/sql-for-beginners-part-3-database-relationships-net-8561将很有用 – jbutler483 2014-09-05 12:19:43