我们还需要数据标准化吗？

现在让我们测试一下我们的更改是否解决了问题并遵循第二范式。对于我们的收据表，transaction_id 成为唯一的主键。交易日期基于 transaction_id 是唯一的，transaction_time 也是如此；即，一笔交易 ID 只能有一个日期和时间。

订单不能在店内或店外下单，因此是否在店内购买的价值取决于 transaction_id。由于客户无法拆分收据，因此交易也会告诉我们一个唯一的客户。最后，如果有人给我们一个交易 ID，我们就可以识别附加到它的单个客户忠诚度号码。

接下来是收据行项目表。行项目取决于与其关联的交易（收据），因此我们在行项目表中保留了交易 ID。 transaction_id 和 line_item_id 的组合成为订单项表上的复合键。 Product_id 和 product 是根据交易和订单项共同确定的。单个交易 ID 不会告诉我们哪种产品（如果收据包含购买的多种产品），并且单个行项目 ID 不会告诉我们正在引用哪个购买（不同的收据可以订购相同的产品）。这意味着 product_id 和 product 值取决于整个密钥。

我们还可以将 transaction_id 和 line_item_id 中的数量关联起来。收据或行项目 ID 中的数量可能相同，但是两个键的组合为我们提供了单个数量值。如果没有交易 ID 和订单项 ID 字段，我们也无法唯一地标识 unit_price 或 promo_item_yn 列值。

虽然我们已经满足了第二范式，但是一些数据异常仍然存在。如果我们尝试创建新的购买产品或新客户，我们无法在当前的表中创建它们，因为我们可能还没有与它们绑定的收据。如果我们需要更新产品或客户（由于拼写错误或名称更改），我们需要使用这些值更新所有行项目行。如果我们想删除产品或客户，除非删除引用它们的收据或行项目，否则我们无法删除。为了解决这些问题，我们可以转向第三范式。

第三范式：除了密钥什么都没有

第三范式确保非键字段只依赖于键。换句话说，它们不依赖于其他非关键字段，从而导致传递依赖。让我们再次回顾一下我们的 2NF 数据：

收据