数据仓库--关系建模和维度建模

墨染丶eye

已于 2024-03-31 22:43:47 修改

阅读量351

点赞数 12

分类专栏：背诵文章标签：数据仓库大数据

于 2024-03-11 22:29:08 首次发布

本文链接：https://blog.csdn.net/a1473227656/article/details/136636470

版权

背诵专栏收录该内容

18 篇文章 1 订阅

订阅专栏

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

关系模型和多维模型

专业数据仓库面临的问题是数据仓库中数据库设计的基本模型选取问题，广泛采用的数据库设计模型有两种，关系型和多维型。

区别

	关系模型	维度模型
设计	纯数据模型和其他模型设计	最终用户的处理请求塑造
适用性	抽象数据形成，非常灵活，但是数据访问的执行不是最优化的，适合间接访问	直接访问数据方面是快速而高效，支持直接存取
抽象级别	具有非常高的抽象级别，可以满足多种需求	只能支持特定需求

关系模型

关系型数据库设计首先要创建一张数据表，表中每一行包含不同的列。关系表可以包含不同的属性，每一列表示不同的物理特征，不同的列可以索引并作为标识符，所有的列都是根据数据定义语言（DDL）标准定义的。
关系模型通过使用关键字和外间在不同行的数据间建立关联，自带一种结构化查询语言（SQL）,作为陈旭和数据间的接口而得到广泛应用。
关系型数据以一种称为标准化的形式存在。数据标准化是指数据库设计会使数据分解称为非常低的粒度级，当进行标准化时候，表中数据只能与这张表中的其他数据关联，标准化基本分为三级：第一级标准形式，第二级标准形式和第三级标准形式。

关系模型适用OLTP的原因

OLTP系统捕捉事件或交易的详细信息
OLTP系统关注独立的事件
一个OLTP系统是通向微观交易的窗口
反映运行业务所需要的细节信息
仅仅适用于回答交易级别的问题
数据一致性，非冗余性及高效的数据存储是最重要的

多维模型

维度模型的组成部分是从需求定义的信息包中演化而来的。维度提供了环境信息，如果没有环境信息，报表将显得毫无意义。成功的维度设计要点在于适当地使用键，维度列集合包含丰富的细节信息，摈弃节省存储空间的主张。

多维模型适合数据集市

捕捉关联指标
通过维度显示
面向商业用户

设计多维模型前的设计决策

选择处理过程，为设计的第一组逻辑结构从信息包里选择主题。
选择粒度，决定数据的详细程度。
识别维度，并统一纬度。
选择事实。
选择数据库的持久度。

维度建模基础

需要将商业维度合并到逻辑数据模型去，维度模型由表示商业维度需要的各种具体数据构成。这些数据结构也包含了指标和事实。
维度建模的数据实体：

指标或度量单位
商业维度
每一个商业维度的属性

维度建模需要达到的目标

模型应该为数据访问提供最好的方式。
整个模型必须以查询为中心。
必须为查询和分析而接受优化。
模型必须显示出事实表与维度表之间的相互作用
整个结构必须每个维度能够有相等的机会与事实表交互。
模型应该允许沿着维度层次结构下钻与上钻。

星型模型

多维模型方法也叫做星型连接，数据库设计多维模型方法的中心是星型连接。

星型模型的成员

事实表：处于星型连接的中心。事实表是包含大量数据值的一种结构。事实表名称来自于需要分析的主题。
维表：处于事实表的周围，用来描述事实表的某个重要方面，维表里的数据量要比事实表里的少。维度表属性由商业维度表示。

数据集市的查询结果

在数据集市运行查询时，查询结果是通过将一个或多个维度表与事实表结合之后产生的。事实表中的某一行与每个维度表的多行建立关系。可以清晰表示星型模型中的尖峰部分。

事实表的内容

事实表是我们存储指标的地方，保存级别尽可能低的细节。

连接事实表的主键，事实表中的一行记录与所有维度表中的相应记录相关
数据颗粒
完全加和指标，某些属性的数值可以通过简单的相加以汇总。
半加和指标，完全加和指标的衍生指标。
表很长但不一定宽，通常事实表包含的属性要比维度表少
稀疏的数据
退化的维度，某些数据元素不是事实也不是严格的维度属性，因为业务参考原因保留在事实表中

事实表与过程

事实表是度量业务过程的引擎。事实表存储用来描述过程的详细度量。事实采用外键为每个度量提供维度环境。单一的事实表很难描述某个主题区域，在维度设计时，为每个待处理的过程构建单个事实表，这种策略可以对每个过程单独开展分析工作，并且可以消除采用单个事实表涵盖多个过程带来的诸多复杂性的问题。同时一些强大的分析方法甚至可以跨越多个过程，在维度设计时，实现多过程分析需要从多个事实表中集成信息。
为方便于独立地分析研究，应为每个过程建立一个事实表

