DB2

正文

在信息技术高度发达的今天，越来越多的人们意识到自己正面临着管理类型各异、并且日益增长的数字资源，当这些资源积累膨胀到一定程度之后，大概每个人都会问一个相同的问题，也是我一直在思考的一个问题--如何把自己所收集的大量资源很好的分类管理起来？

这些资源的文件类型是多种多样的, 比如HTML, PDF, TXT, JPG, ZIP, EXE, TAR, GZ等等, 并且用途各异, 有各类电子书籍, 软件源码, 图片, 或许是你喜欢的文学作品和电影, 甚至是你一年以前的重要邮件, 总之, 你很难用一种分类方法把它们组织得很好, 它们有些内容所具有的含义是多重的, 比如你的一张旅行照片, 可以把它放在顶级叫做图片的目录下--当然这下面可能还要复杂一点, 这样对于所有的图片来说, 这是清晰的. 但你大概也希望在阅读这次出行游记的时候也可以很方便的看到它, 这样我就有了把这张图片放在我的 文档->旅游->图片 目录下的需求, 保存两份就带来冗余的问题. 很明显, 传统文件系统的树形组织关系已经不能很好的满足你方便访问文件的需要. 你需要一种更好的文件访问方式, 即可以通过图片分类找到这张照片, 也可以在阅读你半年前写的一篇游记的同时看到它, 或许你还会期望有更多的途径. 于是你会想办法给这些资源加以分类, 并做出向上面那样的交叉链接, 即使是并不关心它们如何存储, 如何实现访问, 只要给出逻辑上的关系即可, 但你可能发现, 这也不是一件容易的事情. 

于是你就会期望一个内容管理系统，来帮助处理这一切事情，我的想法也是从这里开始的，并且尝试给出一个更清晰的定义。
首先, 我把它仅仅看作一个分类管理系统, 不负责真正数据的存储, 这应该由另一个系统来作, 比如(对象/关系)数据库, 文件系统等. 这两个系统之间应该可以很好的协作、沟通，但不应该耦合太紧，即需要一个清晰的接口。

其次, 我想这套分类管理系统应该提供这样一个功能, 一个小的文本处理程序可以即时的呼叫出来分析并处理当前浏览的文本--比如网页, 或者成批的分析处理一个目录, 或者是一篇word文档，把这些信息按我的要求提取出来并保存, 可以称之为"导入". 这个功能并不属于"分类管理系统"的核心, 它只是针对不同类型数据来源的一个导入插件而已. 在这个系统之上应该留出这样的接口，使得不同的人可以为不同的数据类型更方便的进入这套系统而开发插件。不过如果想要方便的实现数据提取，更多的依赖于源数据的良构性。

关于数据的分类, 将一个对象的属性抽象, 从它的各种属性中抽象出固有的属性, 以区别其它人为赋给的社会属性. 比如人的性别相对比较稳定, 就是固有属性, 其它比如头衔, 工作单位, 家庭住址等就是一些社会属性. 这本身就是一个可以讨论的足够深的话题。 

最底层的数据存储也应该是用户可控的, 比如你在WEB页面看到的一篇文章在后端可能相对于一个或多个文件, 并且这些文件的排列并不是无序的, 你应该可以从表示层推测出这些文件的存储结构, 并方便的进行访问. 这对于备份或是小范围操作是非常方便的, 尽管你还有这个系统提供的其他手段, 但这是你最基本的权利. 在这个系统的末端，我想应该提供一个基于WEB的数据表示层给使用者. 

现在可以把这套系统想像成一个桥, 一边是基本的数据, 一边是这些数据的受益群体. 这座桥根据基本的数据生成一个索引, 而在另一边, 根据数据的受益群体, 而提供相应的视图. 基本数据可以认为是基质的, 分类相对稳定的. 而视图则可以有多个, 视图也体现为某种分类, 但这种分类的依据是数据受益群体的使用习惯, 在某些情况下, 视图的分类方式可能与基本数据的分类方式一致. 

这样, 在基本数据的类别和用户视图的类别之间存在一个映射关系, 提供给用户的视图可能是所有基本数据的一个子集, 也可以是全部. 而这种映射关系就是这座桥, 确切的说是一组桥. 

对于基本数据, 可以是一个全新的数据集合, 也可以是一个现有的, 已经分类好的数据集合. 我们这座桥并不试图去改变原有的数据分类方式和分类标准, 首先, 根据现有的数据内容, 为数据受益群体提供一个合适的视图, 并在基本数据的分类和视图之间作一个映射关系. 

用户视图的建立和选择, 以及如何建立与基本数据的映射关系, 是由熟悉这些数据所涉及领域的专家来完成的, 这套系统并不能代替你完成. 好比我给你提供一个书架, 仅此而已, 如何整理你的书籍, 以及该放在书架的什么位置, 这是你的事. 当然, 我会让书架更舒适一些, 更方便你的阅读和取用. 

