维表和事实表介绍

数据仓库维度建模
优选数据仓库维度建模
目录
1.基础术语 2.维度建模中的两种模型 3.星形模型设计 4.雪花模型设计 5.星形模型的优势 6.雪花模型的优势与劣势
1、基础术语
事实表(Fact Table)
• 每个数据仓库都包含一个或者多个事实数据表。事实数据 表可能包含业务销售数据，如现金登记事务所产生的数据， 事实数据表通常包含大量的行
细类别表，详细类别表通过对事实表在有关维上 性。
维度表可以看作是用户来分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如
的详细描述达到了缩小事实表和提高查询效率的 何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。
主要包含了描述特定商业事件的数据，即某些特定商业事件的度量值。
商品大分类表 大分类编号 大分类名称 大分类备注
5.星形模型的优势
– 用户容易理解 – 优化浏览
• 在数据库模式中，表与表连接的目的在于寻找到需 要的数据
• 如果连接的路径复杂，那么在数据库中浏览数据将 是缓慢而艰难的
• 如果连接路径简单、直接，则浏览数据会更快 • 星型模型的优势之一在于它优化对数据库的浏览
星形模型(Star Schema)
• 事实被维度所包围，且维度没有被新的表连接
雪花模型(Snowflake Schema)
• 事实表被多个维表或一个或多个层次所包围
3.星形模型设计
(1) 正确区分事实、属性和维度。
• 维度模型需要对事实和属性进行区分，业务层的 很多事实都是数值型的，特别是该数值是浮点数 时，他很可能是一个事实，而不是属性。
• 主要包含了描述特定商业事件的数据，即某些特定商业事 件的度量值。

1、数据仓库基本概念1.1、主题（Subject）主题就是指我们所要分析的具体方面。

例如：某年某月某地区某机型某款App的安装情况。

主题有两个元素：一是各个分析角度（维度），如时间位置；二是要分析的具体量度，该量度一般通过数值体现，如App安装量。

1.2、维（Dimension）维是用于从不同角度描述事物特征的，一般维都会有多层（Level：级别），每个Level 都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。

1.3、分层（Hierarchy）OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。

所以我们一般会在维的基础上再次进行分层，维、分层、层级的关系如下图：每一级之间可能是附属关系（如市属于省、省属于国家），也可能是顺序关系（如天周年），如下图所示：1.4、量度量度就是我们要分析的具体的技术指标，诸如年销售额之类。

它们一般为数值型数据。

我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。

1.5、粒度数据的细分层度，例如按天分按小时分。

1.6、事实表和维表事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发生的事情。

事实表中存储数字型ID以及度量信息。

维表则是对事实表中事件的要素的描述信息，就是你观察该事务的角度，是从哪个角度去观察这个内容的。

事实表和维表通过ID相关联，如图所示：1.7、星形/雪花形/事实星座这三者就是数据仓库多维数据模型建模的模式上图所示就是一个标准的星形模型。

雪花形就是在维度下面又细分出维度，这样切分是为了使表结构更加规范化。

雪花模式可以减少冗余，但是减少的那点空间和事实表的容量相比实在是微不足道，而且多个表联结操作会降低性能，所以一般不用雪花模式设计数据仓库。

Analysts
可编辑版
4
聊城大学数学科学学院－－周书锋
4
决策支持系统的演化
淹没于数据，但饥饿于知识
VLDB
Knowledge discovery
Too much data
Valuable
knowledge
可编辑版
5
聊城大学数学科学学院－－周书锋
5
决策支持系统的演化
自然演化体系结构 对于决策者的即时信息需求，直接从OLTP系统中产生 报告 – 使DBA忙乱不堪也使OLTP负载太重！
粒度细：数据分析灵活，但存储空间大计算量大
粒度粗：存储空间小，但有时无法回答一些比较 细节的问题。
可编辑版
32
聊城大学数学科学学院－－周书锋
32
例如：销售数据库存储了每一笔业务的细节，在 分析时对每一笔分析是无意义的。
因此，可以考虑数据仓库的粒度级别以星期为单 位，即在数据从数据库装入数据仓库时，按星期 汇总。
优点：组织方式简单、花费少、使用灵活； 缺点：只有当源数据库的数据组织比较规范、没 有数据不完备及冗余，同时又比较接近多维数据 模型时，虚拟数据仓库的多维语义才容易定义。 而在一般的数据库应用中，这很难做到。
可编辑版
28
聊城大学数学科学学院－－周书锋
28
6.数据仓库的数据组织
2、基于关系表的存储方式
ERP系统也是事务系统，但它们的数据结构非常标 准、规范。
与使用ERP系统的贸易伙伴之间处理效率会更高，
改善企业内部供应链的上下纵向通信（XML）
可编辑版
13
聊城大学数学科学学院－－周书锋
13
电子商务系统
Electronic Commerce

大数据分析基础——维度模型大数据分析基础——维度模型1基本概念维度模型的概念出自于数据仓库领域，是数据仓库建设中的一种数据建模方法。

维度模型主要由事实表和维度表这两个基本要素构成。

1.1维度维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。

维度属于一个数据域，如地理维度(其中包括国家、地区、省以及城市等级别的内容)、时间维度(其中包括年、季、月、周、日等级别的内容)。

维度是维度建模的基础和灵魂。

在维度建模中，将度量称为“事实” ，将环境描述为“维度”，维度是用于分析事实所需要的多样环境。

例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。

维度所包含的表示维度的列，称为维度属性。

维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

1.2事实表事实表是维度模型的基本表，每个数据仓库都包含一个或者多个事实数据表。

事实数据表可能包含业务销售数据，如销售商品所产生的数据，与软件中实际表概念一样。

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。

事实表中一条记录所表达的业务细节程度被称为粒度。

通常粒度可以通过两种方式来表述:一种是维度属性组合所表示的细节程度:一种是所表示的具体业务含义。

作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。

相对维度来说，通常事实表要细长，行的增加速度也比维度表快的多，维度表正好相反。

事实表有三种类型 :1.事务事实表：事务事实表用来描述业务过程，眼踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为“原子事实表\周期快照事实表”。

2.周期快照事实表：周期快照事实表以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。

3.累积快照事实表：累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。

事实表中一般要包含2部分：一是由主键和外键所组成的键部分，另一部分是用户希望在数据仓库中所了解的数值指标，这些指标是为每个派生出来的键而定义和计算的，称为事实或指标。

由于事实是一种度量，所以事实表中的这种指标往往需要具有数值化和可加性的特征。

但是在事实表中，只有那些具有完全可加性的事实才能根据所有的维度进行累加而具有意义。

而事实表有一些事实表示的是某种强度，这类事实就不具有完全加法性，而是一种半加法性。

例如，账目余款反映的是某个时间点的数据，它可以按照地点和商品等大多数维度进行累加，但是对于时间维度则例外，将一年中每个月的账目余款进行累加是毫无意义的，而决策者则可能需要了解所有地区和所有商品账目余款的累加值。

在事实表中还有一些事实是非加法性的，即这些事实具有对事实的描述特性，在这种情况下一般要将这些非加法性事实转移到维度表中。

