观察数据的角度称之为维。
决策数据市多为数据，多维数据分析是决策分析的组要内容。
OLAP是在OLTP的基础上发展起来的，OLTP是以数据库为基础的，
面对的是操作人员和底层管理人员，对基本数据进行查询和增，删，改等处理。
OLAP是以数据仓库为基础的数据分析处理，它有两个特点：
1.在线性，体现为对用户请求的快速响应和交互式操作，它的实现是由
客户/服务器这种体系结构来完成的；
2.多维分析，也是OLAP的核心所在。
OLAP：一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，
以达到深入理解数据的目的。这些信息是从原始数据转换过来的，按照用户的理解，
它反应了企业真实的方方面面。
OLAP：四个特征
1.快速性（Fast）5秒内对用户的大部分分析要求做出反应，小于30秒内。
2.可分析性（Analysis）
3.多维性（Multidimensional）包括对层次维和多重层次维的完全支持。
4.信息性（Information）
OLAP的基本概念
OLAP是针对特定问题的联机数据进行访问和分析。
1.变量：是一个数值度量指标。
2.维：是人们观察数据的特定角度。
例如：企业常常关系产品销售数据随着时间推移而产生的变化情况，
这是从时间的角度来观察产品的销售，所以时间是一个维（时间维）。
企业也时常关心自己的产品在不同地区的销售分布情况，这是从地理分布的角度来观察
产品的销售，所以地理分布也是一个维（地理维）。其他还有如产品维，顾客维等。
3.维的层次
人们观察数据的某个特定角度（即某个维）还可以在细节程度不同的多个描述方面，我们
称这多个描述方面为维的层次。一个维往往具有多个层次，例如，描述时间维时，可以从
日期，月份，季度，年等不同层次来描述，那么日期，月份，季度，年等就是时间维的层次；同样城市，地区，国家等构成了地理维的层次。
4.维成员
维的一个取值称为该维的一个成员。如果一个维是多层次的，那么该维的维成员是有各个
不同维层次的取值组合而成。例如，我们考虑时间维具有日期，月份，年这三个层次，分别在日期，月份，年上各取一个值组合起来，就得到了时间维的一个维成员，即“某年某月某日”。
一个维成员并不一定在每个维层次上都要取值，例如，“某年某月”，“某月某日”，“某年”等等都是时间维的维成员。
对应一个数据项来说，维成员是该数据项在某维中位置的描述。例如，对一个销售数据来说，时间维的维成员“某年某月某日”就表示该销售数据是“某年某月某日”的销售数据，
“某年某月某日”是该销售数据在时间维上位置的描述。
5.多维数组
一个多维数组可以表示为：（维1，维2，......，维n，变量）。例如，若日用品销售数据是按时间、地区和销售渠道组织起来的三维立方体，加上变量“销售额”，就组成了一个多维数组（地区，时间，销售渠道），如果在此基础行再扩展一个产品维，就得到一个四维的结构，其多维数组维（产品，地区，时间，销售渠道，销售额）。
6.数据单元（单元格）
多维数组的取值称为数据单元。当多维数组的各个维都选中一个维成员，这些维成员的组合就惟一确定了一个变量的值。那么数据单元就可以表示为：（维1维成员，维2维成员，......，维n维成员，变量的值）。例如，在产品，地区，时间和销售渠道上各取维成员“牙膏”，“上海”，“1998年12月”和“批发”，就惟一确定了变量“销售额”的一个值（假设为100000），则该数据单元可表示为：（牙膏，上海，1998年12月，批发，100000）。
OLAP是一项给数据分析人员以灵活，可用和及时的方式构造、处理和表示综合数据的技术。
OLAP技术可以在数秒中（通常是5~30秒）完成分类查询。
OLAP主要是关于如何理解聚集的大量的数据。
OLAP的目的就是分析这些数据，寻找模式，趋势以及例外情况。
联机分析处理特征：
1.可以存取大量的数据，比如，几年的销售数据，分析各个商业元素
类型之间的关系，如销售，产品，地区，渠道。
2.要包含聚集的数据，例如，销售量，预算金额以及消费金额。
3.按层次对比不同时间周期的聚集数据，如以月，季度或者年。
4.以不同的方式来表现数据，如以地区，或者每一地区内按不同销售渠道，不同产品等。
5.要包含数据元素之间的复杂的计算，如在某一地区的每一销售渠道的期望利润与销售收入之间的分析。
6.能够快速地响应用户的查询，以便用户的分析思考过程不受系统影响。
基本的多维数据分析概念包括切片，切块，旋转等。
1.切片和切块（Slice and Dice）
选定多维数组的一个二维子集的操作叫做切片，即选定多维数组（维1，维2，......,维n,变量）中的两个维，如维i和维j，称这个二维子集为多维数组在维i和维j上的一个切片，表示为（维i，维j，变量）
切片就是在某两个维上取一定区间的维成员或全部维成员，而在其余的维上选定一个维成员的操作。
维是观察数据的角度，那么切片的作用或结果就是舍弃一些观察角度，使人们能在两个维
上集中观察数据。人的空间想象能力有限，一般很难想象思维四维以上的空间结构。所以，对于维数较多的多维数据空间，数据切片市十分有意义的。
切块可以看成是切片的基础上，进一步确定各个维成员的区间得到的片段体，即是由多个切片叠合起来。
对于时间维的切片（时间取一个确定值），如果将时间维上的取值设定为一个区间（例如，取“1990年~1999年”），而非单一的维成员时，就得到一个数据切块，它可以看成时有1990年~1999年10个切片叠合而成的。
2.钻取（Drill）
钻取有向下钻取（Drill Down）和向上赚取（Drill Up）操作。
向下钻取是使用户在多层数据中能通过导航信息而获得更多的细节性数据，而向上钻取是获取概括性的数据。
Drill的深度与维所划分的层次相对应。
3.旋转（Pivoting）
通过旋转可以得到不同视角的数据。旋转操作相当于平面数据将坐标轴旋转。
例如，旋转可能包含了交换行和列，或是把某一行维移到列维中去，或是把页面显示中的一个维和页面外的维进行交换（令其成为新的行或列中的一个）。
广义OLAP
1.基本代理操作
“代理”是一些智能性代理，当系统处于某种特殊状态时提醒分析员。
（1）示警报告
定义一些条件，一旦条件满足，系统会提醒分析员去做分析，如每日报告完成或月定货完成后通知分析员作分析。
（2）时间报告
按日历和时钟提醒分析员。
（3）异常报告
当超出边界条件时提醒分析员，如销售情况已超出定义阈值的上限或下限时提醒分析员。
OLAP工具评价指标
特征和功能
OLAP是一种分析处理技术，它通过计算公式和转换规则从现有的数据中生存新的信息，并
予以显示。OLAP服务器和工具应能完成一下功能：
支持多维和维中的层次；
沿单个维或沿一组所选维来聚集、概括、预计算和导出数据；
相对一个维或一组选中的维提供计算逻辑、公式和分析例程；
支持分析模型的概念：分析模型是一组选中的维及维的元素，计算逻辑，公式，分析例程、聚集数据，概况数据、导出数据等。
提供丰富的库函数；
提供强大的计算和比较分析能力，例如：分级，比较，归类百分比，极大值，极小值，平均值，按时期的比较等。
进行跨维计算，例如，在面向电子表格的应用程序中进行进行行级别的计算等；
提供时间相关的智能，例如：按日期划分的年，跨域给定时间段的日历，当前时期、财政的和内部的日历等；
从一个维到另一个维进行转换，它在合并或获取数据后特别有用；
导航并分析，它采用沿单个或多个维的轴以及交叉表等来进行细剖和统揽的方法。
这些操作应满足用户分析是的要求，分析过程应是平滑的，连贯的。
--------------------------------------------------------------
数据仓库工具箱-笔记
1.数据仓库必须使组织机构的信息变得容易存取。
数据仓库的内容必定使容易理解的，数据对于业务人员也必定使直观的、明显的，而
不能仅仅对开发人员来说是这样。
容易理解意味着容易阅读，而数据内容在标识方面应该是见名知义的。
数据仓库存取工具必须简单易用，并以最短的延迟时间将查询结果返回给用户。
2.数据仓库必须一致地展示组织机构的信息。
数据仓库中的数据必须是可信的。
它必须通过机构的各种渠道收集得到并精心组织起来，必须经过整理，具有质量保证并且
在量上满足了用户需求的情况下才进行发布。
3.数据仓库必须具有广泛的适应性和便于修改。
修改是不可回避的。
数据仓库在设计上要能够处理这种不可避免的变化。
4.数据仓库必须发挥安全堡垒作用以保护信息资产。
5.数据仓库必须在推进有效决策方面承担最基本的角色。
数据仓库必须维决策的定制提供正确的数据支持，数据仓库有且仅有一个正确的输出--由
数据仓库提供的依据而制定的决策。
6.数据仓库为业务群体所接受的前提是被认定是成功的。
维度模型是为数据仓库用户提交数据的最可行的技术手段。
维度建模相对以往那种着力构造简单而可理解的数据库的技术手段而言，是一个新名称。
将业务设想成一个将分别标记为产品、市场与时间的数据立方体，显得比较直观。
能够想象得出，沿各个维度方向对立方体进行切割所得到的结果：立方体中的点对应于一个产品、市场和时间组合的度量值。
建模时一种以消除数据冗余为追求目标的设计技术，在这里，数据被划分成许多离散的实体，而每个实体形成关系数据库中的一个表。
数据仓库总线的基础：所有数据中心必须采用共同的维度和事实来建造，即要求它们时一致的。
使用总线结构是构造分布式数据仓库系统的秘诀。
数据仓库可查询展示环节的数据必须是维度的、原子的和依附数据仓库总线结构的。
如果展示环节是建立在关系数据库的基础之上的，则这些按维度形式建立起来的表格被称做星型图。
如果建立在维度数据库或者在线分析处理（OLAP,Online Analystic Processing）技术基础之上，则数据就存储在立方体中。
维度建模既可以用于关系数据库，有可以用于维度数据库。两者在可辩别的维度方面具有共同的逻辑设计，但在物理实现方面是不同的。
元数据指的是数据仓库环境中除去数据本身之外的所有信息，它是数据仓库的百科全书的同义词。
操作数据的存储（ODS,Operational Data Store）
由于没有ODS的统一定义，属于那个部分与否由具体情况而定。
ODS经常需要更新，并在某种意义上讲就是操作数据的复制集成，其更新频率与集成程度随特定要求而不同。无论如何，这里的“O”都可以看成是“操作”字眼的同义词。
事实表
事实表是维度模型的基本表，其中存放由大量的业务性能度量值。
用术语“事实”代表一个业务度量值。
例子：
站在市场中观察产品的销售情况，并记录下每个商店每种产品每天的的销售数量和销售额。在各维度值（日期，产品，商店）的交点处就可以得到一个度量值。
维度值的列表给出了事实表的粒度定义并确定出度量值的取值范围是什么。
事实表的一行对应一个度量值，一个度量值就是事实表的一行。事实表的所有度量值必须有相同的粒度。
最有用的事实是诸如销售额这样的数字类型与可做加法的事实。
事实表中最有用的事实是数字类型与可加型事实。
将事实描述成是可连续取值的主要目的在于，作为一个指南帮助设计者区分出相对于维度属性来说的事实的实质。
销售额是连续取值的，在于它实际上可以取得一个很宽范围内的任何值。
作为观测人员，必须在得到确切的取值之前老老实实地站在市场上等待度量值。
度量事实在理论上将可以是文本形式的，不过这种情况很少见。
在大多数情况下，文本度量值可以是某种事物的描述并且取自某个离散列表的值。
设计者应该尽各种努力将文本度量值转换成维度，原因在于维度你能够与其它文本维度属性更有效地关联起来，并且消耗少得多的空间。不能将冗余的文本信息存放在事实表内。
除非文本对于事实表的每行来说都是惟一的，否则它应该归属到维度表中。
事实表倾向于具有更多的行和更少的列。
事实表粒度都归属于三类之一：事务，周期快照与累积快照。
所有事实表有两个或者两个以上的外关键字，外关键字用于连接到维度表的主关键字。
事实表要通过与之相连的维度表进行存取。
事实表本身通常也由外关键字子集组成的自己的主关键字，这个关键字通常称作复合或者连接关键字。
维度模型中每个事实表都有一个符合关键字，反过来，具有一个复合关键字的表也是一个事实表。
在维度模型中每个表示多对多关系的表都事实表，而所有其他的表都是维度表。
在维度模型中，事实表表示维度间多对多的关系。
一个数据字段到底应该作为事实还是维度属性看待：
通常可以这样做出决定：
看字段是一个含有许多的取值并参与运算的度量值（当事实看待），还是
一个多少变化不多并参与作为约束条件的离散取值的描述（当维属性看待）。
维度表时常描述业务中的层次关系。
维度表一般是很不规范化的，通常也非常小（少于所需数据存储总容量的10%）。
事实与维度的融合
维度属性提供了生成报表标签的内容，而事实表则提供了报表的数字型取值。
展示环节的数据应该是维度形式的。
维度模型与规范化模型之间存在着一种自然的关系。单个规范化ER图通常分解为多个维度方案。
-----------------------------------------------------------------------------
零售营销
理解维度建模原理的最佳途径，是通过一系列切实的例子去进行实践。
四步维度设计过程
（1）选取要建模的业务处理过程。
业务处理过程是机构中进行的一般都由源数据收集系统提供支持的自然业务活动。
听取用户的意见是选取业务处理过程的效率最高的方式。
数据仓库中进行分析的性能度量值是从业务评测处理过程得来的。
典型的业务处理过程包括原材料购买、定货、运输、开票、库存与账目管理等。
业务处理过程并不是指业务部门或者职能。
通过将注意力集中放在业务处理过程方面，而不是业务部门方面，就能在机构范围内更加经济地提交一致的数据。
（2）定一业务处理的粒度。 事实表实际代表的内容
粒度定义意味着对各事实表实际代表的内容给出明确的说明。
粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。它给出了后面这个问题的答案：如何描述事实表的单个行？
典型的粒度定义包括：
顾客购物券上扫描设备一次拾取的分列项内容
医生开出的单据项目内容
个人登机通行证内容
仓库中每种产品库存水平的日快照
每个银行账号的月快照
（3）选定用于每个事实表行的维度。
维度所引出的问题是，"业务人员将如何描述从业务处理过程得到的数据？"
应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来。如果对粒度方面的内容很清楚，那么维度的确定一般是非常容易的。通过维度的选定，可以列出那些使每个维度丰满起来的离散的文本属性。
常见维度了例子包括：日期、产品、顾客、事务类型和状况等。
（4）确定用于形成每个事实表行的数字型事实。
事实的确定可以通过回答“要对什么内容进行测评”这个问题来进行。
业务用户在这些业务处理性能度量值的分析方面具有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。典型的事实是诸如订货量或者支出额这样的可加性数字数据。
千万要克服只看看源数据文件就对数据进行建模的偏向。
业务需求
维度模型
1.业务处理
2.粒度
3.维度
4.事实 （数据实际）
首先对业务进行描述，以使建立的维度与事实表更容易理解。
在对业务实例研究进行描述之后，现在就可以开始维度建模的设计工作了。
第一步:选取业务处理
设计工作的第一步使，通过将对业务需求的理解与对可用数据的理解组合起来而确定
建模的业务处理内容。
建立的第一个维度模型应该是一个最有影响的模型--它应该对最紧迫的业务问题做出回答，并且对数据的抽取来说使容易访问的。
第二部：定义粒度
一旦将业务处理确定下来，数据仓库团队下一个就面临关于粒度确定的颜色课题。
应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。
原子型数据是高度维结构化。事实度量值越细微并具有原子性，就越能够确切地知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。
原子型数据可为分析方面提供最大限度的灵活性，因为它可以接受任何可能形式的约束，并可以以任何可能的形式出现。
维度模型的细节性数据是安如泰山的，并随时准备接受业务用户的特殊攻击。
可以总是结合业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。
不过，只要选取较高层面的粒度就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。如果不让用户存取原子型数据，则他将不可避免地在分析方面撞上南墙。
聚集概要性数据作为调整性能的一种手段起着非常重要的作用，但它绝对不能作为用户存取最底层面的细节内容的替代品。
数据仓库几乎总是要求在每个维度可能得到的最低粒度上对数据进行表示的原因，并不是因为查询想看到每个底层面的行，而是因为查询希望以很精确的方式对细节知识进行抽取。
第三步：选定维度
一旦事实表的粒度被选定，则时期、产品与商店方面的维度就应该随之被确定下来。
在基本维度框架范围内，可能需要知道其他诸如针对某种产品的促销这样的维度是否可以分配数据。这个内容可表示为另外一个设计原则。
一个经过仔细考虑的粒度定义确定了事实表的基本维度特征。同时，经常也可能向事实表的基本粒度加入更多的维度，而这些附加的维度会在基本维度的每个组合值方面自然地取得惟一的值。
如果附加的维度因为导致生产另外的事实行而违背了这个基本的粒度定义，那么必须对粒度定义进行修改以适应这个维度的情形。
第四步：确定事实
设计过程的第四步同时也是最后一步，在于仔细确定哪些事实要在事实表中出现。粒度定义在这里再次成为考虑问题的支点。只是需要支出，事实对于粒度必须是真实的。
当考虑潜在的事实时，可能会再次发现，对早先的粒度设想或者维度选取做出调整是非常必要的。
单价也是非加型事实。试图在任何维度范围内对单价进行求和，都会导致出现一些毫无意义的甚至显得荒谬的数值结果。
要针对一系列商店或者一个时间跨度分析某种产品的平均售价，就必须在用销售总量取除销售总额之前，将相关销售额与销售量加起来。虽然数据仓库市场方面的报表生成器或者查询工具都应该自动地正确完成这个功能，但是很遗憾，其中一部分工具仍旧布恩那个很圆满地做到这一点。
在设计的早期阶段，经常对可能需要的最大表即最大事实表的行数做出估计是很有益处的。
维度表属性
用丰富的属性将他们填充起来。
日期维度
日期维度是几乎每个数据中心都必须提供的一个维度，因为实际上，每个数据中心都是时间系列的。事实上，日期通常是数据进行潜在分类排序的首选维度，这样做的目的是，是按时间间隔连续加载的数据能够顺次放到磁盘上的空白存储区中。
日期维度指称按日期进行粒度定义的维度表。这有助于对时期维度和每天的时间维度进行区分。
与其它多数维度不一样，日期维度表可以事先建立。这样的表可存放以日期表示的5到10年的历史数据行。
日期维度表的每列由行所代表的特定日期进行定义。
维度表属性是做报表标记之用。
建议：
将日期关键字指定为整数类型而不是任何形式的日期数据。
一个基于SQL的日期关键字在典型情况下是8字节的，因而事实表各行的每个日期关键字要浪费4个字节。
数据仓库总需要一个明确的维度表。有许多日期属性不能由SQL函数提供支持，这包括财务盘点，时令，节假日与周末等。与企图在查询中给定这些非标准日历运算的做法不同，而更应该在一个日期维度表中去检索它们。
产品维度
产品维度描述每个产品信息。
产品维度几乎总是起源于操作型产品主文件。
在数据中心进行的向下探查操作不过是通过维度表添加一些标题，而向上探查就是删除行标题。可以通过来自多个显式体系的属性而进行向上或者向下探查操作，也可以按非体系部分的属性进行同样的操作。
产品维度是几乎每个数据中心都拥有的两到三个基本维度之一。
用尽可能多的描述属性对这个维度进行填充时，应特别小心。一组丰富而完整的维度属性会转化为丰富而完整的用户数据分析能力。
商场维度
商场维度描述杂货连锁店的每个商场。
在维度表中表示多个体系是不常见的。在理想情况下，属性名与值在跨多个体系的范围应该是惟一的。
必须避免在事实表中出现空关键字，在这方面显得比较合适的设计是在对应的维度表中包括一行来标识该维度对度量值的不可用。
非事实型事实表
维度表几乎总是比事实表的几何尺寸要小。
为节省磁盘空间而投入精力去规范化产品维度表，只不过是在浪费时间。