SQL模式多对多关系

我正在做一个学校的项目，在理解构建SQL模式ER图时遇到了一些麻烦

我有4个实体；与我的订单表具有一对多关系的客户表、与我的商品表具有一对多关系的订单表、当前与汉堡表具有一对多关系的商品表

我遇到的问题是，我的行项目表有一个order id的复合主键，burger id和我认为行项目->burger应该处于多对多关系中，因为一个或多个行项目可以与一个或多个burger关联，反之亦然，但我的理解是，您不希望在规范化的表格中存在任何多对多关系。我认为应该是多对多的假设正确吗？为什么允许我有多对多的关系

作为参考，我的表格目前为3NF格式

忽略模态并假设它总是最小的一个，如果我的Burger实体与行项目有一对多的关系，那么我将有以下内容

这意味着一个汉堡有一个或多个与之相关的行项目，但是我的思维过程告诉我，这不是唯一的情况，事实上一个行项目可以有多个汉堡，但从我阅读的所有内容来看，情况并非如此。复合键让我非常困惑，我确实明白了为什么它会出现在burger->line item one->many中，因为burger count字段只属于一种单一的汉堡类型，它包含了行项目中有多少个汉堡的值

我认为应该是这样的：

编辑： 请忽略customer表和order表，它们只是用来提供完整视图的，我注意到刚才我忘记了包含外键

我相信行项目->汉堡应该是多对多的

为什么一个单行项目与多个汉堡相关？不会的。订单有许多行项目。每一行都指一个汉堡。上图是正确的

---

请注意，通常情况下，您销售的不是汉堡，而是与产品无关的商品，如税收、折扣等。因此，items表的主键通常是OrderId、OrderItemId，ProductID是非关键属性。

我知道这是针对学校的，这就是我积极指出的原因。但我不是想让你们做我的家庭作业，我只是想弄清楚规范化表中到底允许什么。所以，如果有人能帮忙，我会非常感激。多对多关系通常是需要避免的，但不一定与正常化有任何关系。查看通常称为连接表的关联实体，了解M:M通常是如何解析的。相互之间存在关系/关联的是实体而不是表。正是关系/关联具有基数X:Y:等。在我们获得ER设计后，每个实体/框/菱形&每个关系给出一个表，每个参与/行给出一个FK。而且NFs与ER无关。有很多陈述/方法声称是ER，但不是；例如，他们使用关系来表示FK&或多或少直接移动到表中，而没有明确说明Es&R。请告诉我们您的教科书名称和版本。阅读并点击谷歌的“stackexchange家庭作业”。我刚刚更新了我的帖子，提供了更多信息和一些视觉提示，以帮助解决这个问题。好吧，在阅读了更多内容后，我了解到规范化不适用于ER图，但我仍然需要上述方面的帮助。我已经创建了所有可以工作的SQL代码，还有其他所有我不知道如何绘制这些图表以及行项目和汉堡之间的关系，也许我只是想得太多了。我想我只是在兜圈子，因为最初这是我所拥有的，是有意义的，但我说服了自己。我相信这个问题现在会被遗忘，因为它是如此简单和愚蠢，但你仍然帮助我，所以谢谢你的直接回答。