Data Warehouse 数据仓库
Business Intelligence 商业智能
信息（数据）用作两个目的：操作型记录的保存、分析型决策的制订。即操作型系统保存数据，DW/BI系统使用数据。
可以理解为OLTP和OLAP。
存在一种错误认识：DW/BI系统是存储于不同硬件平台上的操作型系统的记录的拷贝。没有认识到两者存在需求差异。
DW/BI基本需求：
方便存取、一致性、适应性、实时性、安全性；DW/BI需要支持决策；DW/BI成功标志是业务群体接收。
对于开发工程师来说，要具有技术基础，并且深入了解业务。责任：
理解业务；对用户提供高质量信息和分析；维护DW/BI环境。
维度建模基于两个需求：
以商业用户可理解的方式发布数据；提供高效查询。
3NF模型也可称之为实体-关系模型。规范化的3NF模型主要用于操作型过程中，对于BI来说，规范化模型太复杂。而且对于多数关系型数据库管理系统，不能有效查询规范化模型，可能因查询的复杂性耗尽数据库优化器。
维度模型包含的信息与规范化模型包含的信息相同，但将数据以一种用户可以理解的满足查询性能要求的、灵活的方式进行了包装。
星型模式与OLAP多维数据库，对可识别的维度具有公共的逻辑设计，物理实现上有差异。
通常推荐将详细的、原子的信息加载到星型模式中，然后将OLAP多维数据库移植到星型模式上。
物理世界里的每一个度量事件，与对应的事实表行具有一对一的关系，这是维度建模的基本原则，其它工作以此为基础。最实用的事实是数值类型和可加类型事实。事实通常是连续值，这样有助于区分到底是事实还是维度属性的问题。
（其实我感觉翻译有点问题，这里的事实和维度可以对应理解为Tableau中的度量和维度）
事实表的粒度可以划分为：事务、周期性快照、累积快照。
事实表通常包含外键集合的主键，称为组合键，具有组合键的表称为事实表。事实表表示多对多关系，其它表称为维度表。
通常几个维度一起唯一标识每个事实表行。当确定了所有维度中唯一标识事实表行的子集后，其它维度使用事实表行的主键的单一值，即其它维度只是参与其中。
维度表通常有多列，或者说包含多个属性，每个维度表有单一主键定义，用于在与事实表联结时实现参照完整性的基础。维度表的属性应该使用真实的词汇，尽量减少使用代码，应该讲代码替换为详细的文本属性。
多数情况下，数据仓库的好坏直接取决于维度属性的设置，其分析能力直接取决于维度属性的质量和深度。强大的维度属性，带来的好处是健壮的分片-分块分析能力。
一般连续的数字可以认为属于事实，离散的数字基本可以认为是维度属性。
维度模型表示每个业务过程包含事实表，事实表存储事件的变化度量，围绕事实表的是多个维度表维度表包含事件发生时实际存在的文本环境，这种类似星状的结构叫做星形连接。
ETL（抽取、转换、加载）系统是处于操作型源系统与DW/BI展现系统之间的区域。
不能在用户查询中使用规范化结构，因为规范化结构难以同时满足可理解性和性能这两个目标。
开发者不应该过度关注构建规范化结构，而应该将主要的精力放在支持改进业务决策的维度展现区域中。
用于支持商业决策的展现区：数据应该以维度模型来展现，要么采用星型模式，要么采用OLAP多维数据库；必须包含详细的原子数据；展现区的数据可以围绕业务过程度量时间来建模；使用公共的、一致性的维度建立维度结构，即遵守总线企业结构，而不是按照个别部门需要的数据来构建。
Kimball DW/BI架构
独立数据集市架构：分析型数据以部门为基础来部署，不需要考虑企业级别的信息共享和集成。（这种架构实际上没有架构，由于分析数据的冗余存储造成浪费和低效）
企业信息工厂CIF架构
混合架构：
维度模型不仅包含汇总数据，必须向业务用户提供对细节数据的查询访问；
维度模型应该围绕业务过程进行组织，而不是按照部门职责进行划分；
维度模型是易于扩展的；
不应将维度模型设计为关注预定义的报表或分析，而应该以度量过程为中心，维度模型应该适应变化；
坚持采用一致性结构的总线结构，避免产生烟筒式的解决方案。
问题：为什么在处理DW/BI项目时，既需要从数据库管理员的角度，也要从商业分析师的角度去考虑问题？
因为我们既要熟悉技术，又要深入了解业务。要对用户提供高质量的信息和分析，又要维护好DW/BI环境。
转载请注明出处：无忧博主，如有疑问，请联系（762063026）。
本文地址：https://wuyouseo.com/it/2446.html