我目前正在尝试重新设计一个销售点数据库，以使其更加规范化，这将极大地帮助管理数据等。我对基于数据的最佳设计实践有点不确定必须处理。首先，基本上有两组措施，它们共用共同的密钥。有库存数据，单位和美元，然后是销售点数据，单位和美元。这些都是客户，商店，商品和日期级别。
我所做的（目前主要在理论上）是为
创建分隔表Item level information
Item_ID,
Customer_ID
itemnumber
(and a few other item specific information).
Stores
Store_ID,
Customer_ID,
Store Number,
(and essentially address information)
Customer
Customer_ID,
Customer Number
(other customer specific information like name).
所以除了那些“支持”表之外，我还有
Main Inventory Data
Store_ID
Item_ID
我也有POS数据表，ID完全相同。
基本上我的问题是：
我的第二个问题是，如果我确实添加了客户ID，如果我将所有这些表加在一起，
让我就数据提供一些额外的细节。例如，我们有两个客户，CustomerA和CustomerB。 CustomerA有几家商店，其商店数量分别为1000,1025,1036和1037.CustomerB还有几家商店，其商店数量分别为1025,1030和1037.商店数量1025和1037在客户之间恰好相同，但商店本身是独一无二的，完全不同。
CustomerA的商店编号1000销售我们的三件商品（这是批发视角），即ABC，DEF和EFG。 CustomerA的商店编号1025还出售我们的三件商品，即ABC，HIJ和XYZ。
这些项目中的每一项都包含两个导入的数据，涉及其与特定客户和商店编号，销售点数据和库存数据的关系。销售点数据将采用PosUnits的形式，即销售商品的数量，PosDollars，即商店中销售商品的总数（基本上是单位数乘以价格被卖掉了）。库存数据将在InventoryUnits中，这是商店中库存的商品数量。 [有一点需要注意，我将库存和pos数据分成不同的表格，因为我们并不总是从每个客户那里收到两条数据。另外，库存和POS数据通常也是单独分析的。]
所以，回到我的例子，CustomerA的商店编号1000，项目ABC可能已售出100个单位，即1245.00美元。 CustomerA的商店编号1025，可能仅以124.50美元的价格仅售出10件相同商品。
现在，如果我们回到CustomerB，就会发生这样的情况：客户还有一个名为ABC的商品，它在许多商店销售。 CustomerA的项目ABC与CustomerB的项目ABC完全不同。他们将它们命名为同样的东西，纯属巧合。
让我补充最后一点澄清，我可能应该在前面说过。我的观点是批发商。当我说项目时，我说的是客户项目编号，而不是批发商项目编号。获得批发商项目涉及交叉参考，并且客户可能有多个项目编号参考相同的批发商项目编号。不过，我不认为有必要深入研究它。
答案 0 :(得分：0)
问题＃1：作为规范化规则的一部分，除非存在需要de-normalization的性能问题，否则应避免在任何表中包含冗余数据。有成千上万的文章可以解释为什么要避免冗余。
关于问题＃2：在规则中只选择查询中需要的列，如果需要Customer_ID从数据库更便宜的地方选择它
请允许我再提一个问题
为什么您可以在Stores和Item_level中重复使用Customer_ID，并考虑Main Inventory Data。这是另一种冗余。