数据模型设计要点

教师表：

TNO T01 T02 T03 TNAME 老师1 老师2 老师3 TTile 高级 中级 初级 课程表：

CNO C01 C02 C03 CNAME 语文 语文 数学 CADDR 201教室 202教室 203教室 TNO T01 T02 T03 新创建成绩表：

ScoreNO Score Level Score1 Score2 Score3 95 98 70 优 优 良 由上例子可以看出，为使设计成本和收益达到平衡，具体使用时不可能全部符合第三范式，一般大部分表能够符合第二范式就可以。

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. 用户及权限设计

数据库中设计哪些用户？其权限如何，密码如何，密码是否存在定期修改的要求？