在设计数据库时如何区分多对多关系？

Question

我必须设计一个数据库。 我正在寻找实体及其关系。 但是每个关系似乎都有多对多的关系。 例如，在我的情况下：

1）员工管理客户

在这里，员工可以管理零个或多个客户。 同样，一个客户端由一个或多个客户端管理。

2）客户下单购买股票

在这里，客户可以定购零，一个或多个股票，而股票可以定购零，一个或多个客户。

3）客户命令卖出股票

在这里，客户可以定购零，一个或多个股票进行卖出，而股票可以定购零，一个或多个客户进行出售。

这些是我情况的一些例子。 我很困惑如何分离这些关系。 在我的场景中，还有许多其他类似的情况。 而且我很难概念化设计。

所以，请告诉我我的情况。

Answer 1

很难回答这个问题。 设计中的一切都是视情况而定。 如果您真的需要存储哪些员工可以管理客户，而一个客户可以由很多员工来管理，则您的关系是多对多的。 注意现实世界中实体之间存在许多关系； 您应该只存储其中哪些是重要的，哪些是必须存储的。

再举一个例子，如果您的库存中包含此类商品的可用数量，那么客户与库存之间的关系也是多对多的。

注意：不要为表名使用名词的复数形式，这会使您对关系感到困惑。

编辑 ：要在数据库表中应用多对多关系，您将需要一个中介器表。 例如，关于“客户和产品”表，您应该创建一个名为“客户产品”的表（或所需的所有内容）。 CustomerProduct表包含两个外键，一个来自Customer表，另一个来自Product表。 通常（并非始终）将一对多关系分解为两个多对一关系。 请参阅此链接 。

Answer 2

您正在开发的系统似乎有很多东西，并且可能还有您没有提到的要求，因此实际上不可能给出完整的答案。 但是希望下面的某些内容可以帮助您在描述设计时“概念化设计”。

1）这是一个非常常见的场景，并且有很多处理这些多对多关系的标准方法。

如果存在两个具有多对多关系的实体A和B，则通常会引入一个由两列组成的实体C-一个是A唯一ID的外键，另一个是唯一ID的外键B。然后您将删除实体A中指向B的外键列，反之亦然。

即

|-----| 
|  A  |  
|-----| 
  \|/
   |
   |
  /|\
|-----| 
|  B  |  
|-----| 

变成：

|-----| |-----|
|  A  | |  B  |
|-----| |-----|
   |       |
   |       |
   |       |
  /|\     /|\
|-------------|
|      C      |
|-------------|

主要的挑战通常是如何称呼这些新实体！ 有时它们可​​能只是a_b_relationship之类的东西，但是如果可以标识更有意义的名称，则很好。

2）您似乎需要做更多分析才能识别所有实际实体。 一种方法是遍历系统的描述并识别名词-通常，如果描述中有一个名词，则在实体关系图中拥有一个实体是适当的。

“订单”作为您忽略的名词跳出来。

通常，对于订单处理，您将有2个实体-包含日期，总价值，客户等的订单，以及一个子订单行，该子订单行标识了已订购的产品数量和单个价格。 因此，在电子商务中，购物车将是订单，购物车中的每个项目都将是订单行记录。

在您的情况下，我们将：

|----------|            |-----------|
|  client  |            |  product  |
|----------|            |-----------|
      |                       |
      |                       |
      |                       |
     /|\                     /|\   
|-------------|       /|-------------| 
|    order    |--------|  orderline  |
|-------------|       \|-------------| 

3）客户出售许多产品

在这里，您正在为客户确定其他角色，在这里我要问的是“客户”在现阶段是否合适。 在理解“第一手”设计之前，您可能会发现更容易根据“买方”和“卖方”进行思考。 如果买方和卖方有很多共同点（特别是如果一个人既可以是买方又可以是卖方），那么您可能最终决定使用单个实体。 您的ERD工具可能为此提供支持-搜索“子类型实体”或“实体子类型”。

具体细节取决于您的实际应用，但是可能每个订单行都应与卖方有关系，而订单应与买方有关系。 这将取决于例如买方是否可以订购大量特定产品，其中一些来自一个卖方，而另一些则来自另一个卖方。 可能会变得复杂！

此外，考虑在出售之前是否需要记录卖方的库存可能会有所帮助。 在这里区分“产品”和“库存”可能很有用，例如

|---------| |-----------|
|  seller | |  product  |
|---------| |-----------|
   |           |
   |           |
   |           |
  /|\         /|\
|-----------------|
|      stock      |
|-----------------|

作为一般性评论，我想这确实可以帮助逐步完成设计过程。 因此，一旦获得了初始模型，就将需要存储的所有数据项分配给适当的实体，并有条不紊地确保设计采用的是第一个普通形式，然后是第二个普通形式，然后是第三个普通形式。 只有做到这一点，并且确信设计能够反映需求之后，才应该考虑如何在数据库中实现设计。 无论如何，这就是我多年前学到的！