数据仓库基础笔记思维导图已经整理完毕，完整连接为：
数据仓库基础知识笔记思维导图

分布式数据仓库

分布式数据仓库类型

• 局部数据仓库与全局数据仓库：业务是在不同地域或者不同生产线上进行的，局部数据仓库是在远程站点上提供和处理数据，全局数据仓库是在整个业务范围集成后的数据。
• 技术上分布的数据仓库：数据仓库包含大量的数据，并且分布在多个处理器上。
• 独立演进的分布式数据仓库：先建立一个数据仓库，然后再建立一个数据仓库。

局部数据仓库与全局数据仓库

• 局部数据仓库包含的是在局部站点上的历史的和集成的数据，局部数据仓库间的数据或数据结构不需要协调一致。

• 全局数据仓库的范围是在企业级集成的业务，包含历史数据以及必须在企业级继承的信息，全局数据可能来源于操作型系统，但通常来源于局部数据仓库。

• 局部数据仓库间数据重叠或公用部分是完全相等的。

• 数据导入到全局数据仓库时有一个简单的数据转换。

• 全局数据仓库有一个公共结构，每个站点以不同的方式映射到公共结构。

• 每个局部区域在将全局数据仓库数据传送到中心位置前先将其缓冲。

• 某些情况下，一些冗余的数据也是需要的。

• 就数据层来说，全局数据仓库并不符合典型的数据仓库结构，细节数据存在于分支机构，轻度综合数据存在于集中全局层。

• 数据的冗余和重叠

  • 数据可以存放在局部数据仓库或者全局数据仓库，但不能在两者中都存放。
  • 多数数据从局部数据仓库到全局数据仓库时，要经过某种形式的换算、转换、重新分类或者汇总。

• 原则上局部数据应局部使用，全局数据应全局使用。

• 全局数据仓库应该全局创建。最好有且只有一个边缘的局部系统进入全局数据仓库。局部系统和全局数据的需求之间映射的定义是集中式的，而不是局部的。必须对映射处理进行局部的管理与控制。映射关系不能集中生成，必须局部生成。

• 分支机构的数据应当采用尽可能灵活的形式。

  • 分支机构的数据必然是以关系型的方式在低粒度级别上进行组织。

技术分布式数据仓库

技术分布式数据仓库的优缺点

• 引入代价低
• 存放在数据仓库中的数据量在理论上没有限制
• 数据仓库中的服务器扩展到一定数量时，网络上会出现过量的传输负载
• 数据仓库越成熟，数据和处理环境就越难于管理

独立开发的数据仓库

多个独立仓库同时开发，且数据仓库之间没有进行协调和约束，单独设计开发即可。

多个数据仓库项目开发

数据体系结构设计者管理多个数据仓库项目开发时，首要问题是开发项目本身的性质。需要了解它们的类型以及同整个体系结构的关系，否则很难有效地管理和协调这些开发项目。

• 完全分离的、非集成的、数据仓库是由不同开发小组开发,除了公司名称，在公司内没有业务集成或者数据共享。多个数据仓库项目之间几乎没有发生冲突的风险，不需要管理和协调。
• **各个开发小组负责创建同一个数据仓库的不同部分，导致多个数据仓库开发项目同时出现。**除非采取特殊措施，否则在使用与分析时，必定出现大量冲突，为了从总体上获得满意的集成效果，要求开发小组间进行密切协作。
• 不同小组负责建立数据仓库中不同级别的数据
• 多个小组试图以非分布式的方式建立数据仓库魂晶中数据 当前细节级的不同部分，很少出现，但是一旦发生，需要特别注意，非常关键，数据体系结构设计者必须知道问题所在以及如何协调他们

分布式数据仓库的开发

1. 为不同地域的分支机构各创建一个局部数据仓库，至少就事务数据而言，在不同的区域间不存在冗余的细节数据。

• 很快完成
• 局部小组控制局部数据仓库的设计和资源
• 如果部门间的数据结构存在共性的话，这种方法不能识别或合理处理这样的共性

2. 在分布的地理位置间协调开发
   • 不太有效，局部开发小组之间不可能完全同步，局部与中央的矛盾。逆序提出一个新的数据模型作为各个局部数据仓库的设计基础。
   • 企业数据仓库反应不同地区、不同部门间的业务集成。第一步是为将反应在企业数据仓库中的业务部门建立企业数据模型，采用迭代开发的方法。
   • 企业数据的分布式模型
     • 企业数据模型反应企业级的业务集成。因此可能与局部数据模型中的某些部分重叠。不管什么情况，都由局部组织来决定如何使企业的数据需求和局部的数据提供能力相适应。
     • 从技术的角度考虑如何将分支机构记录系统数据创建和传送到企业数据仓库，某些情况，正式“缓冲”数据保留在分支机构，另外一些情况，他们被传送到企业环境，且在分支机构不可存取。
     • 通常，企业数据仓库中的数据在结构和概念上都是简单的。
3. 在多种层次上构建数据仓库，不同的开发小组负责构建数据仓库的不同层次
   • 容易管理，风险最小
   • 需要考虑如何协调不同开发小组的工作，包括内容规范说明和结构的描述以及开发时间的确定。
   • 需要考虑数据仓库各层采用的数据平台问题
     • 代价问题
     • 不管数的不同层次是同一平台还是多个平台，都必须认真存储和管理元数据。
   • 互联性
     • 管理低级细节数据的开发小组必须为在其基础上汇总并建立新层次的数据开发小组提供一个正确的数据基础。
4. 多个小组建立当前细节级
   • 只要开发当前细节级的开发小组开发数据集与其他小组是互斥的，就不会出现太多问题，如果重叠：
     • 费用问题
     • 大量数据冗余的细节级数据，造成对数据的错误解释，且没有有效的结果方法。
   • 必须创建一个反应公共戏结束的数据模型
   • 当前没有开发将来可能接入的其他开发小组也可以提出他们的需求
   • 在实现时，将公共数据模型切割为多张物理表，以迭代方式进行开发，不需要建立所有表。
     • 在需要时使用最终用户的反馈信息来有条不紊地对表进行修改
     • 有利于以后增加新表来弥补目前未知的需求
   • 是否应采用同样的技术来存放所有的细节表
     • 单一平台代价低
     • 单一平台维护和培训费用低
     • 如果多个平台代价更低则使用多个平台
   • 其他类型的细节数据
     • 对不同类型的细节数据使用不同的平台
     • 具有一定合理性，能很好地满足企业内不同的策略需求
     • 不同的开发小组至少能对自己特有的需求有一定程度的控制能力
       • 必须购买和支持多个技术平台
       • 最终用户必须接收多种技术培训
       • 各种技术可能很难融合在一起
       • 数据传输问题
       • 细节数据传送后的留存还是删除
5. 公共细节数据采用多种技术平台
   • 是一种可选方案，但是绝不是一种很好的解决方案
   • 跨越多种技术平台的复杂性只能增加管理的难度，除非有特殊的减负策略
   • 这种选择方案能够立刻满足度企业在政策和组织上的不同意见