您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
什么是数据模型
 
火龙果软件    发布于 2014-08-06
   次浏览      
 

数据模型分为两种类型:

1.一种是独立于任何计算机系统实现的,如实体联系模型,这类模型完全不涉及信息在计算机系统中的表示,只是用来描述某个特定组织所关心的信息结构,因而又被称作“概念数据模型”。

2.另一类数据模型则是直接面向数据库中数据逻辑结构的,例如有关系、网状、层次、面向对象等模型。这类模型涉及到计算机系统,一般又称为“基本数据模型”或“结构数据模型”。

建立数据库系统的目的,是为了实现对现实世界中各种信息的计算机处理。换言之,要实现计算机对现实世界中各种信息的自动化、高效化的处理,首先必须建立能够存储和管理现实世界中的信息的数据库系统。数据模型是数据库系统的核心和基础。任何一种数据库系统,都必须建立在一定的数据模型之上。由于现实世界的复杂性,不可能直接从现实世界中建立数据模型。

现实世界 →(抽象)→ 信息世界 →(转化)→ 数据世界

(而首先要把现实世界抽象为信息世界,并建立信息世界中的数据模型,然后再进一步把信息世界中的数据模型转化为可以在计算机中实现的、最终支持数据库系统的数据模型)。信息世界中的数据模型又称为概念模型,概念模型必须具有:

(1)抽象的真实性:是对现实世界本质的、确实存在的内容的抽象。而忽略了现实世界中非本质的和与研究主题无关的内容。

(2)完整、精确的语义表达力,能够模拟现实世界中本质的、与研究主题有关的各种情况

(3)易于理解和修改

(4)易于向DBMS所持的数据模型转换,现实世界抽象成信息世界的目的,是为了用计算机处理现实世界中的信息。

概念模型,作为从现实世界到其数据世界转换的中间模型,它不考虑数据的操作,而只是用比较有效的、自然的方式来描述现实世界的数据及其联系。

最著名、最实用的概念模型设计方法是P.P.S.Chen于1976年提出的“实体-联系模型”(Entity-Relationship Approach),简称E-R模型。

E-R模型的基本构构成:

三个主要概念:实体集、联系集和属性,分别用矩形框、菱形框和椭圆表示。

联系集的类型:一对一(1:1)、 一对多(1:n)、多对多(m:n)及表示

主码的表示:用带下划线的属性表示

多元联系

在E-R中,可以表示两个以上实体集之间的联系,称为多元联系。

联系的属性

联系集和实体集一样,也可以有自己的属性,来表现联系的特点。

自身联系

在一个联系中,一个实体可以出现两次或多次,扮演多个不同角色,此种情况称为实体集的自身联系。

例如,同一部门中,职工与职工之间可以有领导和被领导的关系。

子类和 is-a 层次联系

信息世界中常常有这样的实体集B,它属于另一个实体集A,B中实体的都有特殊的属性需要描述,并且这些特殊属性对实体集A的其它实体无意义。在E-R模型中,称B是A的子类,或A是B的父类。两类实体集之间存在着一种层次联系——is-a 联系。

例如,一个企业中的职工实体集和经理实体集,经理集中的每一位经理,又是职工集中的一位职工,他具有职工的所有属性,但他自己的属性“任职时间”对职工集的其他职工却没意义。此时,我们可以说,经理集与职工集存在着 is-a 联系。(P85图5-8所示)

在设计E-R模型时,首先应根据需求分析,确认实体集、联系集和属性这三种E-R模型的基本要素。

需要强调的三条设计原则是:

(1)相对原则:

建模的过程实际上是对对象抽象的过程。实体、联系、属性,是对同一个对象抽象过程的不同解释和理解。在同一情况下不同的人,或同一人在不同的情况下,对事物抽象的结果可能是不同的。

在E-R模型的整个设计过程中,实体、联系和属性不是一成不变的,而可能会被不断的调整和优化。

(2)一致原则:

同一对象在不同的业务系统中抽象的结果要求保持一致。因为业务系统是建立系统的各子系统。

(3)简单原则:

为简化E-R模型,现实世界中的事物,能作属性对待时,应尽量作为属性处理。

属性与实体和联系之间,并无一定界限。当属性满足如下两个条件时,就不能作实体或联系对待:

