系统分析之四 数据建模和分析
一、数据建模的概述
一)简介
数据建模,它是一种为数据库定义业务需求的技术。因为数据库模型最终要是实现成数据库,所以有时又称为数据库建模。
实际的模型被称作实体关系图。(Entity Relationship Diagram,ERD)
二)概念
1、 实体
我们需要一个概念来抽象的表示一组类似事物的所有实例,我们称这个概念为实体。实体是指某些食物,企业需要存储有关这些食物的数据。
实体分为:人、地点、对象、事件、概念。
实体实例是指实体的具体值。区分实体和实体实例很重要。
2、 属性
如果一个实体是我们想存储数据的某样东西,那么就需要确定我们想存储关于一个给定实体的什么数据。我们称这些数据为属性。
某些属性可以被逻辑上组合成超级属性,称为组合属性。
每个属性的值按照三种类型定义:数据类型、域、默认值。属性的数据类型定义了这个属性中可以存储什么类型的数据。属性的域定义了这个属性可以取的合法值。每个属性应该有逻辑默认值。
1) 属性的有代表性的逻辑数据类型
逻辑数据类型 |
逻辑业务含义 |
NUMBER |
任何数、实数或整数 |
TEXT |
一个字符串,包括数字 |
MEMO |
同TEXT一样,但具有不确定的大小 |
DATE |
任何格式的日期 |
TIME |
任何格式的时间 |
YES/NO |
只能取这两个值中的一个值的属性 |
VALUE SET |
一个有限值集合。大多数情况下应建立一个编码方案。 |
IMAGE |
任何图形或图像 |
2) 逻辑数据类型的有代表性的逻辑域
数据类型 |
域 |
例子 |
NUMBER |
对于整数,指定范围: {最大~最小} 对于实数,指定范围和精度:{精度最小值~精度最大值} |
{10-99}
{1.000~799.999} |
TEXT |
TEXT(属性的最大长度) 实际值通常是无限的,但是用户可以指定某个较小的限制范围 |
TEXT(30) |
MEMO |
不可应用,对长度或没有逻辑限制。 |
|
DATE |
MMDDYYYY格式的变量 |
|
TIME |
对于AM/PM时间:HHMMT 对于军队的时间: HHMM |
|
YES/NO |
{YES,NO} |
{YES,NO} {ON,OFF} |
VALUE SET |
{值1,值2,…,值n} 或 {表示代码及含义的表} |
{FRESHMAN,SOPHOMORE,JUNIOR,SENIOR}
{FR= FRESHMAN,SO= SOPHOMORE,JR= JUNIOR,SR= SENIOR } |
IMAGE |
不可应用 |
|
3) 属性允许的默认值
默认值 |
解释 |
例子 |
来自域中的一个合法值 |
对于这个属性的一个实例,如果用户没有指定值,那么就用这个值。 |
0 1.00 FR |
NONE或NULL |
对于这个属性的一个实例,如果用户没有指定值,那么就保持为空 |
NONE NULL |
REQUIRED或者NOT NULL |
对于这个属性的一个实例,要求用户输入一个来自域中的合法值(适用于没有足够通用的值可以用作默认值而又必须输入一些值的情况) |
REQUIRED NOT NULL |
4) 标识符
每个实体必须具有一个标识符或键。
由一组属性构成的键称为复合键。
一个实体可能有多个键,这些属性都被称为候选键。
候选键是一个实体实例的“主键的候选键”,主键是最常用来唯一的确定一个实体实例的候选键。主键的默认值是NOT NULL。没有被选中作为主键的任何候选键都称为替代键。所有候选键不是主键就是替代键。
子集准则是一个属性或合成属性,其有限的取值范围把所有的实体实例分成了有用的子集,有时也称为反向条目。
5)
3、 关系
1) 基数
定义了一个实体相对于另一个关联实体的某个具体值的最大和最小具体值数量。
2) 度数
关系的度数是参与那个关系的实体数量。
关系也可以存在于同一个实体的不同实例之间,我们称这种关系为递归关系(度数=1)。
关系还可以存在于两个以上的不同实体之间,这种关系有时被称为N维关系。(度数=N)。
关联实体是一个从多个其他实体(称为父实体)继承其主键的实体,其复合键的每个部分指向每个连接实体的一个且仅一个实例。
3) 外键
外键:是一个实体的主键,他被贡献给(复制到)另一个实体以确定一个关系实例。比如,a实体的最大基数是“1”,而b实体的最大基数是“许多”。在这种情况下a实体称为父实体,b实体称为子实体。主键总是由父实体贡献给子实体作为外键。
非确定性关系:每个参与关系的实体都有各自的独立主键的关系。
强实体(独立实体):具有非确定性关系的两个实体称为强实体或独立实体。
确定性关系:父实体贡献其主键成为子实体的主键的一部分的关系。
弱实体:任何确定性关系中的子实体称为弱实体。
非特定关系:一个实体的多个实例同另一个实体的多个实例相关联的关系。这种关系仅适用于初始模型中,应该尽快的分解掉。非特定关系可以分解成两个一对多关系;也可以通过引入独立关系来分解。
4) 泛化
是一种技术,其中几类实体公共的属性被组合成实体。是一种发现和探索实体之间共性的方法。
实体超类是一个实体,其实例存储了一个或多个实体子类的公共属性。
4、
三)
二、逻辑数据建模过程
数据模型是不断累进的,对于一个企业或应用来说,不存在“最终的”数据模型这种东西。
一)战略数据建模
企业数据模型,一般只是标识出最基本的实体。
二)系统分析期间的数据建模
应用数据模型:单个信息系统的数据模型通常称为应用数据模型。
上下文数据模型:问题分析阶段的模型应该仅仅包括实体和关系,而不包括属性。
基于键的数据模型:消除非特定关系,增加关联实体,并包括主键和替代键,此外还包括精确的基数和泛化层次。
具有完成属性的数据模型:包含所有描述性属性和自己准则,每个属性用类型、域和默认值在资料库中定义。
规范化数据模型
用于数据建模的JRP和面谈问题
目的 |
候选问题 |
获取系统实体 |
业务的主体是什么?即什么类型的人、组织、组织部门、地点、事物、材料或事件用于这个系统中,或同这个系统交互(我们需要收集和维护有关这些内容的数据)?这个主体存在多少个实例。 |
获取实体键 |
哪个唯一特征(或多个特征)将每个主题的实例从同一主体的其他实例中区分开来?未来计划改变这个识别方案吗? |
获取实体子集准则 |
一个主体有哪些特征将这个主体的所有实例分成有用的子集?上面的主体是否存在某些子集,而对于这些子集没有方便的方法组织实例。 |
获取属性和域 |
每个主体用什么特征描述?对于这些特征:1)存储什么类型的数据?2)谁负责为数据定义合法值?3)这个数据的合法值是什么?4)必须有值吗?5)如果没有指定值,是否应该指定默认值? |
获取安全和控制需求 |
关于谁可以查看或使用数据有任何限制吗?允许谁创建数据?允许谁修改数据?允许谁删除数据? |
获取数据时间要求 |
数据变化有多频繁?在什么时间段内数据对企业有价值?应该保存数据多长时间?需要历史数据或趋势数据吗?如果特征发生变化,必须知道原始值吗? |
获取泛化层次 |
每个主体的所有实例都是一样的吗?即每个主题存在需要进行不同地描述或处理的特殊类型吗?数据中有可以提取数来共享的吗? |
获取关系和度数 |
什么事件的出现隐含了主体之间的关联?什么业务活动或事务涉及处理和修改几个具有相同类型或不同类型的不同主体的数据。 |
获取基数 |
每个业务活动或事件是以同样的方式处理,或者存在特殊情况吗?事件能够只同某些相关主体一起出现,或者必须涉及所有主体吗? |
三)对系统设计的考虑
四)数据建模的自动化工具
三、如何构造数据模型
一)获取实体
1、 在与系统所有者和用户的面谈或JRP会议期间,注意他们讨论的关键词。
2、 在面谈或JRP会议期间,专门要求系统所有者或用户确定他们想收集、存储和生成信息的事物。
3、 研究现有表格、文件和报告。
4、 用例描述如果在需求分析阶段被记录,那么他们可能成为数据属性和实体的来源。
5、 也可以通过工具获取实体。
6、 实体的名字应该简单、有意义、面向业务,不要用技术词汇,可以适当的增加形容词和从句;生成一个初步的词汇表。
实体名称 |
业务定义 |
|
|
7、
二)上下文数据模型
1、 该模型应该包括基本业务实体以及它们之间的自然关系;
2、 关系应该使用动词词组和实体名称的组合命名,形成简单的业务语句或推断;
1) 一个合同绑定了一个或多个会员。
2) 一个会员执行零个、一个或多个事务。
3) 一个促销商品产生多个会员订单。
三)基于键的数据模型
1、 键的原则
1) 在每个实体实例的生命期中,一个键的值不应该改变;
2) 键的值不能为空;
3) 必须确保键的值是有效的;
4) 使用智能键,智能键的编码类型:序列码、块状编码、字母编码、在显著位置编码、层次编码。有些专家建议不要使用智能键。
5) 考虑用一个代理键来代替独立实体中的大型复合键。
2、
四)泛化层次体系
五)具有完整属性的数据模型
1、 属性名称的确定
1) 许多组织拥有命名标准和认可的简写方式;
2) 仔细的选择属性的名称;
3) 现有表格和文件中的物理属性名称经常被简写以节省空间,逻辑属性名应该更清晰;
4) 二值属性,用问题来命名属性;
5) 外键是对非冗余规则的例外;
6) 一个属性的域不应该是逻辑的;
2、
四、分析数据模型
一)好的数据模型的标准
1、 简单的
2、 无冗余的
3、 灵活的而且对未来的需求具有可适应性
二)数据分析
1、 数据分析
数据分析是为实现简单的、无冗余的、灵活的并可扩展的数据库而准备数据模型的过程。其专门的技术称为规范化。
2、 规范化
是一种数据分析技术,该技术组织数据属性以便他们可以组合起来形成无冗余的、稳定的、灵活的并具有适应性的实体。规范化是一种包括三个步骤的技术,该技术把数据模型规范成第一范式、第二范式和第三范式。
三)规范化举例
具体例子,参看“维基百科”。
1、 第一范式
第一范式是为了要排除“重复组”的出现,所采用的方法是要求数据库的每个字段都只能存放单一值,而且每笔记录都要能利用一个惟一的主键来加以识别。
不符合第一范式的情况:存在重复组,缺乏唯一识别码。关系数据库中的情况:单一字段中有多个有意义的值,用多个字段来表达同一事实。
2、 第二范式
它的规则是要求数据表里的所有数据都要和该数据表的主键有完全依赖关系;如果有哪些数据只和主键的一部份有关的话,就得把它们独立出来变成另一个数据表。如果一个数据表的主键只有单一一个字段的话,它就一定符合第二范式。
一个数据表符合第二范式当且仅当:它符合第一范式,所有非主键的字段都一定和主键有关。
3、 第三范式
用来检验是否所有非键属性都只和候选键有相关性,也就是说所有非键属性互相之间应该是无关的。
传递依赖关系,当一个非键属性依赖于另一个非键属性时,就存在传递依赖关系。
导出属性,是其值可以从其他属性中计算出来或者可以从其他属性值通过逻辑导出的属性。
4、 通过检查进行简化
5、 对规范化的CASE支持
四)
五、将数据需求映射到地点
一)相关问题
1、 在每个地点需要实体和属性的哪些子集来完成工作?
2、 需要什么级别的访问?
3、 该地点可以创建实体实例吗?
4、 该地点可以读取实体实例吗?
5、 该地点可以删除实体实例吗?
6、 该地点可以修改实体实例吗?
二)数据—地点—CRUD矩阵
六、