ofbiz 中的data model(转载)

ofbiz 中的data model


  
 关于ofbiz中的data model
  
 ofbiz中参考"The data model resource toolkit" volumn1,volumn2 及一些CRM、ERP软件中的设计方法,在整个项目的不同子系统中进行data model的设计。在没有看data model之前,我认为ofbiz的entity engine其实不是一个非常好的的设计,他只是起到一层封装的作用而已,没有对以往的直接写sql 语句的做法有很大的提高,因为它大量的使用了map,而这在编码阶段是很容易出错的,许多错误只有到运行时才能发现,给编码人员调试工作带来了很多麻烦。在这方面相比hibernate等or mapping的工具,有着比较大的劣势。而且他的查询做的也不够好。
 但是我想entity engine可能与data model的设计结合可能综合来看会带来很多的好处。
  
 我们以往的数据库设计很多都是基于三范式来进行的,更多从项目出发,根据实际情况来设计,对于扩展性(通过增加字段或表)和一些需要考虑的与业务相关的情况考虑不够。ofbiz的data model设计时就融入了一些oo的思想,对项目而言未必是合适,而且带来一定的编码工作量的增大,并且在查询和统计方面可能会复杂很多,但是参考ofbiz的data model设计,可以为我们的基于业务的复用的思考带来一些新的思路。以技术平台的复用加上业务上的复用,把业务的复用建立在扎实的技术平台之上,这是我们思考已久的事情。而ofbiz3。0的新版本就是这样做的。
  
 data model的设计也可以用很多的pattern来表示,以下对其中几个做一个简单的介绍。
  
 Extensibility Pattern
  
 这是使用比较多的一个,在很多子系统中使用,主要解决了设计时和运行时的扩展性问题。对于一个实体表,我们可能需要另外三到四张相关的表。我们用Entity来表示实体表,那我们还需要EntityClass (optional) EntityType, EntityAttribute, and EntityTypeAttr。他们的关系如下:

 screen.width/2)this.width=screen.width/2" vspace=2 border=0>
  

 我们假设部门内部设计一个管理系统,管理部门内部正在从事的项目,以项目为例,图中的entity即为项目表,比如有项目编号,项目名称,等字段;entitytype表表示产品的类型,比如软件项目(SOFTWARE_PROJ),硬件项目(HARDWARE_PROJ)还是咨询服务(SERVICE_PROJ)。那么如果一个项目只有一种类型,那么entity与entitytype就是一对一的关系,如果一个项目有几个类型,比如金交所同时负责硬件和软件,那么增加entityclass来表示一对多的关系,所以说entityclass是可选的。
  
 对于不同类型,可能有一些公共的属性,我们可以设计为entitytype的字段,对于不同类型可能差异较大,我们需要记录不同的属性的时候,我们注意到entitytype中有一个HAS_TABLE的字段,表示此entitytype记录是否有专门的表来记录类型,如果某记录的HAS_TABLE字段为"Y",则有一个表名与Entitytype中的这条记录的Type字段名称一样的表,表示此类型的信息。比如entitytype中一条记录,insert into table entitytype(seq,type,has_table) values (1,"HARDWARE_PROJ","Y"wink.gifscreen.width/2)this.width=screen.width/2" vspace=2 border=0>,则表示另外有一张表名为HARDWARE_PROJ的表来记录此类型的具体信息。我们可以看到entitytype中还有一个parenttype,用来表示继承关系,比如我们可以将软件项目分为交易类项目,银行类项目,则他们的parenttype都是软件项目。
  
 entityAttr表就比较好理解,表示对entity的扩展,一个attr就可以代表entity中的一个column,比如一些attr只有很少的entity中有,而且也不常用,再如一些设计时没有考虑到的字段,就可以通过这种方式做扩展。
  
 entitytypeattr就是表示对entitytype的扩展。
  
 party patten
  
 基于上面的Extensibility Pattern,我们可以来考虑party pattern的设计,这里的party是指参与者。我们知道目前许多企业都在做向客户中心的转移。那么统一的客户信息就非常必要。比如对于一个大的机构而言,他的供应商,同样也是自己的客户,比如ibm是我们的供应商,但是我们也可以做一些他们的外包的项目,或者未来我们可以为ibm做一些内部项目,这样他们就成了我们的客户。对于party可以分为个人(Person)与组织(Organization)两个类型。不同party间的关系也是错综复杂的,我们如何来定义一个清晰模型就变得越来越重要。如果记录在不同的表中,可能会给未来的分析决策带来不便。
  
 在公司内部,各员工间、不同部门间、以及各角色之间的关系使用传统的方式也变得难以定义。
  
 party的设计目前在不同的数据建模的书中都不相同,但都是作为一个设计的重点。在ofbiz中对party的定义相对简单。由Party PartyClassification PartyClassificationType PartyType PartyAttribute PartyTypeAttr PartyRole RoleType RoleTypeAttr PartyRelationship PriorityType PartyRelationshipType PartyDataObject PartyGroup Person等表构成(注:在文档中还有Customer表,但查实际的entity 定义中没有,PartyGroup文档中没有列出)。

 参照刚才的Extensibility Pattern,根据名称我们也可以知道每张表大致的意思。
 Party中定义所有的Party,所有的参与者在party表中定义,无论客户、供应商、员工或是其他。
 partytype中分解类型,PartyGroup和Person是PartyType表中Has_Table=''Y''的两条记录。
 PartyRole中定义Party具有的角色,角色在RoleType中定义。
  
 还有一点需要注意,对应的权限设计,每个party可以有多个UserLogin帐户,UserLogin与Party是多对一的关系。
  
 小结
 以往在技术架构上考虑的多,确实业务上抽象比较困难,通过在表结构设计方面的一些考虑,可能能为我们在业务上复用带来一些思路。而我确实听说一些国内公司的产品能够实现技术框架、技术组件、业务组件、业务流程几个级别的复用,相信我们也可以做到。
  
 -------------------------------
  
 参考文档
         ofbiz文档:/website/entity-overview.html
         ofbiz data model     

阅读更多
想对作者说点什么? 我来说一句

OFBizDataModel.pdf

2010年09月21日 1.4MB 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