相对于原来的想法--这套系统管理所有的资源, 现在有些不同. 我们把它想像成专有的, 比如一个这样的系统只管理书籍资源, 而另一个这样的系统专门管理音像资源, 可能还有其他的专门管理用于计算机的原始代码, 而这些多个不同的、可相互集成的、可扩展的系统, 放在一起, 就实现了最初的管理所有资源的目标. 可以把对每一种资源的管理视为一个组件, 而我们可以很方便的追加一种新的组件来管理新增的资源种类. 这要求这些组件之间是可协作的, 并且要设计良好, 藕合太松, 达不到协作的目标; 藕合太紧, 失去组件的意义, 增加及删除一个组件都会变得很复杂. 

下面的内容会深入一些, 会设计到一些架构方面的考虑.

这套系统是工作在一个已有的, 分类好的数据集合基础之上的. 如果还没有, 我们也可以帮你建立一个. 我们把这个集合里面的数据仅仅理解为数据本身, 并不包含数据的其它附加属性, 即使在这个集合里面包含这些附加描述, 我们也不去理会. 因为这会引起我们的系统和已有数据集合的接口复杂化, 而这对于我们希望其工作在大多数现有数据集合上的愿望是相悖的. 

我们把这些基本数据的属性放在我们这套系统的内部存储, 这无论如何是必需的, 这是这套系统有价值以及可以工作的前提. 这会带来两方面的工作.

第一, 原有基本数据相关信息的导入问题, 这里面包含原有数据的存取位置, 存取方式, 相关属性等等. 倚赖于原始数据量, 这个工作量可能非常巨大, 会有一些必需的手动操作和人工干预, 大部分工作希望可以通过一个或多个导入脚本来完成，例如使用perl.

第二, 可能存在这样的情况, 原有的数据拥有使用者所倚赖的一些特有的属性, 而我们的系统中恰巧没有对这项属性的描述和处理. 那么我们就面临着在系统中增加这种处理的额外工作. 

对于第二个问题, 我们应尽量避免, 就是说我们在设计针对某种资源种类的组件时, 要进尽可能把用户的需求覆盖到, 不同的用户的通过配置来筛选这些功能. 在这样的情况下, 如果真的有一个特殊的用户需求, 我想用户也不会介意这导致的额外开发成本, 这是他应该承担的，相对于他可以从中获得的利益. 

另外, 我们是否可以继续抽象一下, 把基本的数据集合的适用范围再扩大一些, 超出数字资源的范畴, 比如一个真实的, 以纸质保存书籍的图书馆. 那么我们这套系统是否也应该适合它, 并很好的运作, 除了那些在线对基本数据本身的操作, 比如订正, 增加等. 但我们仍然可以对这些非电子资源的属性进行在线操作, 比如书名和借阅状态的查询, 办理借阅手续等. 而在这种情况下, 我们系统内部保存的这本书的位置应该是他的书架编号, 而不是一个电子链接. 

				  / 用户视图一	- - 用户群体一
电子书籍资源	电子书籍管理组件	- - 用户视图二	- - 用户群体二
			/\	  \ 用户视图三	- - 用户群体三
			//
			\/	  / 用户视图一	\
数字音像资源	数字音像管理组件	- - 用户视图二	- - 用户群体
			/\	  \ 用户视图三	/
			//
			\/
传统图书馆		传统书籍管理组件	- - 用户视图	- - 用户群体


	基本数据源				资源管理组件
-----------------------	--------------------------------------------------------
|		|	|	|	|	|	|	|
|	文件系统	|	| 导入	| XML	|	| 导入	| 用户	|
|	对象关系DB	|  <=>	| 脚本	| 或	| 逻辑层	| 插件	| 视图	|
|	LDAP数据源	|	|  =>	| 关系DB	|	|  <=	|	|
|	非数字资源	|	|	|	|	|	|	|
-----------------------	--------------------------------------------------------

最近由于项目的需要，去方正研究院看了一下方正博思3.0的功能演示。感觉博思的功能已经比较完善，已经可以管理很多种类型的数据资源。比如已经有单文 档，复合文档，复合资产等概念；基于图片的检索；功能强大的相关性浏览；支持数据采集，上载，打包，下载以及光盘小博思等概念；具有用户权限管理，数据加 密等功能。博思需要工作在一个已有大型数据库之上，所有管理的数据，包括大数据量的流媒体，均导入数据库以大对象方式存放，不以文件系统形式存在。即，还 没有明确的与现有分类资源进行搭接的接口。

　

参考资源

• 感谢同事龚健在这方面提供的有益思路和启发！

• CMS Review, http://www.cmsreview.com

• CMS Watch http://www.cmswatch.com