CRM的客户数据模型：Siebel Party Data Model (VI)

关于Siebel CRM

Thomas Siebel和 Patricia House 在1993成立了Siebel公司。起先由销售自动化产品起家，然后在扩展到更大的CRM市场。在20世纪90年代末，Siebel系统成了CRM产品的主导力量，高峰期占了45%的市场份额(在2002年)。.在2005年九月，Oracle公司收购了Siebel，此后又收购了具有更好用户界面的UpShot CRM。2011年发布的Siebel8.2 是目前最新的版本。

在2006年，Oracle CRM On Demandd第一个版本发布，取代了原有的Siebel SaaS 产品：Siebel CRM On Demand。这个新产品融合了Siebel CRM应用经验和UpShot 的新技术。



关于SiebelCRM 的最新信息参见

http://www.oracle.com/us/products/applications/siebel/overview/index.html

SIA, SBA 和 SEA

Siebel CRM 由多个应用组成，分为两大类：

1. 垂直应用(Verticalapplication) 或者 行业应用(Industry Application)，简称SIA

SIA是针对某个行业设计的，比如：通信、金融、制药、油气、电力、媒体和保险等。

2. 水平应用(HorizontalApplication) 或者商业/企业应用(Business/Enterprise Application)，简称 SEA或者SBA

SEA/SBA 适用于每个行业，是为公司内的特定领域设计的，例如：销售、市场和呼叫中心等。这些也称为跨行业应用(Cross-IndustryApplication).

这些不同类型的应用有相同的用户界面和导航方式，采用相同的构架、安装方式和技术。通过配置来满足不同业务的需求。

Siebel CRM 8.1.1 是最后一个版本， SIA和SEA采用不同的数据库schema，或者用Siebel的黑话讲，两者采用了不同的存储类型（repository type）：SIA 存储和SEA存储。8.1.1后的版本，SEA存储合并到SIA存储中，所有应用均基于单一类型的新存储，仍称为SIA存储。一个简单的等式可表达这两种不同类型存储间的关系：SIA 存储= SEA 存储+行业存储。

关于Party Data Model

Siebel 7.x 开始引入一个新的数据模型。此中各种CRM相关实体：account(客户)、组织(organization)、部门(internal division)、联络人(contact)、员工(employee)、职务(position)和户(Household)均归属为Party类型，能从单一的基础表S_PARTY访问到。引入此模型的主要目标是提供更好的access control机制和系统性能。

大部分老版本中包含party数据的表依旧存在和被使用，但是成了S_PARTY表的扩展表。系统使用隐含的表join加载Business component(业务对象)的数据。

Siebel CDI Universal Customer Master (UCM，Siebel客户数据集成方案的UCM)也基于这个party data model。作为Oracle的MasterData Management(MDM)的一部分，UCM提供了完善的功能来管理客户生命周期内的数据。

Data Model(数据模型)

Siebel party data model包含各种party，分为几种partytype，具体描述如下：

1. 经常使用的party：Person/Contact(个人/联络人), User（用户）, Employee（员工）, Partner User（合作伙伴用户）, PartnerOrganizations（合作伙伴）,Position（职务）, Account（账户）, Division（部门）, Business Unit（商业单位）*, Household（户）, User List（用户列表）and Access Group（访问控制组）

1. Party type有：Person(个人), Position(职务), OrganizationUnit(单位), Household(户), User List(用户列表), Access Group(访问控制组).

用面向对象的术语来讲，partytype 是基类，party则是party type的子类。为了防止混淆party 和party type，我们一律称为entity(实体)。

为了提供一个完整和清晰的描述，分三部分来讲述partydata model中重要的实体和它们之间的关系。PartI 讲述与个人和组织相关的实体；lead(线索)和其他实体的关系在PartII中讲解；最后一部分Part III描述与accesscontrol相关的一些重要实体；

*在来自oracle的很多技术文档中，会用Organization 而不是Business Unit，这容易和它的上级实体 Organization Unit混淆。鉴于此问题，本文只用Business Unit。

Part I. Persons and Organizations(个人和组织)

Oracle的技术文档，SiebelData Model Reference，使用了一个虚拟的实体：Group来改进模型图的可读性。我们在Figure1沿用这种优化方法。一个Group是一些person（个人）的组合，例如businessunit(商业单位)，household(户)，position(职务)或者user(用户)的列表。



Figure 1.Siebel Party Data Model的概念模型

