加入收藏 | 设为首页 | 会员中心 | 我要投稿 商洛站长网 (https://www.0914zz.com/)- AI应用、CDN、边缘计算、云计算、物联网!
当前位置: 首页 > 数据库 > MsSql > 正文

数据库范式是什么意思

发布时间:2023-12-22 08:05:01 所属栏目:MsSql 来源:DaWei
导读: 范式是什么玩意,它意指规范化规则,通俗易懂一点讲则是定义的规范、规则,需要我们去遵守,那么为何要定这一套规则呢?我们反过来想,肯定是前人遇到过,若不定义这一套规则,则出现这样或
范式是什么玩意,它意指规范化规则,通俗易懂一点讲则是定义的规范、规则,需要我们去遵守,那么为何要定这一套规则呢?我们反过来想,肯定是前人遇到过,若不定义这一套规则,则出现这样或那样的问题,为了规避这样问题的出现则出了这一套规则,主要是为了解决如下两点问题。

(1)避免在数据修改过程中出现异常。

(2)保持数据最低限度的冗余。

数据库范式最基础的范式为第一范式(1NF)、第二范式(2NF)、第三范式(3NF),还有更高层次的范式,但太过于复杂我们不做探讨,大部分书籍都这样说,我们就这样去了解。

第一范式(1NF)

定义:关系表中行必须是唯一且属性是原子性的。

太晦涩,太抽象,不太懂,我们一一来分析,我们看看上述定义中重点在于行【唯一】,属性【原子性】。

那么到底什么情况下才算是行唯一呢?

第一:既然是唯一,那么行中某一标识必须是已知而非未知即不能为空

第二:唯一也就是说不能重复诺

第三:怎么保证行唯一呢?通过定义一个唯一键来实现唯一行。

到这里我们可以作出总结第一范式满足的条件:

(1)唯一标识的键

(2)键不能为空

(3)键不能重复

(4)属性不可再划分

第二范式(2NF)

定义:在满足第一范式的前提下,每一个非键属性必须满足对整个候选键的完全函数依赖即非键属性不能是对候选键某部分的完全函数依赖。

好了,我们继续入上述解释第一范式来解释第二范式晦涩难懂的定义。

我们可以通过部分候选键(主键)比如OrderId得到OrderDate、CustomerId和CompanyName等列,此时是仅仅是OderId的部分依赖而非对OderId和ProductId二者的完全依赖。

所以将上述定义通俗讲则是:属性对主键应该属于完全依赖而非部分依赖,否则违反第二范式。

第三范式(3NF)

同样第三范式是在满足第一和第二范式的前提下来看第三范式。

定义:所有非键属性必须依赖于非传递的候选键,也就是非键属性相互之间必须相互独立,进一步讲非键属性之间不能形成依赖关系。

我们看看上述经过修改满足第二范式的两个表,此时订单表中OrderId为主键,客户Id即CustomerId和公司名称即CompanyName对OrderId是完全依赖,我们可以通过订单Id得到客户Id,也可以通过订单Id得到公司名称,同时我们也可以通过客户Id得到客户公司名称,也就是说此时CustomerId和CompanyName是一种传递关系,而非相互之间独立。此时若需要满足第三范式则应该是如下表示:

我们可以看出第三范式着重强调的是非键属性与非键属性之间独立,而第二范式着重强调的是非键属性与候选主键的完全依赖。所以第二范式和第三范式我们统一概括为:非键属性必须是对键的依赖,而非相互之间依赖,并且是对整个键的依赖。

(编辑:商洛站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章