以事实表中度量的可加性情况，可以把事实表及其包含的事实分为4种样式。

1．事务事实事务事实以企业事件的单一情况为基础，因此通常只包含事实的次数这一种度量条件，应该尽可能以最低级别来表示。

比如银行的ATM提款机的提款次数，使用某种服务的次数等。

2．快照事实快照事实以企业在某一特定时间的特殊状态为基础。

也就是只有在某一段时间内才出现的结果。

它们也许没有包含所有维的条件，比如不是所有的产品每天都有销售量。

3．线性项目事实这类事实通常用来储存关于企业经营项目的详细信息。

包括表现与企业相关的个别线性项目的所有度量条件，比如销售数量、销售金额、成本和运费等数值数据，也就是关键性能指标。

此类事实运用范围很广，比如采购、销售和库存等。

4．事件（状态事实）这是类特殊的事实，通常只表示事件发生与否和一些非事实本身具备的细节。

它所表现的是一个事件发生后的结果变化，并且没有度量数值表示。

如哪些产品在促销期间内没有卖出，有还是没有，就是事件或状态事实所表现的结果。

在事实表模型的设计中还需要注意到派生事实。

数据的单值、多值、派⽣、简单、复合属性
派⽣属性：“学⽣”实体中有“⽣⽇”和“年龄”等属性，从“⽣⽇”可以计算出“年龄”属性的值，“年龄”属性就是派⽣属性
多值属性：⼀个⼈都多个亲属，亲属就是多值属性。

⼀个⼈有多种爱好。

⼀个⼈可能有多个电话号码
单值属性：学⽣表中的学号就只有⼀个，所以叫单值属性。

复合属性：”姓名“由姓+中间名+名构成
简单属性：与复合相对的，就是简单属性。

使⽤“维度表”和“事实表”来对每种表进⾏定性。

以上的属性都是描述维度的。

维度建模三种模式
1.1 星型模式。

1.2 雪花模式。

1.3 星座模式。

维度表：维度表可以看成是⽤户⽤来分析⼀个事实的窗⼝，它⾥⾯的数据应该是对事实的各个⽅⾯描述，⽐如时间维度表，它⾥⾯的数据就是⼀些⽇，周，⽉，季，年，⽇期等数据，维度表只能是事实表的⼀个分析⾓度。

实体表：实体表就是⼀个实际对象的表，实体表它放的数据⼀定是⼀条条客观存在的事物数据，⽐如说设备，它就是客观存在的，所以可以将其设计⼀个实体表。

事实表：事实表其实质就是通过各种维度和⼀些指标值得组合来确定⼀个事实的，⽐如通过时间维度，地域组织维度，指标值可以去确定在某时某地的⼀些指标值怎么样的事实。

事实表的每⼀条数据都是⼏条维度表的数据和指标值交汇⽽得到的。

【数据仓库】4维度建模之事实表设计事实表是维度建模的核⼼，紧紧围绕着业务过程来设计，通过描述度量来表达业务过程，包含了维度的引⽤和业务度量值。

上⼀篇⽂章我们讲了《》，今天我们聊⼀下事实表的设计。

⼀样，我们的⽬录结构和内容参考了《阿⾥巴巴⼤数据之路》⼀书。

事实表的基础概念粒度事实表中的每⼀条记录所表达的业务细节程度被称为粒度。

粒度由两种⽅式表述：维度属性组合所表⽰的细节程度所表⽰的具体业务含义事实⽤来描述业务过程的度量，⼀般是整形、浮点型的⼗进制数值。

可加：对任何维度进⾏汇总半可加：只能对特定维度进⾏汇总，如库存，按照地点、商品维度汇总是有意义的，按时间汇总是⽆意义的不可加：⽐率型，需要拆解为可加的度量来实现汇总，如商品购买率=> 购买⼈数，浏览⼈数相对于维度表，事实表会显得更细长，变化速度也会⽐维度表快。

事实表中也是可以存储维度属性的，这种操作称为——维度退化，⽽相应的维度属性称为——退化维度。

事实表类型事务事实表：按最细粒度来保存业务过程的数据，如购买商品事实表周期快照事实表：按照固定的时间间隔（年、⽉、⽇），记录事实累计快照事实表：覆盖整个业务⽣命周期，从开始到结束的累计事实，通常具有多个⽇期时间字段来记录关键的时间点，当⽣命周期发⽣变化，记录也会随之被修改。

设计原则原则⼀：尽可能包含所有与业务过程相关的事实事实表的设计⽬的是为了度量业务过程。

所以分析哪些事实与业务过程有关，是设计中⾮常重要的关注点。

在事实表中应尽量包含所有与该业务过程相关的事实，即使有冗余，但因为事实通常是数字型，带来存储开销不会很⼤！原则⼆：只选择与业务过程相关的事实在选择事实时，应该注意只选择与业务过程有关的事实。

⽐如在下单的业务过程中，不应该存在⽀付⾦额这⼀个属于⽀付业务过程的事实。

原则三：不可加的事实拆分为可加的度量如商品购买率 => 购买⼈数，浏览⼈数原则四：在选择维度和事实之前必须先声明粒度⼀般在设计事实表过程中，粒度定义越细越好，从最低级别的原⼦粒度开始能满⾜之后⽆法预期的⽤户需求。

多维数据分析基础多维数据分析是指按照多个维度（即多个⾓度）对数据进⾏观察和分析，多维的分析操作是指通过对多维形式组织起来的数据进⾏切⽚、切块、聚合、钻取、旋转等分析操作，以求剖析数据，使⽤户能够从多种维度、多个侧⾯、多种数据综合度查看数据，从⽽深⼊地了解包含在数据中的信息和规律。

多维数据分析以数据仓库为基础，按照维度模型来设计数据仓库。

在维度模型中，把存储度量的表称作事实表，把存储属性的表叫做维度表。

事实表存储的是可概括的数据，维度中包含属性和层次结构。

⽤户可以按照层次结构对数据进⾏聚合，从High Level上分析数据。

⼀，度量和度量值度量（Measure）是事实表中⼀个数值类型的属性，对数值进⾏聚合计算是有意义的，例如，学⽣的分数，计算学⽣的平均分数是有意义的。

度量值是指可概括的数值，是度量的值，度量值⼜被称作事实（fact），这也是“事实表”名称的由来。

从维度模型来看，事实表中除了维度的外键列和主键列之外，其他的列都是度量，这些列的值是度量值。

由此可以得出，事实表的构成是：主键列+维度外键+度量。

事实表存储数据的详细程度称作事实表的粒度，由于粒度是由事实表引⽤的外键列确定的，因此⼀个事实表只能有⼀个粒度，不同粒度的事实数据必须分别存储到不同的事实表中。

⼆，维度和层次结构维度是分析数据的⾓度，维度和维度之间是相互独⽴的。

在报表中，增加维度只是创建了⼀个新的、独⽴的细分度量值的⽅法。

从数据分析的⾓度来讲，增加维度是把度量值更细分，增加新的属性来分解数据。

