数据模型设计要点参考模板Word格式.docx
《数据模型设计要点参考模板Word格式.docx》由会员分享，可在线阅读，更多相关《数据模型设计要点参考模板Word格式.docx（10页珍藏版）》请在冰豆网上搜索。
2.1.概念数据模型设计（ConceptualDataModel）
本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。
该过程以分析概念实体以及它们之间的关系为目标，而不是以细化概念实体的各项属性为目标。
该阶段工作非常重要，是进行其他阶段工作的基础。
各概念实体的提取一般以业务领域或者需求中提到的“业务名词”为线索，但不应该需求中提到什么名词就在模型中设计什么实体，更不应该需求中没有提到某些名词之间的关系，模型中就根本不考虑对应实体之间的关系。
概念模型设计过程，实际上是以概念实体为线索，对需求分析结果进行测试的过程。
需求分析工作的质量好不好，在此工作中基本能得到初步验证。
概念模型设计过程中提取的概念实体，可能比业务领域中的多，也可能比业务领域中的少，关键看归纳和抽象的粒度。
并且，这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。
完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。
比如一个OCRM系统中提到“营销方案”、“营销团队”、“营销任务”、“年度营销任务”、“日常营销任务”等名词，据此可以提取出以下业务实体和实体间的关系：
虽然用户可能没有提出日常营销任务是否需要营销方案，但通过分析，这种情况是有可能的，所以可以在设计概念模型时，可以将日常营销任务与营销方案的关系设置为1-0,1。
这样，即便是未来发生需求的变化，数据模型也可以迅速提供支持。
2.2.逻辑数据模型设计（LogicalDataModel）
此阶段开始关注概念实体的各项属性。
该阶段还不必更多考虑实现时的物理数据库方面的要求。
设计逻辑数据模型时，需注意参考必要的设计范式要求。
常用的设计范式简单列举其要点并举例如下（以学生选课为例）：
2.2.1.设计范式要求
2.2.1.1.第一范式
目的：
实现属性的原子性——属性不可再分，属性不能重复；
不符合第一范式的设计：
SNO
学号
SNAME
姓名
CNO
课程号
CNAME
课程名
CADDR
上课地址
TNO
教室号
TNAME
教师名
TTile
职称
Score
成绩
Level
等级
SCONCAT
学生联系方式
S01
张三
C01
语文
201教室
T01
老师1
高级
95
优
TEL：
12345；
Email：
abc@
S02
李四
C02
202教室
T02
老师2
中级
98
12346；
S03
王五
C03
数学
203教室
T03
老师3
初级
70
良
12347；
符合第一范式的设计：
STEL
SEMAIL
12345
12346
12347
2.2.1.2.第二范式
实现属性的完全依赖——属性唯一依赖于主键，不能依赖于主键的一部分。
基于第一范式结果进行修改，使其符合第二范式：
1）定义SNO+CNO为主键；
2）
将不完全依赖这个主键的属性剥离到独立的表中；
SNO（PK-1）
CNO（PK-2）
新创建学生表：
新创建教师表：
新创建课程表：
2.2.1.3.第三范式
消除传递依赖。
属性不依赖于其他非主属性。
基于第二范式结果进行修改，将涉及传递依赖的属性也剥离出去，使其符合第三范式：
CNO（PK-1）
ScoreNO
Score1
Score2
Score3
学生表：
教师表：
课程表：
新创建成绩表：
由上例子可以看出，为使设计成本和收益达到平衡，具体使用时不可能全部符合第三范式，一般大部分表能够符合第二范式就可以。
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.物理数据模型（PhysicalDataModel）
物理数据模型设计是在逻辑数据模型设计的基础上，结合具体使用的物理数据库平台，对物理实体的存储特性进行特别设计，同时包括对索引的优化工作。
物理数据模型设计需进行的工作分别描述如下。
2.3.1.物理库设计
2.3.1.1.数据库Server设计
数据库server的标识。
是独立server还是共用server，是独立instance还是共用instance。
数据库必须进行哪些特殊设置：
需修改哪些数据库级参数，哪些instance级参数，哪些session级参数。
可能的参数包括：
查询堆参数、共享内存参数、优化级别、锁个数、buffersize、buffernumber，等等。
如果手工修改，需给出操作手册；
如果程序修改，需提供程序。
2.3.1.2.表空间设计
数据库涉及哪些表空间（tablespace/dbs），其用途如何？
每个表空间由哪些物理文件（Datafile/Chunk）组成？
其大小，所属用户/用户组，权限，操作系统绝对路径如何？
系统默认临时表空间为哪个？
索引表空间应该与数据表空间分别使用不同的硬盘。
如何创建表空间，手工方式下需提供操作手册；
程序方式下需提供程序。
2.3.1.3.用户及权限设计
数据库中设计哪些用户？
其权限如何，密码如何，密码是否存在定期修改的要求？
如何创建用户，手工方式下需提供操作手册；
2.3.2.物理表设计
2.
升级会员 