关系数据库一般设计流程

做程序员的或多或少都设计过一些数据库。我想，在没有很好的理论基础下，设计数据库时，最多遇到的问题恐怕是：是这样好呢，还是那样好。原因是数据库设计本身是一件灵活多变的事，虽说各种不同的设计条条大路通罗马。但数据库设计又不仅仅如此，我相信，同一需求前提下，两个优秀的设计师设计出来的数据库应该是非常相似，甚至几乎一样的。那么，今天先总体上来谈谈数据库的一般设计过程。

　　需求分析除外，数据库的实现分为以下几个主要过程：

概念结构设计，该阶段的主要产物是实体联系图，简称为E-R图；

关系模型的设计跟优化，该阶段的主要目的是把概念模型转化为关系模型，并主要从理论上来优化数据库；这部分将是体现一个数据库设计师能力的主要依据之一。

物理模型设计，该阶段主要内容是把关系模型真正用到具体的DBMS系统上去，如：Mysql、Oracle，再跟据需求的特点，及DBMS本身的特点，调整设计。

访问接口设计，包括：用户子模式设计，主要内容为设计视图，存储过程设计（理论上，这部份内容其实不用单独组成一个阶段；但这部分内容也有相当的重要性，所以这里，把它也单独提取出来）。

　　第一点、概念结构设计，也就是E-R图的设计。这部分没多少难点，我在这里只重新强调下几个概念：

实体：客观存在的，并可相互区分的事物称为实体

属性：实体的特征、特性、指标点

码：唯一标识实体的属性集

域：属性的取值范围

实体型：用实体名跟属性名来刻画的同类褓

实体集：同一类型的实体的集合

联系：在系统范围内的，跟需求相并的关联，主要是实体与实体之间的关联

　　第二点、关系模型的设计、优化。

　　前一点的重点主要是在对关系模型概念的理解，。前一点往往被人忽略，最简单的一个测试方法是：在我眼中，关系就是指联系么？答案是否定的。关于关系严格的定义我会在《第二篇：严格的概念认识——关系、关系模型》里说明。在这个阶段一定要时刻考虚到数据库的完整性，包括：实体完整性、参照完整性及用户定义的完整性。前两个完整性限定一般由DBMS本身来保证，而用户完整性是我们设计数据模型时必须仔细考虑的。这是一件比较烦锁的事，但对于以后在数据库上开发上层应用是非常有保障的。下面稍微详细地描述下各种完整性约束具体指什么：

实体完整性：主键唯一，且各主属性不能为空

参照完整性：外键的值必须在被参照表上存在，或为空

用户定义的完整性：包括是否为空、是否唯一、外键的级联约定等等。

　　另外一块是优化，其主要依据是函数依赖理论，这一块优化不包含针对具体DBMS的优化，及物理模型的优化。这一部分引入了多层范式，包括：1NF~5NF，以及间于3NF及4NF之间的BC`NF。个人觉得，如果不是非常专业的数据库设计师的话，以BC`NF范式来做来自己设计的参考标准是比较合适的，因为要证明符合这个范式非常容易：

　　BCNF定义：关系模式R<U,F>符合1NF，若X->Y且Y不属于X时X必含易做图，则R<R,F>符合BCNF

　　附

1NF定义：每一个分量必须是不可分的数据项。其中，分量你可以看做表中一个属性的具体的值，不可分的意思其实就是能实实在在用明确的数字表示出来，需不是“利润率＝Ｘ／Ｘ”这种没法用数据库直接存储的抽象公式。

R：关系模式的名称

U：属性集，相当于列名

F：属性集上的函数依赖，可以把它理解的一套“哪些属性决定了哪些属性”的集合

　　第三点、物理模型的设计、优化。

　　这一点的主要工作包括：跟据存取及数据量的需求选择合适的DBMS产品、建立索引、选择合适的分布式方案等。所有这些内容，具体的DBMS提供商都会有详细的文档提供，这里不多累述。

　　第四点、视图、存储过程的设计。

　　先讲存储过程的设计，这部分主要需要熟悉SQL语言的操作，包括：数据查询、数据更新的语法，以及如何优化SQL语句，还有就是DBMS本身对SQL语句的优化策略。所有这些都是扎扎实实下硬工夫的地方。视图部分关关键要知道视图是个虚表，在做更新操作时要非常小心。

摘自：galimatoo的专栏