关于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。他们的关系如下：

 
 

 我们假设部门内部设计一个管理系统，管理 部门内部正在从事的项目，以项目为例，图中的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"screen.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