《Ofbiz数据库表结构设计》由会员分享，可在线阅读，更多相关《Ofbiz数据库表结构设计（14页珍藏版）》请在金锄头文库上搜索。
1、目录Ofbiz数据库表结构设计21.ofbiz数据库表结构设计 - PARTY22.ofbiz数据库表结构设计 - CONTACT_MECH43.Ofbiz数据库表结构设计 - 订单ORDER84.ofbiz数据库表结构设计 - 订单支付ORDER_PAYMENT_PREFERENCE105.ofbiz数据库表结构设计 - 库存INVENTORY126.ofbiz数据库表结构设计 Payment & Invoice13Ofbiz数据库表结构设计转载：http:/ ofbiz数据库表结构设计 - PARTYofbiz的精华就在于其数据结构（表结构）的设计。数据结构的通用性也决定了ofbiz几乎可
2、以适用任何企业应用。我们首先来看看PARTY相关的表结构设计。在ofbiz中，PARTY是个抽象概念，它可以是一个人（用户、员工、家人等等），也可以是个组织（公司、部门、项目组、供应商、集团客户等等）。然而毕竟个人和组织的许多属性是不同的，比如姓名就只有个人有，组织只有组织名称等等，因此，在PARTY基础上派生出两个对象（两张表），PERSON带表个人，PARTY_GROUP代表组织。我们注意到在PERSON和PARTY_GROUP两张表里，有PARTY_ID作为外键指向PARTY表的PARTY_ID主键，而PARTY_ID在PERSON和PARTY_GROUP里同时也扮演着主键的角色。这种设
3、计模式大大简化了程序开发的复杂度。下面再来看看PARTY的角色。ofbiz中并没有一个我们习惯的ROLE表，而只有一个ROLE_TYPE表。其实这个ROLE_TYPE就是我们习惯的ROLE，可能是ofbiz觉得现实中分不清什么是ROLE，什么是ROLE_TYPE，取而代之的是ROLE_TYPE里有个PARENT_ROLE_TYPE_ID指向自己，用此方式来表示一个ROLE_TYPE（角色）的层级结构。PARTY_ROLE是PARTY和ROLE_TYPE的多对多关系表，我们当然能够理解，一个PARTY通常会有多个角色。ofbiz的角色相关的设计中，最精妙的是PARTY_RELATIONSHIP。
4、PARTY_RELATIONSHIP的几个主要字段是PARTY_ID_FROM、PARTY_ID_TO、ROLE_TYPE_ID_FROM、ROLE_TYPE_ID_TO、PARTY_RELATIOSHIP_TYPE_ID。现实社会中，每个人都有不同的角色，每个人与其他人或组织也有不同的关系，PARTY_RELATIONSHIP就是为了这些复杂的人以及组织之间的关系而设计的。比如，某个人P是某个公司O的雇员，那么在PARTY_RELATIONSHIP表中，PARTY_ID_FROM指向PARTY表中的P这条数据，PARTY_ID_TO指向PARTY表中的O这条数据，ROLE_TYPE_ID_F
5、ROM指向ROLE_TYPE表中的EMPLOYEE（ofbiz的初始数据中有），ROLE_TYPE_ID_TO指向ROLE_TYPE表中的ORGANIZATION_UNIT（ofbiz的初始数据中有），PARTY_RELATIONSHIP_TYPE_ID指向PARTY_RELATIONSHIP_TYPE表中的EMPLOYMENT（ofbiz的初始数据中有）。用这种方式，我们可以表示出社会上几乎所有的人、组织之间的关系。在PARTY_RELATIONSHIP中，我们还发现有两个属性，FROM_DATE和THRU_DATE，表明，这个relationship只在FROM_DATE和THRU_DAT
6、E之间的日期有效，过期无效。这种设计广泛存在于ofibz的其它对象中，通常当某个对象的内容更新了，ofbiz不会去更新原有的记录，而是将原先的记录的THRU_DATE设为当天（即到今天为止就过期了），另外再新增加一条记录，FROM_DATE设为第二天（即从明天开始有效）。在应用中，我们经常会给人或组织进行分类。如按照公司雇员人数进行分类，按照公司所属行业进行分类，按照用户的年龄进行分类，按照用户的积分进行分类等等。为了能够实现这种灵活的分类方法，ofbiz使用了三张表，PARTY_CLASSIFICATION、PARTY_CLASSIFICATION_GROUP、PARTY_CLASSIFIC
7、ATION_TYPE。其关系如下图：PARTY_CLASSIFICATION_TYPE是分类的方法，如：ANNUAL_REVENUE表示按年收入分类、INDUSTRY_CLASSIFICAT表示按行业分类等等。PARTY_CLASSIFICATION_GROUP表示了在某种分类方式下的分类级别，PARTY_CLASSIFICATION则是PARTY和PARTY_CLASSIFICATION_GROUP的多对多关系表，即明确该PARTY属于哪个分类方式下的哪个级别。举个例子，很多零售企业会根据客户的购买金额把客户分为金牌用户、银牌用户等等，这时，我们需要在PARTY_CLASSIFICATION
8、_GROUP里增加几条记录（如：PARTY_CLASSIFICATION_TYPE_ID=VALUE_RATING，DESCRIPTION=金牌用户）来代表金牌用户、银牌用户等等，然后通过PARTY_CLSSIFICATION将用户与PARTY_CLASSIFICATIO_GROUP进行关联。同样，我们可以定义不同的PARTY_CLASSIFICATIO_GROUP来代表不同其它分类的级别，并将用户（PARTY）进行关联。2. ofbiz数据库表结构设计 - CONTACT_MECHofbiz中，party的电话、地址等联系方式设计得非常巧妙，让我们来仔细分析一下。有一个叫做CONTACT_M
9、ECH的表，这张表我们把它称作联系方式表，一个电话号码、一个通讯地址、一个电子邮件，都分别会在这张表里找到对应的一条 记录。然后通过PARTY_CONTACT_MECH表与PARTY进行多对多关联，也就是一个PARTY可以对应多个联系方式，同样一个联系方式也可以 对应多个PARTY（比如家庭成员共用一个电话号码）。在PARTY_CONTACT_MECH里，我们又发现了FROM_DATE和THRU_DATE两个字段。我们当然可以理解，每个联系方式都会有有效期 间（从FROM_DATE到THRU_DATE），这样的设计使得我们不必为PARTY的联系方式烦恼了。比如，某个用户的电话号码改变了，我们只
10、需在原 先的PARTY_CONTACT_MECH记录里的THRU_DATE设为今天，然后新增一条记录代表用户新的电话号码。这样的设计，保留了老的电话号 码，使得系统运维人员总是能够找到历史的记录。在CONTACT_MECH表里，有两个字段：CONTACT_MECH_TYPE_ID和INFO_STRING。我们先来看 CONTACT_MECH_TYPE_ID，该字段是个外键指向CONTACT_MECH_TYPE。如果我们在初始化ofbiz的时候导入了初始数据， 就会发现CONTACT_MECH_TYPE里存放的是“EMAIL_ADDRESS”、“POSTAL_ADDRESS”、“TELECOM_
11、NUMBER”等联系方式的类型。这里有人会问，怎么没有MOBILE_NUMBER（手机号码）？在ofbiz中，手机的联系方式类 型也是“TELECOM_NUMBER”。那如何表达手机呢？这时需要引入另外一张表，CONTACT_MECH_PURPOSE_TYPE。在初始化数 据里，我们发现许多例如“PHONE_HOME”、“SHIPPING_LOCATION”、“PHONE_MOBILE”等代表联系目的的数据。手机是作为一种联系目的在CONTACT_MECH_PURPOSE_TYPE表中定义了（也就是“PHONE_MOBILE”这条数据），并通过 CONTACT_MECH_TYPE_PURPOS
12、E表（注意不是CONTACT_MECH_PURPOSE_TYPE）与 CONTACT_MECH_TYPE_ID进行了多对多的关联。CONTACT_MECH_TYPE_PURPOSE也就定义了哪些联系方式的类型可以有 哪些联系目的。在CONTACT_MECH里，有个字段叫INFO_STRING，如果这个CONTACT_MECH代表的是email，则INFO_STRING里的 内容就是email。不过如果这个CONTACT_MECH代表的是电话号码或地址，那哪里存放区号、城市、邮编等内容呢？显然，ofbiz是不会把这些信息一股脑儿都弄成字符串存放到INFO_STRING里，这样的话，就必须有另外两
13、张表：TELECOM_NUMBER（存放电话号码）和 POSTAL_ADDRESS（存放地址），这两张表各有外键指向CONTACT_MECH。到这里，我们已经把有关PARTY的联系方式介绍得差不多了，基本概念都已经在了。但是还有一张表，或许是最为关键的一张表，PARTY_CONTACT_MECH_PURPOSE。这张表里有主要是三个字段，都是外键：PARTY_ID（指向PARTY的外键）、CONTACT_MECH_ID（指向CONTACT_MECH的外键）、CONTACT_MECH_PURPOSE_TYPE_ID（指向 CONTACT_MECH_PURPOSE_TYPE的外键）。这三个外键的组
14、合，唯一指明了某个PARTY的某个联系方式（CONTACT_MECH） 是做什么用的（CONTACT_MECH_PURPOSE_TYPE）。不过这个PARTY_CONTACT_MECH_PURPOSE和PARTY_CONTACT_MECH感觉上是重合的，PARTY_CONTACT_MECH_PURPOSE已经包含了PARTY_CONTACT_MECH的所有信息。之所以还要有 PARTY_CONTACT_MECH，可能也是为了概念上以及使用上的方便，不过这个也增加了维护方面的成本。3. Ofbiz数据库表结构设计 - 订单ORDER对于订单来说，主要的表就是ORDER_HEADER和ORDER_
15、ITEM。ORDER_HEADER就是所谓的订单头，一条记录代表一条订单。ORDER_PAYMENT_PREFERENCE是订单的支付，它有三个主要外键，ORDER_ID代表是哪个订单，PAYMENT_METHOD_ID代表是哪种具体付款方法，PAYMENT_METHOD_TYPE_ID代表哪种付款类型。ORDER_HEADER中的字段：ORDER_TYPE_ID是外键指向ORDER_TYPE表，用来表示该订单是个采购订单还是销售订单。EXTERNAL_ID是代表了外部订单号，比如说拿ofbiz作为ERP来处理淘宝上的订单，那EXTERNAL_ID就可以用来存储淘宝上的订单号。STATUS_I
16、D是该订单的状态，是外键指向STATUS_ITEM表，STATUS_ITEM表中STATUS_TYPE_ID为ORDER_STATUS的数据是ORDER_HEADER中STATUS_ID字段 的可选项。这里要注意，ofbiz中订单的状态和货运（SHIPMENT）状态以及支付（PAYMENT）状态是三个分开的对象的状态，象淘宝上“等待支 付”以及“等待卖家发货”这种订单状态，在ofbiz中是PAYMENT对象以及SHIPMENT对象的状态。PRODUCT_STORE_ID是用来表示该销售订单是在哪个店卖出去的。REMAINING_SUB_TOTAL可以看作是除了运费之外的所有费用总和（包括商品的费用，其它各种费用，还要减去各种促销费用）。GRAND_TOTAL可以看作
