精华内容
下载资源
问答
  • 2022-03-04 16:30:31

    对数据分析越来越深入,越来越发现数据标准化的重要性,再高明的数据分析技术,没有规范统一的数据仓库,也是“巧妇难为无米之炊”。遂从头再对数据仓库技术进行一边梳理。

    1. 维度建模理论概要

    1.1 维度设计的主要流程

    1.1.1 选择业务过程

    业务过程是组织完成的操作性活动,例如:获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。业务过程事件建立或获取性能度量,并转换成事实表中的事实。过程定义了特定的设计目标以及对粒度、维度、事实的定义。

    1.1.2 声明粒度

    粒度用于确定某一个事实表中的行表示什么。粒度声明是设计必须履行的合同。在选择维度或事实前必须声明粒度,某个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。

    原子粒度是最低级别的粒度。建议从关注原子级别粒度数据开始设计。同时,上卷汇总粒度对性能调整来说非常重要。针对不同的事实表粒度,要建立不同的物理表,在同一事实表中不要混用多种不同的粒度。

    1.1.3 确认维度

    维度提供围绕某一业务过程事件所涉及的“谁、什么、何处、何时、为什么、如何”等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性(这也是识别维度的重要依据)。当与跟定的事实表行关联时,任何情况下都应使维度保持单一值

    数据管理与维度表的开放是数据仓库建设的主要工作。

    1.1.4 确认事实

    事实涉及来自业务过程事件的度量,基本上都是以数量值表示。一个事实表行与按照事实表粒度描述的度量时间之间存在一对一的关系,事实表对应的是一个物理可观察的事件。所有事实只允许与声明的粒度保持一致。

    1.2 事实表技术基础

    1.2.1 事实表结构

    事实表中存储的是现实世界中所发生的操作性事件所产生的可度量数值。从最低级的原子粒度来看,事实表中一行记录对应现实世界中的一个度量事件。

    事实表的设计完全依赖于物理活动,不受可能产生的最终报表的影响。事实表总是包含外键,用于关联与之相关的维度,也包含可选的退化维度建和日期/时间戳。查询请求的主要目标是基于事实表开展计算和聚集操作。

    1.2.2 可加、半可加、不可加事实

    事实表中的数字度量可划分为三类:

    • 可加事实

    最灵活、最有用的事实是完全可加,可加性度量可以按照与事实表关联的任意维度汇总。

    • 半可加事实

    半可加度量可以对某些维度汇总,但不能对所有维度汇总。差额是常见的半可加事实。

    • 不可加事实

    不可加事实对所有的维度不可加,例如比率。

    1.2.3 事实表中的空值

    事实表中的度量值可以存在空值,因为所有的聚集函数(SUM、COUNT、MIN、MAX、AVG)均可以对空值进行计算。

    事实表的维度外键不能存在空值,否则会导致违反参照完整性的情况发生。关联的维度表必须用默认行(代理键)而不是空值外键表示未知的或无法应用的情况

    1.2.4 事实表的三种标准类型

    • 事务事实表

    事务事实表的一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表,这类健壮的维度确保对事务数据的最大化分片和分块。

    • 周期快照事实表

    周期快照事实表中的每行汇总了发生在某一个标准周期,如某一天、某周、某月的多个度量事件。粒度是周期性的,而不是个体事务。即使周期内没有活动发生,也会在事实表中为每个事实插入包含0或空值的行。周期快照事实表的一个典型的应用场景是库存

    • 累积快照事实表

    累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程(例如,履行订单或索赔过程)具有定义的开始点,标准中间过程,定义的结束点,它们在此类事实表中都可以被建模。通常在事实表中针对过程中的关键步骤都包含时间外键。累积快照事实表中的一行,对应某一具体的订单,当订单产生时会插入一行。但管道过程发生时,累积事实表行被访问并修改(这是很特别的)。

    1.3 维度表技术基础

    1.3.1 维度表结构

    每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键,当然,维度表行的技术定义应与事实表行完全对应。

    维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性。操作代码与指示器可作为属性对待,最强有力的维度属性采用冗长的描述填充。

    维度表属性是查询及BI应用的约束和分组定义的主要目标。报表的描述性标识通常是维度表属性领域值。

    1.3.2 维度代理键

    维度表中会包含一个列,表示唯一主键。该主键不是操作性系统的自然间。 维度主键通常是无意义的整型主键,是按顺序分配的简单整数,以值1开始,每次分配自动加1。但日期维度不需要遵守代理键规则。

    1.3.3 一致性维度

    当不同的维度表属性具有相同的列名和领域内容时,称维度表具有一致性。

    1.3.4 缓慢变化维度

    类型:

    1. 原样保留

    2. 重写

    3. 增加新行

    4. 增加新属性

    5. 增加微型维度

    6. 增加微型维度及类型1支架

    7. 增加类型1属性到类型2维度

    8. 双类型1和类型2维度

    更多相关内容
  • 数据仓库工具箱 维度建模权威指南(第3版) 数据仓库建模经典之作,构建数据仓库必看!
  • 数据仓库维度建模培训ppt
  • 数据仓库维度建模

    2018-07-30 09:14:46
    数据仓库建模方法种类较多,常见的三种是范式建模、维度建模、实体建模,每种方法本质上都是从不同的角度解决业务中的问题。
  • 数据仓库维度建模笔记 2009-03-24 20:01 数据仓库工具箱维度建模的完全指南是数据仓库建模方面的经典著作 1996年第一版出版被认为是数据仓库方面具有里程碑意义的事件作者kimballl是数据仓库方面的权威他将多年的...
  • 数据仓库维度建模; 目录 1.基础术语 2.维度建模中的两种模型 3.星形模型设计 4.雪花模型设计 5.星形模型的优势 6.雪花模型的优势与劣势 ;1基础术语;1基础术语;1基础术语;2维度的两种模型;星形模型(Star Schema;雪花...
  • 数据仓库维度建模.ppt

    2021-09-15 20:26:21
    数据仓库维度建模.ppt
  • 数据仓库维度建模建设步骤

    千次阅读 2020-08-04 22:22:45
    一、数据仓库的架构 数据仓库(Data Warehouse DW)是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库,它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题...

    一、数据仓库的架构

    数据仓库(Data Warehouse DW)是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库,它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题的,以OLAP系统的分析需求为目的。

    数据仓库的架构模型包括了星型架构(图二:pic2.bmp)与雪花型架构(图三:pic3.bmp)两种模式。如图所示,星型架构的中间为事实表,四周为维度表,类似星星;而相比较而言,雪花型架构的中间为事实表,两边的维度表可以再有其关联子表,从而表达了清晰的维度层次关系。

    从OLAP系统的分析需求和ETL的处理效率两方面来考虑:星型结构聚合快,分析效率高;而雪花型结构明确,便于与OLTP系统交互。因此,在实际项目中,我们将综合运用星型架构与雪花型架构来设计数据仓库。

    那么,下面我们就来看一看,构建企业级数据仓库的流程。

    二、构建企业级数据仓库五步法

    (一)、确定主题

    即确定数据分析或前端展现的主题。例如:我们希望分析某年某月某一地区的啤酒销售情况,这就是一个主题。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑。

    我们可以形象的将一个主题想象为一颗星星:统计数值型数据(量度)存在于星星中间的事实表;分析角度(维度)是星星的各个角;我们将通过维度的组合,来考察量度。那么,“某年某月某一地区的啤酒销售情况”这样一个主题,就要求我们通过时间和地区两个维度的组合,来考察销售情况这个量度。从而,不同的主题来源于数据仓库中的不同子集,我们可以称之为数据集市。数据集市体现了数据仓库某一方面的信息,多个数据集市构成了数据仓库。

    (二)、确定量度

    在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总,或者将该数据取次数、独立次数或取最大最小值等,这样的数据称为量度。

    量度是要统计的指标,必须事先选择恰当,基于不同的量度可以进行复杂关键性能指标(KPI)等的设计和计算。

    (三)、确定事实数据粒度

    在确定了量度之后,我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。考虑到量度的聚合程度不同,我们将采用“最小粒度原则”,即将量度的粒度设置到最小。

    例如:假设目前的数据最小记录到秒,即数据库中记录了每一秒的交易额。那么,如果我们可以确认,在将来的分析需求中,时间只需要精确到天就可以的话,我们就可以在ETL处理过程中,按天来汇总数据,此时,数据仓库中量度的粒度就是“天”;反过来,如果我们不能确认将来的分析需求在时间上是否需要精确到秒,那么,我们就需要遵循“最小粒度原则”,在数据仓库的事实表中保留每一秒的数据,以便日后对“秒”进行分析。

    在采用“最小粒度原则”的同时,我们不必担心海量数据所带来的汇总分析效率问题,因为在后续建立多维分析模型(CUBE)的时候,我们会对数据提前进行汇总,从而保障产生分析结果的效率。关于建立多维分析模型(CUBE)的相关问题,我们将在下期栏目中予以阐述。

    (四)、确定维度

    维度是指分析的各个角度。例如我们希望按照时间,或者按照地区,或者按照产品进行分析,那么这里的时间、地区、产品就是相应的维度。基于不同的维度,我们可以看到各量度的汇总情况,也可以基于所有的维度进行交叉分析。

    这里我们首先要确定维度的层次(Hierarchy)和级别(Level)(图四:pic4.bmp)。如图所示,我们在时间维度上,按照“年-季度-月”形成了一个层次,其中“年”、“季度”、“月”成为了这个层次的3个级别;同理,当我们建立产品维度时,我们可以将“产品大类-产品子类-产品”划为一个层次,其中包含“产品大类”、“产品子类”、“产品”三个级别。

    那么,我们分析中所用到的这些维度,在数据仓库中的存在形式是怎样的呢?

    我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度;我们也可以使用三张表,分别保存产品大类、产品子类、产品三部分数据,比如产品维度。(图五:pic5.bmp)

        另外,值得一提的是,我们在建立维度表时要充分使用代理键。代理键是数值型的ID号码(例如图六中每张表的第一个字段),它唯一标识了每一维度成员。更重要的是,在聚合时,数值型字段的匹配和比较,JOIN效率高,便于聚合。同时,代理键对缓慢变化维度有着重要的意义,在原数据主键相同的情况下,它起到了对新数据与历史数据的标识作用。

    在此,我们不妨谈一谈维度表随时间变化的问题,这是我们经常会遇到的情况,我们称其为缓慢变化维度。

    比如我们增加了新的产品,或者产品的ID号码修改了,或者产品增加了一个新的属性,此时,维度表就会被修改或者增加新的记录行。这样,我们在ETL的过程中,就要考虑到缓慢变化维度的处理。对于缓慢变化维度,有三种情况:

    1、缓慢变化维度第一种类型:历史数据需要修改。这种情况下,我们使用UPDATE方法来修改维度表中的数据。例如:产品的ID号码为123,后来发现ID号码错了,需要改写成456,那么,我们就在ETL处理时,直接修改维度表中原来的ID号码为456。

    2、缓慢变化维度第二种类型:历史数据保留,新增数据也要保留。这时,要将原数据更新,将新数据插入,我们使用UPDATE / INSERT。比如:某一员工2005年在A部门,2006年时他调到了B部门。那么在统计2005年的数据时就应该将该员工定位到A部门;而在统计2006年数据时就应该定位到B部门,然后再有新的数据插入时,将按照新部门(B部门)进行处理,这样我们的做法是将该维度成员列表加入标识列,将历史的数据标识为“过期”,将目前的数据标识为“当前的”。另一种方法是将该维度打上时间戳,即将历史数据生效的时间段作为它的一个属性,在与原始表匹配生成事实表时将按照时间段进行关联,这种方法的好处是该维度成员生效时间明确。

    3、缓慢变化维度第三种类型:新增数据维度成员改变了属性。例如:某一维度成员新加入了一列,该列在历史数据中不能基于它浏览,而在目前数据和将来数据中可以按照它浏览,那么此时我们需要改变维度表属性,即加入新的字段列。那么,我们将使用存储过程或程序生成新的维度属性,在后续的数据中将基于新的属性进行查看。

    (五)、创建事实表

    在确定好事实数据和维度后,我们将考虑加载事实表。

    在公司的大量数据堆积如山时,我们想看看里面究竟是什么,结果发现里面是一笔笔生产记录,一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据,即关于某一主题的事实记录表。

    我们的做法是将原始表与维度表进行关联,生成事实表(图六:pic6.bmp)。注意在关联时有为空的数据时(数据源脏),需要使用外连接,连接后我们将各维度的代理键取出放于事实表中,事实表除了各维度代理键外,还有各量度数据,这将来自原始表,事实表中将存在维度代理键和各量度,而不应该存在描述性信息,即符合“瘦高原则”,即要求事实表数据条数尽量多(粒度最小),而描述性信息尽量少。

    如果考虑到扩展,可以将事实表加一唯一标识列,以为了以后扩展将该事实作为雪花型维度,不过不需要时一般建议不用这样做。

    事实数据表是数据仓库的核心,需要精心维护,在JOIN后将得到事实数据表,一般记录条数都比较大,我们需要为其设置复合主键和索引,以实现数据的完整性和基于数据仓库的查询性能优化。事实数据表与维度表一起放于数据仓库中,如果前端需要连接数据仓库进行查询,我们还需要建立一些相关的中间汇总表或物化视图,以方便查询。

    三、什么是ETL

    在数据仓库的构建中,ETL贯穿于项目始终,它是整个数据仓库的生命线,包括了数据清洗、整合、转换、加载等各个过程。如果说数据仓库是一座大厦,那么ETL就是大厦的根基。ETL抽取整合数据的好坏直接影响到最终的结果展现。所以ETL在整个数据仓库项目中起着十分关键的作用,必须摆到十分重要的位置。

    ETL是数据抽取(Extract)、转换(Transform)、加载(Load )的简写,它是指:将OLTP系统中的数据抽取出来,并将不同数据源的数据进行转换和整合,得出一致性的数据,然后加载到数据仓库中。例如:下图就向我们展示了ETL的数据转换效果。(图七:pic7.bmp)

    那么,在这一转换过程中,我们就完成了对数据格式的更正、对数据字段的合并、以及新增指标的计算三项操作。类似地,我们也可以根据其他需求,完善数据仓库中的数据。

    简而言之,通过ETL,我们可以基于源系统中的数据来生成数据仓库。ETL为我们搭建了OLTP系统和OLAP系统之间的桥梁。

     

    五、项目实践技巧

    (一)、准备区的运用

     在构建数据仓库时,如果数据源位于一台服务器上,数据仓库在另一台服务器端,考虑到数据源Server端访问频繁,并且数据量大,需要不断更新,所以可以建立准备区数据库(图八:pic8.bmp)。先将数据抽取到准备区中,然后基于准备区中的数据进行处理,这样处理的好处是防止了在原OLTP系统中频繁访问,进行数据运算或排序等操作。

    例如我们可以按照天将数据抽取到准备区中,基于数据准备区,我们将进行数据的转换、整合、将不同数据源的数据进行一致性处理。数据准备区中将存在原始抽取表、转换中间表和临时表以及ETL日志表等。

    (二)、时间戳的运用

    时间维度对于某一事实主题来说十分重要,因为不同的时间有不同的统计数据信息,那么按照时间记录的信息将发挥很重要的作用。在ETL中,时间戳有其特殊的作用,在上面提到的缓慢变化维度中,我们可以使用时间戳标识维度成员;在记录数据库和数据仓库的操作时,我们也将使用时间戳标识信息。例如:在进行数据抽取时,我们将按照时间戳对OLTP系统中的数据进行抽取,比如在午夜0:00取前一天的数据,我们将按照OLTP系统中的时间戳取GETDATE到GETDATE减一天,这样得到前一天数据。

    (三)、日志表的运用

    在对数据进行处理时,难免会发生数据处理错误,产生出错信息,那么我们如何获得出错信息并及时修正呢? 方法是我们使用一张或多张Log日志表,将出错信息记录下来,在日志表中我们将记录每次抽取的条数、处理成功的条数、处理失败的条数、处理失败的数据、处理时间等等。这样,当数据发生错误时,我们很容易发现问题所在,然后对出错的数据进行修正或重新处理。

    (四)、使用调度

    在对数据仓库进行增量更新时必须使用调度(图九:pic9.bmp),即对事实数据表进行增量更新处理。在使用调度前要考虑到事实数据量,确定需要多长时间更新一次。比如希望按天进行查看,那么我们最好按天进行抽取,如果数据量不大,可以按照月或半年对数据进行更新。如果有缓慢变化维度情况,调度时需要考虑到维度表更新情况,在更新事实数据表之前要先更新维度表。

    调度是数据仓库的关键环节,要考虑缜密。在ETL的流程搭建好后,要定期对其运行,所以调度是执行ETL流程的关键步骤。每一次调度除了写入Log日志表的数据处理信息外,还要使用发送Email或报警服务等,这样也方便的技术人员对ETL流程的把握,增强了安全性和数据处理的准确性。

    五、总结

    构建企业级数据仓库需要简单的五步,掌握了这五步的方法,我们可以构建一个强大的数据仓库。然而,每一步都有很深的内容需要研究与挖掘,尤其在实际项目中,我们要综合考虑。例如:如果数据源的脏数据很多,在搭建数据仓库之前我们首先要进行数据清洗,以剔除掉不需要的信息和脏数据。

    ETL是OLTP系统和OLAP系统之间的桥梁,是数据从源系统流入数据仓库的通道。在数据仓库的项目实施中,它关系到整个项目的数据质量,所以马虎不得,必须将其摆到重要位置,将数据仓库这一大厦的根基筑牢!

    展开全文
  • 农作物信息数据仓库维度建模初探,周志艳,罗锡文,本文根据维度建模的一般方法,结合农作物空间信息数据的特点,给出了农作物信息数据仓库的维度模型,包括该数据仓库的总线矩阵、
  • 一、 事实表相关概念 1、 粒度 1.1 什么是粒度 事实表中一条记录说表达的业务细节程度...(2)半可加事实:只能按照特定的维度进行汇总,不能对所有维度汇总。一般对于不可加性事实需要分解为可加的事实放到事实表(事

    一、 事实表相关概念
    1、 粒度
    1.1 什么是粒度
    事实表中一条记录说表达的业务细节程度被称为粒度。
    1.2 两种常用表现形式
    (1)使用维度属性组合来表示的细节程度。
    (2)表示的具体的业务含义。

    1. 事实
      2.1 什么是事实
      业务过程中具体的度量值称为事实,比如发货数量、支付金额等。
      2.2 三种类型的事实(根据是否可加分类)
      (1)可加事实:可以按照与事实表关联的任意维度进行汇总。
      (2)半可加事实:只能按照特定的维度进行汇总,不能对所有维度汇总。一般对于不可加性事实需要分解为可加的事实放到事实表(事务事实表)中,比如,折扣率,需要转化为具体的折扣金额放到事实表中。
      (3)不可加事实:对任务维度都不可加。一般是某些状态值。

    二、事实表设计原则
    1、尽可能包含所有与业务过程相关的事实。
    2、只选择与业务过程相关的事实。
    3、分解不可加性事实为可加的组件。
    4、在选择维度和事实之前必须先声明粒度。根据经验建议从最低级别的原子粒度开始,这样可以提供最大限度的灵活性,可以支持无法预测的各种细节层次的用户需求。
    5、在同一个事实表中不能有多种不同粒度的事实,防止出现事实重复计算的问题。
    6、同一张事实表的事实的单位要保持一致,如下单金额,优惠金额,需使用同一个单位(元或者美元)。
    7、对事实的null值要处理,防止SQL过滤条件都不生效,一般用0填充。
    8、使用退化维度提高事实表的易用性。根据经验建议将常用的维度信息退化到事实表中,减少关联维表的操作,提高效率。

    三、事实表总体设计方法和步骤
    1、选择业务过程及确定事实表类型。(必须)明确业务需求,需求分析,对业务整个生命周期进行分析,明确关键的业务步骤,选择与需求有关的业务过程。
    2、声明粒度。(必须)精确定义事实表的每一行所表示的业务含义。
    3、确定维度。(必须)
    4、确定事实。(必须)
    5、冗余维度(维度退化)。(可选)减少关联表的数量,提高效果,降低获取数据的复杂性

    四、三种常见事实表及其设计步骤
    4.1、事务事实表(一般放在dwd层)
    用于直接描述业务过程,跟踪空间或者时间上的某点的度量事件,保存的是最原子的数据。
    4.1.1、常见的两种事务事实表
    4.1.1.1、单事务事实表
    每个业务过程设计一个事实表。
    优点:方便对每个业务过程进行独立的分析研究
    4.1.1…2、多事务事实表
    将不同的事实放到同一个事实表中,即同一个事实表包含不同的业务过程。
    两种实现方式:
    (1)将不同业务过程的事实使用不同的事实字段进行存放,不是当前业务过程的度量,则采取零值处理方式。
    (2)将不同的业务过程的事实使用同一个事实字段进行存放,同时增加一个业务过程标签。
    4.1.2、设计步骤参考总体设计方法和步骤。

    4.2、周期快照事实表(一般放在dws层)
    有规律性,可预见的时间间隔记录事实,聚集与之相关的事务进行识别计算,如每天,每月,每年等。
    4.2.1、特点
    (1)粒度通常以维度(一个或者多个)形式声明。
    (2)相对事务事实表是稀疏的,快照事实表是稠密的(其实就是全量表,事务事实表是增量表)。
    (3)事务事实表中的事实是完全可加的,快照事实表至少包含一个用来展示半可加性质的事实。
    4.2.2、两种类型
    (1)单维度的快照事实表:针对单个维度进行采样。
    (2)混合维度的快照事实表:针对多个维度进行采样。
    4.2.3、设计步骤
    (1)确定快照事实表的快照粒度
    通常是某个维度或者多个维度加上采样周期,比如针对卖家每天汇总事实表,记录历史至今的下单金额等状态量。
    (2)确定状态度量
    比如淘宝卖家历史至今汇总事实表,包含了历史截至当日的下单金额、历史截至当日的支付金额等度量,近7天,近一周,近一个月等。
    4.2.4、数据来源
    (1)对事务事实表进行汇总
    (2)直接使用操作型系统的数据作为周期快照事实表的数据源进行加工,比如某个时刻的温度
    4.2.5、注意事项
    (1)事务与快照成对设计,快照事实表基于事务事实表加工得到,以满足更多的下游统计分析需求。
    (2)附加事实:在表上附加一些上一个采样周期的状态度量,从而避免多次使用快照事实表。
    (3)周期到日期度量:尽可能多的增加多种周期到日期的度量,比如淘宝卖家财年至今的下单金额、淘宝商品自然年至今的收藏次数等。

    4.3、累积快照事实表(一般放在dws层)
    表述业务过程开始和结束之间的关键步骤事件,覆盖过程的的整个生命周期,通常具有多个日期字段来记录关键时间点,当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改。
    4.3.1、设计步骤 (建模过程和事务事实表相同,适用于维度建模的步骤,有点细微的差别)
    (1)选择业务过程:一般会同时涉及到多个业务过程。
    (2)确定粒度:相对于事务事实表,每个事件会产生一行记录,对于多事件事实表也是,而对于累积快照事实表,一般只保留一行记录,但事件发生时,对此行记录进行更新。
    (3)确定维度:关键事件生发的日期属于维度而不是事实。
    (4)确定事实:因为涉及到多个业务过程,需要将各个业务过程对应的事实均放入到事实表中;
    累积快照事实表解决的最重要的问题是统计不同业务过程之间的时间间隔,建议将每个过程的时间间隔作为事实放在事实表中。
    (5) 退化维度
    4.3.2、物理实现方式
    (1) 全量表的形式
    此全量表一般为日期分区表,每天的分区存储昨天的全量数据和当天的增量数据合并的结果,保证每条记录的状态最新。
    (2)全量表的变化形式
    根据业务实际情况,确定一个业务实体从产生到结束的时间间隔,每天的分区存储这个时间间隔的数据,历史数据则归档到归档分区中。
    (3)以业务实体的结束时间分区
    每天的分区存放当天结束的数据,未结束的数据则放到一个时间非常大的分区中,这样可以保证粒度全局唯一

    4.4、三种事实表的比较
    1、时期/时间角度
    2、日期维度
    3、粒度
    4、事实
    5、事实表加载
    6、事实表是否更新

    展开全文
  • 浅谈数据仓库维度建模流程 谈到Big Data就离不开数据仓库、数据集市等概念,而谈到数据仓库、数据集市,就又离不开数据仓库设计的方法,维度建模则是其中的典型。与维度建模相对立的则是范式建模,范式建模常用于...

    浅谈数据仓库维度建模流程

    谈到Big Data就离不开数据仓库、数据集市等概念,而谈到数据仓库、数据集市,就又离不开数据仓库设计的方法,维度建模则是其中的典型。与维度建模相对立的则是范式建模,范式建模常用于传统的DB关系型数据库中。范式建模讲究三范式,讲究原子性,一致性,隔离性,持久性。讲究最小原子列不可再分,讲究消除部分依赖,y=f(x),y依赖于x,且x的任一真子集x’不满足对应唯一y。讲究消除传递依赖,当x---->y(y!------>x),z------>x(x!------>z)时则不满足3FN。而维度建模则是与之相对,维度建模不讲究范式,不讲究关系型,不讲究事务,讲究主题域,讲究总线矩阵,讲究维度和事实,讲究…

    附上之前所画一张流程图
    在这里插入图片描述
    之前画此图时是在前辈的帮助下画出,但也是一知半解,其中很多东西不能完全理解,直至现在也是大概明白其中流程,但更多细节值得深入学习。今日不谈后面的ETL过程、数据治理等,就谈谈前期的维度建模。近日又购得Kimball的维度建模,和阿里大数据之路二书,希望能够沉下心深入学习,数据产品要想打造的好,令人满意,则数据内容一定要质量过关。数据内容过关了,面对怎样的数据产出都会有自信,自己的数据没有问题。

    维度建模以用户的可理解性和查询性能为目标,建立始终如一服务于组织的分析需求设计。维度建模是DW/BI系统项目成功的关键。是一种趋向于最终用户对数据仓库进行查询的设计技术,是围绕性能和易理解性构建的。

    谈到维度建模则一定要说到两个较为核心的概念则是维度和事实。维度表和事实表经常听说,那能否对维度和事实有个更好的定义呢。
    事实:既成事实,表示对业务数据的度量,事实很多时候是数字类型的,可以进行计算和聚合。维度:观察数据事物的角度,维度通常是一组层次关系或者描述信息,用来定义事实。

    维度建模最开始要定好主题域,而建立主题域更多时候按业务流程来建立。不同的主题域可能共享一些维度,则这些维度也称为一致性维度。术语“一致性维度”源自Kimball,指的是具有相同属性和内容的维度,拥有这些一致性维度,可以提高数据操作的性能和数据一致性,如几个主题域之间共享维度的复制。维度建模将客观世界划分为度量和上下文,维度建模按照业务流程即主题域建立。

    维度数据模型建模过程
    1.选择业务流程
    确认哪些业务处理流程是数据仓库应该涵盖到的,也是第一步的基础。比如要设计一家公司的销售情况,则与该公司的销售相关的业务流程都应该关注到,然后描述业务流程(如何描述也是一个问题BPMN?UML?),这个时候产出可以有业务流程图。

    2.声明粒度
    再确认哪些业务流程应该是涵盖到的之后,则应该声明粒度,声明粒度应该在确认维度和事实之前,因为只有先定义好粒度后面的维度和事实才能与定义的粒度保持一致,(他们说)一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。这里的粒度用于确认事实中表示的是什么,要定义好粒度大小。在给定业务获取数据时,原始粒度是最低级别的粒度,(他们说)建议从原始粒度数据开始设计,因为原始记录能够满足无法预期的用户查询。轻汇总和重度汇总后的数据粒度对优化查询性能很重要,但这样的粒度设计往往不能满足对细节数据的查询需求。不同的事实可以有不同的粒度,但同一事实中也不要混用多种不同的粒度。

    3.确认维度
    确认模型的维度是第三步,维度的粒度需要和第二步声明的粒度保持一致。维度表是事实表设计的基础。典型的维度都是名称(标签),如日期、商店、用户等。维度表存储了某一维度所有相关的数据。例如日期维度应该包含年、季、月、周等。城市维度表包含所有城市等。

    4.确认事实
    最后一步则是确认事实,这一步识别数字化的度量,构成事实表的记录。用户可直接通过事实表的访问获取数据仓库存储的数据。大部分事实表的度量都是数字类型的,可进行计算。

    星型模型和雪花模型
    谈到维度建模也不能不谈到星型模型和雪花模型了。之前一直以为两者差不多,雪花模型不过是星型模型的拓展而已。最近才发现二者思想挺不一样的。星型模型(容易想到一星四射)事实表关联维度表,维度表与维度表之间没有关联,这样的设计,冗余大(秉持着能用钱解决的问题都不是问题的原则,这一点反而被鼓励),查询快,扩展性差,是反规范化数据。而雪花模型是把星型模型中的维度表进行规范化处理,进一步分解到附加表中。把维度表规范化的具体做法:把低基数的属性从从维度表中移除并形成单独的表。(性别属于低基数,主键具有唯一值是高基数)在雪花模式中,一个维度被规范化成多个关联的维度表,而在星型模式中,每一个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表,而事实表作为雪花模式的子表,存在具有层次关系的多个父表。

    星型模型和雪花模型的对比
    1.数据优化
    星形模型:实用的是反规范化数据。在星形模型中,维度直接指的是事实表,业务层级不会通过维度之间的参照完整性来部署。不能保证数据完整性,一次性地插入或更新操作可能会造成数据异常。对于分析需求不够灵活。它更偏重于为特定目的建造数据视图。
    雪花模型:使用的是规范化数据,也就是说数据在数据库内部是组织好的,以便消除冗余,因此它能够有效地减少数据量。通过引用完整性,其业务层级和维度都将存储在数据模型之中。规范化后的多层次维度表,可以很方便支持业务实体多对多关系,很容易进行全面的数据分析。
    2.业务模型
    星型模型:主键是一个单独的唯一键(数据属性),为特殊数据所选择。外键(参考属性)仅仅是一个表中的字段,用来匹配其他维度表中的主键。
    雪花模型:数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中,所有必要的维度表在事实表中都只拥有外键。
    3.性能
    星型模型:星形模型在维度表、事实表之间的连接较少,所以简化了查询,相应的简化了业务报表的逻辑。获得查询性能、能更快速的进行聚合。
    雪花模型:雪花模型在维度表、事实表之间的连接很多,因此性能方面会比较低。举个例子,如果你想要知道Advertiser 的详细信息,雪花模型就会请求许多信息,比如Advertiser Name、ID以及那些广告主和客户表的地址需要连接起来,然后再与事实表连接。(但是,规范化的维度属性可以节省存储空间。)
    4.ETL
    星型模型:星形模型加载维度表,不需要再维度之间添加附属模型,因此ETL就相对简单,而且可以实现高度的并行化。
    雪花模型:雪花模型加载数据集市,因此ETL操作在设计上更加复杂,而且由于附属模型的限制,不能并行化。
    5.总结
    星型模型:星形模型用来做指标分析更适合,比如“给定的一个客户他们的收入是多少?
    雪花模型:雪花模型使得维度分析更加容易,比如“针对特定的广告主,有哪些客户或者公司是在线的?”

    部分名词:
    总线矩阵的必要性
    企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构,如果我们在建立数据仓库的时候,只考虑单独的某个业务系统的数据建设,则无法满足一致性的目标,例如:相互有联系的系统数据的维度不同导致关联复杂或者关联不上,数据之间互相成为了孤岛,对于后期的扩展或者整个数仓的建设都是巨大的阻碍。
    总线矩阵举例:
    那么总线矩阵就给我们提供了这么一个工具,每一行是一个业务过程,每一列是这个业务过程可能涉及到的一些维度,比如说上图中的零售业务过程,这块涉及到的公用维度包括:日期维度,产品维度,商店维度,促销维度,客户维度,雇员(销售员)维度。
    再看仓库库存业务过程,包含了日期维度,产品维度,仓库维度。
    通过日期维度或者产品维度或者仓库维度,我们可以将每天的某种商品的库存数据和销售数据关联起来进行分析,这就是一致性维度的好处,假设这两部分数据没有经过提前规划,各部分数据都有不同的维表,那这两部分数据想要联系起来太难了。

    退化维度
    退化维度的维度表可以被剔除,从而简化维度数据仓库的模式。因为简单的模式比复杂的更容易理解,也有更好的查询性能。
    当一个维度没有数据仓库需要的任何数据时就可以退化此维度。需要把退化维度的相关数据迁移到事实表中,然后删除退化的维度。
    维度属性也可以存储到事实表中,这种存储到事实表中的维度列被称为“退化维度”。与其他存储在维表中的维度一样 ,退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。那么究竟怎么定义退化维度呢?比如说订单id,这种量级很大的维度,没必要用一张维度表来进行存储,而我们进行数据查询或者数据过滤的时候又非常需要,所以这种就冗余在事实表里面,这种就叫退化维度,citycode这种我们也会冗余在事实表里面,但是它有对应的维度表,所以它不是退化维度。
    kimball书中描述退化维度如下:操作型事务控制号码,例如:订单号码、发票号码、提货单号码通常产生空的维度并且宝石为事务事实表中的退化维度。退化维度是没有对应维度表的维度键。
    维度退化在事实表中有利于使用,一般一个维度键都有对应的维表,如果退化在事实表中,可以减少关联次数,并且退化维可以用于group by操作,进行分组统计。
    还可以这么理解:就是这个东西没有对应的维表,没有修饰它的属性,但是呢,通过它你可以获取一些内容,一些事实,比如说订单编号,你可以获得这个订单里面包含哪些商品,对应的付款人是谁之类的。

    缓慢变化维:维度建模的数据仓库中,有一个概念叫Slowly Changing Dimensions,中文一般翻译成“缓慢变化维”,经常被简写为SCD。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维,并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题,有时也简称为处理SCD的问题。
    处理缓慢变化维的方法通常分为三种方式:
    第一种方式是直接覆盖原值。这样处理,最容易实现,但是没有保留历史数据,无法分析历史变化信息。第一种方式通常简称为“TYPE 1”。
    第二种方式是添加维度行。这样处理,需要代理键的支持。实现方式是当有维度属性发生变化时,生成一条新的维度记录,主键是新分配的代理键,通过自然键可以和原维度记录保持关联。第二种方式通常简称为“TYPE 2”。
    第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列,来记录该属性变化前的值,而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值,缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE 3”。
    在实际建模中,我们可以联合使用三种方式,也可以对一个维度表中的不同属性使用不同的方式,这些,都需要根据实际情况来决定,但目的都是一样的,就是能够支持方便的分析历史变化情况。

    维度建模对数据内容的建设,思想大于技术,思想引导技术。目前大部分理解来源书本、文章、讲解。来自项目实战、自己经验的部分少之又少、很多时候只是一个别人思想、别人文章、别人技术、别人讲解的搬运工、尚不能理解搬运的财富。望后面能有自己的理解。

    展开全文
  • 数据仓库-维度建模

    2021-08-16 21:13:04
    数据仓库定义 数据仓库和数据库 维度建模 维度建模 VS 第三范式 维度建模设计过程 事实概念 事实表技术 维度概念 维度表技术 数据仓库定义 数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据...
  • 数据仓库建模--维度建模
  • 数据仓库维度建模

    2022-06-13 18:55:02
    数据仓库
  • ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT THUNISOFT ESENSOFT T
  • 文章目录1. 维度建模基本概念1.1. 维度表(dimension)1.2. 事实表(fact table)2. 维度建模三种模式2.1...维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解...
  • 大数据-数据仓库维度建模

    千次阅读 2019-05-15 11:09:22
    数据仓库维度建模一、维度建模(dimensional modeling)1. 维度表(dimension)2. 事实表(fact table)二、维度建模的三种模式1. 星形模式(Star Schema)2. 雪花模式(Snowflake Schema)3. 星座模式(Fact Constellations ...
  • 数据仓库维度建模

    2018-02-02 10:20:34
    此书翻译于国外经典全为教材、通俗易懂、知识体系完善、案例丰富、循序渐进、适合初学者适用。
  • 自己更具实际业务整理的数据仓库-维度建模知识点 自己更具实际业务整理的数据仓库-维度建模知识点 自己更具实际业务整理的数据仓库-维度建模知识点 自己更具实际业务整理的数据仓库-维度建模知识点
  • 第一章:数仓建模初步
  • 数据仓库维度建模步骤

    千次阅读 2019-07-19 09:00:20
    在商业智能项目的实施过程中,维度建模技术和企业数据仓库建模是两种不同的方法论,以下是以应用驱动、提供快速原型的商业智能项目的实施和规划过程中使用的维度建模方法时的标准实施过程。具体到项目中则根据项目的...
  • 数据仓库 维度建模

    2019-02-12 11:36:03
     本文将详细介绍数据仓库维度建模技术,并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系:规范化数据仓库,维度建模数据仓库,以及独立数据集市。   维度建模的基本概念  ...
  • 自从20世纪90年代提出数据仓库的概念以来, 数据 仓库技术得到了很大的发展. 数据仓库是一个面向主题的、 集成的、时变的、非易失的数据集合, 支持管理部门的... 目前, 维度建模技术是数据仓库最为流行的数 据建模技术.
  • 数据仓库维度建模——维度表设计

    千次阅读 2021-12-31 18:33:37
    维度所包含的表示维度的列的列,称为维度属性,一般是查询约束条件,分组和报表标签生成的基本来源。 3、获取维度的方式 (1)可以在报表需求中获取 (2)可以在相关的业务过程中发现和挖局 4、维度的主键 用于标识...
  • 我们暂且不管数据仓库的范围到底有多大,在数据仓库体系中,数据模型的核心地位是不可替代的。因此,下面的将详细地阐述数据建模中的典型代表:维度建模,对它的的相关理论以及实际使用做深入的分析。
  • 数据仓库维度模型设计的经典教程,本教程通俗易懂,内容丰富适合数据仓库初学者和有一定经验的开发者。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 11,742
精华内容 4,696
关键字:

数据仓库维度建模