属性是维度表的⼀列，主键属性（Primary Key Attribution）唯⼀地确定了维度表中的其他属性，属性值是int类型；由于主键属性不具有可读性，通常为维度表创建⼀个名称属性（Name Attribution），是字符类型，⽤于说明主键属性标识的实体。

维度表的每⼀⾏都是不同的实体，但是其名称属性可能是相同的，例如，⼈名。

由于主键属性是int类型，值是唯⼀的，占⽤的存储空间⼩，因此⼤量应⽤于事实数据中，作为外键列。

数据仓库中的维度建模与事实表设计数据仓库是一个集成的、主题导向的、时间可变的、非易失性的数据存储，用于支持管理决策。

在数据仓库中，维度建模和事实表设计是非常重要的，它们是数据仓库设计的核心。

维度建模是指将数据仓库中的数据组织成一个统一的、易于理解的维度模型，而事实表设计则是指如何将业务过程和指标以一种易于查询和分析的方式存储到数据库中。

在本文中，我们将探讨数据仓库中的维度建模与事实表设计的相关内容。

一、维度建模维度建模是数据仓库设计的核心，它是数据仓库中维度和事实之间的关系模型。

维度模型由事实表和维度表组成，它们之间存在着一对多的关系。

维度模型是一个简单直观的模型，它将业务过程和指标以一种易于理解的方式组织起来。

1.维度表在维度建模中，维度表是非常重要的，它是用来描述业务对象的表。

维度表通常包含了多个属性字段，每个属性字段描述了业务对象的一个特定属性。

比如，在销售数据中，维度表可能包含了产品、时间、地点等属性字段。

2.事实表事实表是数据仓库中存储业务过程和指标的表，它包含了一个或多个度量字段，度量字段是用来度量业务活动的指标。

事实表和维度表之间通过外键关联起来，事实表中的度量字段通常是和维度表的外键字段关联的。

3.星型模式维度模型通常被称为星型模式，因为它的结构呈现出星型的形状。

在星型模式中，中心的事实表被围绕着多个维度表组织起来，形成了一个星型的结构。

4.雪花模式除了星型模式之外，还有一个常见的维度模型是雪花模式。

在雪花模式中，维度表的层次结构被规范化成多个维度表，这样可以节省存储空间，但也会增加查询复杂度。

5.维度层次维度表中的属性字段通常是按照层次结构组织起来的，比如在时间维度中，可以有年、季度、月、日等层次。

在维度建模中，采用自然层次结构的维度表是非常重要的，它可以帮助用户更加方便地进行查询和分析。

维度建模是数据仓库设计的核心，它可以帮助用户更加方便地理解业务过程和指标。

通过合理的维度建模，可以提高数据仓库的查询性能，减少数据冗余，提高数据的一致性和可靠性。

销售单数据 日库存数据 发货进度数据
比较
特点
时间/时期 粒度 事实表加载 事实表更新 时间维 事实
事务事实
时间 代表一个交易事件 新增 不更新 业务日期 交易活动
周期快照事实
时期 代表一个时间周期 新增 不更新 时期末 时间周期内的绩效
累积快照事实
时间跨度较短的多个时点 代表一个业务周期 新增和修改 新事件产生时更新 多个业务过程的完成日期 限定多个业务阶段内的绩效
注 4、维度表若被多个事实表使用，则应作为公共维度表来设计。
意
5、维度表，区分代理键和自然键的目的是跟踪在操作性系统中无须考虑的数据变化情况
总之，事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能
够以合适的角度来聚合主题内容为准则
04表关系
事实表
1、用来存储事实的度量及指向各个维的外键值 2、不应该包含描述性的信息，也不应该包含除 数字度量字段及使事实与纬度表中对应项的相 关索引字段之外的任何数据 3、可以累计的度量值，最有用的度量值是可累 计的度量值，其累计起来的数字是非常有意义 的，用户可以通过累计度量值获得汇总信息 4、非累计的度量值可以用于事实数据表，单汇 总结果一般是没有意义的，但是求平均值是有 意义的。
时间维
01事实表
用来存储事实的度量 和各维的码值
举例
定义
事实表
事务事实表 Transaction fact table 周期快照事实表 Periodicsnapshot fact table 累积快照事实表 Accumulatingsnapshot fact table
分类
事务事实 周期快照事实 累积快照事实
数据进行分析时所用的量，可 有多个维度，不超15个

