标准化 h/w

Question

被告知将其放入 UNF/1NF/2NF/3NF，这是正确的吗？

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

客户（客户 ID、名字、姓氏、地址、城市、电话、州、邮政编码、数量、产品编号、描述、单价、总计、小计、运费、税率、日期、订单号））

将数据显示为 1NF 中的关系。 （指明任何键。）

客户（客户 ID、名字、姓氏、地址、城市、州、电话、州、邮政编码） 产品（产品编号、数量、描述、单价、总计、小计、运费、税率、客户 ID（FK）。） 订单（订单号、日期、产品号（FK）。）

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

客户（客户 ID、名字、姓氏、地址、城市、电话、州、邮政编码） 产品（产品编号、数量、描述、单价、客户 ID（FK）、总计（FK）。） 订单（订单号，日期，客户 ID（FK），产品号（FK）。） Total(Total, subtotal, shipping, Tax Rates, ProductNo(FK),CustomerID(FK) )

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

客户（客户 ID、名字、姓氏、地址、城市、电话、州、邮政编码） 产品（ProductNo, , Description, Unit Price. CustomerID(FK), Total(FK) ） 订单（OrderNo、Date、CustomerID(FK).ProductNo(FK)） 总计（总计、小计、产品编号（FK）、客户 ID（FK）） 运费（运费、税率、总计（FK）、订单号（FK）） 数量(QtyID, Qty, ProductNo(FK), OrderNo(FK).)

Answer 1

对我来说看起来不错，但您缺少设计的一个关键部分。尽管您已经确定了外键，但您尚未在表上定义任何主键（使用您必须在每个表上计算出主键的外键 :)）。

Answer 2

关于发票的一个有趣的事情......J Frompton 今天订购了一个耙子，但在未来的某个时间价格会发生变化。但是，这不会改变 Frompton 今天支付的价格。

发票完成后，确实应该将它们移动到 1NF 的表中。

Answer 3

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

客户（客户 ID、名字、姓氏、地址、城市、电话、 状态、邮编、数量、产品编号、描述、单价、总计、 小计、运费、税率、日期、订单号))

不，这是不对的。发票上似乎没有任何客户 ID 号。规范化不涉及引入新属性。作为一个非规范化的属性集合，将该列表标记为“客户”还为时过早。

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

• 客户（客户 ID、名字、姓氏、地址、城市、州、 电话、州、邮政编码）
• 产品（产品编号、数量、描述、 单价、总计、小计、运费、税率、CustomerID(FK)。）
• 订单（订单号、日期、产品号（FK）。）

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

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

• 客户（客户 ID、名字、姓氏、地址、城市、电话、州、邮政编码）
• 产品（ProductNo、Qty、Description、UnitPrice、CustomerID(FK)、Total(FK)。）
• Order(OrderNo, Date, CustomerID(FK), ProductNo(FK).)
• 总计（总计、小计、运费、税率、ProductNo(FK)、CustomerID(FK)）

2NF 与删除部分关键依赖项有关。您认为创建“Total”表的合理性是什么部分键依赖？ （提示：没有任何理由。）做这个思想实验（或用 SQL 构建它）：如果“Total”是表“Total”的主键，如果两个订单导致总数一样吗？

我现在就停下来，因为你真的走错了路。您需要开始列出所有属性，然后确定候选键和功能依赖项。如果不从那里开始，您不太可能找到 3NF。