数据模型设计要点Word版

上传人:公**** 文档编号:475886224 上传时间:2022-08-13 格式:DOC 页数:15 大小:132KB
返回 下载 相关 举报
数据模型设计要点Word版_第1页
第1页 / 共15页
数据模型设计要点Word版_第2页
第2页 / 共15页
数据模型设计要点Word版_第3页
第3页 / 共15页
数据模型设计要点Word版_第4页
第4页 / 共15页
数据模型设计要点Word版_第5页
第5页 / 共15页
点击查看更多>>
资源描述

《数据模型设计要点Word版》由会员分享,可在线阅读,更多相关《数据模型设计要点Word版(15页珍藏版)》请在金锄头文库上搜索。

1、数据模型设计要点推荐精选目录1.数据模型设计的输入42.数据模型设计必须的几个阶段42.1.概念数据模型设计(Conceptual Data Model)52.2.逻辑数据模型设计(Logical Data Model)62.2.1.设计范式要求72.2.1.1.第一范式72.2.1.2.第二范式72.2.1.3.第三范式82.2.1.4.逆第三范式92.2.2.其他要求102.2.2.1.数据类型定义102.2.2.2.实体名称定义102.2.2.3.主键定义102.2.2.4.实体关系定义102.2.2.5.数据量估算112.2.2.6.索引定义112.3.物理数据模型(Physical

2、Data Model)112.3.1.物理库设计122.3.1.1.数据库Server设计122.3.1.2.表空间设计122.3.1.3.用户及权限设计122.3.2.物理表设计132.3.2.1.数据类型设计132.3.2.2.存储设计132.3.2.3.主外键设计13推荐精选2.3.2.4.索引设计132.3.2.5.生成建表语句143.数据模型设计相关工具软件144.数据模型设计的产出及规格要求144.1.概念数据模型设计阶段144.2.逻辑数据模型设计阶段144.3.物理数据模型设计阶段15推荐精选1. 数据模型设计的输入传统的瀑布型的开发模型下,其特点是需求驱动。相应的,数据模型设

3、计的必要输入为需求分析阶段的产出,包括需求规格说明书(需求分析说明书)、数据字典。分析型应用由于其需求不易迅速全面予以明确,所以适合用螺旋式开发模型,逐步迭代。但由于分析型应用是数据驱动,所以数据模型的设计要求更高,需要根据业务和数据的实际情况,进行快速全面分析,并有充分的管理思维,才能设计出比较理想的数据模型。其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典,而是要从业务层面分析各个现有业务实体,以管理思维的角度,进行必要的抽象、归纳和挖掘,结合未来管理需要,明确潜在业务实体,以及各业务实体之间的关系,最终予以设计实现。2. 数据模型设计必须的几个阶段无论是瀑布模型还是螺旋模型

4、,数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。其中,概念数据模型设计的主要工作是提取概念实体并分析其关系,这是最关键的工作,直接影响后续工作的质量;逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系,此部分与物理数据库无关;物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。这三个阶段并不是完全单向的,而是可以反向调整。假设后面的阶段发现有问题,可以转到上一阶段进行必要的修改后继续进行。但一定不能不管前一阶段的结果,放任自流地进行后面阶段的工作。2.1. 概念数据模型设计(Conceptual Data Mo

5、del)本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。该过程以分析概念实体以及它们之间的关系为目标,而不是以细化概念实体的各项属性为目标。该阶段工作非常重要,是进行其他阶段工作的基础。推荐精选各概念实体的提取一般以业务领域或者需求中提到的“业务名词”为线索,但不应该需求中提到什么名词就在模型中设计什么实体,更不应该需求中没有提到某些名词之间的关系,模型中就根本不考虑对应实体之间的关系。概念模型设计过程,实际上是以概念实体为线索,对需求分析结果进行测试的过程。需求分析工作的质量好不好,在此工作中基本能得到初步验证。概念模型设计过程中提取的概念实体,可能比业务领域中的多,也可能比业务领

6、域中的少,关键看归纳和抽象的粒度。并且,这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。比如一个OCRM系统中提到“营销方案”、“营销团队”、“营销任务”、“年度营销任务”、“日常营销任务”等名词,据此可以提取出以下业务实体和实体间的关系:虽然用户可能没有提出日常营销任务是否需要营销方案,但通过分析,这种情况是有可能的,所以可以在设计概念模型时,可以将日常营销任务与营销方案的关系设置为1-0,1。这样,即便是未来发生需求的变化,数据模型也可以迅速提供支持。推荐精选2.2. 逻辑数据模型设计(Logical Data Mod

7、el)此阶段开始关注概念实体的各项属性。该阶段还不必更多考虑实现时的物理数据库方面的要求。设计逻辑数据模型时,需注意参考必要的设计范式要求。常用的设计范式简单列举其要点并举例如下(以学生选课为例):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:S02李四C02语文202教