⼤数据：事实表设计⽬录：1. 事实表基础1. 事实表特征2. 事实表设计原则3. 事实表设计⽅法2. 事务事实表1. 设计过程2. 单事务事实表3. 多事务事实表4. 两事实表对⽐5. ⽗⼦事实的处理⽅式6. 事实的设计原则3. 周期快照事实表1. 特性2. 实例阐述周期快照事实表设计过程3. 注意事项4. 累积快照事实表1. 设计过程2. 特点3. 特殊处理4. 物理处理5. 三种事实表的⽐较6. ⽆事实的事实表7. 聚集型事实表1. 聚集的基本原则2. 聚集的基本步骤3. 阿⾥的公共汇总层4. 聚集补充说明⼀、事实表基础1、事实表特征事实表是围绕着业务过程来设计的，通过获取描述业务过程的度量来表达业务过程，包含了引⽤的维度和与业务过程有关的度量；事实表的作⽤：度量业务过程；事实表的粒度：事实表中，⼀条记录所表达的业务细节程度；事实表中，所有事实需要与表定义的粒度保持⼀致，在同⼀个事实表中，不能有多种不同粒度的事实；粒度的表述⽅式：1. 维度属性组合所表⽰的细节程度；（⼀般适⽤于 “聚集性事实表”）2. 所表⽰的具体业务含义；事实的类型：为整型或浮点型的⼗进制数，有三种事实类型：1. 可加型事实：可以按照与事实表相关的任意维度汇总，且汇总结果有意义；2. 半可加型事实：只能按照特定维度汇总，不能对所有维度获得有意义的汇总；（如，事实可以进⾏汇总相加，但是汇总结果没有意义）3. 不可加型事实：完全不具有可加性，⽐如⽐率型事实；对于不可加性的事实，可以分解为可加的组件来实现聚集；退化维度：存储在事实表中的维度列；退化维度也可以⽤来进⾏事实表的过滤查询、实现聚合操作等；事实表的 3 种类型：1. 事务事实表也称原⼦事实表，描述业务过程，跟踪控件或时间上某点的度量事件，保存的是最原⼦的数据；2. 周期快照事实表以⼀个周期为时间间隔，来记录事实，⼀般周期可以是每天、每周、每⽉、每年等；3. 累积快照事实⽤来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个⽣命周期，通常具有多个⽇期字段来记录关键时间点；当过程随着⽣命周期不断变化时，记录也会随着过程的变化⽽被修改；2、事实表设计 8 ⼤原则原则 1：尽可能包含所有与业务过程相关的事实分析哪些事实与业务过程相关，是设计过程中⾮常重要的关注点；在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太⼤；原则 2：只选择与业务过程相关的事实如，订单的下单这个业务过程，事实表中不应该存在⽀付⾦额这个表⽰⽀付业务过程的事实；原则 3：分解不可加性事实为可加的组件如，订单的优惠率，应分解为订单原价⾦额与订单优惠⾦额两个事实存储在事实表中；原则 4：在选择维度和事实之前必须先声明粒度粒度⽤于确定事实表中⼀⾏所表⽰业务的细节层次，决定了维度模型的扩展性；每个维度和事实必须与所定义的粒度保持⼀致；设计事实表时，粒度定义越细越好，⼀般从最低级别的原⼦粒度开始；因为原⼦粒度提供了最⼤限度的灵活性，可以⽀持⽆法预期的各种细节层次的⽤户需求；原则 5：在同⼀个事实表中不能有多种不同粒度的事实疑问：怎么判断不同事实的粒度是否相同？例：⼀个不规范的 “机票⽀付成功事务事实表”粒度为票⼀级；（实际业务中，⼀个订单可以同时⽀付多张票）票⽀付⾦额和票折扣⾦额，两个事实的粒度为 “票级”，与定义的粒度⼀致；订单⽀付⾦额和订单票数，两个事实的粒度为 “订单级”，属于上⼀层订单级数据，与 “票级” 事实表的粒度不⼀致，且不能进⾏汇总；如果，以订单⾦额和订单票数这两个维度汇总总⾦额和总票数，会造成⼤量的重复计算；原则 6：事实的单位要保持⼀致如，订单⾦额、订单优惠⾦额、订单运费这 3 个事实，应该采⽤统⼀的计量单位，统⼀为元或者分，以⽅便使⽤；原则 7：对事实的 null 值要处理原因：在数据库中，null 值对常⽤数字型字段的 SQL 过滤条件都不⽣效；如，⼤于、⼩于、等于、⼤于或等于、⼩于或等于；处理：⽤ 0 代替 null ；原则 8：使⽤退化维度提⾼事实表的易⽤性1. 事实表中存储各种类型的常⽤维度信息，较少下游⽤户使⽤时关联多个表的操作；2. 通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；易⽤性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；在 Kimball 的维度建模中，通常按照星形模型的⽅式设计，通过事实表的外键关联专门的维表，这种⽅式来获取维度，谨慎使⽤退化维表；这与⼤数据领域的事实表设计不⼀样；思路：通过增加冗余存储，减少计算开销，提⾼使⽤效率；3、事实表设计⽅法Kimball 的维度模型设计 4 步法：选择业务过程、声明粒度、确定维度、确定事实；当前的互联⽹⼤数据环境，维度模型的设计，是基于 Kimball 的四步维度建模⽅法进⾏了更进⼀步的改进：第⼀步：选择业务过程及确定事实表类型思路：详细分析需求，对业务的整个⽣命周期进⾏分析，明确关键的业务步骤，从⽽选择与需求有关的业务过程；以实例说明：如何选择业务过程？如何确定事实表类型？例：淘宝的⼀个交易订单1. 分析业务的⽣命周期：如上图，业务过程通常使⽤⾏为动词表⽰业务执⾏的活动；2. 明确关键的业务步骤：该订单流转的业务过程有 4 个：创建订单→买家付款→卖家发货→买家确认收货；3. 根据业务需求，选择与维度建模有关的业务过程；如，是选择 “买家付款” 这个业务过程，还是选择 “创建订单” 和 “买家付款” 这两个业务过程，具体根据业务情况来定；4. 根据所选的业务过程确定事实表类型；如，选择 “买家付款” 这个业务过程，则事实表类型应为只包含买家付款这⼀个业务过程的 “单事务事实表”；如，选择了所有 4 个业务过程，并且需要分享各业务过程的时间间隔，则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”；第⼆步：声明粒度粒度的作⽤：1. 粒度的声明，意味着精确定义事实表的每⼀⾏所表⽰的业务含义；2. 明确的粒度能够确保对实表中⾏的意思的理解不会产⽣混淆，保证所有的事实按照同样的细节层次记录；粒度的选择：尽量选择最细级别的原⼦粒度，以确保事实表的应⽤具有最⼤的灵活性；1. 灵活性：⽀持⽆法预期的各种细节层次的⽤户需求；2. 对于订单级别，粒度可以定义为最细的订单级别；（如，⽗⼦订单，事实表的粒度可以定 “⼦订单级别” ；）第三步：确定维度完成了粒度声明，就意味着确定了主键，对应的维度组合以及相关的维度字段也可以确定了；选择维度的原则：应该选择能够描述清楚业务过程所处的环境的维度信息；如，淘宝订单 “付款事务事实表” 中，粒度为 “⼦订单”，相关的维度有买家、卖家、商品、收货⼈信息、业务类型、订单时间等；第四步：确定事实确定原则：选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度⼀致；思路：可以通过回答 “过程的度量是什么” 来确定；注意：将不可加性事实分解为可加的组件；（分解的原则：可以通过分解后的可加的属性值，计算得到不可加性事实）第五步：冗余维度冗余维度：给事实表添加下游⽤户常⽤的维度；作⽤：1. 提⾼下游⽤户使⽤效率，降低数据获取的复杂性；2. ⽅便实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从等操作；⼆、事务事实表事实事务表：也称原⼦事务表，跟踪控件或时间的某点的度量事务，确保最原⼦的数据；任何类型的时间都可以被理解为⼀种事务；如，交易过程中的创建订单、买家付款；物流过程中的揽活、发货、收件；退款过程中的申请退款、申请⼩⼆介⼊等；都可以被理解为⼀种事务；事实事务表，就是针对这些事务的过程构建的⼀类事实表，⽤以跟踪定义业务过程的个体⾏为，提供丰富的分析能⼒，作为数据仓库原⼦的明细层数据；1、设计过程以 “淘宝交易事务事实表” 为例，阐述事务事实表的⼀般设计过程：　1/1）选择业务过程淘宝交易订单的流转过程，⼀共有 4 个重要过程：创建订单、买家付款、卖家发货、买家确认收货，即下单、⽀付、发货、成功完结4 个业务过程；淘宝交易事务事实表的设计，应着重从这 4 个业务过程展开；Kimball 维度建模理论认为，为了便于进⾏独⽴的分析研究，应该为每个业务过程建⽴⼀个事实表；　1/2）确定粒度业务过程选定后，要针对每个业务过程确定⼀个粒度，即确定事务事实表每⼀⾏所表达的细节层次；1. 详细分析业务细节两类卖家：⼀类是没有店铺的，出售闲置的或⼆⼿的；⼀类是有店铺的，出售新商品；两种交易⽅式：⼀种是选定商品直接购买，产⽣⼀个交易订单；⼀种是将多种商品先加⼊购物车，然后⼀起结算，此时每个商品都会产⽣⼀个订单，同时对于同⼀个店铺额外产⽣⼀个订单，即⽗订单；1. 同⼀家店铺购买的多种商品，⽗订单会承载订单物理、店铺优惠等信息；2. ⼦订单记录了⽗订单的订单号，并且有⼦订单标志；（如，下图 11.3）3. 如果⼀个店铺只购买⼀种商品，⼦订单即为⽗订单，两者合并，只保留⼀条记录；（如，下图 11.2）2. 为事务事实表确定粒度四个重要业务过程，要对每⼀个过程确定⼀个粒度：下单、⽀付、成功完结三个业务过程，选择交易⼦订单粒度，即每个⼦订单为事务事实表的⼀⾏；卖家发货，这个业务在实际中更多的是 “物流单粒度” ，⽽⾮ “⼦订单粒度”，同⼀个⼦订单可以拆开成多个物流单进⾏发货；秉承“确定最细粒度原则”，对于 “卖家发货” 确定为 “物流单粒度”；　1/3）确定维度1. 按照经常⽤于统计分析的场景，确定维度包含：买家、卖家、商品、商品类⽬、发货地区、收货地区、⽗订单维度、杂项维度；2. 杂项维度，由于订单的属性较多，如，订单的业务类型、是否⽆线交易、订单的 attributes 属性等，对于这些使⽤较多却⼜⽆法归属到上述维度的属性，则要新建⼀个杂项维度进⾏存放；PK（Primary Key）：主键；FK（ Foreign Key）：外键；（指其它⼦维表的主键，相对于主维表来说是主维表的外键）　1/4）确定事实作为过程度量的核⼼，事实表应该包含与其描述过程（下单、⽀付、成功完结，三个主要过程）有关的所有事实；逐个业务过程进⾏分析：由于粒度是⼦订单，⽗订单上的⾦额需要分摊到⼦订单上，如⽗订单邮费、⽗订单折扣等；（怎么分摊呢）1. 下单业务过程：下单⾦额、下单数量、下单分摊⾦额（也就是⼦订单商品⾦额）；2. ⽀付业务过程：⽀付⾦额、分摊邮费、折扣⾦额、红包⾦额、积分⾦额；3. 完结业务过程：确定收货⾦额；　1/5）冗余维度冗余维度：将常⽤的维度退化到事实表中；便于下游更⽅便的使⽤：过滤查询、统计聚合等；将买家星级、卖家星级、标签、店铺名称、商品类型、商品特征、商品属性、类⽬层级等常⽤维度属性，都冗余到事实表中；Kimball 维度建模理论建议，在事实表中只存放个维表的外键（也就是各个维度表⾃⼰的主键，只是相对于事实表，称它们为外键）　1/6）其它在设计过程中遗留⼀个问题，对于单⼀事实表中是否包含多个业务过程，还没有给出定论；2、单事务事实表单事务事实表：针对每⼀个业务过程设计⼀个事实表；优点：⽅便的对每个业务过程进⾏独⽴的分析研究；以阿⾥的 1688 交易流程为例：1. 选择业务过程1688 交易流程也分为 4 个主要业务过程：下单、⽀付、发货、完结；1688 交易选择下单和⽀付两个业务过程设计事务事实表，分别是：1688 交易订单下单事务事实表、1688 交易订单⽀付事务事实表；2. 对每个业务过程确定粒度、维度、事实1688 交易订单下单事务事实表：1. 粒度：⼦订单级粒度；2. 维度：买家、卖家、商品、⽗订单、收货地区等；3. 事实：下单分摊⾦额、折扣⾦额等；1688 交易订单⽀付事务事实表：1. 粒度：⼦订单级粒度；2. 维度：买家、卖家、商品、⽗订单、收货地区等；3. 事实：⽀付⾦额、⽀付调整⾦额、⽀付优惠等；3. 详情实例每天的下单记录进⼊当天的下单事务事实表中，每天的⽀付记录进⼊当天的⽀付事务事实表中；由于事实表具有稀疏性质，因此只有当天数据才会进⼊当天的事实表中；3、多事务事实表多是为事实表：同⼀个事实表包含多个不同的业务过程；两种事实处理⽅式：1. 不同业务过程的事实，使⽤不同的事实字段存放；2. 不同业务过程的事实，使⽤同⼀个事实字段存放，但增加⼀个业务过程标签；以淘宝交易事务事实表和淘宝收藏商品事务事实表为例，阐述多事务事实表设计过程：　3/1）淘宝交易事务事实表设计过程1. 分析交易流程，选择主要业务过程四个主要业务过程：下单、⽀付、发货、完结；2. 确定每个业务过程的粒度下单业务过程：⼦订单粒度；⽀付业务过程：⼦订单粒度；发货业务过程：物流单粒度；（由于 “物流单粒度” ⽐ “⼦订单粒度” 更细，秉承 “最细粒度原则”，选择 “物理粒度”；成功完结业务：⼦订单粒度；3. 确定事实表数量相同粒度的业务过程存放到同⼀个事实表中：淘宝交易事务事实表（存放下单、⽀付、完结业务数据）、淘宝交易物理事务事实表（存放发货业务数据）；4. 确定维度和事实1. 确定维度分别分析统计各个业务过程的维度；将同⼀事实表中的业务的维度合并汇总；（不同的业务过程的维度，将含义相同的维度同⼀为⼀个维度）冗余常⽤维度到事实表中；2. 确定事实1. 分别分析统计各个业务过程中的相关事实；2. 处理不同业务的事实：针对每个度量都使⽤⼀个字段进⾏保存，即不同的事实永不不同的字段保存；如果不是当前业务的度量，采⽤零值处理；（如，下单业务过程，⽀付度量和成功完结度量全部置为 0 ；）3. 在事实表中，对不同业务过程进⾏标记淘宝交易事务事实表中包含 3 个业务过程，下单、⽀付、完结，则在事实表中添加：是否当天下单、是否当天⽀付、是否当天完结，3 种标签；　3/2）淘宝收藏商品事务事实表设计过程1. 业务分析确定业务过程：收藏商品、删除商品；2. 确定粒度思想：⽆论是收藏商品还是删除商品，都是⽤户对商品的操作，因此两个业务过程的粒度都可以确定为：⽤户加上商品；“⽤户加上商品”，根据该粒度，可以很直观的连接业务过程，即为收藏业务；3. 确定维度和事实1. 确定维度收藏商品业务过程：⽤户、商品；删除商品业务过程：⽤户、商品；冗余常⽤维度：商品类⽬、商品所属卖家等；2. 确定事实收藏商品业务过程和删除双排业务过程，它们的事实主要是商品价格；事实处理：使⽤功能同⼀个字段存放不同业务过程的事实；扩展：⼀般收藏事务表更多的是⽆事实的事实表，⽤于统⼀收藏或删除次数的；　3/3）多事务事实表的选择当不同业务过程的度量⽐较相似、差异不⼤时，可以采⽤上述的第⼆种多事务事实表的设计⽅式（淘宝收藏事务事实表），使⽤同⼀个字段来表⽰度量数据；存在问题：在同⼀个周期内会存放多条记录；当不同业务过程的度量差异较⼤时，可以选择第⼀种多事务事实表的设计⽅式（淘宝交易事务事实表）；将不同业务过程的度量使⽤不同字段冗余到表中，⾮当前业务过程则置零表⽰；存在问题：度量字段零值较多；4、两种事实表对⽐多事务事实表与单事务事实表对⽐分析：　4/1）业务过程单事务事实表：⼀个业务过程建⽴⼀个事实表，只反映⼀个业务过程的事实；多事务事实表：同⼀个事实表中反映多个业务过程；多个业务过程是否能放在同⼀事实表：分析不同业务过程之间的相似性和业务源系统；业务过程相似性判断：根据不同业务过程的维度和事实的重合情况；如，淘宝交易系统中的下单、⽀付、成功完结这 3 个业务过程，存在相似性，都属于订单处理中的⼀环，并且都来⾃于交易系统；　4/2）粒度和维度如果不同业务的粒度相同，且同时拥有相似的维度时，可以选择多事务事实表；如果各个业务的粒度不同，则必须建⽴不同的事实表；　4/3）事实处理事实的⽅式不同：1. 单事务事实表，能⽅便灵活的处理事实，仅仅体现同⼀个业务过程的事实即可；2. 多事务事实表，由于有多个业务过程，所有需要处理更多的事实；事实表选择：如果单⼀业务过程的事实较多，同时不同业务过程的事实⼜不相同，则考虑使⽤单事务事实表；（如果使⽤多事务事实表，会导致事实表零值或空值⽐较多）　4/4）下游业务使⽤单事务事实表，对下游⽤户⽽⾔更容易理解，关注哪个业务过程就使⽤相应的事务事实表；多事务事实表，包含多个业务过程，⽤户使⽤时往往较为困惑；　4/5）计算存储成本当业务过程数据来源于同⼀个业务系统，具有相同的粒度和维度，且维度较多⽽事实相对不对时，可以考虑使⽤多事务事实表，不仅其加⼯计算成本低，在存储上也相对节省；　4/6）单事务事实表和多事务事实表的⽐较5、⽗⼦事实的处理⽅式1. 以⼦订单为粒度，分摊⽗订单的事实；2. 将所有业务过程的度量，全部带进事务事实表中，包含⽗事实，也⼀起冗余到事实表中；为了下游⽤户使⽤，也将粒度不同的⽗事实冗余到⼦粒度的事实表中；仅拥有⽗⼦事实的处理，可将不同粒度的事实冗余到⼀个事实表中；弱不是⽗⼦事实，且粒度不同，不能冗余同⼀个事实表；例：淘宝交易系统，在同⼀家店铺⼀次购买多个商品，每个商品都会产⽣⼀个订单，⽽这⼏个商品⼀起产⽣⼀个⽗订单；⽗订单事实：订单总额、⽀付总额、⽀付邮费等；确定粒度：根据粒度最细原则，以⼦订单为粒度；以⼦订单为粒度，需要将⽗订单的事实进⾏分摊；将说有的事实（包括⽗订单的事实），全部冗余到淘宝交易事务事实表内；6、事实的设计准则　6/1）事实完整性事实表应包含与其描述的过程有关的所有事实，尽可能多的获取所有的度量；事实表中所有的事实，粒度必须⼀致；（⽗⼦事实除外）否则只能创建多个事实表，存放多种粒度的事实；　6/2）事实⼀致性在确定事务事实表时，明确存储每⼀个事实，以确保度量的⼀致性；度量⼀致性：度量单位⼀直、度量字段⼀直（是单字段还是组合字段）；如，在淘宝交易事务事实表中，是⽗⼦订单时，虽以⼦订单为粒度，但也要明确下单⾦额和下单有效⾦额；虽然下游⽤户可以通过⼦订单⽀付⾦额和⼦订单下单有效⾦额汇总计算，但是在事实表中统⼀计算可以保证度量的⼀致性；　6/3）事实可加性将⾮可加性事实拆成组合的可加性事实；如，分摊⽐例、利润率等，虽然它们也是下游分析的关键点，但往往在事务事实表中关注更多的是可加性事实，下游⽤户在聚合统计时更加⽅便；三、周期快照事实表作⽤：存储⼀些状态度量；状态度量：如账户余额、商品库存、卖家累积交易额等状态；数据的特点：⼀般需要聚合与之相关的事务，才能识别或者通过计算得到；背景：由于通过事务事实表的⼀些数据进⾏聚合得到这些状态度量时，效率⾮常低下，特别是事务事实表数据量⾮常⼤的时候；事实：随着时间变化，表中的每⼀⾏数据，都是截⾄当前采⽤周期时的最新状态度量；粒度：⼀般可以⽤采样周期以及什么将被采样作为周期快照事实表的粒度；⼀般采⽤的内容是⼀个或多个维度，所以周期快照事实表的粒度通常也是被多维声明的；存储过程：（例：卖家历史⾄今下单⾦额）1. 采样，也就是聚集⼀个周期内产⽣的所有交易订单，统计计算这些订单的下单⾦额总和；2. 将本周期内采样汇总的数据，与历史截⾄上⼀周期的卖家下单总⾦额，进⾏汇总；3. 将汇总的⾦额存储在周期快照事实表中；（即每⾏的数据：历史截⾄该⾏所在周期的卖家下单⾦额）事务事实表可以很好的跟踪⼀个事件，并对其进⾏度量，以提供丰富的分析能⼒；背景：当需要⼀些状态度量，如，账户余额、买卖家星级、商品库存、卖家累积交易额等，则需要聚集与这些状态度量相关的⼀些事物，进⾏统计计算分析才能得到；或者通过聚合事物也⽆法识别这些状态量；对于这些状态量，事物事实表是⽆效率的；例：卖家累积交易⾦额，如果需要查看卖家年初⾄今，⼀长时间段的交易额，使⽤事务事实表进⾏统计汇总可以得到，但是随着时间跨度变⼤，聚集效率会越来越低；周期快照事实表：也称 “快照事实表”，在确定的时间间隔内，对实体的度量进⾏抽样，这样可以很容易的研究实体的度量值，⽽不需要聚集长期的事务历史；事实表中的事实，以周期为间隔记录⼀⾏，每次记录的事实都是历史⾄今的汇总数据或者统计计算后的数据；快照事实表在阿⾥数据仓库中的设计和应⽤：以淘宝交易结束后的评价数据、卖家的累积⽀付⾦额、买卖家星级等事实表的设计为例；周期快照事实表的 2 种产出模式（或者说从哪⾥采样数据，具体使⽤哪种⽅式，要看采样数据的来源）：1. 从事务事实表进⾏汇总产出；（常见产出模式）2. 直接使⽤操作型系统的数据，作为周期快照事实表的数据源进⾏加⼯；（如，淘宝卖家星级、卖家 DSR 事实表等）1、特性与事务事实表对⽐：粒度：事务事实表的粒度能以多种⽅式表达，快照事实表的粒度通常以维度形式声明；事务事实表是稀疏的，但是快照事实表是稠密的；事实：事务事实表中的事实是完全可加的，但快照模型将⾄少包含⼀个⽤来展⽰半可加性质的事实；　1/1）⽤快照采样快照事实表周期性的采样状态度量；快照周期联合⼀个或多个维度，将被⽤来快照事实表的粒度，事实表的每⾏都将包含记录所涉及状态的事实；例：淘宝交易卖家⾃然年汇总事实表；业务需求：淘宝活动运营⼩⼆或者卖家，需要经常查看⼀些交易状态数据，如，⾃然年⾄今的下单⾦额、⽀付⾦额、⽀付买家数、⽀付商品件数等状态度；对于卖家，可能每天早上都想看⼀下截⾄昨天的成交情况；对于⼩⼆，可能在频繁的活动周期就需要查看⼀次成交情况；如果使⽤事务事实表进⾏聚集，带来的问题是：随着时间跨度增⼤，聚集效率会越来越低；因此需要设计快照事实表进⾏状态的度量；采⽤周期：天；下图所⽰的快照事实表，记录了每个卖家的下单和⽀付情况：　1/2）快照粒度粒度：采⽤周期 + 样本内容；如，在淘宝交易卖家快照事实表中，粒度被理解为 “每天针对卖家的历史截⾄当⽇的下单⽀付⾦额进⾏快照”；相当于每天记录⼀次历史⾄今的下单⽀付总⾦额；事实表中的数据，每周期记录⼀⾏，每次记录的数据：历史⾄今的下单⽀付⾦额（销售总额）；快照周期根据业务需求情况⽽定，事实表维度也不只⼀个，还包括卖家和类⽬；　1/3）密度与稀疏性事务事实表是稀疏的：只有当天发⽣的业务过程，事实表才会记录该业务过程的事实，如下单、⽀付等；快照事实表是稠密的：⽆论当天是否有业务过程发⽣，都会记录⼀⾏；⽆论当天发⽣多少业务过程，也只会记录⼀⾏；如，针对卖家的历史⾄今的下单和⽀付⾦额，⽆论当天卖家是否有下单事实，都会给该卖家记录⼀⾏；稠密性的重要性：如果在每个周期内不记录⾏，就会和事务事实表⼀样，那么确定状态将变得⾮常困难；　1/4）半可加性快照事实表中收集到的状态度量都是半可加的；根据时间维度进⾏统计汇总的结果是没有意义的；半可加性事实：只能根据特定维度汇总，不能根据表的所有维度汇总，且汇总结果要有意义；虽不可以进⾏汇总，但可以计算⼀些平均值，如，⼀个周期内平均每个订单的平均⾦额；2、实例周期快照事实表设计过程设计步骤：1. 确定快照事实表的快照粒度；2. 确定快照事实表采⽤的状态度量；。