为每个过程构建自身的事实表来进行建模，是事实表构建的唯一真理

过程模型用于描述业务活动，关键在于过程建模设计功能分解，也就是说一个过程可以被分解成多个子过程。对于给定的两个事实，需要考虑这些事实同时发生与否，这些事实可用于同一个粒度与否。当连个事实对事件描述不再同一个时间点上，他们描述的就是不同的过程。
为将要独立研究的每个过程都构建一个事实表，但并不是每个事实表都对应一个过程。这类事实表通过获取多个事实表的数据形成，也会包含聚集数据。
当来个或更多的事实发生于不同的时间时，他们表示的是不同的过程，将他们呢放入同一事实表中将妨碍对单个过程的分析。
当描述事件的两个或者多个事实具有相同粒度时，他们描述的是不同的过程。维度可选关系，是否是不同的过程，主要看维度表是否可以影响事实表粒度改变。

从多个事实表中分析事实

对不同单一过程事实表进行比较也同样重要，一些强大的分析跨越了过程的边界。

在比较不同的事实表时，注意不要采用相同的SQL SELECT语句获取相关的事实，应该采用称为横向钻取包含两个步骤的过程来获得。
不要试图对事实表进行连接操作，无论操作时直接操作，还时通过维度表操作，对事实表的连接操作将会产生不正确的结果。

横向钻取

按照相同的细节层次从每个星型模式中汇总事实
合并汇总事实
无论是从结构还是从内容上考虑，在每个数据库中存在相同的公共维度非常关键。从结构上，在每个星型模式中需要有在第一阶段所需要的公共维度，从内容上，维度值需要有相同的表示方式以确保第二阶段对中间结果的合并操作。
很想钻取也可以应用到单一星型模式中，产生有用的比较结果。
实现横向钻取的四种方式

过程划分，针对每个星型模型执行一个查询，检索同样的维度，分别区级那一层上的事实，第二阶段在报表环境中完成，在此环境中合并结果集，产生最终的报表。
使用临时表，针对每个星型模型执行一个查询，存储于RDBMS临时表中，第二个阶段，附加的查询将存储的两个临时表通过RDBMS实现连接操作。
使用SQL相对较新的扩展功能实现
采用的工具不能执行横向钻取，可以设计并建立按照共同的细节层次汇总过程的合并事实表，采用合并事实表的方式执行钻取操作，应该数据仓库表被夹在期间执行，而不是在查询期间执行。

获取事实

获取所有的度量，事实表应该提供一个相关度量的完整集合，即使这样做会存在冗余，无论采用何种工具开发和查询报表，明确地存储每一个事实可以确保度量的一致性。注意：
- 不要在查询时计算总额这种类型值，在查询时开展计算工作会用到视图，这会妨碍对数据库管理系统查询执行的优化调整工作。
- 在事实表中存储延伸量，而最好不要存储数量单位。数量单位是对开展分析工作有兼职的维度，如果没有合适的维度表用于存储数量单位，可以将它们放置于退化维中。
非可加事实，并不是所有的度量都具有可加性，例如比率或者百分比。解决方案为将比率分解为可加的组件，将它们存储在事实表中，以便在查询或者报表中以需要的级别安全地聚集。由于非可加事实并为存储在事实表中，需要注意不要丢失这些事实。

不含事实的事实表

事实表能表示指标或者事实，然而即使事实表没有任何指标，一些商业事件也可以被事实表所表示。

稀疏性

记录在事实表中的行表达了业务活动的发生情况，这意味着，事实表中的行没有包含所有可能的维度值组合，出现在事实表中的组合数量远小于可能存在的组合数量，事实表的这项特性被称为稀疏性。

退化维

有时，不可能将所有与业务相关的维度分类到一个紧凑的表集合中。类似这样的情况，将一个或多个维度存储到事实表中是合适的选择。若采用这种方法，存储到事实表中的维度列被称为退化维度。但是需要避免过度使用退化维，如果一个属性不是事务标识，应考虑将其放置到杂项维度。虽然事务标识通常作为退化维度，但并不是必须遵循的规则。在一些情况中，事实表中事务标识的存储可能会给商业只能工具带来问题。

数据粒度

如果将事实表的数据保持在最低粒度，用户通过数据仓库可以下钻到最低次的细节数据，而且不需要访问操作型系统，事实表的基本层次必须是所有相应维度自然的最低层次，这样上钻与下钻的查询就可以高效执行。但是为了保持事实表有最低层次的数据颗粒，必须付出存储和维护方面的代价。

星型模型的键

主键

维度表每行都可以由维度表中的主键进行唯一的识别。
事实表:复合的主键，每一个部分对应一个维度
维度表:生成的主键
如果数据仓库包含了历史数据，假设由于产品存放到另外一个仓库，产品代码在某一年发生改变，我们就不得不改变数据仓库中产品代码。