Entities(实体说明)

Party

party 代表一个人或者一群人。

Group

Group 代表一群人。

Person/Contact(个人/联络人)

person/contact 代表个体，可以是：

1. 你公司的员工

2. 客户公司的员工

3. 竞争对手的员工

4. 个人客户

Person/Contact 是 其他个人相关实体的上级实体：User(用户) ，Employee（职员）和Partner User（合作伙伴用户）

User Logins/Users(登录帐号/用户)

user login（登录帐号）是可登录到Siebel应用系统中的帐号，包含了登录名和其他必要的安全数据。一个User(用户)则被分配了登录帐号的person（个人）。

Employees(员工)/Agents(经纪人)/Partner Users(合作伙伴用户)

Employee/agent 代表公司的内部雇员。每个Employee/agent 有一个或者多个职务。每位employee/agent一般会分配一个user login（登录帐号）。

Employee和Partner User 均保存在一样的Employee记录中。如果此人的职务对应的公司不是一个合作伙伴，这个人便是内部员工。如果公司是一个合作伙伴，此员工便是一个partneruser。

Households（户）

通常情况下，一个household(户)是一群个人消费者，经济上有关联，一起购买了产品和服务。例如：

1. 一组人，典型的是家庭，居住在一个地方。

2. 一组购买人，居住在不同的地方。

Household（户）是Contact（联络人），user(用户)，empolyee（员工）和partneruser（合作伙伴用户）的任意组合。

Organization Units(组织)

代表一个公司、工作地、子公司、部门 或者其他形式的组织的子集。 Organization Unit(组织)的数据是Account(账户), Division（部门）,Business Unit (商业单位)和Partner Organization(合作伙伴)所共有的。

Accounts(账户)

Account(账户)是购买产品和服务的组织或者组织内的子集。

Divisions(部门)

是一个公司内的职能单元，比如制造和销售。它也泛指特定公司内的一组人员。

Business Units（商业单位）

代表一个特殊的Division，可以认为是公司,包含普通的Division。

Partner Organization（合作伙伴）

是一个特殊的BusinessUnit（商业单位），是你公司的合作伙伴。

Addresses（地址）

用于跟踪person(个人)、household(户)和organizationunit(商业单位)。

Personal Addresses（个人地址）

特殊类型的地址，跟踪person(个人)和household(户)。

Business Addresses（单位地址）

特殊类型的地址，跟踪organizationunit(商业单位)，例如Account（账户）和PartnerOrganization（合作伙伴）。

Party Relationships

用于跟踪Party间多对多的关系。

Person Relationships（个人关联）

用于跟踪 个人(person/contact)间的关系，比如丈夫、妻子和老板等。

Organization Relationships(组织关联)

用于跟踪Account(账户)间的商业关系，比如 合作伙伴，供应商和竞争对手等。

Relationships(关系说明)

1. Relationship 用于跟踪Party 间的多对多的关系。

2. organization units.一个Organization Unit(组织) 只能有一个上级OrganizationUnit，但是可以有多个子OrganizationUnit。

3. 一个OrganizationUnit(组织)可以有多个Business Address（单位地址），但是一个Business Address只连接一个Organization Unit。

4. 一个household(户) 有一个或者多个personaladdress(个人地址)，但是一个Personal Address只能连接一个household。

5. 一个Person（个人）有一个或者多个Personal Address(个人地址)，一个PersonalAddress只能连接一个Person。

6. 一个Person（个人）会与一个或者多个Group关联，一个Group也会包含一个或者多个Person。

7. 一个Person/contact能拥有一个userlogin(登录帐号)

8. 在SIA(SiebelIndustry Applications) 7.7后的版本，Party和 Personal Address变成了多对多的关系。各种类型的地址均存储在Personal Address实体中了。

Part II. Leads(线索)

Figure 2. Lead(线索)和其他实体间的关系

Entities（实体说明）

Leads(线索)

Lead（线索）是一个潜在的客户或者老客户，可能有机会购买产品和服务。市场营销部门规划和开展以获取Lead为目标的工作。 一旦Lead被创建或者导入，销售代表会评估这个lead，这样销售部门能集中力量关注最有可能产生利润的lead。一个lead包含的信息通常有限，比如 姓名、公司信息、对产品的兴趣 和调查回馈信息等。

Relationships（关系说明）

1. 一个PartnerOrganization(合作伙伴)可能会向你公司推荐一个或者多个lead，每个lead只能被一个Partner Organization推荐。