事实表设计的步骤
设计一个有效的事实表是构建数据仓库的重要部分。

以下是一些详细的步骤，可以帮助你设计一个优秀的事实表：
1. 深入理解业务需求：首先，你需要深入了解业务过程，明确事实表需要记录哪些信息。

例如，如果你正在设计一个销售事实表，你需要知道销售的具体业务过程，包括销售的产品、数量、价格、时间等。

2. 确定粒度：粒度是数据仓库中数据的最小单元。

在设计事实表时，你需要决定每一行应该代表什么。

一般来说，从最细的粒度开始设计，例如每个销售事务，然后根据需要上卷汇总。

这样可以确保数据仓库能够满足各种查询和报表需求。

3. 选择适当的维度：维度是描述数据特征的类别，例如时间、地点、产品等。

在设计事实表时，你需要选择能够描述清楚业务过程的维度信息。

例如，在销售事实表中，你可能需要包含时间维度、客户维度、产品维度和销售渠道维度等。

4. 考虑数据完整性：在设计事实表时，你需要考虑如何确保数据的完整性。

你可以通过添加约束、触发器或使用数据校验程序来实现这一点。

5. 优化性能：在设计和构建事实表时，还需要考虑性能问题。

你可以通过优化索引、分区和使用汇总表等方法来提高查询速度。

