数据模型设计要点目录1.数据模型设计的输入42.数据模型设计必须的几个阶段42.1.概念数据模型设计（Conceptual Data Model） (4)2.2.逻辑数据模型设计（Logical Data Model） (6)2.2.1.设计范式要求62.2.1.1.第一范式62.2.1.2.第二范式72.2.1.3.第三范式82.2.1.4.逆第三范式102.2.2.其他要求102.2.2.1.数据类型定义102.2.2.2.实体名称定义102.2.2.3.主键定义102.2.2.4.实体关系定义112.2.2.5.数据量估算112.2.2.6.索引定义112.3.物理数据模型（Physical Data Model） (11)2.3.1.物理库设计122.3.1.1.数据库Server设计122.3.1.2.表空间设计122.3.1.3.用户及权限设计122.3.2.物理表设计122.3.2.1.数据类型设计122.3.2.2.存储设计132.3.2.3.主外键设计132.3.2.4.索引设计132.3.2.5.生成建表语句133.数据模型设计相关工具软件134.数据模型设计的产出及规格要求144.1.概念数据模型设计阶段 (14)4.2.逻辑数据模型设计阶段 (14)4.3.物理数据模型设计阶段 (14)1.数据模型设计的输入传统的瀑布型的开发模型下，其特点是需求驱动。

相应的，数据模型设计的必要输入为需求分析阶段的产出，包括需求规格说明书（需求分析说明书）、数据字典。

分析型应用由于其需求不易迅速全面予以明确，所以适合用螺旋式开发模型，逐步迭代。

但由于分析型应用是数据驱动，所以数据模型的设计要求更高，需要根据业务和数据的实际情况，进行快速全面分析，并有充分的管理思维，才能设计出比较理想的数据模型。

其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典，而是要从业务层面分析各个现有业务实体，以管理思维的角度，进行必要的抽象、归纳和挖掘，结合未来管理需要，明确潜在业务实体，以及各业务实体之间的关系，最终予以设计实现。

2.数据模型设计必须的几个阶段无论是瀑布模型还是螺旋模型，数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。

其中，概念数据模型设计的主要工作是提取概念实体并分析其关系，这是最关键的工作，直接影响后续工作的质量；逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系，此部分与物理数据库无关；物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。

这三个阶段并不是完全单向的，而是可以反向调整。

假设后面的阶段发现有问题，可以转到上一阶段进行必要的修改后继续进行。

但一定不能不管前一阶段的结果，放任自流地进行后面阶段的工作。

2.1.概念数据模型设计（Conceptual Data Model）本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。

该过程以分析概念实体以及它们之间的关系为目标，而不是以细化概念实体的各项属性为目标。

该阶段工作非常重要，是进行其他阶段工作的基础。

各概念实体的提取一般以业务领域或者需求中提到的“业务名词”为线索，但不应该需求中提到什么名词就在模型中设计什么实体，更不应该需求中没有提到某些名词之间的关系，模型中就根本不考虑对应实体之间的关系。

概念模型设计过程，实际上是以概念实体为线索，对需求分析结果进行测试的过程。

需求分析工作的质量好不好，在此工作中基本能得到初步验证。

概念模型设计过程中提取的概念实体，可能比业务领域中的多，也可能比业务领域中的少，关键看归纳和抽象的粒度。

并且，这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。

完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。

比如一个OCRM 系统中提到“营销方案”、“营销团队”、“营销任务”、“年度营销任务”、“日常营销任务”等名词，据此可以提取出以下业务实体和实体间的关系：Relationship_1Relationship_2Relationship_3Relationship_4年度营销任务日常营销任务（例行）计划营销任务营销方案营销团队虽然用户可能没有提出日常营销任务是否需要营销方案，但通过分析，这种情况是有可能的，所以可以在设计概念模型时，可以将日常营销任务与营销方案的关系设置为1-0,1。

这样，即便是未来发生需求的变化，数据模型也可以迅速提供支持。

2.2.逻辑数据模型设计（Logical Data Model）此阶段开始关注概念实体的各项属性。

该阶段还不必更多考虑实现时的物理数据库方面的要求。

设计逻辑数据模型时，需注意参考必要的设计范式要求。

常用的设计范式简单列举其要点并举例如下（以学生选课为例）：2.2.1.设计范式要求2.2.1.1.第一范式目的：实现属性的原子性——属性不可再分，属性不能重复；不符合第一范式的设计：符合第一范式的设计：2.2.1.2.第二范式目的：实现属性的完全依赖——属性唯一依赖于主键，不能依赖于主键的一部分。

基于第一范式结果进行修改，使其符合第二范式：1）定义SNO+CNO为主键；2）将不完全依赖这个主键的属性剥离到独立的表中；新创建学生表：新创建教师表：新创建课程表：2.2.1.3.第三范式目的：消除传递依赖。

属性不依赖于其他非主属性。

基于第二范式结果进行修改，将涉及传递依赖的属性也剥离出去，使其符合第三范式：学生表：教师表：课程表：新创建成绩表：由上例子可以看出，为使设计成本和收益达到平衡，具体使用时不可能全部符合第三范式，一般大部分表能够符合第二范式就可以。

