ImageVerifierCode 换一换
格式:DOCX , 页数:10 ,大小:41.94KB ,
资源ID:7870209      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/7870209.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(数据模型设计要点.docx)为本站会员(b****6)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

数据模型设计要点.docx

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

2、确潜在业务实体,以及各业务实体之间的关系,最终予以设计实现。2. 数据模型设计必须的几个阶段无论是瀑布模型还是螺旋模型,数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。其中,概念数据模型设计的主要工作是提取概念实体并分析其关系,这是最关键的工作,直接影响后续工作的质量;逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系,此部分与物理数据库无关;物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。这三个阶段并不是完全单向的,而是可以反向调整。假设后面的阶段发现有问题,可以转到上一阶段进行必要的修改后继续进行。但一定

3、不能不管前一阶段的结果,放任自流地进行后面阶段的工作。2.1. 概念数据模型设计(Conceptual Data Model)本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。该过程以分析概念实体以及它们之间的关系为目标,而不是以细化概念实体的各项属性为目标。该阶段工作非常重要,是进行其他阶段工作的基础。各概念实体的提取一般以业务领域或者需求中提到的“业务名词”为线索,但不应该需求中提到什么名词就在模型中设计什么实体,更不应该需求中没有提到某些名词之间的关系,模型中就根本不考虑对应实体之间的关系。概念模型设计过程,实际上是以概念实体为线索,对需求分析结果进行测试的过程。需求分析工作的质

4、量好不好,在此工作中基本能得到初步验证。概念模型设计过程中提取的概念实体,可能比业务领域中的多,也可能比业务领域中的少,关键看归纳和抽象的粒度。并且,这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。比如一个OCRM系统中提到“营销方案”、“营销团队”、“营销任务”、“年度营销任务”、“日常营销任务”等名词,据此可以提取出以下业务实体和实体间的关系:虽然用户可能没有提出日常营销任务是否需要营销方案,但通过分析,这种情况是有可能的,所以可以在设计概念模型时,可以将日常营销任务与营销方案的关系设置为1-0,1。这样,即便是未来发

5、生需求的变化,数据模型也可以迅速提供支持。2.2. 逻辑数据模型设计(Logical Data Model)此阶段开始关注概念实体的各项属性。该阶段还不必更多考虑实现时的物理数据库方面的要求。设计逻辑数据模型时,需注意参考必要的设计范式要求。常用的设计范式简单列举其要点并举例如下(以学生选课为例):2.2.1. 设计范式要求2.2.1.1. 第一范式目的:实现属性的原子性属性不可再分,属性不能重复;不符合第一范式的设计:SNO学号SNAME姓名CNO课程号CNAME课程名CADDR上课地址TNO教室号TNAME教师名TTile职称Score成绩Level等级SCONCAT学生联系方式S01张三

6、C01语文201教室T01老师1高级95优TEL:12345;Email:abcS02李四C02语文202教室T02老师2中级98优TEL:12346;Email:abcS03王五C03数学203教室T03老师3初级70良TEL:12347;Email:abc符合第一范式的设计:SNOSNAMECNOCNAMECADDRTNOTNAMETTileScoreLevelSTELSEMAILS01张三C01语文201教室T01老师1高级95优12345abcS02李四C02语文202教室T02老师2中级98优12346abcS03王五C03数学203教室T03老师3初级70良12347abc2.2.

7、1.2. 第二范式目的:实现属性的完全依赖属性唯一依赖于主键,不能依赖于主键的一部分。基于第一范式结果进行修改,使其符合第二范式:1)定义SNO+CNO为主键;2)将不完全依赖这个主键的属性剥离到独立的表中;SNO(PK-1)CNO(PK-2)ScoreLevelS01C0195优S02C0298优S03C0370良新创建学生表:SNOSNAMESTELSEMAILS01张三12345abcS02李四12346abcS03王五12347abc新创建教师表:TNOTNAMETTileT01老师1高级T02老师2中级T03老师3初级新创建课程表:CNOCNAMECADDRTNOC01语文201教室

8、T01C02语文202教室T02C03数学203教室T032.2.1.3. 第三范式目的:消除传递依赖。属性不依赖于其他非主属性。基于第二范式结果进行修改,将涉及传递依赖的属性也剥离出去,使其符合第三范式:SNO(PK-1)CNO(PK-1)ScoreNOS01C01Score1S02C01Score2S03C02Score3学生表:SNOSNAMESTELSEMAILS01张三12345abcS02李四12346abcS03王五12347abc教师表:TNOTNAMETTileT01老师1高级T02老师2中级T03老师3初级课程表:CNOCNAMECADDRTNOC01语文201教室T01C

9、02语文202教室T02C03数学203教室T03新创建成绩表:ScoreNOScoreLevelScore195优Score298优Score370良由上例子可以看出,为使设计成本和收益达到平衡,具体使用时不可能全部符合第三范式,一般大部分表能够符合第二范式就可以。2.2.1.4. 逆第三范式特别在统计分析系统的数据模型设计过程中,还会有针对性的特别进行大量的“逆第三范式”的处理。在传统的OLTP系统中,同样也也会存在逆第三范式的处理。典型的例子是核心业务系统中的交易流水表。之前该表一般设计为只记录经办柜员的柜员号,但后来随着交易量大幅增加,为提高查询效率,后来在新的核心业务系统设计中,一般