6. 反馈和迭代：最后，你需要将设计的事实表应用到实际业务场景中，并根据反馈进行迭代和优化。

以上是事实表设计的步骤。

希望这些步骤能够帮助你成功地构建出一个优秀的数据仓库事实表。

数据立方体模型总结数据立方体认识定义：数据立方体是一类多维矩阵，让用户从多个角度探索和分析数据集，通常是一次同时考虑三个因素（维度）。

数据立方体模型属于数据仓库的多维数据模型。

意义：当我们试图从一堆数据中提取信息时，我们需要工具来帮助我们找到那些有关联的和重要的信息，以及探讨不同的情景。

一份报告，不管是印在纸上的还是出现在屏幕上，都是数据的二维表示，是行和列构成的表格。

在我们只有两个因素要考虑时，这就足矣，但在真实世界中我们需要更强的工具。

数据立方体模型在预测趋势和分析业绩时，数据立方体是极其有用的。

数据立方体的构成:数据立方体由两个单元构成1）维度：因素 2）测度:实际的数据值建立数据立方体模型的方法（OLAP）OLAP（On-line Analytical Processing，联机分析处理）是共享多维信息的、针对特定问题的联机数据访问和分析的快速软件技术。

联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析操作，侧重对决策人员和高层管理人员的决策支持，可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理，并且以一种直观而易懂的形式将查询结果提供给决策人员，以便他们准确掌握企业（公司）的经营状况，了解对象的需求，制定正确的方案。

