C_企业数据架构建模

《C_企业数据架构建模》由会员分享，可在线阅读，更多相关《C_企业数据架构建模（17页珍藏版）》请在金锄头文库上搜索。

1、企业数据架构建模企业数据架构建模企业数据架构建模企业数据架构建模背景?不同于书本和培训课程中所提的单例模式，真正的企业 具有非常复杂的数据架构具有非常复杂的数据架构。?大多数数据将会存于大型遗留或包系统中，数据结构的 细节对于这些系统来说可能是不可见的。?其他数据将存于电子表格和个人数据库（例如 Microsoft Access）中，且可能对于 IT 部门或高级业务数据管理员 来说是不可见的来说是不可见的。?一些关键数据可能存于由服务供应商或业务合作伙伴维 系的外部系统中。复杂数据架构?随着您对复杂数据架构的探究，就会逐渐接受两个现实?您很少控制的了高级业务数据概念实现的方式。数据很可能是高

2、度分散的，并且常常在质量方面缺乏足够的控制。?大部分数据在大量系统中进行复制，并且在质量、格式及含义上 出现重大变更。一些由企业应用程序集成（Enterprise Application Integration，EAI）技术或精心的的业务流程进行 维护的副本，也许是好的（但很可能不完善）。大部分仅仅由临 时的批量传输或受迫并破裂的人工流程维护的副本是很差的组时的批量传输或受迫并破裂的人工流程维护的副本是很差的。组 织及业务流程的冲突或简单的信任上的失败可能会阻碍常识的增 长。企业数据架构和各种组件组合?这些条件有几个重要的结果。例如，当计划，如客户关 系管理（CtR l tihiMtCRM）系

3、管理（Customer Relationship Management，CRM） 和业务智能（Business Intelligence）需要通过各种各样 的来源来合并数据时，差的副本也许会使得业务或技术 问题恶化。一些组织在端到端流程中利用各种遗留系统。 业务或 IT 都可能会进行改变以简化业务流程，流水化数 据流并减少复制。?尽管建模为解决这些难题带来好处，但是传统的建模方 法不能解决这些难题。它们会建立要么过于详细以至于 无法使用的模型，要么建立不够详细的模型，并且他们 没有着重于企业数据架构和各种组件整合的难题。UML与企业数据架构建模?我们相信用企业级观点来创建强有力的、简 单并有效

4、的数据结构模型是很重要的: 一组被 称为“企业数据架构”的模型。?使用基于统一建模语言（UML）的方法，可 以满足企业数据架构建模的真正需求。数据架构是什么？?企业的信息系统架构有许多相关的方面，包括应 用程序、硬件、网络、业务流程、技术选择和数 据。如图 1 中所示，数据架构是一组分层的模型， 为战略性的计划提供坚实的基础，如：?数据策略（Data Strategy），概括了为改进集合及数 据使用的业务目标。?业务流程改进。?对新的变更系统的未来的决策。?整合、数据存储及报告计划。企业数据架构模型企业数据架构模型 支持各种公共的支持各种公共的IT 和业务改进计划和业务改进计划数据架构不是一组

5、单个系统的详细模型?数据架构不是一组单个系统的详细模型，因 为它们不能传送用来满足以上需求的所需要 的“大图片”信息。而且它不仅仅是业务流 程和系统范围的顶级模型，因为它们没有包 含足够的细节以回答实际的问题。数据架构图数据架构图详细解析?它说明了范围和数据架构环境。企业的主要数据领域映 射到其中个轴各种类型的模型映射到另个轴范射到其中一个轴，各种类型的模型映射到另一个轴，范 围从高度着重业务的模型到详细的系统架构。完整的数 据架构的范围呈现为跨图表中央的带状。说明了哪个模 型用于企业中哪个数据领域，完整的数据架构是横跨中 央的带状。?水平分组是按照企业到企业区分的，上面的那些代表典平分是按分

