数据库三范式哲学

目的：关系型数据库设计规范化目的是使结构更合理，节约存储空间，消除存储异常，使数据冗余尽量小，便于插入、删除和更新

原则：遵从概念单一化 "一事一地"原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。

方法：将关系模式投影分解成两个或两个以上的关系模式。

要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。

第一范式表示问题的定义（原子性），过去、现在、将来是什么，目标非常明确？例如：学生是什么,即学生信息系统是由学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话等等，这些都得明确定义。为了便于理解记忆（见《金字塔原理》第一章也由同样的观点http://book.douban.com/annotation/17348963/  ），需要将其归类处理。

 

第二范式表示结构性分析问题，将问题进行分解，归类。按照特性归类如下：

（1）（学号）→ (姓名,年龄，性别，系别，系办地址、系办电话)

（2）  (课程名称) → (学分)

（3）（学号，课程）→ (学科成绩) 

第三范式表示。。。

 

 

（1）原子性。

原子性。为了保证原子性，提高有效性，需要将抽象概念进行分解，直到不可分割为止。虽然抽象的概念比较好管理，但在数据量比较大时访问效率较低。因为特别是数据无序时更是如此。例如，客户联系方式有电话号码，邮箱，Email，QQ，微博等等。如果将其杂乱地融合在一块，那么访问时效率比较低。因为联系方式较多，彼此之间无逻辑关系。

 

（2）列必须完全依赖主键，不存在部分依赖。(强关系，而不是弱关系，即非主键列与主键列必须为组合关系，而不是聚合关系)。如果存在聚合关系，那么应将其抽出形成独立一张表，新表与原表应为一对多关系。如果不这么做，那么在对表进行操作时会出现问题。例如：张三使用自行车，李四也可以使用自行车，王五任然可以使用自行车。对于自行车任何人都可以使用，并不是那一个人的专利。

    a）数据冗余。

    b）插入异常。

    c）更新异常。

    d）删除异常。

 

（3）属性不依赖于其它非主属性，不能间接依赖，也即是依赖不具备传递性。因为虽然满足了2范式，但分离数据后，不能保证数据的唯一性。即分离后的数据与原始数据必须等价。为了解决此问题，首先将子表开设一列满足分离后数据与数据自己的联系。例如：之前客户表和订单表融合在一起，但此数据库的设计未满足三范式，数据冗余，而且也不能保证数据唯一性及操作异常。需要将数据归类分离出去，形成独立的，然而为了保证数据的完整性，还需维护彼此的关系，建立相应的列来存储此关系。即一个客户有多个订单。在订单表中设计一列为此订单所属客户。然后通过存储过程实现数据的合并。

 

 

UML类之间的几种关系。详见：http://www.uml.org.cn/oobject/201012233.asp

 

参考：http://hi.baidu.com/fzcskycn/blog/item/83e2606392cfce670d33faba.html