标准化h/w

Question

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

将上述数据显示为UNF中的关系(非标准化数据).

客户(CustomerID,FirstName,LastName,Address,City,Phone,State,Postcode,Qty,ProductNo,Description,Unit price,Total,Subtotal,Shipping,Tax Rate,Date,OrderNo.))

在1NF中将数据显示为关系.(表示任何键.)

客户(CustomerID,FirstName,LastName,地址,城市,州,电话,州,邮政编码)产品(ProductNo,Qty,Description,Unitprice,total,subtotal,shipping,Tax rates(s),CustomerID(FK).)Order( 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,地址,城市,电话,州,邮政编码)产品(ProductNo ,,描述,单价,CustomerID(FK),Total(FK))订单(OrderNo,Date,CustomerID(FK).ProductNo (FK))总计(总计,小计,ProductNo(FK),客户ID(FK))运费(运费,税率,总计(FK),订单号(FK))数量(QtyID,Qty,ProductNo(FK),OrderNo( FK).)

Answer 1

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

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

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

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

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

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

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

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

2NF 与删除部分键依赖关系有关。您发现哪些部分关键依赖关系证明创建表“Total”是合理的？（提示：没有任何理由这样做。）做这个思想实验（或用 SQL 构建它）：如果“Total”是表“Total”的主键，如果两个订单导致总数相同？

我现在就到此为止，因为你真的一开始就走错了路。您需要从所有属性的列表开始，然后确定候选键和功能依赖性。如果不从这里开始，您就不可能找到 3NF。