数据模型设计要点Word下载.docx
- 文档编号:21002299
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:10
- 大小:41.94KB
数据模型设计要点Word下载.docx
《数据模型设计要点Word下载.docx》由会员分享,可在线阅读,更多相关《数据模型设计要点Word下载.docx(10页珍藏版)》请在冰豆网上搜索。
需求分析工作的质量好不好,在此工作中基本能得到初步验证。
概念模型设计过程中提取的概念实体,可能比业务领域中的多,也可能比业务领域中的少,关键看归纳和抽象的粒度。
并且,这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。
完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。
比如一个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.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、参数、用户及权限。
包括必要的程序或者操作手册。
《表空间设计说明书及程序》:
说明表空间层面的设计结果。
《数据库表设计说明书及程序》:
说明数据库表的设计结果。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据模型 设计 要点