对象角度分析关系范式
范式以及规范化过程

1NF ---> 2NF,消除非主属性对码的部分函数依赖

2NF  ---> 3NF,消除非主属性对码的传递函数依赖

3NF  ---> BCNF, 消除主属性对码的部分和传递函数依赖

BCNF  ---> 4NF, 消除非平凡且非函数依赖的多值依赖


第一范式：属性不可再分，如果按照面向对象里面的字段和结合数据类型来分析，一就是一，二就是二，哪来再分的概念，第一范式不管从对象角度还是现有的关系数据管理系统角度都是符合的，你也设计不出不满足第一范式的表，这是最基本的了。


第二范式：非主属性要完全依赖于主属性，官话叫做消除部分函数依赖。问题出在复合主键上，复合键里面的各个属性决定了整个表里的部分列，要解决此问题就要从DDD(领域驱动设计)里的实体分析，实体只定义一个ID，一般由机器产生，系统通过这个ID跟踪实体，好了，一个实体对象有哪些属性必然是完全依赖于主键，这样就符合二范式了，而且如果只有一个ID作为主属性，那么当再严格到三范式的时候就必然是BC范式。

举例：

(学号, 课程名称) → (姓名, 年龄, 学分)

(课程名称) → (学分)

(学号) → (姓名, 年龄)


第三范式：重点在非主键列上，如果一个非主键列决定了另外的非主键列，这样官话叫做传递函数依赖，要实现互不依赖，这就是提取值对象的时候，把传递部分取出来作为对象的值，用hibernate映射就是一个组件，如果事先按照对象角度分析就没有这些范式问题。

关键字段 → 非关键字段x → 非关键字段y


现在是不是可以得到一个结论，优秀的数据库建模专家和优秀的面向对象建模人员搞出来的业务对象其字段是差不多的？

但是数据库建模和对象建模一个非常严重的不匹配就是继承，关系模式不支持继承，在表达关系上，关系模式只能通过外键表达一对一和一对多，而且无方向，但对象关系却可以表达多对对，这也是对象思维的抽象美，而关系数据还是靠近数学了一点。这也再一次佐证软件开发需要的不仅仅是数学。


总之，规范化或者对象设计的基本思想都是概念上的单一化和足够内聚，规范化具体是逐步消除依赖中的不合适部分，使模式中的各关系模式达到某种程度的分离，让一个关系描述一个概念，一个实体或者一种联系，如果超过一就要把它分离。