siebel学习笔记-数据结构层次，BC之间的关系

数据结构层次
整个Siebel的数据的层次结构分为三个层次，每一个层次都对应了下一个层次的相应的元素，一个层次的改动不影响另一个层次的稳定性，一张表现他们层次的经典图如下：可以看到，一个BC其实对应的就是一个逻辑的表（可以是一个基表也可以是几个关联的表的一个逻辑的表），BC里的field就是对应了数据表的列，多个相关主题的BC则组成了BO前面的文章已经交代了View，Screen等屏幕元素，这些屏幕元素和BC,BO也存在一定关系，从BO和BC的观点来重新定义这些概念就是，View其实对应的就是一个BO，而Applet则对应着一个BC，所谓Control则是屏幕上对应于关系数据字段的显示。多个相关的View则组成了一个Screen，而多个相关的Screen则组成了一个Siebel应用（如Call Center应用）。
需要注意的是一个BO需要有个一个主要的BC（该BC表示了自己关注的业务实体），如下图：


Siebel Fundamental (5) Business component & Business Object
Business Component（BC）和Business Object（BO）
个人觉得Siebel应用架构的一个成功的地方就是在应用里引入了BC，BO的概念，从而使得几千张关系数据表能够按照业务的含义组织成业务对象，对于业务人员而言具有了业务上的含义，而不仅仅是从技术人员的观点来对待数据（就是关系表而已）。

Link：BC之间的关系
对于关系表之间的关系,如主外键关系，从业务的BO观点来看则是BC之间的关系（请注意，不是严格的一对一，并非是一个关系表的外键一定会组成BC间的关系）。因为一个BO总是由一个主要的BC以及和它相关的一些BC组成，而主要的BC总是以一定的关系和附属的BC关联，这种关系就称之为Link，如下图：
我们已经交代过一个View展现的就是一个BO，而BO是由一个Master BC和相关的一些子BC组成，如果不存在Link，则子BC的所有数据都会展现出来，而建立了Link之后，就只有和Master BC选定的记录相关联的数据才会展现出来。这些关系可能是：

1：1关系：一对一的关系很多是用在Extension表上，Extension表的后缀名通常为_X（Extension表是Siebel里常见的一种表，一般Siebel业务的基础数据存储在Base表中，然后把一些扩展的数据和一些可以客户化的字段（attribute字段）放在Extension表中，从而给不同行业，不同场景提供了一个扩充性很强的数据模型。）

1：M关系：一对多的BC关系一般用于Master-Detail的业务场景，比如一个Account以及该Account已经购买的产品就是一个Master-Detail关系。这种关系类似于关系表的主键外键关系，这种关系在Extension表上也存在，通常后缀名称是_XM。

M：M关系：多对多的关系是通过一个叫做交集表（Intersection Table）体现出来的，两个BC之间没有主外键关系，但是每个BC和该交集表有主外键关系，如下图：
多对多的关系通常表达的是值对（value pair）的关系，如上图表示的是公司-行业的值对组合。
Party Business Component
Party BC大概是Siebel里最基础的BC了，Party BC包含了个人相关实体，组织相关的实体，以及访问控制组等为了一定的目的建立起来的一些组织。如下图：
Party BC基表是S_Party，但是和一般的BC不一样的是，作为基表的S_Party本身存储很少的数据，主要是Party的名称，Party的类型（是contact，employee还是account等），而更多Party相关的数据都存储在Extension表里，如S_CONTACT，S_USER等（比较特殊的是这些Extension表的结尾并不是使用*_X来命名）；此外，这些extension表的extension表（如S_CONTACT_X）本身也算是S_PARTY的Extension表，这个也是Party BC的一些特殊的地方。下图是一个很好的表达了Party的访问控制组的图：
rowid为1的行的party类型是User List，所以这一行数据相关的信息应该存储在S_USERLIST extension表里；而rowid为2的行的类型是Access Group，所以该行数据的额外信息应该是在表S_PARTY_GROUP extension表里等等。这个就是一个Siebel里的一个扩展性非常强的数据模型的一个例子。