① 不再具有需要进一步描述的性质,因为属性在含义上是不可再分的数据项

② 性不能再与其它实体集具有联系,即E-R模型中的联系只能是实体集之间的联系。

设计一个大型的企业或单位的E-R模型,一般按照先局部、后整体,最后优化的方法进行。

下面以一个企业的职工信息管理系统为例,说明E-R模型的设计过程:

该管理系统涉及到三个部门的业务:

1.人事处管理职工的基本信息、职务信息和所在部门信息

2.财务处管理职工的工资情况

3.科研处管理科研项目和职工参加项目的情况

第一步:确定局部应用范围,设计局部E-R模型

(1)确定局部应用范围

本例中初步决定按照不同的职能部门划分不同的应用范围,即分为三个子模块:人事管理、工资管理和项目管理。

下面以人事管理为例,说明设计局部E-R模型的一般过程。

(2)确认实体集

在人事管理中,需要对职工、部门、职称职务进行管理,所以需要确定相应的三个实体集

(3)确认实体集间的联系集

需要判断所有二二实体集之间是否存在或存在着怎样联系:

1.职工与部门:n:1;

2.职工与职称职务:m:n

3.部门与职称职务之间没有联系

(4)确认实体集及联系集的属性

1.职工:职工号、姓名、性别、年龄

2.部门:部门号、名称、电话

3.职称职务:代号、名称、津贴,住房面积

4.职工和职称职务的联系:任职时间;

5.职工和部门的联系,没有单独的属性;

(5)画出局部E-R模型

第二步:集成局部E-R模型,形成全局初步的E-R模型

由于各局部E-R模型设计时所考虑问题的角度不同和各自业务需要的不同,合并各局部E-R模型时可能会存在许多不一致的地方,称为冲突。而这些冲突,必须在合并局部E-R模型时进行合理的消除。

冲突主要有如下三类:

(1)命名冲突:

包括实体集名、联系集名和属性名之间的同名异义和异名同义等冲突。

同名异义:同样的名称,在不同的局部E-R模型中表示不同含义的对象

异名同义:相同意义的对象在不同局部E-R模型中具有不同的名称

命名冲突通过不同部门间协商解决

(2)属性冲突:

包括属性值类型、取值范围、数量单位的冲突

(3)结构冲突:

包括两种情况:

1.一是同一对象在不同应用中具有的抽象不同。如职工工资,在人事部门的业务中可能作为属性对待,而在财务部门的业务中会作为一个实体集处理。另外,实体集间的联系在不同的业务应用中也可能有不同的联系集。

2.二是同一实体在各局部应用中包含的属性个数和属性排列次序不完全相同。

处理冲突,要根据具体需求分析,在各方兼顾的情况下,对发生冲突的属性、实体集、联系集进行合理的调整和综合。形成一个全系统用户共同理解和认可的统一的E-R模型,是合并各局部E-R模型的主要工作和关键所在。

在集成全局E-R模型时,一般采用两两集成的方法进行。将两个具有相同实体集的E-R模型,以该相同实体集为基准进行集成。

第三步:消除冗余,优化全局E-R模型

一个“好”的全局E-R模型,除了能够满足用户的功能需求外,还必须符合下列三个条件:

1.实体集个数应尽可能少;

2.实体集所含属性尽可能少;

3.实体集间的联系无冗余。

对于具有1:1的联系的,且有相同码的两个实体集可以合并,以减少实体集的个数;

另外,有些实体集中的属性,可能是冗余数据,需要进行适当的取舍。

所谓冗余数据,是指在不同实体集中重复存在的,或在同一实体集中可以由其它属性值计算得到的数据。

冗余数据一方面加大了工作量,浪费了存储空间,另一方面,又有可能造成数据的不一致性,破坏数据的完整性。

但并不是所有的数据冗余都必须被消除,所有能合并的实体集都要被合并,有时,为了工作的方便或工效的提高,要保持适当的数据冗余,和合理的实体集分解。

E-R模型是概念模型的表示。它是对现实世界客观事务及其联系的抽象,是用户对系统的应用需求的概念化表示,计算机不能直接处理它。

要使计算机能够处理E-R模型中的信息。首先必须将它转化为具体的DBMS能处理的数据模型。