6、，那代表典 型的集合。?在右侧边缘的带不是“图”的部分，但显示了模型如何 映射到标准的基于 UML 方法（如 Rational Unified Process， 或 RUP）的三级透视图上。?除了利用该模型来阐述数据架构工作的范围，您还可以 利用它来建立知识的当前状态和正在进行或计划着的活利用它来建立知识的当前状态和正在进行或计划着的活 动的范围的映象。简单地在适当的交点绘制现有的或计 划着的建模工作。您还可以通过颜色来指示模型的状态 或有效性，这是很有用的。?数据架构图描述了“什么”组成了数据架构。支持它的 数据策略和计划阐述了“为什么。”单个的模型说明数数据策略和为单个模说明数 据是什么、

7、在哪里，以及什么时候由谁如何改变的。哪些模型构成了数据架构？?数据架构主要由四级模型定义的。?通常，只有在业务流程发生重大变更时，高级数据模型 才会变更，但其他的模型将存在于各种各样的版本中， 代表“目前”的结构和一个或多个“将来”的进展。高级数据模型?顶层是一组高级数据模型，用概念性观点描述业务数据， 独立于任何当前实际系统的实现每个高级数据模型独立于任何当前实际系统的实现。每个高级数据模型 （high-level data model，HLDM）包含：?主要数据项（业务实体）及其关系的通用（规范的）UML 类模型。?业务属性的超级，包含对这些属性含义（语义）、标准化格式 （语法）和普遍制约

8、的描述。数据模型与实体?因为这些是数据模型，所以它们不会包含类方法，尽管 若业务对象有责任管理其他结构的话对这些方法进行若业务对象有责任管理其他结构的话，对这些方法进行 概括是适合的。?模型应包含所有业务意义的属性和定义数据结构的内容 （例如，控制多样性业务规则的输入）。?设想一个假设的汽车租赁公司。下图显示了实例 HLDM 的部分内容说明了业务实体“hi l ”如何拥有两个的部分内容，说明了业务实体“vehicle”如何拥有两个 变量 car 和 van，以及任意一个车辆（vehicle）怎 样隶属于一个或多个租赁业务（rental）。部分高级数据模型 用于假设的汽车租赁业务。?我们的实例非

9、常地简化，但这些实例仍旧可以说明那些 技术如何能够应用于带有真实世界复杂度的实例中而技术如何能够应用于带有真实世界复杂度的实例中。而 且我们还在命名类及属性方面放松 UML 的约定，以使其 更具可读性 例如，“Registration Mark”包含一 个空格。实现概述?下一个步骤是将 HLDM 的概念化实体和当前或计划系统的真实关键 数据对象之间的关系模型化说明了真实对象如何实现概念实体数据对象之间的关系模型化，说明了真实对象如何实现概念实体。 同一数据项的不同实现之间的关系和跨多种系统扩展变更的方式将 在后面进行模型化。?此处的关键是着重于“可见的”系统的数据结构 例如，由用户 接口暴露出

10、的数据结构、报告及数据接口。这也许和物理的数据结 构不同，但不重要。高度可定制的包可能内含复杂的元模型，但所 关心的内容是依照业务的系统实例化。出于历史原因，旧的遗留系 统也许会具有不可思议的物理结构而且外部服务的实现细节可能统也许会具有不可思议的物理结构，而且外部服务的实现细节可能 会完全地隐藏在接口后面，但在这两种情况下，您的关注点将会在 可视化结构上 逻辑系统实体和他们的属性。部分实现模型?本图显示了简单汽车租赁 HLDM 是如何由三个系统进行实现的： CarFleet（内部队伍管理系统）VanCare（用于支持篷车队外包CarFleet（内部队伍管理系统）、 VanCare（用于支持篷

11、车队外包 维护的外部系统）和 RentalSystem（主要的租赁控制系统）。?说明了三个系统中的关键数据对象如何实现来自于高级数据模型的 概念化实体（呈现黄色）。映射关系?对于本模型，UML 实现关系是关键。颜色和物理布局可 以带来好的效果和致的命名方案如这个显示出的图以带来好的效果和一致的命名方案，如这个显示出的图 应该能标识出逻辑系统实体及其宿主系统。?在概念上的实体的和真实的实体的结构或含义有所不同 的地方，当可以直接将关系进行映射（如上图所示）之 前，一般化和聚集关系是用来分解类结构的。甚至当 HLDM 作为元模型并且实现模型是具体的时候该方法也为元模并实现模是具候该方法 可以使用，

