数据模型设计要点
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据模型设计要点
目录
1.数据模型设计的输入 (4)
2.数据模型设计必须的几个阶段 (4)
2.1.概念数据模型设计(Conceptual Data Model) (5)
2.2.逻辑数据模型设计(Logical Data Model) (6)
2.2.1.设计范式要求 (7)
2.2.1.1.第一范式 (7)
2.2.1.2.第二范式 (7)
2.2.1.3.第三范式 (8)
2.2.1.4.逆第三范式 (9)
2.2.2.其他要求 (10)
2.2.2.1.数据类型定义 (10)
2.2.2.2.实体名称定义 (10)
2.2.2.3.主键定义 (10)
2.2.2.4.实体关系定义 (10)
2.2.2.5.数据量估算 (11)
2.2.2.6.索引定义 (11)
2.3.物理数据模型(Physical Data Model) (11)
2.3.1.物理库设计 (12)
2.3.1.1.数据库Server设计 (12)
2.3.1.2.表空间设计 (12)
2.3.1.3.用户及权限设计 (12)
2.3.2.物理表设计 (13)
2.3.2.1.数据类型设计 (13)
2.3.2.2.存储设计 (13)
2.3.2.3.主外键设计 (13)
2.3.2.4.索引设计 (13)
2.3.2.5.生成建表语句 (14)
3.数据模型设计相关工具软件 (14)
4.数据模型设计的产出及规格要求 (14)
4.1.概念数据模型设计阶段 (14)
4.2.逻辑数据模型设计阶段 (14)
4.3.物理数据模型设计阶段 (15)
1.数据模型设计的输入
传统的瀑布型的开发模型下,其特点是需求驱动。相应的,数据模型设计的必要输入为需求分析阶段的产出,包括需求规格说明书(需求分析说明书)、数据字典。
分析型应用由于其需求不易迅速全面予以明确,所以适合用螺旋式开发模型,逐步迭代。但由于分析型应用是数据驱动,所以数据模型的设计要求更高,需要根据业务和数据的实际情况,进行快速全面分析,并有充分的管理思维,才能设计出比较理想的数据模型。其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典,而是要从业务层面分析各个现有业务实体,以管理思维的角度,进行必要的抽象、归纳和挖掘,结合未来管理需要,明确潜在业务实体,以及各业务实体之间的关系,最终予以设计实现。
2.数据模型设计必须的几个阶段
无论是瀑布模型还是螺旋模型,数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。
其中,概念数据模型设计的主要工作是提取概念实体并分析其关系,这是最关键的工作,直接影响后续工作的质量;逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系,此部分与物理数据库无关;物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。
这三个阶段并不是完全单向的,而是可以反向调整。假设后面的阶段发现有问题,可以转到上一阶段进行必要的修改后继续进行。但一定不能不管前一阶段的结果,放任自流地进
行后面阶段的工作。
2.1.概念数据模型设计(Conceptual Data Model)
本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。该过程以分析概念实体以及它们之间的关系为目标,而不是以细化概念实体的各项属性为目标。
该阶段工作非常重要,是进行其他阶段工作的基础。
各概念实体的提取一般以业务领域或者需求中提到的“业务名词”为线索,但不应该需求中提到什么名词就在模型中设计什么实体,更不应该需求中没有提到某些名词之间的关系,模型中就根本不考虑对应实体之间的关系。概念模型设计过程,实际上是以概念实体为线索,对需求分析结果进行测试的过程。需求分析工作的质量好不好,在此工作中基本能得到初步验证。
概念模型设计过程中提取的概念实体,可能比业务领域中的多,也可能比业务领域中的少,关键看归纳和抽象的粒度。并且,这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。
比如一个OCRM系统中提到“营销方案”、“营销团队”、“营销任务”、“年度营销任务”、“日常营销任务”等名词,据此可以提取出以下业务实体和实体间的关系:
Relationship_1
Relationship_2
Relationship_3
Relationship_4
年度营销任务
日常营销任务(例行)
计划营销任务
营销方案
营销团队
虽然用户可能没有提出日常营销任务是否需要营销方案,但通过分析,这种情况是有可能的,所以可以在设计概念模型时,可以将日常营销任务与营销方案的关系设置为1-0,1。这样,即便是未来发生需求的变化,数据模型也可以迅速提供支持。
2.2. 逻辑数据模型设计(Logical Data Model )
此阶段开始关注概念实体的各项属性。
该阶段还不必更多考虑实现时的物理数据库方面的要求。
设计逻辑数据模型时,需注意参考必要的设计范式要求。常用的设计范式简单列举其要点并举例如下(以学生选课为例):
2.2.1.设计范式要求
2.2.1.1.第一范式
目的:实现属性的原子性——属性不可再分,属性不能重复;
不符合第一范式的设计:
符合第一范式的设计:
2.2.1.2.第二范式
目的:实现属性的完全依赖——属性唯一依赖于主键,不能依赖于主键的一部分。
基于第一范式结果进行修改,使其符合第二范式:1)定义SNO+CNO为主键;2)将不完全依赖这个主键的属性剥离到独立的表中;
新创建学生表: