[在家休息,没事做瞎想]
从流水式架构想到的... 如果"录入书目-订购-验收"不是现在的两头大中间小架构
,而是流水式结构(参看昨天的示意图),就应该以操作ID作为流水
号,此流水号是下个流水号的钥匙,然后串成一大串; 这样的话,数据结构就一定要三个步骤都一样,也就是说要用操作ID
做流水号的话,就同时意味着不能实现减少每一步所携带的信息.
没必要用操作ID做流水号,没必要用统一的流水号.直线下的流水式架构,应该是三个步骤共用一个号,把整个流程与别的整个流程区别开来.应该用OO的信息隐蔽与接口通
信 ,三个步骤用三种不同的数据结构(对象),可以用一个父类包含共同
的属性(ISBN,登录号,书名等常用的查询入口)
,三个步骤的对象继承它,再加上自己步骤的特色属性操作.
如果要做此架构,首先要提取三个步骤共同的/贯穿整个流程的属性和
操作.
ISBN,登录号,书名,书目号... 这些常用的查询入口.
代理商,批号,发票号...这些都不是每一步骤必要的信息.不用放进父类.
回头想想,其实这几个信息中,真正关系到我们必要数据的
,又有几个? 如果真正要紧(really matters)的,
只是验收时的代理商,系统最终记录的只是验收一步的批号,那么前两步的就没必要记录了
.
如果金钱上的统计不用系统(by师姐),那么我们今天输入那么多代
理商/批号/发票号进系统,干什么呢? 根本就没必要给系统输入那么多冗余啊~ 而且就今天系统的批号"已订出!"智能程度,即使存了也达不到要用
的信度...
图书馆系统,只要对本馆的资源做逻辑上的,内容上的记录(书目
+馆藏)就够了,没必要记录金钱上的信息. 因为图书馆系统是面向读者的,而馆员买书已经自有另外的办法.
其实,这么简单的冗余,系统设计者再不专业,也不可能没考虑到. 其实,一直不得系统要领的,是我们自己的用法才对.
三个步骤,只要想想各自的名字,一般人都可以想象得到是与买书
(采访)的过程密切相关的,三个步骤在时间上是隔开的.书目录入 ,就是看有什么可以选择(通常是从联合目录,从网上直接传数据过来
,或者在馆员收到全国总书目之类的,对准备买的/有必要入系统的书
人工录入书目),看中了就向书商订购,订了之后就要等一段时间
,等书商发货,书送到了才验收. 所以说,三个步骤是有时间差的. 很自然地,订购和验收都要些书商/代理商/批号了. ——系统是辅助我们买书,我们买书每一个小进展都有同步
,它的最终目的就是让我们从头到尾用它一个系统就可以完成馆藏
"从无到有"所走的全程(虽然目前还没达到). 它的数据项并不全都是设计来"记录"的,有些是为了跟流程同步的
"中间辅助性"数据(如,批号,代理商).
现在想想,是否一验收了订购就自动消失了,不是设计者的执着
,而是为了对付冗余而作的中间变量删除?(但我不明白的是
,为什么"删"不干净?即使机器ID,行号有历史不可逆性
,凭已删ID可以顺藤摸瓜,至少,数据库的一致性要做到不读脏数据
吧?)
同理,在书目录入中,有一项要填写"订书目录"(社科新书目等,种类有征订/数据/交换入/指定参考书)
,要写些编号的. 那就是我们看中要买什么书的商品目录,所以也要写是来自哪个书商
/代理商. 所以代理商信息是三个步骤都有的.是用来流水作业的 .
现在才发现,原来"系统是面向读者的,而馆员买书已经自有另外的办
法"只是我们自己的定位,其实系统设计者在设计的当年就已经
"Think Big",把馆藏的整个生命周期,图书馆的整个业务
,都包含在里面了. 你可以说他野心大了,你可以说即使今天还未实现,你可以说他想的根
本是一个梦想... 不过真是佩服.应该这个差距. 我们似乎对未来缺乏想象力,甚至连接未来的想法还不能够接受
(我来采访这么久了才"悟"出系统设计的初衷,虽然这些东西
,只要稍加思考就可以知道,不过我来两个月了,都没有受到类似
"系统本来可以怎样怎样,只不过..."的暗示,可能说明了我们传统
上是忽视未知,或者说因为我的确不够专业).
回到我们的现实,就我们今时今日的操作方式, "电话+人手+纸张"完成采购,在书来了再开始用系统,录入书目
/订购/验收,三步一次做完, 这样的工作流程,我想就不必再向系统输入代理商/批号
/发票号之类了(如果统计也不用系统,其他工作也不需这些信息的话
). 我们的操作,是与我们对系统的理解"限于面向读者/馆藏管理
"相对应的. 就这个理解,就没必要把采购的信息录入系统了,只需书目录入和验收
就行了(而且是用一步完成,没必要分两步).
其实对系统的理解,各馆有各馆的实际,馆藏规模,工作传统,馆员对新东西的接受程度都不同. 没有哪种理解更高级,只有哪种更适合每个馆自己的实际. 所以,我建议就今天我们的习惯,还是按照回我们的理解来工作. 当然,我也还是有其他想法.
按照这个逻辑(我们对系统的定位,在于管理馆藏和读者),把订购一块从系统删去,采访部用自己的方法买来书,在书来了,登到的时候在系统直接验收,整理好,就可以送编目,分类后分库.
书目录入 <
书目 >
订购 <
书目+ 代理商 >
验收 <
书目+ 代理商+ 登录号+分库 >
图1. 配合采购流程的系统信息封装 采访(验收) <
书目+登录号 >
编目 <
书目+登录号 + 分类 >
图2.适合我们的系统信息封装
分库可以在编目后回送到采访部做,也可以另辟一个部门做,也可以由编目做.
相应地,为减少编目的工作量,采访录入书目的时候,现在编目做的著录归到书目录入(既然我们不用联合目录和全国书目,全都是书到手了再做书目,就有足够的 资料做著录了. 也许,经典意义上的"采访"做书目不详细,要"编目"时才仔细"著录",是因为书未到书看不到.. 那么按照我们的工作方式,就没必要两个部门重复劳动了...或者,我们不叫"采访部"和"编目部",叫"数据录入部"和"数据加工部"?)
不过,这些都是想,要系统配合才好. 这些也许可以作我们下次系统升级时的系统分析. 对于我自己来说,会想到这些可真是神奇,在学系统分析的时候完全没想过自己会想这些....
Trackback: http://tb.donews.net/TrackBack.aspx?PostId=1086095