在国外，不少软件厂商采取了发展其前端产品来弥补关系数据库管理系统支持的不足，力图统一分散的公共应用逻辑，在短时间内响应非数据处理专业人员的复杂查询要求。

（拓展）当今数据处理大致分为两类：OLAP（On-line Analytical Processing，联机分析处理）OLTP(On-line Transaction Processing，联机事务处理），两者的区别：OLAP与OLTP数据处理类型面向对象功能实现数据模型数据量操作类型 OLTP 业务开发人员日常事务处理关系模型几条或几十条记录查询、插入、更新、删除 OLAP 分析决策人员面向分析决策多维模型百万千万条记录查询为主 OLAP的基本操作我们已经知道OLAP的操作是以查询――也就是数据库的SELECT操作为主，但是查询可以很复杂，比如基于关系数据库的查询可以多表关联，可以使用COUNT、SUM、AVG等聚合函数。

SQL_Server数据仓库相关概念-维度表和事实表概述基本概念：1.多维数据集：多维数据集是联机分析处理(OLAP) 中的主要对象，是一项可对数据仓库中的数据进行快速访问的技术。

多维数据集是一个数据集合，通常从数据仓库的子集构造，并组织和汇总成一个由一组维度和度量值定义的多维结构。

2.维度：是多维数据集的结构性特性。

它们是事实数据表中用来描述数据的分类的有组织层次结构(级别)。

这些分类和级别描述了一些相似的成员集合，用户将基于这些成员集合进行分析。

3.度量值：在多维数据集中，度量值是一组值，这些值基于多维数据集的事实数据表中的一列，而且通常为数字。

此外，度量值是所分析的多维数据集的中心值。

即，度量值是最终用户浏览多维数据集时重点查看的数字数据。

您所选择的度量值取决于最终用户所请求的信息类型。

一些常见的度量值有sales、cost、expenditures 和production count 等。

4.元数据：不同OLAP 组件中的数据和应用程序的结构模型。

元数据描述OLTP 数据库中的表、数据仓库和数据集市中的多维数据集这类对象，还记录哪些应用程序引用不同的记录块。

5.级别：级别是维度层次结构的一个元素。

级别描述了数据的层次结构，从数据的最高(汇总程度最大)级别直到最低(最详细)级别。

6.数据挖掘：数据挖掘使您得以定义包含分组和预测规则的模型，以便应用于关系数据库或多维OLAP 数据集中的数据。

之后，这些预测模型便可用于自动执行复杂的数据分析，以找出帮助识别新机会并选择有获胜把握的机会的趋势。

7.多维OLAP (MOLAP)：MOLAP 存储模式使得分区的聚合和其源数据的复本以多维结构存储在分析服务器计算机上。

根据分区聚合的百分比和设计，MOLAP 存储模式为达到最快查询响应时间提供了潜在可能性。

总而言之，MOLAP 更加适合于频繁使用的多维数据集中的分区和对快速查询响应的需要。

8.关系OLAP (ROLAP)：ROLAP 存储模式使得分区的聚合存储在关系数据库的表(在分区数据源中指定)中。

维度表示你要对数据进行分析时所用的一个量, 比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按..分析就构成一个维度。

前面的示例就可以有两个维度：类型和区域。

另外每个维度还可以有子维度（称为属性），例如类别可以有子类型，产品名等属性。

下面是两个常见的维度表结构：产品维度表：Prod_id, Product_Name, Category, Color, Size, Price时间维度表：TimeKey, Season, Year, Month, Date而事实表是数据聚合后依据某个维度生成的结果表。

它的结构示例如下：销售事实表：Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量，以货币计), Unit(销售量)上面的这些表就是存在于数据仓库中的。