8、室T02老师2中级98优TEL:12346;Email:S03王五C03数学203教室T03老师3初级70良TEL:12347;Email:符合第一范式的设计:SNOSNAMECNOCNAMECADDRTNOTNAMETTileScoreLevelSTELSEMAILS01张三C01语文201教室T01老师1高级95优S02李四C02语文202教室T02老师2中级98优S03王五C03数学203教室T03老师3初级70良2.2.1.2. 第二范式目的:实现属性的完全依赖属性唯一依赖于主键,不能依赖于主键的一部分。基于第一范式结果进行修改,使其符合第二范式:1)定义SNO+CNO为主键;2)将不

9、完全依赖这个主键的属性剥离到独立的表中;SNO(PK-1)CNO(PK-2)ScoreLevel推荐精选S01C0195优S02C0298优S03C0370良新创建学生表:SNOSNAMESTELSEMAILS01张三S02李四S03王五新创建教师表:TNOTNAMETTileT01老师1高级T02老师2中级T03老师3初级新创建课程表:CNOCNAMECADDRTNOC01语文201教室T01C02语文202教室T02C03数学203教室T032.2.1.3. 第三范式目的:消除传递依赖。属性不依赖于其他非主属性。基于第二范式结果进行修改,将涉及传递依赖的属性也剥离出去,使其符合第三范式:S

10、NO(PK-1)CNO(PK-1)ScoreNOS01C01Score1S02C01Score2S03C02Score3学生表:SNOSNAMESTELSEMAIL推荐精选S01张三S02李四S03王五教师表:TNOTNAMETTileT01老师1高级T02老师2中级T03老师3初级课程表:CNOCNAMECADDRTNOC01语文201教室T01C02语文202教室T02C03数学203教室T03新创建成绩表:ScoreNOScoreLevelScore195优Score298优Score370良由上例子可以看出,为使设计成本和收益达到平衡,具体使用时不可能全部符合第三范式,一般大部分表能够

11、符合第二范式就可以。2.2.1.4. 逆第三范式特别在统计分析系统的数据模型设计过程中,还会有针对性的特别进行大量的“逆第三范式”的处理。在传统的OLTP系统中,同样也也会存在逆第三范式的处理。典型的例子是核心业务系统中的交易流水表。之前该表一般设计为只记录经办柜员的柜员号,但后来随着交易量大幅增加,为提高查询效率,后来在新的核心业务系统设计中,一般把柜员名称冗余在此表中。在数据分析应用中,这种情况就更多了,只要设计比较清晰,并购清楚知道哪些字段推荐精选是冗余过来的,并且与来源表的数据类型严格保持一致即可。2.2.2. 其他要求2.2.2.1. 数据类型定义逻辑数据模型中需明确数据类型和精度,

12、对使用较多的数据类型,必要时可定义Domain来进行元数据的统一。2.2.2.2. 实体名称定义需明确逻辑实体的中文名称和英文名称,需建立必要的命名规范。2.2.2.3. 主键定义需明确定义各逻辑实体的主键和唯一索引。从之前各范式的目的和使用描述来看,定义主键和唯一索引是必须的过程,否则谈不上进行第二、第三范式处理。尽量采用属性或属性的组合做为主键,至少为其指定唯一索引。物理设计时,根据效率等各方面要求进行取舍,决定到底是用有业务含义的属性做为主键还是用无业务含义的序列号字段做主键。2.2.2.4. 实体关系定义逻辑数据模型中需明确各逻辑实体之间的关系。该工作是概念数据模型设计工作的延续,还是

13、以业务领域的业务实体间的关系为线索对关联关系进行细化定义,而不是无原则地乱去分析,或者从程序查询角度分析,甚至仅从数据加工处理角度分析。该工作包括两层含义:1) 定义逻辑实体之间的关联类型明确定义各表之间的关联关系:1-1、1-多,多-1,多-多。假设存在孤立,毫无关联的表,则需仔细分析其存在的必要性。2) 定义逻辑实体之间的主外键对照关系推荐精选具体进行物理设计时可斟酌是否真正以外键的范式实现,但此阶段必须先定义,否则极易出现该关联的字段数据类型不一致,至少会造成关联查询的问题。2.2.2.5. 数据量估算分析各逻辑实体的存储量和每日记录增长量。2.2.2.6. 索引定义设计逻辑实体的目的就是为了查询,所以为提高查询效率,为逻辑实体指定索引是必须的设计步骤。在此阶段,可基于各表的使用特点为其指定索引,指定的索引如果是组合索引,需明确其字段顺序。由于索引的设置方法与最终物理数据库的设计方法有关,所以也可将索引定义的工作移到物理设计时再进行。2.3. 物理数据模型

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 资格认证/考试 > 自考

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号