替代键

维度表主键的选择原则:

避免维度表中主键有内在的含义
不要用生产系统中的键作为维度表的主键
替代键是系统生成的简单序列号码，没有任何含义。将生产系统的键作为维度表的附加属性。

外键

每个维度表都与中央的事实表有一对多的关系，所以，每个维度表中的主键必须是事实表中的外键。
事实表外键的选择:

一个单独的复合主键
连接的主键，由所有维度表的主键连接而成
一个生成的主键，所有外键都必须作为附加属性

星型模型的优势

严格的坚持这种模式并不是最好的选择，如果有多个最终用户的话。

用户容易理解，星型模型准确的反映了用户如何想的，他们在查询和分析时需要什么数据
优化浏览，即使寻找的查询结果看上去复杂，但是查询过程简单而直接。
最适合查询处理，如果不考虑查询中涉及的维的数量，也不考虑查询的复杂程度，实际上每一个查询都是简单的使用一些参数过滤维度表，然后从事实表中得到相应的结果集

星型连接和星型索引

星型连接是一种高速的，并行的，单独操作的多表连接，它可以通过一个单独的操作连接多个表，显著地提高查询性能。
星型索引是一种专门的索引，可以提高连接的性能，这些索引建立在事实表的一个或多个外键上，提高了维表与事实表的连接速度

聚集事实表

聚集是从低粒度的事实表衍生出来预先计算汇总的数据，这些汇总的数据形成了一组独立的聚集事实表。
可以将一个跨越任何维度数的特定的汇总构建为一个聚集事实表。
在一些典型情况下，最低粒度的事实表相当大
如果你不按产品保存细节信息，你就不会得到按照产品分类的结果集。
如果可以预先计算汇总数据，那么查询将运行的更快，如果有合适的聚集汇总数据，那么每一个查询的性能将大大提高。
聚集事实表将最低粒度的数据按照维度多层结构进行汇总，形成高层次数据。
多维数据库主要优势在于速度，并且不会受到SQL的限制，但是随着维度数量以及相应值的增加，需要预先计算的、可能产生的组合数量会爆炸性增长，这一情况限制了多维数据集对海量数据的处理能力，这一限制不可避免地见底了多维数据集的优势。星型模式和多维数据集可以共同使用，这样就可以利用关系数据库的可扩展能力来存储各种不同粒度的细节数据，利用这些细节数据，可以构建多维数据集来支持交互式查询体验。

星型模式与多维数据集共存的方式

星型模式作为原子数据的继承仓库，而多维数据集作为数据集市。
星型模式作为数据仓库或者数据集市，多维数据集作为高性能报表的辅助部分。
多路聚集事实表
单路聚集，如果从一个维度层次结构中的一个层次升到了更高的层次，而其他的维度保持在最低粒度。
二路聚集，如果从二个维度层次结构中的一个层次升到了更高的层次，而其他的维度保持在最低粒度。
三路聚集，如果从三个维度层次结构中的一个层次升到了更高的层次，而其他的维度保持在最低粒度。
多路聚集，如果从多个维度层次结构中的一个层次升到了更高的层次，而其他的维度保持在最低粒度。
聚集受稀疏性的影响
聚集的选项
在实例的情况中，维度表的数目不会有三个，而是多的多，甚至聚集表的数目会扩展到几百个。
聚集策略的目标:
不要陷在过多的聚集之中，要支持聚集，需要额外的衍生维度表。
尽量满足大量用户的需求，在任何情况下，都要为高级用户做好准备。
建立那些不会过分增加存储容量的聚集。对具有较低稀疏比例的大型聚集要注意。
对最终用户保持聚集的不可见性
尽量减少对数据准备过程的影响
聚集是一种调整性能的机制，要提高性能就要进行汇总。
做好准备工作，开始时候构建一些合理的聚集表，并在需要时做一些调整

星型模式族

一组相关的星型模式称为星型模式族
星型模式中的事实表共享维度表
多个星型模式中的维度表也可能共享一个星型模式中的事实表。

一组星型模式族中的表的分类

快照表与事务表，数据仓库中，有一类问题与单独事务在一段特定的时期中如何影响特定的账户有关，另一类问题则关注特定账户的余额或者某段时间时期结束时账户的总共余额，事务表回答第一类问题，快照表回答第二类问题
核心表与定制表，所有产品和服务与一个核心事实表相连，而每一个产品或服务与单独一个定制表相连。
支持企业价值链或者价值环，为价值链中每一个步骤构造一个事实表表及相应的一系列维度表。
使维度一致，一致的维度是从源系统中抽取的，解决了相互冲突的问题，完整的属性整合，使维度一致是数据仓库的一项基本需求。