2.2.1.4.逆第三范式特别在统计分析系统的数据模型设计过程中，还会有针对性的特别进行大量的“逆第三范式”的处理。

在传统的OLTP系统中，同样也也会存在逆第三范式的处理。

典型的例子是核心业务系统中的交易流水表。

之前该表一般设计为只记录经办柜员的柜员号，但后来随着交易量大幅增加，为提高查询效率，后来在新的核心业务系统设计中，一般把柜员名称冗余在此表中。

在数据分析应用中，这种情况就更多了，只要设计比较清晰，并购清楚知道哪些字段是冗余过来的，并且与来源表的数据类型严格保持一致即可。

2.2.2.其他要求2.2.2.1.数据类型定义逻辑数据模型中需明确数据类型和精度，对使用较多的数据类型，必要时可定义Domain来进行元数据的统一。

2.2.2.2.实体名称定义需明确逻辑实体的中文名称和英文名称，需建立必要的命名规范。

2.2.2.3.主键定义需明确定义各逻辑实体的主键和唯一索引。

从之前各范式的目的和使用描述来看，定义主键和唯一索引是必须的过程，否则谈不上进行第二、第三范式处理。

尽量采用属性或属性的组合做为主键，至少为其指定唯一索引。

物理设计时，根据效率等各方面要求进行取舍，决定到底是用有业务含义的属性做为主键还是用无业务含义的序列号字段做主键。

2.2.2.4.实体关系定义逻辑数据模型中需明确各逻辑实体之间的关系。

该工作是概念数据模型设计工作的延续，还是以业务领域的业务实体间的关系为线索对关联关系进行细化定义，而不是无原则地乱去分析，或者从程序查询角度分析，甚至仅从数据加工处理角度分析。

该工作包括两层含义：1）定义逻辑实体之间的关联类型明确定义各表之间的关联关系：1-1、1-多，多-1，多-多。

假设存在孤立，毫无关联的表，则需仔细分析其存在的必要性。

2）定义逻辑实体之间的主外键对照关系具体进行物理设计时可斟酌是否真正以外键的范式实现，但此阶段必须先定义，否则极易出现该关联的字段数据类型不一致，至少会造成关联查询的问题。

2.2.2.5.数据量估算分析各逻辑实体的存储量和每日记录增长量。

2.2.2.6.索引定义设计逻辑实体的目的就是为了查询，所以为提高查询效率，为逻辑实体指定索引是必须的设计步骤。

在此阶段，可基于各表的使用特点为其指定索引，指定的索引如果是组合索引，需明确其字段顺序。

由于索引的设置方法与最终物理数据库的设计方法有关，所以也可将索引定义的工作移到物理设计时再进行。

2.3.物理数据模型（Physical Data Model）物理数据模型设计是在逻辑数据模型设计的基础上，结合具体使用的物理数据库平台，对物理实体的存储特性进行特别设计，同时包括对索引的优化工作。

物理数据模型设计需进行的工作分别描述如下。

2.3.1.物理库设计2.3.1.1.数据库Server设计数据库server的标识。

是独立server还是共用server，是独立instance还是共用instance。

数据库必须进行哪些特殊设置：需修改哪些数据库级参数，哪些instance级参数，哪些session级参数。

可能的参数包括：查询堆参数、共享内存参数、优化级别、锁个数、buffer size、buffer number，等等。

如果手工修改，需给出操作手册；如果程序修改，需提供程序。

2.3.1.2.表空间设计数据库涉及哪些表空间（tablespace/dbs），其用途如何？每个表空间由哪些物理文件（Datafile/Chunk）组成？其大小，所属用户/用户组，权限，操作系统绝对路径如何？系统默认临时表空间为哪个？索引表空间应该与数据表空间分别使用不同的硬盘。

如何创建表空间，手工方式下需提供操作手册；程序方式下需提供程序。

2.3.1.3.用户及权限设计数据库中设计哪些用户？其权限如何，密码如何，密码是否存在定期修改的要求？如何创建用户，手工方式下需提供操作手册；程序方式下需提供程序。

2.3.2.物理表设计2.3.2.1.数据类型设计明确定义各物理实体属性字段的数据类型，同类的数据类型可考虑在数据库平台中建立必要的Domain或别名，以进行统一。

将数据类型固定在几个有限的取值范围内，避免随便定义新的类型或新的精度。

2.3.2.2.存储设计设计物理表存储在哪个表空间内。

设计物理表的初始化块和后续块大小。

根据需要，对物理表进行分区设计。

根据修改动作的多少，为物理表设计适合的水位线（WaterMark），以减少存储碎片的产生。

2.3.2.3.主外键设计定义物理表的主键，若是组合主键，定义字段的先后顺序。

定义表的外键。

2.3.2.4.索引设计设计需要的索引，若是组合索引，定义字段的先后顺序。

若设计了索引数据表空间，将索引定义到该空间内。

为提高查询效率，可为单个表设计多个索引。

2.3.2.5.生成建表语句物理设计完成，需生成建表语句。

3.数据模型设计相关工具软件数据模型设计相关的工具软件很多，选择余地很大，但工具再强大，也需要人去用，工具本身并不能帮助进行数据模型设计，甚至在方法不当的情况下还会起反作用。

需明确工具的使用规范，以最终统一和提高产出工件的标准化和质量。