数据模型设计要点.docx
《数据模型设计要点.docx》由会员分享，可在线阅读，更多相关《数据模型设计要点.docx（10页珍藏版）》请在冰豆网上搜索。
数据模型设计要点
数据模型设计要点
1.数据模型设计的输入
传统的瀑布型的开发模型下，其特点是需求驱动。
相应的，数据模型设计的必要输入为需求分析阶段的产出，包括需求规格说明书（需求分析说明书）、数据字典。
分析型应用由于其需求不易迅速全面予以明确，所以适合用螺旋式开发模型，逐步迭代。
但由于分析型应用是数据驱动，所以数据模型的设计要求更高，需要根据业务和数据的实际情况，进行快速全面分析，并有充分的管理思维，才能设计出比较理想的数据模型。
其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典，而是要从业务层面分析各个现有业务实体，以管理思维的角度，进行必要的抽象、归纳和挖掘，结合未来管理需要，明确潜在业务实体，以及各业务实体之间的关系，最终予以设计实现。
2.数据模型设计必须的几个阶段
无论是瀑布模型还是螺旋模型，数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。
其中，概念数据模型设计的主要工作是提取概念实体并分析其关系，这是最关键的工作，直接影响后续工作的质量；逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系，此部分与物理数据库无关；物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。
这三个阶段并不是完全单向的，而是可以反向调整。
假设后面的阶段发现有问题，可以转到上一阶段进行必要的修改后继续进行。
但一定不能不管前一阶段的结果，放任自流地进行后面阶段的工作。
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
优
TEL：
12346；Email：
abc@
S03
王五
C03
数学
203教室
T03
老师3
初级
70
良
TEL：
12347；Email：
abc@
符合第一范式的设计：
SNO
SNAME
CNO
CNAME
CADDR
TNO
TNAME
TTile
Score
Level
STEL
SEMAIL
S01
张三
C01
语文
201教室
T01
老师1
高级
95
优
12345
abc@
S02
李四
C02
语文
202教室
T02
老师2
中级
98
优
12346
abc@
S03
王五
C03
数学
203教室
T03
老师3
初级
70
良
12347
abc@
2.2.1.2.第二范式
目的：
实现属性的完全依赖——属性唯一依赖于主键，不能依赖于主键的一部分。
基于第一范式结果进行修改，使其符合第二范式：
1）定义SNO+CNO为主键；2）
将不完全依赖这个主键的属性剥离到独立的表中；
SNO（PK-1）
CNO（PK-2）
Score
Level
S01
C01
95
优
S02
C02
98
优
S03
C03
70
良
新创建学生表：
SNO
SNAME
STEL
SEMAIL
S01
张三
12345
abc@
S02
李四
12346
abc@
S03
王五
12347
abc@
新创建教师表：
TNO
TNAME
TTile
T01
老师1
高级
T02
老师2
中级
T03
老师3
初级
新创建课程表：
CNO
CNAME
CADDR
TNO
C01
语文
201教室
T01
C02
语文
202教室
T02
C03
数学
203教室
T03
2.2.1.3.第三范式
目的：
消除传递依赖。
属性不依赖于其他非主属性。
基于第二范式结果进行修改，将涉及传递依赖的属性也剥离出去，使其符合第三范式：
SNO（PK-1）
CNO（PK-1）
ScoreNO
S01
C01
Score1
S02
C01
Score2
S03
C02
Score3
学生表：
SNO
SNAME
STEL
SEMAIL
S01
张三
12345
abc@
S02
李四
12346
abc@
S03
王五
12347
abc@
教师表：
TNO
TNAME
TTile
T01
老师1
高级
T02
老师2
中级
T03
老师3
初级
课程表：
CNO
CNAME
CADDR
TNO
C01
语文
201教室
T01
C02
语文
202教室
T02
C03
数学
203教室
T03
新创建成绩表：
ScoreNO
Score
Level
Score1
95
优
Score2
98
优
Score3
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.物理数据模型（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.3.2.1.数据类型设计
明确定义各物理实体属性字段的数据类型，同类的数据类型可考虑在数据库平台中建立必要的Domain或别名，以进行统一。
将数据类型固定在几个有限的取值范围内，避免随便定义新的类型或新的精度。
2.3.2.2.存储设计
设计物理表存储在哪个表空间内。
设计物理表的初始化块和后续块大小。
根据需要，对物理表进行分区设计。
根据修改动作的多少，为物理表设计适合的水位线（WaterMark），以减少存储碎片的产生。
2.3.2.3.主外键设计
定义物理表的主键，若是组合主键，定义字段的先后顺序。
定义表的外键。
2.3.2.4.索引设计
设计需要的索引，若是组合索引，定义字段的先后顺序。
若设计了索引数据表空间，将索引定义到该空间内。
为提高查询效率，可为单个表设计多个索引。
2.3.2.5.生成建表语句
物理设计完成，需生成建表语句。
3.数据模型设计相关工具软件
数据模型设计相关的工具软件很多，选择余地很大，但工具再强大，也需要人去用，工具本身并不能帮助进行数据模型设计，甚至在方法不当的情况下还会起反作用。
需明确工具的使用规范，以最终统一和提高产出工件的标准化和质量。
工具需要与文档描述相结合。
可充分使用工具软件的文档生成功能以生成必要的文档，并在此基础上进行必要的修订，以集中对设计进行说明。
4.数据模型设计的产出及规格要求
4.1.概念数据模型设计阶段
《概念数据模型设计说明书》：
说明提取出的实体，并解释其含义。
《概念数据模型设计文件》：
着重说明实体间关系。
建议以文字为主描述实体，以图为主描述实体关系。
4.2.逻辑数据模型设计阶段
《逻辑数据模型设计说明书》：
说明提取出的实体，并解释其含义；描述属性含义及取值范围、约束等信息，并描述主键和唯一索引。
《逻辑数据模型设计文件》：
着重说明实体间关系。
建议以文字为主描述实体，以图为主描述实体关系。
4.3.物理数据模型设计阶段
《数据库设计说明书及程序》：
说明数据库层面的设计结果，包括server、参数、用户及权限。
包括必要的程序或者操作手册。
《表空间设计说明书及程序》：
说明表空间层面的设计结果。
包括必要的程序或者操作手册。
《数据库表设计说明书及程序》：
说明数据库表的设计结果。
包括必要的程序或者操作手册。
升级会员 