【问题标题】:Before Normalization标准化之前
【发布时间】:2013-01-10 19:15:20
【问题描述】:

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

据我了解,首先要收集base entities,他们的attributesrelation 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)

根据我的理解,我要么尝试一次规范化所有属性,要么只规范化 customeritemtransaction 的属性。

我知道我错过了什么,我就是想不通。

感谢任何帮助。感谢您宝贵的时间。

【问题讨论】:

  • 您接受的答案中的几乎所有内容都是错误的。
  • @Catchall:您对 2.NF 的看法是正确的,但告诉 Almost everything is wrong 是荒谬的,您可能会添加到商店的价值列表不是问题中所要求的,也不是帮助任何人。但我删除了我的答案,因为我不认为t want to be downvoted because of your ridiculous comment and your apparent inability to understand it combined with a much higher reputation. I dont 认为用户接受了因为它没有帮助他。

标签: database normalization


【解决方案1】:

据我了解,必须先收集基础实体, 它们的属性,实体之间的关系,然后开始 标准化。

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

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

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

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

  • A.店铺名称
  • 乙。存储物理地址
  • C.商品 sku
  • D.商品名称
  • E.商品价格
  • F.交易时间戳
  • G.交易类型(如“购买”、“退货”、“商店信用”等)
  • H.交易寄存器(哪台机器执行了交易)
  • 我。交易出纳员(执行交易的员工)
  • J.交易项目 sku
  • K.交易商品价格
  • L.交易物品数量
  • M.交易商品加价
  • N.交易项目销售税
  • O.交易总额
  • 页。交易支付类型(现金、支票、信用卡)
  • 问。交易支付金额

然后,您可能会确定这些功能依赖关系适用。

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

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

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

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

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

【讨论】:

    猜你喜欢
    • 2018-04-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-08-29
    • 1970-01-01
    • 2019-12-02
    • 2020-10-15
    • 1970-01-01
    相关资源
    最近更新 更多