2. 一个businessunit （商业单位） 能拥有多个lead，一个lead也可以属于多个business unit。

3. 一个Account(账户) 可以与多个lead关联，但是一个lead只能关联到一个Account。

4. 一个Contact（联络人）可以与多个lead关联，但是一个lead只能管理一个Contact。

Part III Access Control（访问控制）

Figure 3. 访问控制相关的实体

Entities(实体说明)

User Lists(用户列表)

你可以把任意一个用户放入一个UserList （用户列表），然后通过AccessGroup(访问控制组)让这个用户获得数据访问权限。用户包括：user login（登录帐号）、employee(员工)和PartnerUser(合作伙伴用户)。

Access Groups（访问控制组）

可以把 Position（职务）,Organization Unit（组织）,Household（户）和User List（用户列表）放入一个AccessGroup，控制它们的成员访问数据的权限。

Positions(职务)

是Division（部门）中的岗位。用于控制对客户数据的访问。客户数据能与一个或者多个Position关联。

Relationships(关系说明)

1. 多个AccessGroup 能被组织成层次结构，一个AccessGroup仅有一个上级。

2. Access group 只包含 Group类型的记录，但是不包含person/contact类型的记录。一个Group记录可以被多个AccessGroup包含。

3. Position 能被组织成层次结构，但是一个Position只向一个上级汇报。

4. 一个Position只能与一个OrganizationUnit 关联，一个OrganizationUnit 能拥有多个Position。

相关数据库表

Siebel CRM的存储基于关系数据库，此章解释前面的逻辑实体是如何映射到关系表的。

图示范例

下面解释了表映射是如何用图描述的。



上图中的关系可以这么解释:

1. 实体X的属性映射到表A的列。

2. 实体Y是X的子实体，继承了X的属性。

3. 因为Y继承了X的属性，所以Y的属性不仅映射到了表A，还映射到了表B。

4. 表B可以认为是表A的扩展表。

主要实体的关系表

Figure 4. 主要实体的关系表
Organization Unit 映射到基表S_PARTY和扩展表S_ORG_EXT。当S_ORG_EXIT的标志列INT_ORG_FLG等于Y的时候，它便代表一个Division记录。Account记录的标志列永远是N。

Party Relationship和地址的关系表

Figure 5. Party Relationships 和地址的关系表
在SEA中， Business Address 存储在表S_ADDR_ORG，其他类型的地址均存储在S_ADDR_PER。 但是在SIA中，所有地址均存储在S_ADDR_PER中，遗弃了S_ADDR_ORG。

在SEA中，Organization Relationship存储在S_ORG_REL表中， Person Relationship存储在S_CONTACT_REL，其他类型的存储在S_PARTY_REL。在SIA中，所有类型的PartyRelationship（包括了 Organization/Person Relationship）均存储在S_PARTY_REL中，S_ORG_REL和 S_CONTACT_REL则被废弃了。

参考资料和资源

About the Siebel Party Model

http://docs.oracle.com/cd/B40099_02/books/UPG/UPG_Plan_DB9.html#wp1101815

Siebel Party Model – Introduction

http://crackingsiebel.com/2011/10/13/siebel-party-model-introduction/

Oracle's Siebel Business ApplicationsBookshelf, Documentation Library, Version 8.2

http://docs.oracle.com/cd/E16348_01/homepage.htm

PARTY DATA MODEL

http://siebeloracle.wordpress.com/2009/07/07/party-data-model-siebel-eim-party_type_cd-s_party/,Posted by Mandeep Grewal, July 7, 2009

SIEBEL 8.0 ESSENTIALS

http://dream2real.weebly.com/oracle-siebel-crm.html

Siebel Data Model Reference Version 8.1

http://wenku.it168.com/d_000329919.shtml,November 2008.

Security Guide for Siebel BusinessApplications Version 7.8, Rev. A, May 2005

, http://docs.oracle.com/cd/B31104_02/books/PDF/Secur.pdf,Party Data Model, pp. 286.

Siebel 7 Interface Tables Reference, Table 3. Data and RelatedInterface Tables

http://docs.oracle.com/cd/E05603_01/PDFFiles/ITR.pdf

Migrating Address Data After a Direct SEAto SIA Upgrade

http://docs.oracle.com/cd/E14004_01/books/UPG/UPG_PostUpg_DB_FS3.html#wp1237034