12、反之亦然。来源及使用者模型?模型的下一层显示了同一数据项的不同实现之间的关系、 如何在不同系统上扩展变更以及不同数据元素的组织如何在不同系统上扩展变更，以及不同数据元素的组织 的管理人。使用构造型?除了关注点在识别角色、起源及每个数据项的发展上意外，模型类 似于实现概述利用下面的构造型：似于实现概述，利用下面的构造型：? 标识已经过协议的原版数据源。? 和 标识一个能够直接通过现有接口 使用另一系统数据的位置。注释将解释其如何工作的。? and 标识出一个系统得到了另一系统的规则 或不规则的数据（或者更新列表）的副本，及该副本是否未修改或被接收系统修 改了。注释中将描述计时及相似的问题。? 标

13、识出在哪里系统不是原版的，并且在理论上应具 有原版数据的副本，但由于流程不是足够地确定，所以第二数据集出现分歧。? 标识出数据项和组织或角色（显示为业务角色，和适当的数据 类有依赖关系）的保管关系。? 标识出重要的跨组织的数据的使用。?在需要对不同属性用不同方式进行处理的地方（例如， 个实现对类的些属性是原版的另个类对其他属一个实现对类的一些属性是原版的，另一个类对其他属 性是原版的），高级数据模型应通过两个或多个分离的 类对那些属性进行建模。来源及使用者模型（下图）能 够清楚地说明不同的责任及他们的来源。来源及使用者模型?添加描述不同实现如何相关及它们如何与不同组织角色 相关的信息（绿色）相

14、关的信息（绿色）。迁移及转换模型?模型的最后一层描述了执行系统的数据如何在系统间移 动时进行转换它们表现在动时进行转换。它们表现在：?系统接口的物理类及属性结构（等同于数据库结构，在其中直接 数据访问是最好或唯一的选择）。该模型还将显示带有接口机制 （如 EAI 集线器或干线）的 HLDM 的实现。?不同物理数据结构之间的实现关系。?属性级的转换规则，用目标约束语言（Object Constraint属性级的转换规则，用目标约束语言（Object Constraint language，OCL）编制而成。?接口驱动器、约束和计时规则，通过交互或时序图进行建模。?扩充我们的汽车租赁实例，假设我们

15、想通过 EAI 来保持 Rt lSt中列出的 HiU it 保持最新提取合RentalSystem 中列出的 Hire Unit 保持最新，提取、合 并，并转换两个源列表。下图中的“将来”的模型描述 了物理接口和转换规则，包括 EAI 消息中数据的正则结 构。?CarFleet 有一个由两个主要表格组成的基于数据的接口， Vancare 有一个程序化的接口（例如，对象模型或 Web 个程序接（，模或 服务），Rental System 也一样，包含一个接收更新的 Insert() 方法。转换模型?添加说明数据在系 统间移动时如何转统间移动时如何转 换的细节。公共标准?公共的或行业的标准有两个任

16、务：?它们为 HLDM 或在 EAI 干线和外部接口内的 HLDM 的实现形成基础。?它们会确定外部接口或一些物理系统的数据结构，因 此描绘出在接口中进行转换的物理数据结构。元模型?图中的元模型展示了 设计中各种模型及其设计中各种模型及其 组件之间如何相关使用并开发数据架构?数据架构有很多用途。它帮助您处理数据如同它真的在 由业务使用并且如果您想要开发并实现支持数据策略由业务使用，并且如果您想要开发并实现支持数据策略 的治理，它是其中关键的部件。它还应该用于指导跨系 统的开发，例如企业应用程序整合（EAI）、公共报告和 数据存储计划。?虽然我们对数据架构的阐述是按照“自顶向下”的，但 是数据架构通常按照“由中间开始”进行开发从特定是数据架构通常按照“由中间开始”进行开发，从特定 系统接口的数据需求和合理化实行开始，并不按照严格 的自顶向下的流程和信息需求分析。这种方式允许数据 架构开发以满足不带有难于管理的依赖性的具体的战术 战略需求，并向基于分离的自顶向下和自底向上建模运 行的数据分析提供交叉校验。?数据架构业务对整个企业从