概念模型就是在了解了用户的需求,用户的业务领域工作情况以后,经过分析和总结,提炼出来的用以描述用户业务需求的一些概念的东西。如销售业务中的“客户”和“定单”,还有就是“商品”,“业务员”。 用USECASE来描述就是:“业务员”与“客户”就购买“商品”之事签定下“定单”。(此时可以不包含属性,只有实体集,联系集的分析结构)
逻辑模型就是要将概念模型具体化。要实现概念模型所描述的东西,需要那些具体的功能和处理那些具体的信息。这就到了需求分析的细化阶段。还以销售业务为例:“客户”信息基本上要包括:单位名称,联系人,联系电话,地址等属性;“商品”信息基本上要包括:名称,类型,规格,单价等属性;“定单”信息基本上要包括:日期和时间属性。并且“定单”要与“客户”,“业务员”和“商品”明细关联。 系统需要建立几个数据表:业务员信息表,客户信息表,商品信息表,定单表。
系统要包括几个功能:业务员信息维护,客户信息维护,商品信息维护,建立销售定单 。
以上这些均属于建立逻辑模型,这些说明只表明系统要实现什么,但怎样实现,用什么工具实现还没有讲,后者属于物理模型范围。
物理模型就 是针对上述逻辑模型所说的内容,在具体的物理介质上实现出来。如:数据库使用SQLServer2000,这样就可以编写具体的SQL脚本在数据库服务器上将数据库建立起来。其中包括业务员信息表,客户信息表,商品信息表,定单表。客户端使用VS开发工具,那么在工作站上用VS建立起功能菜单,包括:业务员信息维护,客户信息维护,商品信息维护,建立销售定单等功能,并用工具将每一个功能编码实现。
这三个过程,就是实现一个软件系统的三个关键的步骤,是一个从抽象到具体的一个不断细化完善的分析,设计和开发的过程。
数据库建模:在设计数据库时,对现实世界进行分析、抽象、并从中找出内在联系,进而确定数据库的结构,这一过程就称为数据库建模。它主要包括两部分内容:确定最基本的数据结构;对约束建模。
1.概念模型的表示方法
E-R图主要是由实体、属性和联系三个要素构成的。在E-R图中,使用了下面四种基本的图形符号。
2.确定系统实体、属性及联系
系统分析阶段建立数据字典和数据流程图->建立概念模型->逻辑模型->物理模型
利用系统分析阶段建立的数据字典,并对照数据流程图对系统中的各个数据项进行分类、组织,确定系统中的实体、实体的属性、标识实体的码以及实体之间联系的类型。
在数据字典中“数据项”是基本数据单位,一般可以作为实体的属性。“数据结构”、“数据存储”和“数据流”条目都可以作为实体,因为它们总是包含了若干的数据项。作为属性必须是不可再分的数据项,也就是说在属性中不能包含其他的属性。
3.确定局部(分)E-R图
根据上面的分析,可以画出部分实体-联系图。
在这些实体中有下画线的属性可以作为实体的码,这几个实体之间存在着1:1、l:n和m:n几种联系。
4.集成完整(总)E-R图
各个局部(分)E-R图画好以后,应当将它们合并起来集成为完整(总)E-R图。在集成时应当注意如下几点:
(1)消除不必要的冗余实体、属性和联系。
(2)解决各分E-R图之间的冲突。
(3)根据情况修改或重构E-R图。
6.2.3逻辑结构设计
逻辑结构设计的任务,就是把概念结构设计阶段建立的基本E-R图,按选定的管理系统软件支持的数据模型(层次、网状、关系),转换成相应的逻辑模型。这种转换要符合关系数据模型的原则。
E-R图向关系模型的转换是要解决如何将实体和实体间的联系转换为关系,并确定这些关系的属性和码。这种转换一般按下面的原则进行:
(1)一个实体转换为一个关系,实体的属性就是关系的属性,实体的码就是关系的码。
(2)一个联系也转换为一个关系,联系的属性及联系所连接的实体的码都转换为关系的属性,但是关系的码会根据联系的类型变化,如果是:
1:1联系,两端实体的码都成为关系的候选码。
1:n联系,n端实体的码成为关系的码。
m:n联系,两端实体码的组合成为关系的码。
总结:
概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。
在数据仓库领域有一个概念叫conceptual data model,中文一般翻译为“概念数据模型”。
概念数据模型是最终用户对数据存储的看法,反映了最终用户综合性的信息需求,它以数据类的方式描述企业级的数据需求,数据类代表了在业务环境中自然聚集成的几个主要类别数据。
概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性,也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。
概念数据模型的目标是统一业务概念,作为业务人员和技术人员之间沟通的桥梁,确定不同实体之间的最高层次的关系。
在有些数据模型的设计过程中,概念数据模型是和逻辑数据模型合在一起进行设计的。
在数据仓库领域有一个概念叫logical data model,中文一般翻译为“逻辑数据模型”。
逻辑数据模型反映的是系统分析设计人员对数据存储的观点,是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的,关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。
逻辑数据模型的内容包括所有的实体和关系,确定每个实体的属性,定义每个实体的主键,指定实体的外键,需要进行范式化处理。
逻辑数据模型的目标是尽可能详细的描述数据,但并不考虑数据在物理上如何来实现。
逻辑数据建模不仅会影响数据库设计的方向,还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多,那么在物理数据模型设计时就可以有许多可供选择的方法。
在数据仓库领域有一个概念叫physical data model,中文一般翻译为“物理数据模型”。
物理数据模型是在逻辑数据模型的基础上,考虑各种具体的技术实现因素,进行数据库体系结构设计,真正实现数据在数据库中的存放。
物理数据模型的内容包括确定所有的表和列,定义外键用于确定表之间的关系,基于用户的需求可能进行发范式化等内容。在物理实现上的考虑,可能会导致物理数据模型和逻辑数据模型有较大的不同。
物理数据模型的目标是指定如何用数据库模式来实现逻辑数据模型,以及真正的保存数据。