E-R模型可以向现有的各种数据模型转换。而目前市场上DBMS大部分是基于关系数据模型的,所以我们只学习E-R模型向关系数据模型的转换方法。

从E-R图中可以看出,E-R模型实际上是实体型及实体间联系所组成的有机整体,而前面我们也学过,关系模型的逻辑结构是一系列关系模式的集合。所以将E-R模型转化为关系模型,实质上就是将实体型和联系转化为关系模式。也就是如何用关系模式来表达实体型以及实体集之间的联系的问题。

下面学习这种转化的步骤:

第一步:将每一个实体型转换为一个关系模式

将实体集的属性转换成关系的属性,实体集的码对应关系的码。实体集的名对应关系的名。例如职工管理系统全局E-R模型中的五个实体集可以表示如下:

1.职工(职工号,姓名,性别,年龄)*

2.部门(部门号,名称,电话,负责人)

3.职称职务(代号,名称,津贴,住房面积)

4.工资(工资号,补贴,保险,基本工资,实发工资)

5.项目(项目号,名称,起始日期,鉴定日期)

第二步:将每个联系转换为关系模式

用关系表示联系,实质上是用关系的属性描述联系,那么该关系的属性从何而来呢?我们说,对于给定的联系R,由它所转换的关系具有以下属性:

1.联系R单独的属性都转换为该关系的属性;

2.联系R涉及到的每个实体集的码属性(集)转换为该关系的属性。

如职工管理系统中的联系可以表示如下:

1.分工(职工号,部门号)* n:1联系

2.任职(职工号,代号,任职日期) n:m 联系

3.拥有(职工号,工资号)* 1:1联系,职工号和工资号都可以作为主码

4.参加(职工号,项目号,角色) n:m联系

根据联系的类型不同,联系转换为关系后,关系的码的确定也相应有不同的规则:

1.若联系R为1:1联系,则每个相关实体的码均可作为关系的候选码;

2.若联系R为1:n联系,则关系的码为n端实体的码;

3.若联系R为n:m联系,则关系的码为相关实体的码的集合;

第三步:根据具体情况,把具有相同码的多个关系模式合并成一个关系模式

具有相同码的不同关系模式,从本质上说,它们描述的是同一实体的不同侧面(即属性),因此,它们可以合并。合并的过程也就是将对事物不同侧面的描述转化为对事物的全方位的描述。

合并后关系包括两关系的所有属性,这样做可以简化系统,节省存储空间。上列关系中的职工关系、分工关系和拥有关系就可以合并为一:

职工(职工号,姓名,性别,年龄,部门,工资号)

现在我们不难看,当将联系R转换为关系模式时,只有当R为m:n联系时,才有必要建立新的关系模式;当R为1:1、1:n及is-a联系时,只需对与该联系有关的关系作相应的修改即可。

在关系数据模型产生之前,数据库管理系统普遍使用的数据模型是层次和网状数据模型,它们又被称为非关系数据模型.它们的数据结构和图的结构是相互对应的.

在非关系模型中,概念模型中的实体型反映为记录型, 实体型的属性反映为记录的字段。因此,图的结点表示为记录型,结点之间的连线表示为记录型之间的联系。

在非关系数据模型中,将两个记录型之间的一对一、一对多和多对多的联系,归结为一个只有1:n联系的基本层次联系,(因为1:1可以看作是1:n的特例,m:n可以分解为两个1:n的联系)。

   
次浏览       
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]

MySQL索引背后的数据结构
MySQL性能调优与架构设计
SQL Server数据库备份与恢复
让数据库飞起来 10大DB2优化
oracle的临时表空间写满磁盘
数据库的跨平台设计
更多...   


并发、大容量、高性能数据库
高级数据库架构设计师
Hadoop原理与实践
Oracle 数据仓库
数据仓库和数据挖掘
Oracle数据库开发与管理


GE 区块链技术与实现培训
航天科工某子公司 Nodejs高级应用开发
中盛益华 卓越管理者必须具备的五项能力
某信息技术公司 Python培训
某博彩IT系统厂商 易用性测试与评估
中国邮储银行 测试成熟度模型集成(TMMI)
中物院 产品经理与产品管理
更多...