物料清单数据库模型答案

【问题标题】：Bill of materials database model物料清单数据库模型
【发布时间】：2013-07-15 09:55:28
【问题描述】：

我目前正在开展一个项目，该项目应有助于我们控制库存以及采购以组装最终产品。

我们正处于对数据库进行建模的阶段，其中一项要求是生成 BOM（物料清单）。

我已阅读 this thread 并找到了 BOM 的示例数据模型：

conceptual data model 和 physical data model

但我不确定我是否完全理解。

我们的最终产品由几个子组件组成，因此每个子组件是product_hierarchytable 中的一行，最终产品也是该表中的一行。每个子组件由单独的（原子）零件组成，每个零件在表格tpart 中标识（每个零件都有制造商字段、最小再订购数量和其他特定字段）。

在生成 BOM 时，所有单独的部分也应该包括在内，所以我不清楚如何为我们的数据库建模：

单独的部分是product_hierarchy 中的一行，它永远不会是一个人的“父”（不再需要表格 tpart）
product_hierarchy和tpart之间的N:M关系：每个单元有几个部分；每个部分可以属于多个单元

我倾向于第二种选择，因为零件基本上是一个完全不同的实体（有价格，几个可能的供应商，...），而组装实体没有外部（如：在我们公司之外）属性.

感谢任何输入！谢谢！

【问题讨论】：

我的第一个想法是这可能缺乏抽象层次。例如，在浴室中，您可能知道您将要提供浴缸、脸盆和 WC，而不必指定这些物品是什么 - 并允许它们可能会改变。
您是否已经知道这将在哪个 RDBMS（Oracle、SQLServer、MySQL 等）上实现？（MySQL 中的 BOM 样式数据存在问题，而许多其他 RDBMS 则没有。）
@MarkBannister 最有可能是 MySQL，那可能是什么问题？
问题是 MySQL 不支持递归公用表表达式或任何类似的东西（例如 Oracle 的 connect by 语法） - 所以如果您尝试通过拥有父产品代码来建模层次结构在与产品代码相同的表中（称为 en.wikipedia.org/wiki/Adjacency_list_model ），您将无法在单个查询中查询完整的表层次结构。如果您致力于使用 MySQL，那么您应该调查 en.wikipedia.org/wiki/Nested_set_model，但我强烈建议您考虑使用其他 RDBMS，例如 PostgreSQL。

标签： database-design

【解决方案1】：

您链接的模型未能解决 BOM 通常具有的一些主要属性：

零件和子组件可以重复使用。例如，在许多组件中使用同一种螺栓是很常见的。
需要有一个BOM 特定数量。例如，重要的是要知道一个组件需要（比如说）50 个螺栓，但其他组件可能只需要 30 个相同类型的螺栓。

这是一个解决这些问题的简单模型：

PART 表是顶部组件或子组件或叶零件。它使用一个公开的“部件号”来标识它的行，这实际上根本不是一个数字，并且可以包含非数字字符。

BOM 表自己建模 PART 的多对多关系。它实际上与任何其他联结表没有什么不同，除了两个“端点”表实际上是同一个表。这样，一个子装配体或零件可以在多个父装配体中重复使用。

在此模型之上，您可以很自然地添加诸如“绘图位置”或“度量单位”之类的内容（例如，油漆可以是 BOM 的一部分，但以“千克”而不是“件”来衡量）。

实际上你可能想做更多的事情，但超出了像这样的简单 StackOverflow 帖子的范围。

例如：

您如何处理变化？你有部分版本控制吗？您是否对 BOM 本身进行版本控制？
不同的供应商可能对基本相同的部件使用不同的部件号。
您可能希望跟踪存储或组装/生产零件的“地点”（仓库或工厂）。对于不同的站点，“相同”的装配体甚至可能具有略微不同的 BOM。
您可能需要区分“制造”和“购买”部件。
您是否有生命周期工作流程（批准/发布/废弃）？
您可能想要存储用户定义的属性。属性通常包括质量、体积和材料等内容，但可能还有许多其他无法提前预见的内容。
您可能希望将物理 CAD 模型连接到数据库中的数据。
您可能希望禁止某些用户对数据库进行某些更改（例如，采购部门不能更改装配结构，至少在没有监督的情况下不能更改）。
等等等等……

这些是实际 PDM 系统趋于复杂的部分原因。如果您确实需要所有这些功能，您可能应该考虑使用商业产品，而不是尝试自己重新实现它...

【讨论】：

感谢您的回答。关于：“您链接的模型无法解决 BOM 通常具有的一些主要属性”，我是这么认为的，并且也提出了与“BOM”表相同的想法，但我不确定这是要走的路.但是，我无法立即看到将“零件”用作顶部组件、子组件和叶子的优势。我们确实已经有了“零件编号”，但我们的装配零件却没有。至于您的“额外”评论：确实需要其中一些（例如用户权限），我们也在考虑使用现有的（开源或非开源）解决方案。
@user729103 好吧，您需要一个表来使 PART_NO 唯一 - 您不能（轻松）使 PART_NO 在多个表中唯一。但是，如果您愿意，您可以从 PART 表中“继承”特定的“子类”...
@BrankoDimitrijevic 这里的 BOM 结构适用于子组件和叶子，但我看不出它如何适用于顶部组件。顶部装配没有 PARENT_PART_NO。我们不能将该字段设置为 NULL，因为它在 PK 中。你有解决这个问题的建议方法吗？
@Ben 您只是省略了整行。更准确地说：对于顶级装配，BOM 表中将有零行，CHILD_PART_NO 等于该装配的 PART_NO。
@BrankoDimitrijevic 谢谢！我现在在生产中使用它。

【解决方案2】：

听起来您可能有两种产品。一个是“原子”部分，另一个是“复合”最终产品。我会将它们存储在两个单独的表中，因为它们都需要不同的信息。

CompoundProduct 表还需要一个子表，用于将部件链接到最终产品。

如果您愿意，您仍然可以拥有一个包含所有产品的“抽象”产品表：零件和最终产品。在此表中，您可以存储代码和名称，并且可以方便地拥有一张可以购买并显示在订单或发票上的产品表。 Part 表和 CompoundProduct 表都可以有一个产品 id，它是抽象产品表的外键，但在 Part 和 CompoundProduct 中也是唯一的。

所以总的来说，这个数据库方案是强大而灵活的，但我认为它不够完整，或者可能太灵活，无法满足您的需求。

【讨论】：