10、把柜员名称冗余在此表中。在数据分析应用中,这种情况就更多了,只要设计比较清晰,并购清楚知道哪些字段是冗余过来的,并且与来源表的数据类型严格保持一致即可。2.2.2. 其他要求2.2.2.1. 数据类型定义逻辑数据模型中需明确数据类型和精度,对使用较多的数据类型,必要时可定义Domain来进行元数据的统一。2.2.2.2. 实体名称定义需明确逻辑实体的中文名称和英文名称,需建立必要的命名规范。2.2.2.3. 主键定义需明确定义各逻辑实体的主键和唯一索引。从之前各范式的目的和使用描述来看,定义主键和唯一索引是必须的过程,否则谈不上进行第二、第三范式处理。尽量采用属性或属性的组合做为主键,至少为其

11、指定唯一索引。物理设计时,根据效率等各方面要求进行取舍,决定到底是用有业务含义的属性做为主键还是用无业务含义的序列号字段做主键。2.2.2.4. 实体关系定义逻辑数据模型中需明确各逻辑实体之间的关系。该工作是概念数据模型设计工作的延续,还是以业务领域的业务实体间的关系为线索对关联关系进行细化定义,而不是无原则地乱去分析,或者从程序查询角度分析,甚至仅从数据加工处理角度分析。该工作包括两层含义:1) 定义逻辑实体之间的关联类型明确定义各表之间的关联关系:1-1、1-多,多-1,多-多。假设存在孤立,毫无关联的表,则需仔细分析其存在的必要性。2) 定义逻辑实体之间的主外键对照关系具体进行物理设计时

12、可斟酌是否真正以外键的范式实现,但此阶段必须先定义,否则极易出现该关联的字段数据类型不一致,至少会造成关联查询的问题。2.2.2.5. 数据量估算分析各逻辑实体的存储量和每日记录增长量。2.2.2.6. 索引定义设计逻辑实体的目的就是为了查询,所以为提高查询效率,为逻辑实体指定索引是必须的设计步骤。在此阶段,可基于各表的使用特点为其指定索引,指定的索引如果是组合索引,需明确其字段顺序。由于索引的设置方法与最终物理数据库的设计方法有关,所以也可将索引定义的工作移到物理设计时再进行。2.3. 物理数据模型(Physical Data Model)物理数据模型设计是在逻辑数据模型设计的基础上,结合具

13、体使用的物理数据库平台,对物理实体的存储特性进行特别设计,同时包括对索引的优化工作。物理数据模型设计需进行的工作分别描述如下。2.3.1. 物理库设计2.3.1.1. 数据库Server设计数据库server的标识。是独立server还是共用server,是独立instance还是共用instance。数据库必须进行哪些特殊设置:需修改哪些数据库级参数,哪些instance级参数,哪些session级参数。可能的参数包括:查询堆参数、共享内存参数、优化级别、锁个数、buffer size、buffer number,等等。如果手工修改,需给出操作手册;如果程序修改,需提供程序。2.3.1.2.

14、 表空间设计数据库涉及哪些表空间(tablespace/dbs),其用途如何?每个表空间由哪些物理文件(Datafile/Chunk)组成?其大小,所属用户/用户组,权限,操作系统绝对路径如何?系统默认临时表空间为哪个?索引表空间应该与数据表空间分别使用不同的硬盘。如何创建表空间,手工方式下需提供操作手册;程序方式下需提供程序。2.3.1.3. 用户及权限设计数据库中设计哪些用户?其权限如何,密码如何,密码是否存在定期修改的要求?如何创建用户,手工方式下需提供操作手册;程序方式下需提供程序。 2.3.2. 物理表设计2.3.2.1. 数据类型设计明确定义各物理实体属性字段的数据类型,同类的数据

15、类型可考虑在数据库平台中建立必要的Domain或别名,以进行统一。将数据类型固定在几个有限的取值范围内,避免随便定义新的类型或新的精度。2.3.2.2. 存储设计设计物理表存储在哪个表空间内。设计物理表的初始化块和后续块大小。根据需要,对物理表进行分区设计。根据修改动作的多少,为物理表设计适合的水位线(WaterMark),以减少存储碎片的产生。2.3.2.3. 主外键设计定义物理表的主键,若是组合主键,定义字段的先后顺序。定义表的外键。2.3.2.4. 索引设计设计需要的索引,若是组合索引,定义字段的先后顺序。若设计了索引数据表空间,将索引定义到该空间内。为提高查询效率,可为单个表设计多个索

16、引。2.3.2.5. 生成建表语句物理设计完成,需生成建表语句。3. 数据模型设计相关工具软件数据模型设计相关的工具软件很多,选择余地很大,但工具再强大,也需要人去用,工具本身并不能帮助进行数据模型设计,甚至在方法不当的情况下还会起反作用。需明确工具的使用规范,以最终统一和提高产出工件的标准化和质量。工具需要与文档描述相结合。可充分使用工具软件的文档生成功能以生成必要的文档,并在此基础上进行必要的修订,以集中对设计进行说明。4. 数据模型设计的产出及规格要求4.1. 概念数据模型设计阶段概念数据模型设计说明书:说明提取出的实体,并解释其含义。概念数据模型设计文件:着重说明实体间关系。建议以文字为主描述实体,以图为主描述实体关系。4.2. 逻辑数据模型设计阶段逻辑数据模型设计说明书:说明提取出的实体,并解释其含义;描述属性含义及取值范围、约束等信息,并描述主键和唯一索引。逻辑数据模型设计文件:着重说明实体间关系。建议以文字为主描述实体,以图为主描述实体关系。4.3. 物理数据模型设计阶段数据库设计说明书及程序:说明数据库层面的设计结果,包括server、参数、用户及权限。包括必要的程序或者操作手册。表空间设计说明书及程序:说明表空间层面的设计结果。包括必要的程序或者操作手册。数据库表设计说明书及程序:说明数据库表的设计结果。包括必要的程序或者操作手册。

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1