从这里可以看出它有几个特点：1. 维度表的冗余很大，主要是因为维度一般不大(相对于事实表来说的)，而维度表的冗余可以使事实表节省很多空间。

2. 事实表一般都很大，如果以普通方式查询的话，得到结果一般发的时间都不是我们可以接受的。

所以它一般要进行一些特殊处理。

如SQL Server 2005就会对事实表进行如预生成处理等。

3. 维度表的主键一般都取整型值的标志列类型，这样也是为了节省事实表的存储空间。

事实表和维度表的分界线事实表是用来存储主题的主干内容的。

以日常的工作量为例，工作量可能具有如下属性：工作日期，人员，上班时长，加班时长，工作性质，是否外勤，工作内容，审核人。

那么什么才是主干内容？很容易看出上班时长，加班时长是主干，也就是工作量主题的基本内容，那么工作日期，人员，工作性质，是否外勤，工作内容是否为主干信息呢？认真分析特征会发现，日期，人员，性质，是否外勤都是可以被分类的，例如日期有年-月-日的层次，人员也有上下级关系，外勤和正常上班也是两类上班考勤记录，而上班时长和加班时长则不具有此类意义。

维度建模的基本概念及过程摘要：本文首先介绍维度模型中的维度表和事实表这2个基本构成要素的基础知识；其次，介绍设计维度模型的4个基本步骤；再次，围绕某银行为实现业务价值链数据集成的需要，介绍多维体系结构中的3个关键性概念：数据仓库总线结构、一致性维度、一致性事实。

关键词：维度表;事实表;维度模型设计过程;数据仓库总线结构;一致性维度;一致性事实。

引言: 与流行的说法不同，Ralph Kimball本人并没有定义“维度”和“事实”这样的术语。

术语“维度”与“事实”，最初是20世纪60年代在一个由General Mills与Dartmouth大学主持的联合研究计划中提出的。

70年代，AC Nielsen和IRI都一致地使用这些术语描述他们的数据发布应用，用现在更为准确的话来说，就是关于零售数据的维度数据集市（Data Mart）。

在简明性成为生活方式的潮流之前的长时期内，早期的数据库垄断组织们致力于将这些概念用来简化用做分析的信息。

他们意识到，除非数据库做得简单易用，否则没有人会用它。

因此，在将可理解性和性能作为最高目标的驱动下，产生了维度模型的构造思想。

1 维度表和事实表1.1 事实表事实表是维度模型的基本表，其中如图所示存放有大量的业务性能度量值。

力图将从一个业务处理过程得到的度量值数据存放在单个数据集市。

由于度量值数据压倒性地成为任何数据集市的最大部分，因此应该避免在企业范围内的不同地方存储其拷贝。

用术语“事实”代表一个业务度量值。

可以设想一个作为例子的情形：查询某个客户在某个机构下某个产品合约账户的某个币种的某个时点余额，在各维度值(客户、产品合约、账户、机构、币种、日期)的交点处就可以得到一个度量值。

维度值的列表给出了事实表的粒度定义，并确定出度量值的取值范围是什么。

事实表的一行对应一个度量值，一个度量值就是事实表的一行；事实表的所有度量值必须具有相同的粒度。

最有用的事实是诸如账户余额这样的数字类型为可做加法的事实。

数仓事实表和维度表事实表（Fact Table）和维度表（Dimension Table）是构建数据仓库的两个基本组成部分。

事实表含有数据仓库所分析的业务事实数据，维度表包含了描述事实表中数据的相关维度属性。

事实表是数据仓库中的核心组件，存储了与业务过程或事件相关的数值度量。

它通常是一个大型的记录集合，每个记录代表一个特定的业务事实，例如销售额、订单数量、客户数量等。

事实表的主要特点包括以下几点：1. 事实表通常是较大的表，因为它包含了大量的事实数据。

这些数据通常是高度汇总的，以支持各种分析需求。

2. 事实表是高度粒度化的，即它存储了最详细的业务事实数据。

例如，每个销售订单的具体信息都可以被存储在事实表中。

3. 事实表是和时间相关的，它可以基于时间分析业务过程的变化和趋势。

时间维度的属性通常作为事实表的一部分，以支持时间序列的分析。

维度表提供了对事实表中数据进行详细描述和解释的属性。

它是事实表的关联表，通过一个或多个维度将数据与事实表进行关联。

维度表的主要特点包括以下几点：1. 维度表描述了事实表中数据的上下文信息，提供了多维度的分析能力。

例如，对于销售事实表，维度表可以包含产品维度、时间维度、地理维度等等。

2. 维度表通常是相对较小的表，因为它包含的是对事实记录的描述性属性。

通常情况下，维度表中的每一行对应着一个唯一的维度值。

3. 维度表是稳定的，它的数据相对不太频繁地变动。

例如，产品维度表一般不会频繁更新，只有在新增产品或者修改产品属性时才需要更新。

事实表和维度表之间通过关系建立了数据仓库的模型，常见的有星型模型和雪花模型。

在星型模型中，事实表与多个维度表直接关联；而在雪花模型中，维度表可以再被分解为更细粒度的表，以实现更多复杂的维度关联关系。

通过事实表和维度表的组合，数据仓库可以支持各种复杂的多维度分析需求。

事实表存储了数值化的业务事实数据，而维度表提供了对这些数据进行描述和解释的属性。

通过对事实表和维度表进行查询和分析，可以获得对业务过程的深入理解，发现隐藏在数据背后的规律和趋势。