关系型数据库设计要点(1)

设计数据库的步骤

1.需求分析阶段:分析客户的业务和数据处理需求.

2.概要设计阶段:主要就是绘制数据库的E-R图.

3.详细设计阶段:应用数据库的三大范式进行审核数据库的结构.

总结:在进行数据库的系统分析时,都以下列4点为参考的基本步骤.

01.收集信息.

02.标识实体.

03.标识每个实体需要储存的详细信息.

04.标识实体之间的关系.

示例：

某酒店管理系统E-R图：

E-R图

数据模型图：

数据模型图

掌握关系型数据库的三大范式

1.第一范式:

目标是确保每列的原子性.如果每列都是不可再分的最小数据单元,则满足第一范式.

第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项。

举例说明：

表1

在上面的表中，“家庭信息”和“学校信息”列均不满足原子性的要求，故不满足第一范式，调整如下：

表2

可见，调整后的每一列都是不可再分的，因此满足第一范式（1NF）；

2.第二范式:

第二范式在第一范式的基础上更进一层,其目标是确保表中的每列都和主键相关,也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中.如果一个关系满足第一范式,并且除了主键以外的其他列都依赖于该主键.则满足第二范式.

第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。

举例说明：

表3

在上图所示的情况中，同一个订单中可能包含不同的产品，因此主键必须是“订单号”和“产品号”联合组成，

但可以发现，产品数量、产品折扣、产品价格与“订单号”和“产品号”都相关，但是订单金额和订单时间仅与“订单号”相关，与“产品号”无关，

这样就不满足第二范式的要求，调整如下，需分成两个表：

表4 表5

3.第三范式:

第三范式在第二范式的基础上更进一层,第三范式的目标是确保每列都和主键列直接相关,而不是间接相关.如果一个关系满足第二范式,并且除了主键以外的其他列都这能依赖于主键列,列和列之间不存在相互依赖关系,则满足第三范式。

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

举例说明：

表6

上表中，所有属性都完全依赖于学号，所以满足第二范式，但是“班主任性别”和“班主任年龄”直接依赖的是“班主任姓名”，

而不是主键“学号”，所以需做如下调整：

表7 表8

这样以来，就满足了第三范式的要求。

注: 把上表中的班主任姓名改成班主任教工号可能更确切，更符合实际情况，不过只要能理解就行。

注意事项：

1.必须先满足第一范式才能满足第二范式，必须同时满足第一第二范式才能满足第三范式。

三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。

总结：

第1范式：每个表中都有1列，并且该列是不可拆分的最小单元（强调的是列的原子性，即列不能够再分成其他几列）

第2范式：1张表只描述一件事情（非主键列是否完全依赖于主键，还是依赖于主键的一部分）

第3范式：用外键做表的关联（非主键列是直接依赖于主键，还是直接依赖于非主键列）

4. BCNF范式：在第三范式的基础上消除主属性对于主键的部分与传递函数依赖。

要了解 BCNF 范式，那么先看这样一个例子：

假如：

某公司有若干个仓库；

每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；

一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？

答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量

键值：（管理员，物品名），（仓库名，物品名）

主属性：仓库名、管理员、物品名

非主属性：数量

因为不存在非主属性对码的部分函数依赖和传递函数依赖，所以， 此关系模式属于3NF。

基于此关系模式的关系（具体的数据）可能如图所示：

表9

既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：

先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。

某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。

如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。

从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。

造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

仓库（仓库名，管理员）

库存（仓库名，物品名，数量）

这样，之前的插入异常，修改异常与删除异常的问题就被解决了。

数据库规范性和性能的关系

为了满足三大范式,我们的数据操作性能会受到相应的影响,所以,在实际的数据库设计中,既要考虑三大范式,避免数据的冗余和各种数据操作异常;又要考虑到数据访问性能,有时,为了减少表间连接,提高数据库的访问性能,允许适当的数据冗余列,这才是最合适的数据库设计方案。规范化的优点是明显的，它避免了大量的数据冗余，节省了存储空间，保持了数据的一致性。当一个库里的数据经常发生变化时，达到3NF的库可以使用户不必在超过两个以上的地方更改同一个值。那么是不是只要把所有的表都规范为3NF后，数据库的设计就是最优的呢?这可不一定。范式越高意味着表的划分更细，一个数据库中需要的表也就越多，用户不得不将原本相关联的数据分摊到多个表中。当用户同时需要这些数据时只能采用连接表的形式将数据重新合并在一起。同时把多个表连接在一起的花费是巨大的，尤其是当需要连接的两张或者多张表数据非常庞大的时候，表连接操作几乎是一个噩梦，这将会严重地降低系统运行性能。

参考材料：

链接：https://www.zhihu.com/question/24696366/answer/29189700

来源：知乎