主数据管理系统和ODS的关系Word下载.docx
《主数据管理系统和ODS的关系Word下载.docx》由会员分享，可在线阅读，更多相关《主数据管理系统和ODS的关系Word下载.docx（18页珍藏版）》请在冰点文库上搜索。
主数据管理的典型应用有CustomerDataIntegration—客户数据管理和ProductInformationIntegraiton—产品数据管理。
图2.主数据管理的信息流
一般来说，主数据管理系统从IT建设的角度而言都会是一个相对复杂的系统，它往往会和企业数据仓库/决策支持系统以及企业内的各个业务系统发生关系，技术实现上也会涉及到ETL、EAI、EII等多个方面，如图2所示，一个典型的主数据管理的信息流为：
1.某个业务系统触发对企业主数据的改动；
2.主数据管理系统将整合之后完整、准确的主数据分发给所有有关的应用系统；
3.主数据管理系统为决策支持和数据仓库系统提供准确的数据源。
因此对于主数据管理系统的建设，要从建设初期就考虑整体的平台框架和技术实现。
以客户主数据为例，常见的主数据域包括：
∙Party：
参与方。
参与方包含的范围是所有与企业发生了或者发生过正式业务关系的任何合法的实体，比如填写了投保单的参与方。
Party是分类别的，可以是个人、机构和团体。
对于Party来说，因为开展业务的需要，可能要对他们进行分级、分类，比如VIP，黑名单等。
个人包括个人基本属性、个人名称、职业、性别、教育等自然属性；
机构是指在法律上有登记的组织实体，可以分为政府机构、商业机构、非盈利机构等类别；
团体可以有多种形态，比如他们可以是家庭、兴趣小组、某个大机构中的一部分，或者通过某种数据分析技术得出的客户细分群体。
∙PartyRole：
参与方在业务中扮演的角色。
例如，对于保险行业而言，可以有：
投保人，被保人，受益人，担保人，报案人，核保人，查勘员，核赔人等。
∙Relationship：
Party与Party之间的关系,例如可以是：
夫妻关系、父子关系、母女关系、兄弟姐妹关系、总（母）公司分（子）公司关系、企业事业单位隶属、上下级关系等。
∙Account：
帐户是客户使用企业服务的付费实体。
∙Location：
Location记录的是每个Party可能拥有的所有联系地址，地址的类别包括邮寄地址、email地址、电信联络地址等。
∙Contract：
Party与企业之间的契约。
主数据有几个鲜明的特点，其中包括：
它是准确的、集成的，其次它是跨业务部门的，再有就是它是在各个业务部门被重复使用的。
主数据管理的意义
图3.主数据管理的要素
如图3所示：
集成、共享、数据质量、数据治理是主数据管理的四大要素，主数据管理要做的就是从企业的多个业务系统中整合最核心的、最需要共享的数据（主数据），集中进行数据的清洗和丰富，并且以服务的方式把统一的、完整的、准确的、具有权威性的主数据分发给全企业范围内需要使用这些数据的操作型应用和分析型应用，包括各个业务系统、业务流程和决策支持系统等。
主数据管理使得企业能够集中化管理数据，在分散的系统间保证主数据的一致性，改进数据合规性、快速部署新应用、充分了解客户、加速推出新产品的速度。
从IT建设的角度，主数据管理可以增强IT结构的灵活性，构建覆盖整个企业范围内的数据管理基础和相应规范，并且更灵活地适应企业业务需求的变化。
以客户主数据为例，客户主数据是目前企业级客户普遍面临的一个问题，在大多数企业中，客户信息通常分散于CRM等各个业务系统中，而每个业务系统中都只有客户信息的片断，即不完整的客户信息，但却缺乏企业级的完整、统一的单一客户视图，结果导致企业不能完全了解客户，无法协调统一的市场行为，导致客户满意度下降，市场份额减少。
因此，建立客户主数据系统的目的在于：
∙整合并存储所有业务系统和渠道的客户及潜在客户的信息：
一方面从相关系统中抽取客户信息，并完成客户信息的清洗和整合工作，建立企业级的客户统一视图；
另一方面，客户主数据管理系统将形成的统一客户信息以广播的形式同步到其他各个系统，从而确保客户信息的一致；
∙为相关的应用系统提供联机交易支持，提供客户信息的唯一访问入口点，为所有应用系统提供及时和全面的客户信息；
服务于OCRM系统，充分利用数据的价值，在所有客户接触点上提供更多具有附加价值的服务；
∙实现SOA的体系结构：
建立客户主数据系统之前，数据被锁定在每一个应用系统和流程中，建立主数据管理系统之后，数据从应用系统中被释放出来，并且被处理成为一组可重用的服务，被各个应用系统调用。
主数据管理系统与数据仓库系统的关系
主数据管理系统与数据仓库系统是相辅相成的两个系统，但二者绝不是重复的，也不是互斥的。
它们有很多共同之处：
∙首先二者对企业都具有相同的价值，可以减少数据冗余和不一致性、提升对数据的洞察力，二者都是跨部门的集中式系统；
∙其次二者都依赖很多相同的技术手段，都会涉及到ETL技术、都需要元数据管理、都强调数据质量；
∙第三就是二者建设手段类似，都需要数据治理的规范作为指导、都需要不同系统、不同部门的协作、需要统一的安全策略。
但是，主数据管理系统和数据仓库/决策支持系统二者之间也存在很多不同：
∙处理类型不同：
主数据管理（MDM）系统是偏交易型的系统，它为各个业务系统提供联机交易服务，系统的服务对象是呼叫中心、B2C、CRM等业务系统；
而数据仓库是属于分析型的系统，面向的是分析型的应用，是在大量历史交易数据的基础上进行多维分析，系统的使用对象是各层领导和业务分析、市场销售预测人员等；
∙实时性不同：
与传统的数据仓库方案的批量ETL方式不同，主数据管理系统在数据初始加载阶段要使用ETL，但在后续运行中要大量依赖实时整合的方式来进行主数据的集成和同步；
∙数据量不同：
数据仓库存储的是大量的历史数据和各个维度的汇总数据，可能会是海量的，而MDM存储的仅仅是客户和产品等信息。
虽然主数据管理系统和数据仓库系统异同共存，但是二者却有着紧密的联系，并且可以互为促进、互为补充。
举例而言，数据仓库系统的分析结果可以作为衍生数据输入到MDM系统，从而使MDM系统能够更好地为操作型CRM系统服务。
以航空公司为例，客户的主数据模型大致可以分为三部分：
首先包括客户基本信息和偏好信息。
∙客户基本信息：
o个人及公司信息
o消费者市场状况
o常旅客会员卡号，状态，及累计里程等
o客户间关系（个体-个体，个体-公司）
o联系地址，包括电话，电子邮件等
∙客户偏好信息：
o餐食偏好
o是否吸烟
o座位偏好
o机型偏好
o公务舱位偏好
o旅行舱位偏好
o休息室服务偏好
除了这两部分之外，我们还可以从数据仓库系统中提取相关的信息，作为客户主数据的衍生信息部分，从而更好地、全方位地描述客户特征，这些可以包括：
∙衍生信息：
o本月飞行里程
o年度飞行里程（最近12个月内）
o提前预订倾向
o习惯预订模式
o使用自主服务倾向
o上次预订使用的信用卡号
o累计/本月转签/取消航班次数
o转签航班倾向
o取消航班倾向
oNoShow倾向等。
主数据管理系统和ODS的关系
在某些情况下，主数据管理系统和ODS系统可能容易被混淆，的确，从实时上来看，主数据管理系统和ODS系统存储的都是实时数据，但是二者存储的数据内容是全然不同的，主数据管理系统中不存储交易数据，比如银行客户的交易流水信息是不应该放在主数据管理系统中进行管理的，这与MDM与ODS的一个很大区别。
举一个航空公司的例子，比如某个客户在电子商务网站上定了一张机票，产生一个订单，然后他又通过呼叫中心要求改签，这个场景中，两个系统之间要实现客户信息和订单信息的共享，其中客户信息共享通过MDM系统来实现，而订单信息则需要采用ODS或其它手段进行共享，我们是不推荐把此类信息交由MDM系统来管理的。
主数据管理解决方案介绍
目前业界比较常见的主数据管理解决方案主要可以分为三类：
∙第一是依托专业套装软件来实现主数据管理，这类方案是作为套装软件的一部分，主要是为套装软件的其它模块提供服务的，因此，通常功能都缺乏完善性。
∙还有一类是侧重于分析型应用的主数据管理，这类方案在数据实时同步以及面向交易型应用时通常缺乏整体方案的完整性。
∙再有一类就是专注于主数据管理的中立的、完整的解决方案，这一类应用独立于套装软件，不仅具有整体架构的完整性和先进性，从功能上讲往往也最为完善，除了具有比较完整的数据模型（DataModel）之外，还会提供广泛的集成性，具备先进的机制实现数据同步，并且可以对外提供多种预置的主数据服务被外部交易系统调用，从而使系统具有很强的实时操作性，同时还强调主数据管理、主数据质量控制以及主数据维护的手段和规范性。
企业主数据管理系统逻辑架构
一个完整的主数据管理解决方案的逻辑架构应如下图所示：
图4.主数据管理系统逻辑架构
在一个完整的主数据管理解决方案中，除了主数据管理的核心服务组件之外通常还会涉及到企业元数据管理、企业信息集成、ETL、数据分析和数据仓库以及EAI/ESB等其他各种技术和服务组件。
其中主数据管理服务又包括如下一些主要的服务组件：
∙InterfaceServices：
为企业中需要主数据的所有业务系统提供各种服务接口，通过实时的、批量的接口可以读取或者修改主数据，这些接口包括Batch,WebServices,XMLInterface,MessagingInterface,Publish/Subscribe,Import/ExportServices,DataStandardizationInterface,DirectoryIntegration等。
除了这些标准的技术接口之外,对于某些专有系统还提供适配器（Adapter）接口,通过适配器接口可以和一些特有的系统做接口，例如企业中的传统（Legacy）应用系统或者SAP等打包应用。
∙LifecycleManagementServices:
履行针对主数据的CRUD操作，执行对主数据存储库中的数据进行更新、存取和管理时的业务逻辑，除此之外，它还负责维护主数据的衍生信息，例如客户之间的关系、客户的偏好、客户在各种客户服务渠道上的行为轨迹等。
LifecycleManagementServices贯穿整个主数据管理的生命周期，它利用DataQualityManagementServices来确保数据质量、利用MasterDataEventManagementServices来捕获各种主数据变化等相关的事件，以及利用HierarchyandRelationshipManagementServices用来维护数据实体之间的关系和层次。
∙DataQualityManagementServices：
确保主数据的质量和标准化，这在主数据管理解决方案中一个非常重要的组件，在我们从各个业务系统获取数据之后，要对数据进行清洗和验证，例如对于地址而言，要弥补地址的缺失、地市的缺失、邮编的缺失、进行地址的标准化等。
对于其他数据要进行非空检查、外键检查、数据过滤等。
然后要对数据进行匹配/重复识别、自动进行基于规则的合并/去重、交叉验证等，并且还要遵从企业的数据管控规范和流程。
它可以是MasterDataManagementServices的一个内部组件，也可以调用整个企业的InformationIntegrityServices来实现。
∙AuthoringServices：
依据数据管控流程，定义和扩展企业的主数据模型。
∙HierarchyRelationshipandManagementServices：
定义数据实体的层次（Hierarchy）,分组（Grouping）,关系（Relationship）,版本（Version）等。
∙MasterDataEventManagementServices：
捕获事件并且触发相应的操作，包括事件发现、事件管理和通知功能，它在主数据管理系统和业务系统之间进行数据同步时起到至关重要的作用。
∙BaseServices：
提供通用服务，包括安全控制、错误处理、交易日志、事件日志等功能。
∙MasterDataRepository:
主数据存储库，包括Metadata,MasterData,HistoryData,ReferenceData等。
下面我们介绍两个这些逻辑组件之间的协作场景：
图5.场景1--初始数据加载
场景1：
初始数据加载：
1.源数据从外部业务系统及EDW系统中通过批处理方式拷贝到磁带；
2.数据被加载到StagingDB，进行数据质量分析；
3.DataQualityManagementServices对数据进行清洗、匹配、标准化等；
4.ETLTransformandLoadservices对合格数据进行转换并准备好加载数据；
5.MasterDataInterfaceServices接收批处理更新请求，调用LifecycleManagementUpdateService进行数据的批量更新；
6.LifecycleManagementUpdateService调用Hierarchy&
RelationshipManagementServices和BaseServices更新主数据库。
图6.场景2--主数据库更新，然后同步到各业务系统
场景2：
主数据库更新，然后同步到各业务系统
1.某业务系统发起一个创建主数据的交易，该业务系统将交易数据以消息的形式发送到消息队列；
2.MDMInterfaceServices捕获该消息，进行消息解析，并调用SecurityandPrivacyServices进行权限验证；
3.MDMInterfaceServices调用LifecycleMgmt.UpdateService；
4.LifecycleMgmt.UpdateService再调用DataQualityManagementServices进行数据的清洗和标准化；
5.UpdateService调用SearchServices发现该主数据已经存在，确认这是对已有主数据的更新操作；
6.UpdateService通过调用外部系统对数据进行扩充；
7.UpdateService在更新主数据库之前调用EventManagementServices；
8.EventManagementServices确认是否需要涉及数据管控方面的处理；
9.UpdateService调用Hierarchy&
RelationshipManagementServices并且更新主数据库；
10.AuditLoggingServices纪录相应交易日志和历史数据；
11.MDMLifecycleManagementService调用MDMInterfaceServices返回更新处理请求；
12.源业务系统接收到处理请求之后，利用MDM系统发回来的数据对本地的应用系统数据库进行更新操作；
13.其他所有需要主动被更新的相关的业务系统都会接收到更新后的最新数据。
IBM主数据管理解决方案
IBM的主数据管理解决方案InfoSphereMasterDataManagement是IBM信息管理大家族的一员。
图7.IBMInfoSphereMDMServer产品构成
如上图所示，IBMMDMServer包含：
∙Knowledge（知识层）：
知识层包括当事方（人员和组织）、角色、地址位置、当事人属性（统计学信息）、关系、财务简档、多渠道集成、协议和产品、事件等。
∙Action（交互层）：
MDMServer本身就是按照SOA的体系结构设计的，它提供700多个开箱既有的服务接口，这些服务可划分为多个主题范围，如下图所示：
∙
∙图8.MDMServerBusinessServices
其中主要包括：
o当事方人口统计学服务：
o角色：
一个当事方可以扮演一个或多个角色，如帐户方角色服务用于管理当事方在一个或多个帐户中扮演的多个角色，折扣或索赔方角色服务用于维护当事方在一个或多个折扣或索赔中扮演的角色的信息。
o关系服务：
维护当事方对当事方关系，当事方对当事方关系不仅可以存在于两个独立的当事方之间（例如甲方和乙方是配偶），也可以存在于双方在某个帐户中扮演的角色范围之内（例如甲方是乙方遗嘱的执行人）。
o位置服务：
维护关于位置的数据，如地址和联系方式。
o客户服务和销售服务：
包含管理多渠道集成所需要的客户服务与销售信息的综合业务服务。
例如：
隐私服务用于维护数据管理与请求的默认隐私偏好以及客户声明的隐私偏好；
偏好服务用于管理复杂的客户服务偏好（比如，特定联系方法和特定产品的联系偏好）。
o协议和产品服务：
帐户或合同服务用于维护某个帐户或合同的详细信息，这里合同定义为一个或多个当事方与公司的合法协议。
o数据维护服务：
MDMServer提供重复嫌疑管理服务,进行当事方记录的合并等。
o当事方财务简档：
比如收入来源信息、财务帐户信息等。
o当事方识别服务：
为每个客户记录创建一个唯一客户ID，并且维护对其它系统的交叉引用。
o历史纪录和审核服务：
包含检索对象的历史审核数据的服务。
∙Integrity（完整性层）：
完整性服务用于管理数据质量和维护客户数据的单一版本，包括疑似处理、重复处理、数据检查、标准化等。
∙Intellegence（智能层）：
包括事件管理、业务处理规则、数据安全性。
∙DataGovernance（数据管控层）：
管理数据实体间的关系（Relationship）,分组（Group）,层次（Hierarchy），以及数据生命周期等。
∙ServiceInteface（接口层）：
MDMServer支持多个实时和批处理接口，其中实时接口包括XML接口、WebServices接口、消息接口、Java对象接口、COBOL和CICS接口等。
此外，还支持用户自定义接口。
使用IBM全套解决方案的主数据管理案例
以下是一个使用全套IBM软件解决方案的案例，这是一个典型的客户主数据管理的应用场景，其中使用的产品包括：
WebSpherePortalServer，WebSphereMDMServer，WebSphereEnterpriseServicesBus,WebSphereQualityStage,DB2等。
图9.主数据管理应用案例
图9描述了一个主数据管理应用的端到端流程：
1.业务系统通过自己的用户界面创建一个新的用户，并且把数据写入了其应用系统数据库中；
2.该业务系统向MQ发送一条XML消息；
消息中包含了客户基本信息和策略信息；
3.MDMServer接收到该MQ消息，对此消息进行处理；
4.MDMServer通过与QualityStage的接口调用WebSphereQualityStage的服务，进行客户姓名和联系方式的清洗和标准化；
5.WebSphereQualityStage对客户姓名和联系方式的清洗和标准化；
6.WebSphereQualityStage返回标准化了的客户数据；
7.MDMServer接收到标准化了的客户姓名和地址，查询主数据库获取候选姓名，调用QualityStage的疑似匹配服务；
8.QualityStage进行疑似处理；
9.QualityStage将打分结果返回给MDMServer，结果表明这是一个新客户；
10.MDMServer向某外部系统发出WebServices请求，进行数据扩充；
11.外部系统将结果返回MDMServer；
12.MDMServer分配一个唯一的PartyID，并且将客户主数据写入MDMServerDB；
13.根据客户Profile，MDMServer发现该客户是新推出的一项新业务的目标客户；
14.MDMServer向MQ产生一条XML/JMS消息；
15.WebSphereESB接收到XML消息并且将其转换为市场促销系统所需要的消息格式；
升级会员 