一家企业，与外界其他企业之间存在各种各样的业务往来关系，这些公司统称为合作伙伴。一般而言，合作伙伴分为客户/经销商、供应商和生产商三大类。

本系统的设计中对合作伙伴采用基础信息集中管理，业务信息分别管理的方式。之所以采用这种方式，主要是为了适应企业中不同业务组织管理的需要和系统那个未来扩充的需要。

下图为合作伙伴管理的基本实体关系：

合作伙伴基本实体关系

基本关系图中增加了客户信用等级和供应商信用等级。当信用等级与供应商/客户信息的关系为非空时，根据数据库设计范式，这种结构存在着一定的问题，即公司与供应商/客户之间的一对多的关系是冗余的。之所以这样设计的原因在于供应商与公司之间的关系属于基本事实，而信用等级等属于附加信息。当然，要保证数据的一致性，需要在程序中进行控制，这里不再多谈。

在这一层次的设计中，供应商、客户和生产商信息中仅包含业务或财务相关的信息，如账户余额、保证金、应收应付等信息，联系信息等会在下面讲到。

合作伙伴可以是个人（尤其是客户很多可能是个人），也可以是公司，合作伙伴有自己的联系地址（可以是多个）、银行账户、联系人等等信息。

合作伙伴详细信息的实体关系如下图所示：

合作伙伴详细信息实体关系

如上图所示，合作伙伴类型确定合作伙伴的属性是合作伙伴是个人还是公司，其他的详细信息包括联系人信息、地址信息、账户信息和公司信息。

联系人信息实体对象具有双重功能，既记录个人类合作伙伴的信息，同时又记录公司类合作伙伴的联系人信息。

通过上面的两张图我们可以看到，系统通过合作伙伴这一实体，有效地将合作伙伴的业务信息和详细信息逻辑上隔离开来，业务信息的变化不影响详细信息的变化，反过来，详细信息的变化也不会影响业务信息的变化，同时，详细信息可以灵活扩充。

这种结构的另外一种好处体现在程序实现上，各类合作伙伴的详细信息的代码复用是显而易见的。

写到这里，忍不住多说两句，其实数据库的设计中一方面要尽可能遵循设计范式，另一方面，多借鉴OOA和OOD的思想，多考虑一些设计层面和业务变化的需求，使得后期需求的变化尽可能少的影响数据库结构性的变化。一套系统运行几年后对客户最有价格的是数据，而不是程序，这也是为什么我首先从数据库设计开始写起的原因。