2021年度评测师考试知识点整理.docVIP

数据库范式 范式：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库老祖宗）在上个世纪70年代提出关系数据库模型后总结出来，范式是关系数据库理论基本，也是咱们在设计数据库构造过程中所要遵循规则和指引办法。当前有迹可寻共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。普通所用到只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。下面就简朴简介下这三个范式。 ◆ 第一范式（1NF）：强调是列原子性，即列不可以再提成其她几列。 考虑这样一种表：【联系人】（姓名，性别，电话） 如果在实际场景中，一种联系人有家庭电话和公司电话，那么这种表构造设计就没有达到 1NF。要符合 1NF 咱们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 较好辨别，但是 2NF 和 3NF 就容易搞混淆。 ◆ 第二范式（2NF）：一方面是 1NF，此外包括两某些内容，一是表必要有一种主键；二是没有包括在主键中列必要完全依赖于主键，而不能只依赖于主键一某些。 考虑一种订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。 由于咱们懂得在一种订单中可以订购各种产品，因此单单一种 OrderID 是局限性以成为主键，主键应当是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。因此 OrderDetail 表不符合 2NF。不符合 2NF 设计容易产生冗余数据。 可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复状况。 ◆ 第三范式（3NF）：一方面是 2NF，此外非主键列必要直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键状况。 考虑一种订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。 其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），因此符合 2NF。但是问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，因此不符合 3NF。 通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。 第二范式（2NF）和第三范式（3NF）概念很容易混淆，区别它们核心点在于，2NF：非主键列与否完全依赖于主键，还是依赖于主键一某些；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。 ◆ BCNF是比第三范式更严格一种范式。它规定关系模型中所有属性（涉及主属性和非主属性）都不传递依赖于任何候选核心字。也就是说，当关系型表中功能上互相依赖那些列每一列都是一种候选核心字时候，该满足BCNF。 BCNF事实上是在第三范式基本上，进一步消除了主属性传递依赖。 3．?举例 有这样一种配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表达仓库号，PNO表达配件号，ENO表达职工号，QNT表达数量。 有如下约束规定： （1）???????一种仓库有多名职工； （2）???????一种职工仅在一种仓库工作； （3）???????每个仓库里一种型号配件由专人负责，但一种人可以管理几种配件； （4）???????同一种型号配件可以分放在几种仓库中。 分析表中函数依赖关系，可以得到： （1）???????ENO-WNO; （2）???????（WNO，PNO）-QNT （3）???????（WNO，PNO）-ENO （4）???????（ENO，PNO）-QNT 可以看到，候选键有：（ENO,PNO）