如何构建具有多种选择的物料清单

时间:2019-03-27 21:01:16

标签: ms-access database-design

我一直在努力制定Access中的物料清单。我有一个表调用IM_Item_Registry,其中有Item_Code和一个布尔值(如果它是组件)。我受困的是,该公司过去的过失为来自不同供应商的同一原料制造了多个零件编号。产品可能会在运行开始时使用成分1,在运行结束时使用成分2,具体取决于库存,并且可能因工作而异(缺乏纪律和根据价格随机购买)。这让我头疼,因为它们通常具有不同的内含物。我将如何增加同时使用两者的灵活性?还是制作多个版本然后按计划选择这些版本会更容易?

我知道已加载了该文件,如果需要的话,我可以提供更多详细信息,但感谢您一直在研究如何进行此操作的帮助。

编辑(3/28/2019) 这是给注塑公司的。

IM_Item_Registry(字段:Item_Code,类别(原始,制造,客户提供,组装组件),描述,组件(布尔),活动(布尔),度量单位。

为此物料清单100011生成的组件将其称为手柄。帐单100011使用98%夹杂的原始树脂700049和2%夹杂的原始颜色600020。但是,我们可能会用完原始颜色600020,而不得不用掉原始颜色600051,这会将700049更改为98.5%的包含,因为600051需要1.5%的包含才能获得相同的颜色。

我想创建一个表,该表会调用通用术语,假设600020和600051是黄色添加剂。然后创建一个“ ghost”编号以调用600020或600051,并给出两个配方配方。开始生产时,他们将扫描自己实际用来创建生产BOM的颜色,并记录使用了哪种颜色以及使用了多少颜色。有没有办法在Access数据库结构中做到这一点?

我假设我同时需要item_registry表,BoM表(字段:BOM#,ParentID,Ghost_ID)和组件表(字段:Ghost_ID,item_code,包含率)。

1 个答案:

答案 0 :(得分:0)

数据库规范化是在关系数据库中设计高效,有用的表和关系的指导原则。访问表单,子表单,报表等需要正确规范化的表才能按预期工作。规范化有各种级别,但是通常的想法是避免在数据的行和列之间重复数据。拥有重复的数据需要大量的存储开销,并需要确保数据库上的操作不会产生不一致的状态(矛盾的数据值)。规范化的表允许在数据列和/或行之间定义有用的约束,以确保数据有效。

问题中提出的[BoM]表未规范化。但是在此之前,还没有定义ParentID,也不清楚它代表什么。相反,为了帮助说明为什么未将其标准化,让我在[BoM]表中添加[Product]列。然后,如果这样的句柄具有两个替代的组件列表(重影?),则表将看起来像

BOMID, Product, GhostID
-----  -------  -------
1      Handle   1
1      Handle   2

看到重复吗?现在,如果将产品重命名为“ Bronze Handle”,则需要为单个概念元素更新两行。它还引入了具有矛盾数据的可能性,例如

BOMID, Product,       GhostID
-----  -------        -------
1      Handle         1
1      Bronze Handle  2

关于这一点已经足够了,因为我在这里已经对标准化概念进行了太多讨论。以下是一个基本的标准化架构,可以更好地为您服务,但是请注意,它与您在问题中提出的建议并没有太大不同。唯一真正的区别是,BoM表通过将其列(和目的)划分为另一个表来进行归一化。

我没有在这里列出所有列,仅列出了主键和外键以及其他一些有意义的列。 PK =主键(唯一,非空键),FK =外键。应该在PK和FK列上定义适当的索引,并在适当的约束下定义关系。

Table: [IM_Item_Registry]
Item_Code (PK)

Table: [BOM]
BOMID (PK)
ProductID (FK)

Table: [BOM_Option]
OptionID (PK)
BOMID (FK)
Primary (boolean) - flags the primary/usual list of components
Description

Table: [Option_Items]
OptionID (FK; part of composite PK)
Item_Code (FK; part of composite PK)
Inclusion_Rate 

[BOM].[ProductID]列表示另一个表格,其中包含应与物料清单分开定义的产品详细信息。如果此数据库确实非常简单,那么它可能只是一个包含名称的字符串字段[Product],但我认为还有很多有用的细节要存储。也许这就是ParentID也提到的内容? (我建议选择不太抽象的名称,例如“ parent”和“ ghost”,因此我选择“ option”一词。)

实际上,由于[BOM_Option]应该限制为每个BOM的单个选项,因此它将能够正确地规范化以创建另一个表,例如

Table: [BOM_Primary]
[BOMID] (FK and PK) - Primary key so only one primary option can be defined at once
[OptionID] (FK)