Kimball维度建模技术
基本概念
- 收集业务需求与数据实现:开始维度建模工作前,项目组需要理解业务需求,以及作为基础的源数据实际情况,通过与业务代表交流来发现需求,用于理解他们基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。
- 协作维度建模研讨:维度模型应该由主题专家与企业数据管理代表设计而成。工作由数据建模者负责,但模型应该通过与业务代表开展一系列高级别交互讨论获得。维度模型不应该由那些不懂业务以及业务需求的人来设计,协作是成功的关键。
- 4步骤维度设计过程:
- 选择业务过程
- 声明粒度
- 确认维度
- 确定事实
- 业务过程:组织完成的操作型活动。
- 粒度:粒度用于确定某一事实表中的行表示什么。
- 描述环境的维度:维度提供围绕某一业务过程所涉及的“谁、什么、何处、何时、为什么、如何”等背景。
- 用于度量的事实:事实涉及来自业务过程事件的度量,基本上都是以数量值表示。
- 星型模式与OLAP多维数据库:星型模式是部署在关系型数据库管理系统之上的多维结构,主要包括事实表,以及通过主外键关系与之关联的维度表。联机分析处理(OLAP)多维数据库时是现在多维数据库之上的多维结构,它与关系型星型模式内容等价或者说来源于关系型星型模式。
- 方便地扩展到维度模型:维度模型对数据关系发生变化具有灵活的适应性。以下变化不会改变现存的BI查询或应用。
- 当事实与存在的事实表粒度一致时,可以创建新列。
- 通过建立新的外键列,可以将维度关联到已存在的事实表上,前提是维度列与事实表粒度保持一致。
- 可以在维度表上通过建立新列添加属性。
- 可以使事实表的粒度更原子化,方法是在维度表上增加属性,然后以更细粒度重置事实表,小心保存事实表以及维度表的列名。
事实表技术基础
- 事实表结构:发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中。事实表的设计完全依赖于物理活动,不受可能产生的最终报表的影响。事实表总是包含外键,用于关联与之相关的维度,也包含可选的退化维度键和日期时间戳。查询请求的主要目标是基于事实表开展计算和聚集操作。
- 可加、半可加、不可加事实:可加性度量可以按照与事实表关联任意维度汇总。半可加度量可以对某些维度汇总,但不能对所有维度汇总。一些度量是完全不可加,尽可能存储非可加度量的完全可加分量,并在计算出最终可加事实前,将这些分量汇总到最终的结果集合中。
- 事实表中的空值:事实表中可以存在空值,但是事实表的外键中不能存在空值。
- 一致性事实:如果某些度量出现在不同的事实表中,如果需要比较计算不同事实表中的事实,应保证针对事实的技术定义是相同的。
- 事务事实表:事务事实表的一行对应空间或者时间上某点的度量事件。事务事实表可以是稠密的也可以是稀疏的,因为仅当存在度量时才会建立行。度量数字事实必须与事务粒度保持一致。
- 周期快照事实表:周期快照事实表中的每行汇总了发生在某一标准周期,如某一天、某周、某月的多个度量事件。
- 累积快照事实表:累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。
- 无事实的事实表:某些事件仅仅记录一系列某一时刻发生的多维实体的事实表称为无事实的事实表。
- 聚集事实表或OLAP多维数据库:聚集事实表时对原子粒度事实表数据进行简单的数字化上卷操作,目的是为了提高查询性能。汇总而度量聚集OLAP多维数据库一般与关系类型聚集方法类似,但是OLAP多维数据库可以被商业用户直接访问。
- 合并事实表:通常将来自多个过程的,以相同粒度表示的事实合并为一个单一的合并事实表。特别适合那些经常需要共同分析的多过程度量。
维度表技术基础
- 维度表结构:每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键。维度表通常比较宽,是扁平型非规范表,包含大量低粒度文本属性。维度表属性是查询及BI应用的约束和分组定义的主要目标。
- 维度表代理键:维度表中会包含一个列,表示唯一主键。该主键不是操作系统的自然键,由于需要跟踪变化,因此若采用自然键,将需要多个维度行表示。维度表代理键一般是按照顺序分配的简单整数,以值1开始,当需要新键时自动加1,日期维度不需要遵守代理键规则。
- 自然键、持久键、超自然键:由于操作系统建立的自然键受业务规则的影响,无法被DW/BI系统控制。这个键称作自然键、持久键或者超自然键。
- 下钻:维度进行下钻。
- 退化维度:有时维度除了主键没有其他内容,或者内容已经被分布在事实表或者其他维度表中,这种维度被放入事实表中称为退化维度。
- 非规范化扁平维度:维度设计者需要抵制多年来操作型数据库设计所带来的的对规范化设计的要求,实现维度建模的双重目标:简化及速度。
- 多层次维度:多数维度包含不止一个自然层次。
- 文档属性的标识与指示器:令人迷惑的缩写、真假标识以及业务指标可以作为维度表中文本字词含义的补充解释。操作代码值所包含的意义应该分解成不同的表标识不同描述性维度属性的部分。
- 维度表中的空值属性:当给定维度行没有被全部填充时,或者当存在属性没有被应用到维度行时,将产生空值维度属性,推荐采用描述性字符代替空值。
- 日历日期维度:日历日期维度通常包含许多描述,例如周数、月份名称、财务周期、国家假日等。日期维度的主键可以更有意义,例如用一个整数表示YYYYMMDD而不是使用顺序使用的代理键。日期时间戳并不是维度表的外键,可以以单独列的形式存在。
- 扮演角色的维度:单个物理维度可以被事实表多次引用,每个引用连接逻辑上存在差异的角色维度。
- 杂项维度:事务型商业过程通常产生一系列混杂的、低粒度的标识和指示器。建立单独的将不同维度合并到一起的杂项维度。这些维度通常在一个模式中标记为事务型概要维度,不需要所有属性可能值的笛卡尔积,但应该值包含实际发生在源数据中的合并值。
- 雪花维度:但维度表中层次关系是规范的时,低粒度属性作为辅助表通过属性连接键连接到基本维度表,当这一过程包含多重维度表层次时,建立的多级层次结构被称为雪花模式。
- 支架维度:维度可包含对其他维度的引用。
使用一致性维度集成
- 一致性维度:当不同的维度表的属性具有相同的列名和领域内容时,称为维度表具有一致性。
- 缩减维度:缩减维度是一种一致性维度,由基本维度的列与行的自己构成。
- 跨表钻取:当每个查询的行头包含相同的一致性属性时,使不同的查询能够针对两个或者更多的事实表进行查询。
- 价值链:用于区分组织中主要业务过程的自然流程。
- 企业数据仓库总线架构:通过关注业务过程将DW/BI规划过程分解为可管理的模块,通过重用跨不同过程的标准化一致性维度发布实现集成。
- 企业数据仓库总线矩阵:矩阵行表示业务过程,列表示维度,矩阵中的点表示维度与给定的业务过程是否存在关联关系。
- 总线矩阵实现细节:扩展每个业务过程行以展示特定事实表或OLAP多维数据库。
- 机会/利益相关方矩阵:通过替换包含业务功能的维度列规划不同的矩阵,通过确定矩阵的点以表示那些业务功能与那些业务过程相关。
处理缓慢变化维的技术
- 类型0:原样保留:适合属性标记为原型的情况,或者日期维度的大多数属性。
- 类型1:重写
- 类型2:增加新行:在维度表中增加新行,新航采用修改的属性值。当发生类型2变化时,最少在维度行中增加三个额外列
- 行有效日期/时间戳列
- 行截止日期/时间戳列
- 当前行标识
- 类型3:增加新属性:将在维度表上增加新属性以保存原来的属性值,新属性值以变化类型1方法重写主属性。
- 类型4:微型维度:当维度中的一组属性快速变化时,将其划分为微型维度。变化类型4微型维度需要自己的唯一主键,基维度和微型维度主键从相关的事实表中获取。
- 类型5:增加微型维度以及类型1支架表:用于精确保存历史属性值,按照当前属性值,增加报表的历史事实。建立在微型维度之上,并嵌入当前类型1引用及维度中的微型维度。
- 类型6:增加类型1属性到类型2维度:在类型2的基础上,同时嵌入维度行属性当前类型1版本,因此事实行可以被过滤或分组。
- 类型7:双类型1和类型2维度:事实表可以被访问,通过建模为类型1维度仅仅展示最新属性值,建模为类型2维度展示最新的历史概要。维度的持久键和主代理键同时存在事实表上。
处理维度层次关系
- 固定深度位置的层次:层次级别作为维度表中的不同位置属性出现。
- 轻微参差不齐/可变深度层次:变换为固定深度位置设计,针对不同的维度属性确立最大深度,然后基于业务规则放置属性值。
- 具有层次桥接表的参差不齐/可变深度层次:采用构建桥接表的方式建模,桥接表对每个可能的路径保留一行,确保能够遍历所有层次的形式,采用标准SQL而不是特定的语言扩展来实现。
- 具有路径字符属性的可变深度层次:可以在维度中采用路径字符属性,以避免使用桥接表表示课表深度层次,对维度表中的每行,路径字符属性包含特定的嵌入文本字符,包含从层次最高节点到特定维度行所描述的节点的完成路径描述。
高级事实表技术
- 事实表代理键:代理键可以用作所有维度表的主键。此外,可以使用单列代理事实键可作用于
- 作为事实表的唯一主键列
- 在ETL中用作事实表行的直接标识符
- 允许将事实表更新操作分解为风险更小的插入和删除操作
- 属性或事实的数字值:如果数字值主要用于计算,则可能属于事实表。如果主要用于分组或者过滤,则应该将其定义为维度属性。某些情况下数字值既建模为维度又建模为属性时非常有益的。
- 日期/持续时间事实:累积快照事实表获取多个过程里程碑,每个都包含日期外键并可能包含日期/时间戳,商业用户通常希望分析这些里程碑之间的滞后以及延迟时间。根据过程开始时间点为每个度量步骤存储一个时间延迟。
- 头/行事实表:操作型交易系统通常包括事务头指针行,头指针行与多个事务行关联。采用头/行模式,所有头指针级别维度外键与退化维度应该被包含在行级别事实表。
- 分配的事实:头指针/行事务数据与对应的事实具有不同粒度这样的情况经常发生,应该尽量分配头指针事实,使基于业务所提供的规则划分为行级别,分配的事实可以按照所有维度进行分片并上钻操作。
- 利用分配建立利润与损失事实表:收入-开销=利润。理想地实现利润方程事实表应为原子收入事务事实粒度并包含许多开销项。因为这些表处于原子粒度,才能实现数字化上卷。
- 多种货币事实:以多种货币单位记录财务事务的事实行应该包含一对列,其中一列包含以真实币种表示的事实,另外一列包含同样的但是以整个事实表同一的单一标准币种表示的事实。
- 多种度量事实单位:将事实表以供人的标准度量单位存储,同时存储标准度量与其他度量的转换系数。转换系数必须存储在事实表行中以确保计算简单正确,并尽量降低查询复杂性。
- 年-日事实:在BI应用或者OLAP多维数据库中建立年-日矩阵,而不是在事实表中查出年-日事实。
- 多遍SQL避免事实表之间的连接:要采用跨钻的方式使用两个事实表,并对结果按照公共行头指针属性值,采用排序融合操作以产生真确的结果。
- 针对事实表的时间跟踪:存在三种基本事实表粒度,事务级别,周期快照,累积快照。在个别情况下,在事实表中增加行有效时间、行截止时间、当前行标识非常有用。
- 迟到的事实:用于新事实行的多数当前维度内容无法匹配输入行,通常发生在当事实行延迟产生时,在此情况下,当迟到度量事件出现时,必须搜索相关维度以发现有效的维度键。