0

目前我在学习标准化时遇到了麻烦。虽然我知道 1NF - 3NF 背后的基本概念，但我仍然不了解标准化之前需要遵循的步骤。

根据我的理解，一个人必须先收集base entities，他们的attributes，relation among the entities然后start normalization。但我不明白，我是应该一次规范化所有属性还是规范化彼此具有某种关系的实体的属性。

考虑一个商店的例子。

store(name, address, contact)
customer(sn, name, address)
item(id, name, price)
transaction(id, date, customer_sn, item_id, quantity, total_price)

根据我的理解，我要么尝试一次规范化所有属性，要么只规范化customer,item和的属性transaction。

我知道我错过了一些东西，我只是无法弄清楚。

任何帮助表示赞赏。感谢您宝贵的时间。

4

1 回答 1

-1

根据我的理解，必须首先收集基本实体、它们的属性、实体之间的关系，然后开始规范化。

不，你不必那样做。事实上，在开始规范化之前，即使不是不可能，也很难识别一些基本实体。

在逻辑层面，您首先收集所有需要的属性，然后将它们放在一个大关系中。您几乎可以在每本关于数据库系统的教科书中找到这方面的较小示例。

收集所有必需的属性后，确定它们之间的依赖关系。

对于商店，您可能会收集这些属性。

  • A、店铺名称
  • B. 存储物理地址
  • C. 项目 sku
  • D. 物品名称
  • E. 商品价格
  • F. 交易时间戳
  • G. 交易类型（如“Purchase”、“Return”、“Store Credit”等）
  • H. 事务寄存器（哪台机器执行了事务）
  • 一、交易出纳（哪位员工进行了交易）
  • J. 交易项目 sku
  • K. 交易项目价格
  • l.交易项目数量
  • M. 交易项目扩展价格
  • N. 交易项目销售税
  • O. 交易总额
  • P. 交易支付方式（现金、支票、信用卡）
  • Q. 交易支付金额

之后，您可能会确定这些功能依赖关系是否适用。

  • A->B
  • B->A
  • C->D
  • C->E
  • FH->GI
  • FH->O
  • J->K
  • FHJ->L
  • KL->M
  • KL->N
  • M->N

这是您开始规范化的地方。每次分解一个关系以将其提升到更高的范式时，都会添加另一个关系。每次添加另一个关系时，您也会对其应用所有规范化原则。该过程是递归的。

好的 CASE 工具可以根据依赖关系列表生成所有可能的 5NF 分解。

其他设计决策也很重要，但可能与规范化无关。

例如，一个设计项目可能决定每人只存储一个电话号码。另一个项目可能决定为每个人存储多个电话号码。这种决定很重要，但与标准化无关。也就是说，每个人存储一个电话号码不违反任何正常形式，每个人存储多个电话号码也没有。

于 2013-01-10T11:15:20.390 回答