定义
为了把现实世界中的具体事物抽象、组织为某一数据库管理系统支持的
数据模型
,人们常常首先将现实世界抽象为信息世界,然后将信息世界转换为机器世界。也就是说,首先把现实世界中的客观
对象
抽象为某一种信息结构,这种信息结构并不依赖于具体的
计算机
系统,不是某一个数据库管理系统(DBMS)支持的数据模型,而是概念级的模型,称为概念模型。
简介
概念数据模型是面向用户、面向现实世界的数据模型,是与DBMS无关的。它主要用来描述一个单位的概念化结构。采用概念数据模型,数据库设计人员可以在设计的开始阶段,把主要精力用于了解和描述现实世界上,而把涉及DBMS的一些技术性的问题推迟到设计阶段去考虑。
由于概念模型用于信息世界的建模型,是现实世界到信息世界的第一层抽象,是用户与数据库设计人员之间进行交流的语言,因此概念模型一方面应该具有较强的语义表达能力,能够方便、直接地表达应用中的各种
语义知识
,另一方面它还应该简单、清晰、易于用户理解。由于概念模型在此次的迭代过程非常简单,所以本来计划PASS掉其中的具体分析,不过概念模型的确非常之重要,他是
OOD
的一个基石。除了
用例
,应该说概念模型是
OO
开发过程中另一个充满主观色彩的工件。
一般来说,构建概念模型的过程与
程序
员的关系并不大。最适合进行这项活动的人,应该是那些有较深资历的领域专家,极端一点,甚至可以就是最为熟悉自身业务流程的客户代表。只要稍稍学习简单的建模知识,他们就可以胜任了。技术出身的人要做好这个工作,在开始之前他可能首先需要做的就是:忘掉VB,忘掉JAVA,忘掉.Net, 忘掉C++ 。。。
不过,作为开发人员,我比较认可一个思维跳出技术的条框,学习真正从“映射现实世界”的角度考虑问题的好办法,就是——假想一下,自己正在通过某部电影的故事来制作一个RPG游戏,电影里的桥段与游戏中的场景相对应,然后思考,其中需要表达哪些不同概念。好吧,试着弄一个简单的例子,这里,我用《无间道》来试试(不要笑我eld啊)。
构建模型
构建概念模型,需要从场景中提取各种“对系统目标有用”的概念。通常的方法是通过识别主要的领域词汇,或者通过已有的概念目录
检查表
来查找。由于时间关系,我已经预先想好了一些。看过的朋友知道,像“卧底”、“警察”、“黑社会”、“
情报
”等等,都是《无间道》这部电影里的一些核心概念。很自然地,开始时我会倾向于发展这样一个模型:(见右图)
这样看起来比较直观。“警察”和“黑帮成员”是两个较大的概念,下面分别有较小的两个子概念。像黄Sir和韩琛这样的角色,是可以很直接地归入到“正规警察”和“普通黑帮成员”的范围中去的,而陈永仁和
刘健
明都分别属于不同的卧底角色。但这样出现了一个问题,就是陈和刘都是同时具有警察、黑帮的双重身份(尽管一个在明,一个在暗)的人,他们都有可能同时拥有警察和黑帮的某些行为。比如陈永仁在拥有黑帮“劈友”,“收数”的行为时,也有可能执行警察“逮捕”,“救死扶伤”这样的责任,
刘健
明表面上是警察,暗中也有进行黑帮“洗钱”的行为。两个人的行为相似,但本质立场不同,怎样在模型中表达出这样的概念呢?
曾经也想过将“卧底”同时作为“警察”和“黑帮成员”的子概念,但觉得这样比较复杂且僵硬,实现起来也不容易(对不起,我又想到实现了)。后来觉得可以试试将“身份”和“行为”概念提取出来,于是建立下面这样的一个模型(见右图):
在这个模型中,每个人物可以机动地拥有1个以上的身份,多个行为。每个行为也可以与特定的身份挂钩。这样的话,对表达不同角色的复杂身份就可以比较灵活了。对陈、刘之间的本性问题,又引入“价值观”这样的概念描述。但可以看到,改变后的模型
复杂度
提高了,尤其当人物的“行为”很多的时候,就可能会在其下面出现比较大的概念群了。
可想而知,如果真的要做成RPG的话,更多的概念需要被提取出来。譬如“情感”、“人际关系”、“
情报
”、“武器”、“女朋友”。。。。。。由于时间关系,就不在这里乱唱了。这次做的这个粗陋的模型,就权当抛砖引玉吧。
找出模型
这是书中推荐的一条指导原则,我没有从正面理解也没有找到论据去推翻他,这是让我困惑的地方。其他一些指导性的原则包括:不能简单地因为
需求
说明中没有明显的要求保留某个概念的信息或是概念中没有属性,就去掉概念,在问题领域中,那些只担当纯行为的概念也是存在的。其后便是一个用于搜索概念的‘黑名单’,这让我更觉得不可思议,为什么是这样一个长长的黑名单而不是几条简洁的依据。最后我还是决心把他抄一遍:
举例
| |
物理的或实在的
对象
|
销售点终端、飞机
|
规格说明、设计或者事物的描述
|
产品规格说明、航班描述
|
地点
|
商店、机场
|
事务
|
销售、支付、预定
|
在线事务处理项
|
在线销售项
|
人的角色
|
出纳员、飞行员
|
包含其他事物的包容器
|
商店、银行识别号、飞机
|
被包含在包容器内的事物
|
销售商品项、乘客
|
信用卡授权系统、空中交通控制系统
| |
抽象的名词性概念
|
饥饿的人、恐高症
|
组织
|
销售部、对象航线
|
事件
|
销售、抢劫、会议、出航、坠机、着陆
|
过程(通常不用概念来表达,但有时也会用概念来表达过程)
|
出售一个产品的过程、预定一个座位的过程
|
规则和策略
|
退货政策、取消政策
|
目录
|
产品目录、零件目录
|
财政收支、工作情况、合同等的记录
|
收据、分类帐目、雇佣合同、维护日志
|
金融工具和服务机构
|
信用卡、股票
|
手册、书籍
|
雇员手册、修理手册
|
抄完了一遍,没有找出一个通用性的指导原则,书中接下来给出的是根据名词性短语找出概念,这让我想起了某一期的
程序
员中有关于
建模
的文章,其中的概念模型的建立就是说根据名词来找,想来这是一种极其幼稚的做法了,其中还有这样一种情况,某些名词只作为
对象
的属性。
建模过程
1,运用概念目录列表或名词性短语找出问题领域中的后选概念
2,绘制概念到概念模型图中
3,为概念添加关联关系
4,为概念添加属性
模型设计
概念模型设计
E-R方法是设计概念模型时常用的方法。用设计好的ER图再附以相应的说明书可作为阶段成果
概念模型设计可分三步完成:
局部模型
① 确定局部概念模型的范围
② 定义实体
③ 定义联系
④ 确定属性
⑤ 逐一画出所有的局部ER图,并附以相应的说明
文件
全局模型
建立全局E-R图的步骤如下:
① 确定公共实体
类型
② 合并局部E-R图
③ 消除不一致因素
④ 优化全局E-R图
模型评审
概念模型的评审分两部分进行:
第一部分是用户评审。
第二部分是开发人员评审。