数据仓库和商业智能（Data Warehousing and Business Intelligence,DW/BI）系统。
DW/BI的业务驱动目标
发布DW/BI系统的隐喻
维度建模核心概念及涉及的主要词汇包括事实表与维度表
Kimball DW/BI架构的组件与原则
不同DW/BI架构的比较研究，维度建模在不同架构中所扮演的角色
有关维度建模的误解
信息的目的：操作型记录的保存和分析型决策的制定。操作系统保存数据，DW/BI系统使用数据。
操作系统通常不必维护历史数据，只需修改数据以反映最新的状态。一般一次处理一个事务记录。而DW/BI系统的用户研究分析企业的运转，并对其性能进行评估。DW/BI系统一般不会一次只处理一个事务。对DW/BI系统进行优化的目的是高性能地完成用户的查询，而回答用户的查询通常需要搜索成千上万条事务，并将查询结果放入一个查询集合中。需应对复杂问题，DW/BI系统的用户通常要求保存历史环境，用于精确地评估组织在一段时间内的性能。
DW/BI系统要能方便地存取信息.
DW/BI系统的内容必须是易于理解的。数据结构与标识必须符合业务用户的思维过程和词汇。
DW/BI系统必须以一致的形式展现信息。
一致性也意味着表示DW/BI系统内容的公共标识和定义，可在不同数据源公用。
DW/BI系统必须能够适应变化。
当业务问题改变或新数据增加到数据仓库中时，已经存在的数据和应用不应该被改变或破坏。如必须修改DW/BI系统中的描述性数据，要能以适当的方式描述变化，并使这些变化对用户来说是透明的。
DW/BI系统必须能够及时展现信息。
DW/BI系统必须成为保护信息财富的安全堡垒。
保存在数据仓库中的信息时组织的信息化财富。如果将信息发送给错误的人，将给组织带来伤害。####DW/BI系统必须成为提高决策制定能力的权威和可信的基础。*
DW/BI系统成功的标志是业务群体接受DW/BI系统。*
维度建模
维度建模主要基于以下两个需要同时满足的需求：
以商业用户可理解的方式发布数据；
提供高效的查询性能。
维度模型通常应用在关系数据库管理系统之上，但并不要求维度模型必须满足第3范式（3NF）。
维度模型包含的信息与规范化的模型包含的信息相同，但将数据以一种用户可理解的、满足查询性能要求的、灵活多变的方式进行了包装。
在关系数据库管理系统中实现的维度模型称为星型模式。在多维度数据库环境中实现的维度模型通常称为联机分析处理（OnLine Analytical Processing，OLAP）多维数据库。
当数据被加载到OLAP多维数据库时，对这些数据的存储和索引，采用了为维度数据设计的格式和技术。OLAP多维数据库还提供了大量见状的分析函数，这些分析函数比sql编写的函数更好，特别是针对大数据集合时，分析函数体现的优势更加明显。
OLAP部署的注意事项：
构建于关系数据库之上的星型模式是建立OLAP多维数据库的良好物理基础。
由于供应商多，OLAP多维数据库数据结构比关系数据库管理系统变化更大，因此，最终的部署细节通常与选择的提供商有关。
维度模型中的事实表存储组织机构业务过程事件的性能度量结果。
事实表中的每行对应一个度量事件。每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一个事实表中的所有度量行必须具有相同的粒度。牢记建立事实表时使统一的细节级别这一原则可以确保不会出现重复计算度量的问题。
一般事实表具有两个或多个外键与维度表的主键关联。当事实表中所有键与对应维度表中各自的主键正确匹配时，这些表满足参照完整性。可以通过维度表使用连接操作来实现对实事表的访问。
事实表通常包含外键集合的主键。事实表的主键常称为组合键，具有组合键的表称为事实表。事实表表示多对多关系。其他表称为维度表。
维度表是事实表不可或缺的组成部分。维度表包含与业务过程度量事件有关的文本环境。维度表通常以层次关系表示。维度表通常是多列，或者说包含多个属性。与事实表比较，维度表趋向于包含较少的行，但由于可能存在大量文本列而导致存在多列的情况。每个维度表由单一主键定义，用于在与事实表连接操作时实现参照完整性的基础。
维度属性可作为查询约束、分组、报表标识的主要来源。对查询或报表请求来说，属性以词或词组加以区分。如用户希望按类别来查询数据时，要查看的类别必须存在于维度属性中。
维度表属性在DW/BI系统中起着至关重要的作用。属性应该是包含真实使用的词汇而不是令人感到迷惑的缩写。应该尽量减少在维度表中使用代码，应该将代码替换为详细的文本属性。应该对那些操作型的代码进行解码，以用于维度属性中，这样可以为查询、报表、和BI应用提供具备一致性的标识。对那些不可避免会发生不一致情况的报表应用，应尽量使用解码值。
在一些情况下，操作码或标识符对用户具有确定的业务含义，或者需要利用这些操作码与后台的操作环境交互。这时代码应以明确的维度属性出现，辅以对应的用户友好的文本描述。如操作码头2位表示类别，3、4位表示区域。这时应该将隐含的意思拆分，以不同维度属性方式展现给用户，方便用户开展过滤、分组和制作报表等工作。
大部分情况，数据仓库的好坏直接取决于维度属性的设置；DW/BI环境的分析能力直接取决于维度属性的质量和深度。为维度属性提供详细的业务术语耗费的精力越多，效果越好。为属性列填充领域值耗费的精力越多，效果就越好。为确保属性值的质量耗费时间越多，效果就越好。强大的维度属性带来的回报是健壮的分片-分块分析能力。
注：维度提供数据的入口点，提供所有DW/BI分析的最终标识和分组。
在分析操作型源数据时，有时不清楚一个数值数据元素应该是事实属性还是维度属性。可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往可能是事实；或者该列是对具体值的描述，是一个常量、某一约束和行标识的参与者，此时该属性往往是维度属性。
注：连续值数字基本上可以认为属于事实，来自于一个不太大的列表的离散数字基本可以认为是维度属性。维度表通常不一定要满足第3范式，它常常是非规范化的，一个维度表往往存在多对一的关系。与事实表比较，维度表通常要小的多，因此采用规范化或雪花模式实际上对数据库总容量没多大影响。维度表存储空间需要关注简单性和可访问性。
维度模型表示每个业务过程包含事实表，事实表存储时间的数字化度量，围绕事实表的是多个维度表，维度表包含事件发生时实际存在的文本环境。这种类似星状的结构通常称为星型连接。
数据库引擎首先处理多重索引的维度表，然后将满足用户约束的维度表关键字与事实表通过笛卡尔积连接。优化器可以一遍扫描事实表索引，实现与事实表的多重连接查询评估。维度模型非常适于变化。维度模型可预测的框架可适应用户行为的变化。每个维度的地位都相同，所有维度在事实表中都存在对应的入口点。
粒度最小的数据或原子数据具有最多的维度。尚未聚集的原子数据是最具有可表达性的数据。这些原子数据是构建能满足用户提出的任意查询的事实表的设计基础。对维度模型来说，可以将全新的维度增加到模式中，只要该维度的单一值被定义到已经存在的事实表行中。同样，可以将新的事实增加到事实表中，前提是其细节级别与当前事实表保持一致。可以向已存在的维度表增加新的属性。
另一种体会事实表与维度表互为补充的方式似乎可以考察将它们转化为报表。维度属性支持报表过滤和标识，事实表支持报表中的数字值。
基于Kimball架构的DW/BI环境的组成
将DW/BI环境划分为4个不同的，各具特色的组成部分。它们分别是：操作型源系统、ETL系统、数据展现和商业智能应用。
书上的图.png
操作型源系统是记录的操作型系统，用于获取业务事务。可以认为源系统处于数据仓库之外，因为我们几乎不能控制这些操作系统中数据的格式和内容。这些源系统主要关注的事情是处理性能和可用性。源系统一般不维护历史信息。源系统是一种针对特定意图的应用，并未承诺要与组织中其他操作型系统共享诸如产品、客户、区域、日期这样的公共数据。适合于交叉应用的企业资源规划（Enterprise Resource Planning，ERP）系统或操作型主数据管理系统可用于解决这些问题。
DW/BI环境中获取、转换、加载（Extract Transformation and Load，ETL）系统*包括一个工作区间、实例化的数据结构以及一个过程集合。ETL系统是处于操作型源系统与DW/BI展现系统之间的区域。
获取是将数据从操作型系统导入数据仓库环境这一ETL过程的第一步。数据获取到ETL系统后，需要进行多种转换操作（如：清洗数据，合并来自不同数据源的数据，复制数据等。）ETL系统通过增强或数据变换，采用清洗和整合上述任务的方法，增加数据的利用值。
ETL最后的步骤是实际构建和加载数据到展现区域的目标维度模型中。由于ETL系统的主要任务是在交付过程中划分维度和事实，所以其包含子系统非常重要。当维度模型中的维度表和事实表被更新、索引、适当聚集，并确保良好质量后，业务用户就可以开始使用这些数据了。
DW/BI展现区用于组织、存储数据，支持用户、报表制作者以及其他分析型商业智能（BI）应用的查询。由于展现区后端的ETL是不允许用户直接进行查询的，所以DW/BI环境中的展现区成为用户关注的区域。业务团队可以在此通过访问工具和BI应用浏览和观察业务。获取数据实际上是包含维度模型的展现区的主要职责。
关于展现区，数据应该以维度模型来展现，要么采用星型模型，要么采用OLAP多维数据库。维度模型是为DW/BI用户发布数据的最可行的技术。必须包含详细的原子数据。为满足用户无法预期的、随意查询，必须使用原子数据。展现区中一定要包含最细粒度的数据，以便用户能够获得最准确的查询结果。
必须使用公共的、一致性的维度来建立维度结构。遵守总线结构是对展现区的最后一个要求。
注：建立规范化结构支持ETL过程是可以采用的方法。然而，这不是最终的目标。不能在用户查询中使用规范化结构，因为规范化结构难以同时满足可理解性和性能这两个目标。
网友评论