UDM中的人(people)和组织(organization)
Silverston 在他的书[1]中描述了一灵活的数据模型,涵盖了人和组织、Party(中文中没有直接对应的词,不翻译)间的关系、地址、联络方式和Party间的沟通信息。本文描述了一个简化的版本。
注意:
此模型可用作与CRM相关的各种应用的逻辑模型,不要直接当作物理模型,结果会很惨。
Person 实体存储个人的信息,这些信息与工作或者角色无关,例如:
1. 姓名
2. 性别
3. 出生日期
为了节省时间和篇幅,此处忽略了用单独实体表示Person属性的数据模型。
Organization实体存储的信息是关于因共同目的而组成的群体,比如公司、部门、政府机构或者非营利机构等。下图显示了一简单的层次图,由一些常见的Organization实体组成。
Figure 1. Organization
一个Party是Person(个人)或者Organization(组织)。Party 实体存储个人和组织间共同的特性。下图显示的是上级实体Party和它的两个子实体的关系。
Figure 2. Party
Party(个人或者组织)在企业环境中会承担各种角色,比如客户(customer),联络人(contact),供应商(supplier),雇员(employee) 或者内部组织(internalorganization)。因为一个Party可能承担多个角色(同时或者随之时间推移),需要为每种角色定义的相关的信息。例如,信用信息只能与客户角色相关。
Party Role实体存储这些角色的信息。Silverston定义了很多Party Role的子类。简化起见,下图只列出了一些比如容易理解的子类。
Figure 3. Party Role
如上图显示,每个PartyRole由唯一的一条PartyRole Type记录描述。
虽然一个PartyRole是否有效通常由与其他角色的关系(relationship)决定,但是Party Role也可以设置“begindate” 和 “end date”属性,定义它的有效区间。
注意:因为Party的产生和维护是有具体原因的(与企业发生了某种联系),所以大部分Party 至少会承担一种角色,通常会超过一个角色。但是有可能某个Party没有任何角色,比如个人的普查数据(当然你也可能认为角色便是“普查参与人”)。
一个PartyRelationship 便是两个PartyRole之间的联系。下图显示了超类和它的一些关系子类。
Figure 4. Party Relationship
与PartyRole 类似,每个relationship由唯一的一个Party Relationship Type描述。Party Relationship Type 决定了参与某种relationship的Party Role 类型。
Party Relationship实体用“begin date”和”enddate”属性设置有效区间。
Contact Mechanism实体存储Party 的联络途径,比如电话、邮政地址、手机号码、传真和电子邮件。下图显示了ContactMechanism实体和它的子类。
Figure 5. Contact Mechanism
每种ContactMechanism由唯一的一条ContactMechanism Type记录描述。
此处忽略了在ContactMechanism记录间的联系,减低复杂性。
The Party Contact Mechanism entity storeswhich contact mechanisms are related to which parties. Each Party contactMechanism is a way to contact a particular party. The Party Contact Mechanismentity and related entities are shown in the following diagram.
Party Contact Mechanism 实体存储与Party 相关的ContactMechanism。每个PartyContact Mechanism是联络Party的一条途径。它与相关实体的关系如下图显示:
Figure 6. Party Contact Mechanism
Party Contact Mechanism可与 Party Role Type 发生关联,用以标明Party 的某个联络机制只针对某个特定的角色。例如某组织成为其他组织的客户时,提供了一特定地址,这并不适用于其他角色。
如果上图显示的,每个PartyContact Mechanism 有多个使用目的,由Party Contact Mechanism Purpose定义。每种PartyContact Mechanism Purpose则由ContactMechanism Purpose Type实体描述。
Facility是物理场地,比如仓库,工厂,建筑物,楼层,房间和办公室。这些实体此处忽略,降低模型的复杂性。
Communication Event记录了Party 间各种类型的沟通信息(在特定关系下)。比如,电话呼叫、会议、电子邮件等。CommunicationEvent的结构和相关实体此处忽略,减低复杂性。
Figure 7. Overall Party Model
1. 一个Party可以担任一个或者多个PartyRole,而一个PartyRole只能赋给一个Party。
2. 一个PartyRelationship由两个PartyRole组成,而不是两个Party。
3. 一个CommunicationEvent发生在某个关系下,一个关系会有多个CommunicationEvent。
4. 一个Party有一个或者多个PartyContact Mechanism,一个PartyContact Mechanism能用于一个或者多个使用目的。
5. 一个PartyContact Mechanism 必须指向一个ContactMechanism,Post Address(邮政地址)是Contact Mechanism的一个子类。
6. 可设定一个PartyContact Mechanism针对某个PartyRole Type。
1. Len Silverston, The Data Model ResourceBook Revised Edition Volume 1, A Library of Universal Data Models for AllEnterprises, John Wiley & Sons.