1. 复制
1.1. 复制技术将分析和查询对主事务操作环境性能的影响降至最低
1.2. 复制解决方案通常监视数据集的更改日志，而不是数据集本身
1.3. 标准复制解决方案是准实时的，数据集的一个副本和另一个副本之间的更改有很小的延迟
1.4. 由于复制解决方案的好处是对源数据集的影响最小，传送的数据量也最小（非常明显），因此许多数据集成解决方案中都使用了复制，即使是那些不包括远程物理分布的解决方案也是如此
1.5. 当源数据集和目标数据集是彼此的精确副本时，复制工具的表现最佳
1.6. 如果数据更改动作发生在多个副本站点时，那么数据复制解决方案不是最佳的选择
2. 归档
2.1. 不经常使用的数据可以移动到对组织成本较低的备用数据结构或存储解决方案中
2.2. ETL功能可用于归档数据并可能将其转换为存档环境中的数据结构
2.3. 使用归档存储来自正在退役的应用程序的数据以及来自长期未使用的生产系统的数据，可以提高操作效率
3. 企业消息格式/规范格式
3.1. 规范化的数据模型是组织或数据交换团队使用的通用模型，用于标准化数据共享的格式
3.2. 规范格式的使用降低了系统或组织之间数据转换量
3.3. 每个系统都只需要将数据转换为中央规范格式的数据，而不需要将数据转换为众多系统格式
3.4. 开发和商定共享消息格式是一项重要的任务，拥有规范格式可以显著降低企业中数据互操作的复杂性，从而大大降低支持成本
4. 交互模型
4.1. 点到点
-
4.1.1. 共享数据系统之间的绝大多数交互都是“点对点”的，它们直接相互传递数据
-
4.1.2. 影响处理(Impacts to Processing)
- 4.1.2.1. 如果源系统是操作型的，那么提供数据的工作量可能会影响交易处理
-
4.1.3. 管理接口(Managing Interfaces)
- 4.1.3.1. 点对点交互模型所需的接口数量接近系统数量的平方数
-
4.1.4. 潜在的不一致(Potential for Inconsistency)
- 4.1.4.1. 当多个系统需要不同的版本或数据格式时，就会出现设计问题
4.2. 中心辐射型
-
4.2.1. 中心辐射型(Hub-and-Spoke)模型是点对点的替代方案，它将共享数据（物理或虚拟）整合到应用程序可以使用的一个中央数据中心
-
4.2.2. 数据中心提供一致的数据视图，对源系统性能的影响有限
-
4.2.3. 数据中心甚至最小化了必须访问的数据源系统和抽取的数量，从而减少对源系统资源的影响
4.3. 发布与订阅
-
4.3.1. 发布和订阅模型涉及推送（发布）数据的系统和其他接受（订阅）数据的系统
-
4.3.2. 当多个数据消费者需要特定格式的数据集时，集中开发该数据集并使其对所有需要的人都可用，可确保所有参与者及时收到一致的数据集
5. 数据集成和互操作架构概念
5.1. 应用耦合
-
5.1.1. 耦合描述了两个系统交织的程度
-
5.1.2. 两个紧密耦合的系统通常有一个同步接口，其中一个系统等待另一个系统的响应
-
5.1.3. 紧密耦合代表了运营上的风险：如果一方系统不可用，那么它们实际上都不可用，并且两个系统的业务连续性计划必须保持一致
-
5.1.4. 松耦合是一种优选的接口设计，其中在系统之间传送数据不需要等待响应，而且一个系统不可用时，不会导致另一个系统无法使用
5.2. 编排和流程控制
-
5.2.1. 编排(Orchestration)是一个术语，用来描述在一个系统中如何组织和执行多个相关流程
-
5.2.2. 所有处理消息或数据报的系统，必须能够管理这些流程的执行顺序，以保持一致性和连续性
-
5.2.3. 流程控制是确保数据的调度、交付、抽取和装载的准确和完整的组件
-
5.2.4. 数据库活动日志
-
5.2.5. 批量作业日志
-
5.2.6. 警报
-
5.2.7. 异常日志
-
5.2.8. 作业依赖图，包含补救方案、标准回复
-
5.2.9. 作业的时钟信息，如依赖作业的定时、期望的作业长度、计算（可用）的窗口时间
5.3. 企业应用集成
- 5.3.1. 在企业应用集成模型(Enterprise Application Integration, EAI)中，软件模块之间仅通过定义良好的接口调用（应用程序编程接口-API）进行交互
5.4. 企业服务总线
-
5.4.1. 企业服务总线(Enterprise Service Bus, ESB)是一个系统，它充当系统之间的中介，在它们之间传送消息。应用程序可以通过ESB现有的功能封装发送和接收的消息或文件
-
5.4.2. 企业服务总线(Enterprise Service Bus, ESB)是用于在多个系统之间接近实时共享数据的数据集成解决方案，其数据中心是一个虚拟概念，代表组织中数据共享的标准和规范格式
5.5. 面向服务的架构
-
5.5.1. 大多数成熟的企业数据集成策略都采用面向服务的架构(Service-Oriented Architecture, SOA)思想
-
5.5.2. 应用程序不必与其他应用程序直接交互或了解其他应用程序的内部工作
-
5.5.3. SOA支持应用程序的独立性和组织替换系统的能力，而无需对与之交互的系统进行重大更改
-
5.5.4. SOA的目标是在独立的软件模块之间定义良好的交互
- 5.5.4.1. 每个模块可供其他软件模块或个人消费者执行功能（提供服务）
-
5.5.5. SOA的关键概念是提供了独立的服务：该服务没有调用应用程序的预先知识，服务的实现是调用应用程序的黑匣子
-
5.5.6. SOA可以通过Web服务、消息传送、RESTful API等多种技术来实现
-
5.5.6.1. 通常作为可以供应用系统或个人消费者调用的API（应用程序编程接口）实现服务
-
5.5.6.2. 一个定义良好的API注册表包含了可用的选项、需要提供的参数以及提供的结果信息
-
5.6. 复杂事件处理
-
5.6.1. 事件处理是一种跟踪和分析（处理）有关发生事件的信息流（数据流），并从中得出结论的方法
-
5.6.2. 复杂事件处理(Complex Event Processing, CEP)将多个来源的数据进行合并，通过识别出有意义的事件（如机会或威胁），为这些事件设置规则来指导事件处理及路由，进而预测行为或活动，并根据预测的结果自动触发实时响应
-
5.6.2.1. 组织可以使用复杂事件处理来预测行为或活动，并根据预测的结果自动触发实时响应
-
5.6.2.2. 当测量值超过预定的时间、温度或其他值的阈值时，事件也可以定义为状态的变化
-
-
5.6.3. CEP存在很多数据挑战
-
5.6.3.1. 有时事件发生的概率让在发生事件时检索必要的额外数据变得不切实际
-
5.6.3.2. 高效的处理通常要求预先在CEP引擎的内存中预存一些数据
-
-
5.6.4. 复杂事件处理需要一个能够集成各种类型数据的环境
- 5.6.4.1. 由于预测通常涉及大量各种类型的数据，所以复杂事件处理常常与大数据相关
5.7. 数据联邦和虚拟化
-
5.7.1. 当数据存在于不同的数据存储库时，还可以通过除物理集成以外的方式来聚合
-
5.7.2. 无论各自结构如何，数据联邦(Data Federation)提供访问各个独立数据存储库组合的权限
-
5.7.3. 数据虚拟化(Data Virtualization)使分布式数据库以及多个异构数据存储能够作为单个数据库来访问和查看
5.8. 数据即服务
-
5.8.1. 软件即服务(SaaS)是一种交付和许可模式
-
5.8.2. 许可应用程序提供服务，但软件和数据位于软件供应商控制的数据中心，而不是获得许可组织的数据中心
-
5.8.3. 数据即服务(DaaS)的一个定义是从供应商获得许可并按需由供应商提供数据，而不是存储和维护在被许可组织数据中心的数据
5.9. 云化集成
-
5.9.1. 云化集成，也称为集成平台即服务或IPaaS，是作为云服务交付的一种系统集成形式
-
5.9.2. 用它处理数据、流程、面向服务架构(SOA)和应用集成
-
5.9.3. 集成可以分为内部集成和企业间集成(B2B)
-
5.9.3.1. 内部集成需求是通过内部中间件平台提供服务，并且通常使用服务总线(ESB)来管理系统之间的数据交换
-
5.9.3.2. 企业间集成是通过电子数据交换(EDI)网关、增值网络(VAN)或市场完成
-
6. 数据交换标准
6.1. 数据交换标准是数据元素结构的正式规则
6.2. 数据交换规范是组织或数据交换团队使用的通用模型，用于标准化数据共享格式
6.3. 交换模式定义了任何系统或组织交换数据所需的数据转换结构
- 6.3.1. 数据需要映射到交换规范中
6.4. 国家信息交换模型(NIEM)
-
6.4.1. 是为在美国政府机构之间交换文件和交易而开发的数据交换标准
-
6.4.2. 目的是使信息的发送者和接收者对该信息的含义有一个共同的、明确的理解
-
6.4.3. 与NIEM的一致性确保了基本的信息集被很好地理解，并且在不同的社区中具有相同的一致性的含义，从而实现互操作性
