标准化h / w

Question

被告知要把它放入UNF / 1NF / 2NF / 3NF，这是对的吗？

将上述数据显示为UNF中的关系（非标准化数据）。

客户（CustomerID，FirstName，LastName，地址，城市，电话，州，邮政编码，数量，产品编号，描述，单价，总计，小计，运费，税率，日期，订单号。）

在1NF中将数据显示为关系。 （表示任何键。）

客户（CustomerID，FirstName，LastName，地址，城市，州，电话，州，邮政编码） 产品（ProductNo，Qty，Description，Unitprice，total，subtotal，shipping，Tax rates（s），CustomerID（FK）。） 订单（OrderNo，Date，ProductNo（FK）。）

在2NF中将数据显示为关系。 （表示任何键。）

客户（CustomerID，FirstName，LastName，地址，城市，电话，州，邮政编码） 产品（ProductNo，Qty，Description，UnitPrice，CustomerID（FK），Total（FK）。） 订单（OrderNo，Date，CustomerID（FK），ProductNo（FK）。） 总计（总计，小计，运费，税率，ProductNo（FK），CustomerID（FK））

在3NF中将数据显示为关系。 （表示任何键。）

客户（CustomerID，FirstName，LastName，地址，城市，电话，州，邮政编码） 产品（产品编号，描述，单价。客户ID（FK），总计（FK）） 订单（OrderNo，日期，客户ID（FK）.ProductNo（FK）） 总计（总计，小计，ProductNo（FK），客户ID（FK）） 运费（运费，税率，总额（FK），订单号（FK）） 数量（QtyID，Qty，ProductNo（FK），OrderNo（FK）。）

Answer 1

这对我来说很好，但你错过了一个关键部分的设计。您没有在表上定义任何主键，尽管您已经识别了外键（使用外键来计算每个表上的主键:)。

Answer 2

关于发票的有趣之处...... J Frompton今天订购了一个佣金，但未来一段时间价格会发生变化。但是，这并没有改变Frompton今天支付的价格。

一旦发票完成，他们确实应该转移到1NF的表格。

Answer 3

  

将上述数据显示为UNF中的关系（非标准化数据）。

     

客户（CustomerID，FirstName，LastName，地址，城市，电话，   州，邮编，数量，产品编号，描述，单价，总计，   小计，运费，税率，日期，订单号。））

不，那不对。发票上似乎没有任何客户ID号。规范化不涉及引入新属性。作为非标准化的属性集合，列为“客户”的标签为时过早。

  

在1NF中将数据显示为关系。 （表示任何键。）

     

  
• 客户（CustomerID，FirstName，姓氏，地址，城市，州，   电话，州，邮政编码）
  
• 产品（ProductNo，Qty，Description，   Unitprice，total，subtotal，shipping，Tax rates（s），CustomerID（FK）。）
  
• 订单（OrderNo，Date，ProductNo（FK）。）
  

删除CustomerID。 （见上文。）我猜测“Product”表的候选键之一是“ProductNo”。如果是这种情况，为什么该表包含“CustomerID”？

  

在2NF中将数据显示为关系。 （表示任何键。）

     

  
• 客户（CustomerID，FirstName，LastName，地址，城市，电话，州，邮政编码）
  
• 产品（ProductNo，Qty，Description，UnitPrice，CustomerID（FK），Total（FK）。）
  
• 订单（OrderNo，Date，CustomerID（FK），ProductNo（FK）。）
  
• 总计（总计，小计，运费，税率，产品编号（FK），客户ID（FK））
  

2NF与删除部分密钥依赖关系有关。您确定哪些部分密钥依赖关系证明创建表“Total”是合理的？ （提示：没有任何理由。）执行此思想实验（或在SQL中构建）：如果“Total”是表“Total”的主键，如果两个订单导致相同的总数？

我暂时停在那里，因为你真的错了。您需要使用所有属性的列表启动，然后识别候选键和功能依赖项。没有在那里开始，你不太可能找到3NF。