热门问题
时间线
聊天
视角

第三范式

要求所有非主鍵都只和候選鍵有關聯的資料庫正規化形式 来自维基百科,自由的百科全书

Remove ads

第三范式(3NF)是数据库规范化所使用的正规形式,要求所有非主键属性都只和候选键有相关性,也就是说非主键属性之间应该是独立无关的。

如果再对第三范式做进一步加强就成了BC范式,强调的重点在于“资料间的关系是奠基在主键上、以整个主键为考量、而且除了主键之外不考虑其他因素”。

正规定义

令:

  • 表一个关系;
  • 表维持 所需的一组函数依赖
  • 属性的子集合
  • 的一个属性

最早由埃德加·科德在1971年给出的第三范式定义为[1]

  • 关系R(表)满足第二范式 (2NF);
  • R的每个非键属性是R的每个候选键的非传递依赖。

Carlo Zaniolo于1982年给出的一个等价定义为[2][3]

如果对于 这种型式的函数依赖而言,下列叙述任一为真的话,则可以称 符合第三范式:

  • ;也就是说 明显函数依赖
  • 超键
  • 候选键的一部分

任何一个具有部分依赖性或是转移依赖性的关系都违反了第三范式。

Remove ads

范例

以下面这个定义机械元件的关系为例:

更多信息 元件编号 (主键), 制造商名称 ...

本例中制造商地址很明显地不该被列在这个关系里面,因为和元件本身比起来,制造商地址应该和制造商比较有关系;正确的做法应该是把独立出新的资料表:

更多信息 制造商名称 (主键), 制造商地址 ...

然后把原本的资料表改成这样:

更多信息 元件编号 (主键), 制造商名称 ...

先前那个资料表的问题在于每提到一次制造商名称就要多存一次它的地址,而这就不符合第三范式的原则。

下面提供了另一个例子:

更多信息 订单编号(Order Number) (主键), 客户名称 (Customer Name) ...

在本例中,非主键字段完全依赖于主键订单编号,也就是说唯一的订单编号能导出唯一非主键字段值,符合第二范式。第三范式要求非主键字段之间不能有依赖关系,显然本例中小计依赖于非主键字段“单价”和“数量”,不符合第三范式。小计不应该放在这个资料表里面,只要把单价乘上数量就可以得到小计了;如果想要符合第三范式的话,就把小计拿掉 (不过在做查询时, SELECT Order.Total FROM Order 需改成 SELECT UnitPrice * Quantity FROM Order )。

更多信息 订单编号(Order Number) (主键), 客户名称 (Customer Name) ...
Remove ads

参考文献

外部链接

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads