精华内容
下载资源
问答
  • 谈笑间学会数据仓库-为什么要维度建模
    2021-08-20 17:42:58

    是不是有很多人在学习数据仓库——维度建模的时候会有这种疑问呢?

    到底有何意义呢?

    请看下面通俗易懂的描述
            凡是建设数据仓库,一定会提到维度建模方法。这一方法是Kimball最先提出的,其最简单的描述就是,按照事实表、维度表来构建数据仓库、数据集市。在维度建模方法体系中,维度是描述事实的角度,如日期、商品、地址等,事实是要度量的指标,如用户数、销售额等。按照一般书籍的介绍,维度建模还会分为星型模型、雪花模型等,各有优缺点,但很少直接回答一个问题,也就是数据仓库为什么要采用维度建模?

    这个问题的基本判断在于,数据是否要开放给业务人员使用?采用维度建模构建出来的数据库结构表更加符合普通人的直觉、易于被普通人所理解,从而有利于数据的推广使用。下面以超市收银小票为例说明常规的三范式模型和维度模型。

    三范式的数据模型示意如下:

    维度模型示意如下:

     

    以上两个模型的最小数据粒度都是小票项目,可以容易看出来,维度模型是将关系模型的层次结构展开平铺而成。从上面的这个范例可以引出采用维度建模方法的基本理由,就是:

    数据结构简单。在决定是否要采用维度建模之前,必须回答一个问题,“数据模型是否要开放给业务人员直接使用”,如果答案肯定,则应该采用维度建模的方法。维度模型这个概念有点学术化,但究其本质而言,是将层次化的数据结构展开为单一层次,有点类似于将一个业务过程的数据汇总到一个excel的sheet页中。

    不过维度建模的代价也很明显,就是其灵活性较差,数据冗余较多,所以,在很多书中提出了一个折中的办法,即“雪花模型”,同时还煞有介事的对比了雪花模型与星型模型(即上面的示例)的优缺点,让很多初学者心中飘来了一个挥之不去的疑问,“既然雪花模型既有关系模型的优点,还有维度模型的优点,为什么还要存在星型模型呢”?。窃以为,这完全是多此一举的做法,维度建模追求的是使用简单,多增加一级关联,增加的使用复杂度就会增加不止一点,会给多数不懂技术的业务人员带来极大的障碍,是一种舍本逐末的做法。

    基于这种考虑,在建设数据仓库的过程中,明细层和集市层分别采用不同的建模方法,也就是:

    明细层采用传统的三范式关系模型。这一层次的数据模型要将业务过程描述清楚,将源数据(即业务系统)中隐含的、有歧义的概念进行清晰化,如活跃用户、VIP用户等。该层次的数据模型追求的目标是灵活地表达业务过程,要保证数据一致性、唯一性、正确性,以尽量少的代价与源数据保持数据同步,同时该层次的数据模型不建议开给不懂技术的业务人员直接使用,因此,采用关系型的三范式模型是最佳的选择。

    集市层采用维度模型。集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合,该层次的数据模型会开放给业务人员使用,进行数据挖掘及业务分析。由于业务员多数不懂数据库技术,缺少将业务需求转换为关系型数据结构的逻辑思维,更写不出复杂的SQL语句,因此,越简单的数据模型,越能被他们所接受,因此,这个层次所构建出来的数据模型,要按照业务过程进行组织,每个事实表代表一个独立的业务过程,事实表之间不存在直接的依赖关系,这样业务人员可以很容易地将分析需求对应到事实表上,利用工具或手工写出简单的SQL,将统计数据提取出来进行分析。以上,就是数据仓库采用维度建模和关系建模的基本判断。

    总体来说:

            维度建模就是为了减少关联,减少数据存储,增加业务复杂度。维度建模相对于比较简单,一般采用星型模块减少了关联,增加了冗余,提升了性能空间。抽象的理解一下子,就是范式建模就是多维空间,而维度建模就是二维空间或者三维空间。

    不能再多了哦~

    参考链接:

            https://blog.csdn.net/dtqyhq/article/details/42914369

     

    更多相关内容
  • 下面的内容,是笔者在学习和工作中的一些总结,其中概念性的内容大多来自书中,实践性的内容大多来自自己的...因此,下面的将详细地阐述数据建模中的典型代表:维度建模,对它的的相关理论以及实际使用做深入的分析。
  • 数据仓库建模 Powerdesigner 维度建模 软件分析 建模 视频教程
  • 为什么要维度建模【数据仓库】

    千次阅读 2018-03-22 15:31:24
    凡是建设数据仓库,一定会提到维度建模方法。...按照一般书籍的介绍,维度建模还会分为星型模型、雪花模型等,各有优缺点,但很少直接回答一个问题,也就是数据仓库为什么要采用维度建模?这个问题的基本判断在于...

    凡是建设数据仓库,一定会提到维度建模方法。这一方法是Kimball最先提出的,其最简单的描述就是,按照事实表、维度表来构建数据仓库、数据集市。在维度建模方法体系中,维度是描述事实的角度,如日期、商品、地址等,事实是要度量的指标,如用户数、销售额等。按照一般书籍的介绍,维度建模还会分为星型模型、雪花模型等,各有优缺点,但很少直接回答一个问题,也就是数据仓库为什么要采用维度建模?

    这个问题的基本判断在于,数据是否要开放给业务人员使用?采用维度建模构建出来的数据库结构表更加符合普通人的直觉、易于被普通人所理解,从而有利于数据的推广使用。下面以超市收银小票为例说明常规的三范式模型和维度模型。

    三范式的数据模型示意如下:

     

    维度模型示意如下:

     

    以上两个模型的最小数据粒度都是小票项目,可以容易看出来,维度模型是将关系模型的层次结构展开平铺而成。从上面的这个范例可以引出采用维度建模方法的基本理由,就是:

    数据结构简单。在决定是否要采用维度建模之前,必须回答一个问题,“数据模型是否要开放给业务人员直接使用”,如果答案肯定,则应该采用维度建模的方法。维度模型这个概念有点学术化,但究其本质而言,是将层次化的数据结构展开为单一层次,有点类似于将一个业务过程的数据汇总到一个excel的sheet页中。

    不过维度建模的代价也很明显,就是其灵活性较差,数据冗余较多,所以,在很多书中提出了一个折中的办法,即“雪花模型”,同时还煞有介事的对比了雪花模型与星型模型(即上面的示例)的优缺点,让很多初学者心中飘来了一个挥之不去的疑问,“既然雪花模型既有关系模型的优点,还有维度模型的优点,为什么还要存在星型模型呢”?。窃以为,这完全是多此一举的做法,维度建模追求的是使用简单,多增加一级关联,增加的使用复杂度就会增加不止一点,会给多数不懂技术的业务人员带来极大的障碍,是一种舍本逐末的做法。

    基于这种考虑,在建设数据仓库的过程中,明细层和集市层分别采用不同的建模方法,也就是:

    明细层采用传统的三范式关系模型。这一层次的数据模型要将业务过程描述清楚,将源数据(即业务系统)中隐含的、有歧义的概念进行清晰化,如活跃用户、VIP用户等。该层次的数据模型追求的目标是灵活地表达业务过程,要保证数据一致性、唯一性、正确性,以尽量少的代价与源数据保持数据同步,同时该层次的数据模型不建议开给不懂技术的业务人员直接使用,因此,采用关系型的三范式模型是最佳的选择。

    集市层采用维度模型。集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合,该层次的数据模型会开放给业务人员使用,进行数据挖掘及业务分析。由于业务员多数不懂数据库技术,缺少将业务需求转换为关系型数据结构的逻辑思维,更写不出复杂的SQL语句,因此,越简单的数据模型,越能被他们所接受,因此,这个层次所构建出来的数据模型,要按照业务过程进行组织,每个事实表代表一个独立的业务过程,事实表之间不存在直接的依赖关系,这样业务人员可以很容易地将分析需求对应到事实表上,利用工具或手工写出简单的SQL,将统计数据提取出来进行分析。

    摘自:http://blog.csdn.net/dtqyhq/article/details/42914369

    展开全文
  • 维度建模指南

    2018-06-19 14:10:39
    维度建模指南,上传资源即表示确认该资源不违反资源分享的使用条款,并且您拥有该资源的所有版权或者上传资源的授权
  • 文章目录一、前言二、什么维度建模三、维度建模的基本要素3.1 事实表3.2 维度表 一、前言 学习数据仓库,你一定会了解到两个人:数据仓库之父比尔·恩门(Bill Inmon)和数据仓库权威专家Ralph Kimball。 Inmon和...

    一、前言

    学习数据仓库,你一定会了解到两个人:数据仓库之父比尔·恩门(Bill Inmon)和数据仓库权威专家Ralph Kimball。

    Inmon和Kimball两种DW架构支撑了数据仓库以及商业智能近二十年的发展,其中Inmon主张自上而下的架构,不同的OLTP数据集中到面向主题、集成的、不易失的和时间变化的结构中,用于以后的分析;且数据可以通过下钻到最细层,或者上卷到汇总层;数据集市应该是数据仓库的子集;每个数据集市是针对独立部门特殊设计的。

    而Kimball正好与Inmon相反,Kimball架构是一种自下而上的架构,它认为数据仓库是一系列数据集市的集合。企业可以通过一系列维数相同的数据集市递增地构建数据仓库,通过使用一致的维度,能够共同看到不同数据集市中的信息,这表示它们拥有公共定义的元素。

    这里我主要介绍维度建模方法。这一方法是Kimball最先提出的,其最简单的描述就是按照事实表、维度表来构建数据仓库、数据集市。在维度建模方法体系中,维度是描述事实的角度,如日期、客户、供应商等,事实是要度量的指标,如客户数、销售额等。按照一般书籍的介绍,维度建模还会分为星型模型、雪花模型等,各有优缺点,但很少直接回答一个问题,也就是数据仓库为什么要采用维度建模?

    星型模型
    星型模型
    在这里插入图片描述
    雪花模型

    数据仓库包含的内容很多,它可以包括架构、建模和方法论。对应到具体工作中的话,它可以包含下面的这些内容:

    1、数据架构体系:以Hadoop、Spark等组建为中心的数据架构体系。

    2、各种数据建模方法:如维度建模、范式建模法、实体建模法。

    3、辅助系统:调度系统、元数据系统、ETL系统、可视化系统这类辅助系统。

    我们暂且不管数据仓库的范围到底有多大,在数据仓库体系中,数据模型的核心地位是不可替代的。因此,下面的将详细地阐述数据建模中的典型代表:维度建模,对它的的相关理论以及实际使用做深入的分析。

    为了能更真切地理解什么是维度建模,我将在后续的文章中模拟一个大家都十分熟悉的电商场景,运用讲到的理论进行建模。理论和现实的工作场景毕竟会有所差距,这一块,我会分享一下企业在实际的应用中所做出的取舍。接下来具体来了解维度建模。

    二、什么是维度建模

    维度模型是数据仓库领域大师Ralph Kimball 所倡导,他的《数据仓库工具箱》,是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。

    我们换一种方式来解释什么是维度建模。学过数据库的童鞋应该都知道星型模型,星型模型就是我们一种典型的维度模型。我们在进行维度建模的时候会建一张事实表,这个事实表就是星型模型的中心,然后会有一堆维度表,这些维度表就是向外发散的星星。那么什么是事实表、什么又是维度表,下面会专门来解释。

    星型模型

    三、维度建模的基本要素

    维度建模中有一些比较重要的概念,理解了这些概念,基本也就理解了什么是维度建模。

    3.1 事实表

    发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中。从最低的粒度级别来看,事实表行对应一个度量事件,反之亦然。不太理解举个例子。比如一次购买行为我们就可以理解为是一个事实,大家看一下星星模型示例。

    在这里插入图片描述
    图中的订单表(ICstockbill)就是一个事实表,你可以理解他就是在现实中发生的一次操作型事件,我们每完成一个订单,就会在订单中增加一条记录。我们可以回过头再看一下事实表的特征,在事实表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录。

    3.2 维度表

    每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键,当然,维度表行的描述环境应与事实表行完全对应。 维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性。图中的customer(客户表)、goods(商品表)、d_time(时间表)这些都属于维度表,这些表都有一个唯一的主键,然后在表中存放了详细的数据信息。

    最后说一下维度模型的优缺点:

    在这里插入图片描述
    1、数据冗余小(因为很多具体的信息都存在相应的维度表中了,比如客户信息就只有一份)

    2、结构清晰(表结构一目了然)

    3、便于做OLAP分析(数据分析用起来会很方便)

    4、增加使用成本,比如查询时要关联多张表

    5、数据不一致,比如用户发起购买行为的时候的数据,和我们维度表里面存放的数据不一致

    再说没有数据仓库的宽事实表的优缺点:

    在这里插入图片描述
    1、业务直观,在做业务的时候,这种表特别方便,直接能对到业务中。

    2、使用方便,写sql的时候很方便。

    3、数据冗余巨大,真的很大,在几亿的用户规模下,他的订单行为会很恐怖、粒度僵硬,什么都写死了,这张表的可复用性太低。

    展开全文
  • 维度建模

    千次阅读 2021-05-16 23:00:36
    1 维度建模关键概念 1.1 度量和环境 1.2 事实和维度 在维度建模中,度量称为事实,上下文和环境称为维度。 1.3 事实表 事实常以数值形式出现,而且一般都被大量文本形式的上下文包围着。这些文本形式的上下文描述了...

    1 维度建模关键概念

    1.1 度量和环境

    在这里插入图片描述

    1.2 事实和维度

    在维度建模中,度量称为事实,上下文和环境称为维度。

    1.3 事实表

    事实常以数值形式出现,而且一般都被大量文本形式的上下文包围着。这些文本形式的上下文描述了事实的“5个w”(when、where、what、who、why)信息
    事实表的一行对应一个度量事件。
    维度建模认为事实表应该包含最底层、最原子性的细节,因为这样会带来最大的灵活性。
    事实表中最常用的度量一般是数值型和可加类型。但事实表的度量并非都是可加的,有些是半可加性质的,另一些则是非可加性质的。
    除了存储的事实外,事实表都会包含多个相关的外键。
    事实表根据粒度的角色划分不同,可分为事务事实表、周期快照事实表、累计快照事实表

    • 事务事实表用于承载事务数据,通常粒度比较低,例如产品交易事务事实表
    • 周期快照事实表用于记录有规律的、固定时间间隔的业务累计数据,通常粒度比较大,例如账户月平均余额事实表
    • 累计快照事实表用于记录具有时间跨度的业务处理过程的整个信息,通常这类事实表相对比较少见

    这里需要注意的是,在进行事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不同粒度的事实建立在同一张事实表中。

    1.4 维度表

    维度表包含了事实表所记录的业务过程度量的上下文和环境,它们除了记录“5个w”等信息外,通常还包含了很多的描述字段和标签字段。
    维度表通常有多列或者说多个属性。
    维度表应该尽可能多地包括一些有意义的文字描述。
    维度属性是查询约束条件(SQl where条件)、分组(SQL group语句)与报表标签生成的基本来源。
    维度属性在数据仓库中承担着一个重要的角色。
    维度表是事实表的入口。

    如果不能确定从数据源取出的一个数字型数据字段到底应该作为事实还是维度属性看待。通常可以,看字段是一个含有许多取值并参与运算的度量值(当事实看待),还是一个变化不多并作为约束条件的离散值得描述(当维度属性看待)。

    1.5 星型架构和雪花架构

    组合维度表和事实表的基本架构

    1.5.1 星型架构

    所有维度表直接连接到事实表,整个组合的形状类似于星星。
    星型架构是一种非规范化的架构,其数据存储存在冗余。
    例如考虑商品的维度表,其品牌信息在商品的每一行中都存在,包括其品牌ID、名称、品牌拥有者等。通常很多商品的品牌都是一样的,所以在商品维度表中品牌的信息被重复存储了很多次,也就是存在冗余。

    在这里插入图片描述

    1.5.2 雪花架构

    当有一个或者多个维度表没有直接连接到事实表,而通过其他维度表连接到事实表上。
    雪花架构是对星型架构维度表的规范化。
    比如上述的商品例子,在雪花架构中,其每行仅存储品牌ID,而品牌的所有其他信息(包括品牌名称、拥有者、注册地等所有描述信息)都存储在单独的品牌维度表内。通过品牌ID整个外键,商品表可以间接获取到所有品牌的描述信息。雪花架构去除了数据冗余,节省了部分存储,但是在使用过程中复杂度增加,给用户使用带来不方便。因此在维度建模的实际中,雪花架构很少使用到。

    在这里插入图片描述

    星型架构牺牲了部分存储的冗余,但是带来了使用上的极度便捷。现在存储成本极低,多出的存储开销相比后续每次的关联计算、用户使用和学习成本来说,是非常划算的。

    2 维度建模一般过程

    选择业务过程-》定义粒度-》确定维度-》确定事实

    2.1 选取业务过程

    业务过程即企业和组织的业务活动,它们一般都有相应的源头业务系统支持。
    业务过程并不是指业务部门或者职能。如果建立的维度模型是同部门捆绑在一起的,就无法避免出现数据不一致的情况(如业务编码、含义等)。确保数据一致性的最佳办法是从企业和公司全局与整体角度,对于某一个业务过程建立单一的、一致的维度模型。

    2.2 定义粒度

    定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明。其实质就是如何描述事实表的单个行。
    如果没有明确的粒度定义,则不能进入后面的环节。如果在后面的环节中发现粒度的定义不够或者是错误,那么也必须返回这一环节重新定义粒度。
    最大限度地选择业务过程中最为原子性的粒度,这样可以带来后续的最大灵活度

    2.3 确定维度

    维度是对度量的上下文和环境的描述。

    2.4 确定事实

    维度一般是名词,事实一般是动词。

    3 维度表设计

    3.1 维度变化

    1、重写维度值

    当一个维度值属性发送变化时,重写维度值,直接用新值覆盖旧值。该方法适用于维度建模中不需要保留此维度属性历史变化的情况,常用于订正或者维度属性改变无关紧要的场景。

    2、插入新的维度行

    插入新的维度行通过在维度表中插入新的行来保存和记录变化的情况。属性改变前的事实表行和旧的维度值关联,而新的事实表行和新的维度值关联。
    这也给维度表用户带来了困惑,为什么查询一个会员会在维度表中发现多行记录?用户的使用和学习成本无疑增加了,而且数据开发人员对于维度变化的处理逻辑无疑变得复杂了。

    3、插入新的维度列

    这种方法通过新增一列

    这三种方法,在大数据时代都不是完美的。

    3.2 维度层次

    维度层次指的是某个维度表中属性之间存在的从属关系问题。比如商品的类目可能是有层次的(一级类目、二级类目)

    • 方法一:将所有维度层次结构全部扁平化、冗余存储到一个维度化表中
    • 方法二:新建类目维度表,并在维度表中维护父子关系

    我们常用第一种来处理维度的层级问题

    3.3 维度一致性

    可以采用共享同一个的维度表或者让其中一个维度表是另外一个维度表的子集等方式来保证一致性

    3.4 维度整合和拆分

    1、在实际整合中,同一个维度的整合需要考虑如下问题。

    • 命名规范:要确保一致和统一
    • 字段类型:统一整合为一个字段类型
    • 字段编码和含义:编码及含义要整合为一致。实际中可能碰到商品状态A系统有3个,而B系统有四个的情况,此时需要和业务人员或者需求方共同讨论确定整合逻辑。

    2、与整合相对的是拆分
    在维度建模理论中,处理拆分通常有两种处理办法。
    1)建一个基础维度表,此基础维度表包含这些不同业务的共有属性,同时建立各自业务的单独维度表以包含其独特的业务属性。
    2)拆分,即不合并,即各个业务差异独特性的业务各自建立完全独立的两个维度表,各自管理各自维度表和属性
    实际操作中,通常倾向于拆分(即不合并)

    3.5 维度其他

    1、退化维度
    退化维度在分析中通常用来对事实表行进行分组
    2、行为维度
    行为问题是基于过去维度成员的行为进行分组或者过滤事实的办法。行为维度即将事实转化为维度,以确保获得更多的分析能力。
    3、角色维度
    角色维度指的是一个事实表中多个外键指向同一个维度表。
    当事实表和维度表存在上述多对一关系时,没有必要为维度表建立多个副本,只需要基于维度表建立多个视图即可。
    4、杂项维度
    一般由前台业务系统中的指示符或者标志字段组合而成。
    通常的解决方案就是建立杂项维度,将这些字段建立到一个维度表中,在事实表中只需要保存一个外键。
    5、微型维度
    微型维度的提出主要是为了解决快变超大维度问题。
    以客户维度为例,如果维度表中有数百万、千万甚至以亿计的记录,而且这些记录中的字段又经常变化,则将这样的维度表一般称为快变超大维度。
    解决的方法是,将分析频率比较高或者变化频率比较大的字段提取出来,建立一个单独的维度表。这个单独的维度表就是微型维度表。
    6、多值维度和属性
    当事实表的一行涉及维度表的多行时,会产生多值维度。同样。维度表的一行需要获取单一属性的多个值时,也会产生多值维度。
    通常有两种办法可以解决多值维度或者多值属性。
    1)扁平化多值维度:在事实表中引入多列。此外考虑到业务的可变性,可同时添加预留字段
    2)桥接表:在事实表和多值维度表之间新增一个表,这个表起到桥接作用

    4 深入事实表

    事实表的主要类型:事实事实表、快照事实表、累计快照事实表

    4.1 事务事实表

    事务事实表通常用于记录业务过程事件,而且是原子粒度的事件。事务事实表中的数据在事务事件发送后产生,数据的粒度通常是每个事务一条记录。一旦事务被提交,事实表数据被插入,数据就不再进行改变。通过事务事实表存储单次业务事件/行为的细节,以及存储与事件相关的维度细节,用户即可单独或者聚合分析业务事件和行为。

    在事实表的设计中,一个常见的原则是只存放比例的分子和分母,一般不将比例的计算放入事实表中。

    4.2 快照事实表

    所谓周期快照事实表,是指间隔一定的周期对业务的状态进行一次拍照并记录下来的事实表。
    周期快照事实表的周期通常需要和业务方共同确定,最常见的周期是天、周和月等。
    周期快照事实表中的事实一般是半可加的,如某个商品的库存可以跨商品、仓库等相加,但是明显在时间上相加是没有意义的。

    4.3 累计快照事实表

    累计快照事实表非常适用于具有工作流或者流水线形式业务的分析,这些业务通常涉及多个时间节点或者有主要里程碑事件,而累计快照事实表正是从全流程角度对其业务状态拍照。

    5 大数据维度建模实践改良

    5.1 事实表

    最初的维度建模设计主要是出于存储的成本以及处理的性能考虑。大数据时代下,各种分布式存储和计算技术的发展,存储、成本以及性能等不再是关键,所以在维度建模理论反规范化思想的基础上,可以更进一步地把常用的维度属性沉淀在事实表中。以存储的冗余为代价,换来下游的使用便捷以及多次关联计算开销。
    当然,反规范化也不是把所有的维度属性都放在事实表中,应该将业务使用最为频繁和常用的维度属性沉淀在事实表中。

    5.2 维度表

    用维度表快照的方式来处理缓慢变化维,实际上也是用存储的冗余开销换来了缓慢变化维复杂逻辑的消除以及下游使用的便捷。例如,将维度表的快照每天存储一份。
    维度层次的扁平化也就是在单一维度表中用冗余字段来存储所有层次,维度有5个层次就用5个层次的字段,有10个层次就用10个层次的字段,存储和成本不是问题。
    当然,也可以通过大字段的方式来解决,比如把多值属性组装成键值对放在一个长字符串内。

    展开全文
  • 作者基于多年的大数据处理经验,当前管理着100PB+数据仓库和2000+节点的集群。持续系统化给大家分享一下关于数据仓库建设的...1.什么是数仓建模本质? 所谓的数据仓库建模,听着很高大,我们透过现象看本质。其...
  • 维度建模的优缺点

    千次阅读 2021-05-04 18:21:58
    维度建模是将层次化的数据结构展开单一层次,构建出来的数据库结构表更加符合人的直觉、易于被人所理解,从而有利于数据的推广使用。 2、快速的响应业务 面向分析构建的,每次不需要编写冗长的SQL,查询打宽表,...
  • 凡是建设数据仓库,一定会提到维度建模方法。...按照一般书籍的介绍,维度建模还会分为星型模型、雪花模型等,各有优缺点,但很少直接回答一个问题,也就是数据仓库为什么要采用维度建模? 这个问题的基本判断...
  • 维度建模方法论

    千次阅读 2022-02-11 15:20:21
    维度建模方法 一、前言 本人学习《数仓工具箱》的学习总结,纯学习分享,供大家参考。 二、经典数仓架构理论 围绕着维度建模,那就不得不了解,早期的数据仓库构架方法。这里介绍一下两个经典的数仓架构理论。 2.1...
  • 数据仓库工具箱:维度建模的完全指南(中文)
  • Kimball维度建模

    千次阅读 2022-01-04 17:47:26
    最简洁的语言描述维度建模的理论和流程
  • 作者基于多年的大数据处理经验,当前管理着100PB+数据仓库和2000+节点的集群。持续系统化给大家分享一下关于数据仓库建设的经验总结。...为什么维度建能模脱颖而出? 1.从小公司到大公司看数仓建模发展 ...
  • 详解维度建模

    2020-04-15 13:09:13
    0x01 什么维度建模维度模型是数据仓库领域另一位大师 Ralph Kimball 所倡导,他的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling,中文名《数据仓库工具箱》,是数据仓库工程领域最流行的...
  • 维度建模(dimensional modeling)是数据仓库建设中的一种数据建模方法,Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市,这种方法最被人广泛知晓的名字就是星型模式...
  • 维度建模是数据建模的一种特殊方法。维度建模有两个同义词,数据集市和星型结构。星型结构是为了更好地进行数据分析,参考下面图示的维度模型,可以有一个很直观的理解。通过它可以立即知道如何通过客户、产品、时间...
  • 维度建模示例

    2021-03-17 00:34:16
    以库存模块和零售模块这两个模块来谈一谈维度建模的相关事项梳理库存业务中的表的构造与设计思想梳理一下缓慢变化维的处理方法与优缺这篇博客计划用周末来完成,只能简单的讨论一下建模概况,从维度建模...
  • 维度建模的基本理论

    2021-10-26 14:27:44
    维度建模 围绕三个问题来展开 1、怎么组织数据仓库中的数据? 2、怎么组织才能使得数据的使用最为方便和便捷? 3、怎么组织才能使得数据仓库具有良好的可扩展性和可维护性? 维度建模两大派系 Bill Inmon(数据...
  • 维度建模和范式建模对比

    千次阅读 2021-04-14 18:24:45
    一、两种建模思想 对于 Inmon 和 Kimball 两种建模方式可以长篇大论叙述,但理论是很枯燥的,尤其是晦涩难懂的文字,大家读完估计也不会收获太多,所以我根据自己的理解用通俗的语言提炼出最核心的概念。 范式建模 ...
  • 大数据之维度建模中的重要概念

    千次阅读 2022-03-16 16:20:13
    本篇博客,是在经历了小10轮大数据开发面试后,博主对大数据建模中,比较重要的知识点进行了梳理,截取了书中一些常考的概念,供大家参考。
  • 凡是建设数据仓库,一定会提到维度建模方法。...按照一般书籍的介绍,维度建模还会分为星型模型、雪花模型等,各有优缺点,但很少直接回答一个问题,也就是数据仓库为什么要采用维度建模? 这个问题的基本判断...
  • ER建模 维度表和事实表 维度建模三种模式 如何维度建模 什么是缓慢变化的维度 最常见的三种数据仓库建模体系 联机分析处理 OLAP 元数据(Metadata)
  • 范式建模 Third Normal Form,3NF 是数据模型常用的一个方法,主要解决关系型数据库的数据存储。 目前关系型数据库的建模方法,大部分采用三范式建模,即通过实体关系(Entity Relationship,ER)模型描述企业业务。...
  • 数仓维度建模实例

    千次阅读 2022-04-14 17:35:25
    本文将介绍维度建模理论,基于自己经验的实施步骤 数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据.... 只有数据模型将数据有序的组织和存储起来之后,大数据才能得到高性能、低...
  • 数仓维度建模

    2020-09-13 22:28:07
    20世纪80年代末期,数据仓库技术兴起。自Ralph Kimball 于1996 年首次出版The Data Warehouse Toolkit(Wiley)一书以来,数据仓库和商业智能(Data Warehousing and Business ...维度建模被视设计数据仓库和数据
  • 维度建模之事实表

    千次阅读 2019-12-08 13:54:38
    维度建模之事实表 每个数据仓库都包含一个或者多个事实数据表。其中可能包含业务销售数据,如现金登记事务所产生的数据,通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 58,277
精华内容 23,310
关键字:

为什么要使用维度建模