【发布时间】：2013-10-13 07:29:11
【问题描述】：
所以基本上我是在规范化发票，在所有 2NF RELATIONAL SCHEMA'S 中包含 FK *INV_NUM* 是否错误。这是我已经拥有的。
*显示PK
1NF（*INV_NUM、INV_DATE、C_ID、C_NAME、C_STR、C_STATE、PART_NUM、PART_DESC、PART_QUANUSED、PART_PRICE、LBR_NUM、LBR_DESC、LBR_PRICE、TAX_RATE）
部分依赖
- (C_ID--> C_NAME,C_NAME,C_STR,C_STATE)
- （PART_NUM--> PART_DESC、PART_QUANUSED、PART_PRICE）
- (LBR_NUM--> LBR_DESC, LBR_PRICE)
传递依赖
- (C_STATE--> TAX_RATE)
2NF 客户 (*C_ID, C_NAME,C_NAME,C_STR,C_STATE)
2NF PART（*PART_NUM、PART_DESC、PART_QUANUSED、PART_PRICE）
2NF 劳动力（*LBR_NUM、LBR_DESC、LBR_PRICE）
【问题讨论】：
-
“传递依赖”
C_STATE--> TAX_RATE是什么意思？传递依赖关系在 3 个属性之间。 -
这是我的书传递依赖中传递依赖的定义 – X-> Y, Y->Z (X 是 PK) 因此，X -> Z 是传递依赖 – 传递依赖存在仅当非主属性之间存在函数依赖关系时（例如，Y->Z）。 • 非主键 = 不是任何候选键的一部分 • 候选键 = 最小超键
-
在我的问题的业务规则中，它说 Tax_Rate 是根据客户的状态计算的，所以我是如何得出这个假设的。
-
通常的符号是 X -> Y -> Z，它暗示 X -> Z，但反之则不然，所以它们不是等价的符号。所以如果你只是说 C_STATE--> TAX_RATE，那并不能告诉我们这应该是一个传递依赖，也不能告诉我们哪个是“中间”属性。顺便说一句，在 3NF 的上下文中，哪些属性是素数变得很重要。
标签： database-design database-schema rdbms relational database-normalization