数据库设计知识点

第1范示：行不能重复，列不可再分（列的值唯一）

第2范示：非主依赖  非主键列依赖于主键列

第3范示：非主独立 非主键列之间相互独立

 

数据建模步凑

1． 分析需求，画出用例图

2． 编写用例文本，设计界面原型，模拟功能性场景

3． 找实体

4． 识别实体的属性

5． 识别实体之间的关系（一对一，一对多，多对多）

6． 画出概念数据模型(ER图)

7． 将概念数据模型转化为物理数据模型(表格)

8． 根据范式修改物理数据模型继续重复5

 

对象建模步凑

1． 分析需求，画出用例图

2． 编写用例文本，设计界面原型，模拟功能性场景

3． 找出业务模型（领域对象）

4． 找关键性的名词和动词，识别类的属性和职责

5． 识别业务模型之间的关系（关联，依赖，组合，聚合，泛化，实现）

6． 将业务模型转化为概念数据模型，重复数据建模的3，4，5，6

ER中的实体和OO中的领域对象的区别：

1.       domain model抽象层次更高，更加贴近于现实世界和业务，而实体贴近于数据库

2.       一个实体必然对应一张表，而domain mode则可能是虚拟的只存在于业务层（如购物车）而不需要持久化到数据库，或者一个domain model由多张表的数据共同组合而成

3.       当业务复杂时，使用domain model描述需求效果更好，但是相应的在domain model和数据库表之间的映射会变得十分复杂，匹配程度很低

4.       以数据库为出发点进行数据建模，很容易上手（即界面上要显示的数据都来自于数据库的某张表格），但是业务复杂后正确的设计需要丰富的经验。以OO为出发点进行建模，不论业务复杂与否，很容易抽象出大致的domain model，但是当业务复杂后在做domain model和数据库表之间的映射则会变得非常困难

总结：大致来说理论上我们提倡OO，提倡DDD，但是由于客观条件（整个国内软件环境，中小公司急功近利的心态，不注重扩展性和维护性，主管人员 设计人员思想陈旧，项目周期 成本限制）以及主观条件（程序员自身的素质 对OO的理解）的限制，因此很多情况下仍然使用DB建模或者打着DDD的幌子走DB的老路。不论如何，现在DDD的思想已经遍地开花，总的趋势是逐渐向OO，向DDD上靠拢。因此，处于这样的一个过度时期，既不能完全地以DB为中心设计，也不能完全地OO，而是应该结合2者，（类似中国特色的社会主义道路）取长补短。