标签：esc 它的 订单 model 不同类 最大化 特殊 常见 综合
本文将会讲述 BI/DW/DA 领域的一些常见概念，如：事实表、维度表、建模、多维分析、cube 等，但不涉及具体实例分析。
维是用于从不同角度描述事物特征的，一般维都会有多层（Level：级别），每个Level都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：
以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。其中ID一般被视为代理主键（Agent），它只被用于作为唯一性标志，并且是多维模型中关联关系的代理者，在业务层面并不具有任何意义；NAME一般是业务主键（Business），在业务层面限制唯一性，一般作为数据装载（Load）时的关联键；而DESCRIPTION则记录了详细描述信息，在多维展示和分析时我们都会选择使用DESCRIPTION来表述具体含义。
多维数据模型是为了满足用户从多角度多层次进行数据查询和分析的需要而建立起来的基于事实和维的数据库模型，其基本的应用是为了实现OLAP（Online Analytical Processing）。
当然，通过多维数据模型的数据展示、查询和获取就是其作用的展现，但其真的作用的实现在于，通过数据仓库可以根据不同的数据需求建立起各类多维模型，并组成数据集市开放给不同的用户群体使用，也就是根据需求定制的各类数据商品摆放在数据集市中供不同的数据消费者进行采购。
因为上面这个结构的维是无法直接应用于OLAP的，我前面的文章有介绍，其实OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以每一个维必须有Hierarchy，至少有一个默认的，当然可以有多个，见下图：
有了Hierarchy，维里面的Level就有了自上而下的树形结构关系，也就是上层的每一个成员（Member）都会包含下层的0个或多个成员，也就是树的分支节点。这里需要注意的是每个Hierarchy树的根节点一般都设置成所有成员的汇总（Total），当该维未被OLAP中使用时，默认显示的就是该维上的汇总节点，也就是该维所有数据的聚合（或者说该维未被用于细分）。Hierarchy中的每一层都会包含若干个成员（Member），还是以时间维，假设我们建的是2006-2015这样一个时间跨度的时间维，那么最高层节点仅有一个Total的成员，包含了所有这10年的时间，而年的那层Level中包含2006、2007…2015这10个成员，每一年又包含了4个季度成员，每个季度包含3个月份成员……这样似乎顺理成章多了，我们就可以基于Hierarchy做一些OLAP操作了。
这是一个最简单的星形模型的实例。事实表里面主要包含两方面的信息：维和度量，维的具体描述信息记录在维表，事实表中的维属性只是一个关联到维表的键，并不记录具体信息；度量一般都会记录事件的相应数值，比如这里的产品的销售数量、销售额等。维表中的信息一般是可以分层的，比如时间维的年月日、地域维的省市县等，这类分层的信息就是为了满足事实表中的度量可以在不同的粒度上完成聚合，比如2010年商品的销售额，来自上海市的销售额等。
还有一点需要注意的是，维表的信息更新频率不高或者保持相对的稳定，例如一个已经建立的十年的时间维在短期是不需要更新的，地域维也是；但是事实表中的数据会不断地更新或增加，因为事件一直在不断地发生，用户在不断地购买商品、接受服务。
注：雪花模型是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。相比星型模型，雪花模型的特点是贴近业务，数据冗余较少，但由于表连接的增加，导致了效率相对星型模型来的要低一些。
这里所说的立方其实就是多维模型中间的事实表（Fact Table），它会引用所有相关维的维主键作为自身的联合主键，加上度量（Measure）和计算度量（Calculated Measure）就组成了立方的结构：
度量是用于描述事件的数字尺度，比如网站的浏览量（Pageviews）、访问量（Visits），再如电子商务的订单量、销售额等。度量是实际储存于物理表中的，而计算度量则没有，计算度量是通过度量计算得到的，比如同比（如去年同期的月利润）、环比（如上个月的利润）、利率（如环比利润增长率）、份额（如该月中某类产品利润所占比例）、累计（如从年初到当前的累加利润）、移动平均（如最近7天的平均利润额）等，这些计算度量在Oracle中都可以借助分析函数直接计算得到，相信大部分的OLAP组件都会提供类似在时间序列上的分析功能。而这些计算度量往往对于分析而言更具意义，立方中借助与各个维的关联关系从不同的角度和层面来展现这些度量。
cube
一般是经过大量聚类运算好的而加以用特定方式存贮的多维报表，多拉几个维度构成的报表虽然也有分析功能，但是它是死的，而cube可以进行任意维度角度组合去看待数据，分析的味道更浓一些。对于cube,
你可以把它想像成一个魔方的客观形态(其实cube的维数一般比魔方的三维要多);而数据OLAP就是要从中抽取数据; 一个cube基于一个主题,
并且分为几个维, 维是围绕主题的;
举例：基于销售的方体(cube) 主题是 销售，维是city; item; day; buyer; 等等，基于 cube，我们可以快速抽取和计算数据。
模型是对现实世界的抽象，设计数据库系统时，一般会事先用抽象的图表（ER图）反映数据彼此之间的关系，称为建立数据模型。数据模型是数据库管理系统用来表示实体与实体间联系的方法。在设计数据库时，对业务进行分析、抽象、并从中找出内在联系，进而确定数据库的结构，这一过程就称为数据建模。
数据模型与数据建模的过程就是用标准来定义、规范数据。合理的业务模型设计对ETL至关重要。数据仓库是企业惟一、真实、可靠的综合数据平台。数据仓库的设计建模一般都依照三范式、星型模型、雪花模型，无论哪种设计思想，都应该最大化地涵盖关键业务数据，把运营环境中杂乱无序的数据结构统一成为合理的、关联的、分析型的新结构，而ETL则会依照模型的定义去提取数据源，进行转换、清洗，并最终加载到目标数据仓库中。
模型的重要之处在于对数据做标准化定义，实现统一的编码、统一的分类和组织。标准化定义的内容包括：标准代码统一、业务术语统一。ETL依照模型进行初始加载、增量加载、缓慢增长维、慢速变化维、事实表加载等数据集成，并根据业务需求制定相应的加载策略、刷新策略、汇总策略、维护策略。
数据模型按不同的应用层次分成三种类型：分别是概念数据模型、逻辑数据模型、物理数据模型。概念数据模型（Conceptual Data Model）简称概念模型，是面向数据库用户的实现世界的模型，主要用来描述世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的数据管理系统（Database Management System，简称DBMS）无关。概念数据模型必须换成逻辑数据模型，才能在DBMS中实现。逻辑数据模型是业务抽象到DBMS中，物理数据模型是逻辑数据模型的具体实现。
数据仓库的物理模型较常见的操作型数据库的物理模型有很大不同。最明显的区别是：操作型数据库主要是用来支撑即时操作，对数据库的性能和质量要求都比较高，为了防止“garbage
in，garbage
out”，通常设计操作型数据库的都要遵循几个范式的约束，除非少数情况下为了性能进行妥协，才可能出现冗余。而数据仓库的建立并不上为了支撑即时操作，或者说，数据仓库的数据是来源于即时操作产生的数据，而不是直接来源于即时操作。所以它的数据质量是由操作性系统来保证的，而不是由几个范式来保证的。而且为了更好的跟踪历史信息，以及更快的产生报表，数据仓库的物理模型中存在着大量冗余字段。
数据仓库的物理模型分为星型和雪花型两种。所谓星型，就是将模型中只有一个主题，其他的表中存储的都是主题的一些特征。比如货物销量的主题仓库中，每次出售记录是事实表，而时间，售货员，商品是维度，都和事实表有联系，组织起来就是星型。而如果更细化来看，商品是有种类，产地，价格等特征的，从这个角度来看，有两个主题，一个是商品出售，一个是商品本身。组织起来就是雪花型。实际项目中，由于操作型系统业务的复杂性导致本身产生了大量的数据，所以，组织起来也以雪花型居多。
事实表是用来存储主题的主干内容的。以日常的工作量为例，工作量可能具有如下属性：工作日期，人员，上班时长，加班时长，工作性质，是否外勤，工作内容，审核人。那么什么才是主干内容？很容易看出上班时长，加班时长是主干，也就是工作量主题的基本内容，那么工作日期，人员，工作性质，是否外勤，工作内容是否为主干信息呢？认真分析特征会发现，日期，人员，性质，是否外勤都是可以被分类的，例如日期有年-月-日的层次，人员也有上下级关系，外勤和正常上班也是两类上班考勤记录，而上班时长和加班时长则不具有此类意义。所以一般把能够分类的属性单独列出来，成为维度表，在事实表中维护事实与维度的引用关系。
在上述例子中，事实表可以设计成如下
WorkDate EmployeeID，WorkTypeID，Islegwork，Content，
而时间，员工，工作类型，是否外勤则归为维度表。
总的来看，和其他建立主外键关系的表也都一样。但是维度表的建立是需要有层次的（虽然不是必须，但是也是典型特征），而事实表的建立是针对已经发生的事实的，是历史数据的存档，也就是说是不应该修改的。以测试部测试软件的Bug为例。每个Bug都是一个事实。这个Bug的状态在数据字典里可能设计成新建，转派，修复，拒绝等等。那么在事实表中Bug表中有一个字段为Status。当测试员或者开发人员改变了这个状态的值，事实表中该如何更新呢？是直接更新Status还是什么其他的方式？显然，为了能够追踪这个Bug的历史信息，应该是重新插入一条新的记录（这里可以参考历史拉链表的etl刷新策略）。那么这和以往的数据库设计有什么区别呢？可以看出对于原始记录和新插入的记录，其他字段全部是相同的，也就是全部冗余的。如果以BugID作为主键，这时候会发现主键都是冗余的（当然，插入之前只能删除主键）。所以可以看出，事实表一般是没有主键的。数据的质量完全由业务系统来把握。
总的说来，事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。
钻取是改变维的层次，变换分析的粒度。它包括向上钻取（roll
up）和向下钻取（drill down）。roll
up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；是指自动生成汇总行的分析方法。通过向导的方式，用户可以定义分析因素的汇总行，例如对于各地区各年度的销售情况，可以生成地区与年度的合计行，也可以生成地区或者年度的合计行。
而drill
down则相反，它从汇总数据深入到细节数据进行观察或增加新维。例如，用户分析“各地区、城市的销售情况”时，可以对某一个城市的销售额细分为各个年度的销售额，对某一年度的销售额，可以继续细分为各个季度的销售额。通过钻取的功能，使用户对数据能更深入了解，更容易发现问题，做出正确的决策。
钻取允许你驾御一个报表内的不同层次的信息。 在你的商业模式中，我们定义不同层次的信息，这些定义方式也代表着你的商业构建方法。
你能够从一个信息层到有细节的更低层或更高层进行提取。例如，假如你的数据是被区域、市场、和商店所组织的，并且你能够运行一个显示区域销售的报表，那么你就可以从一个区域层钻取数据以便显示组成该区域的市场的销售。反之，你能从从商店中钻取数据去浏览商店所属的市场状况。
交叉分析是指对数据在不同维度进行交叉展现，进行多角度结合分析的方法，弥补了独立维度进行分析没法发现的一些问题。交叉分析以多维模型和数据立方为基础，也可以认为是一种特殊的细分方式，但跟细分的概念有点差异，如果有兴趣可以先阅读下之前的文章——数据立方体与OLAP。细分的方法更多的是基于同一维度的纵深展开，也就是OLAP中的钻取（Drill-down），比如从月汇总的数据细分来看每天的数据，就是在时间维度上的细分，或者从省份的数据细分查看省份中各城市的数据，是基于地域维的下钻。交叉分析不再局限于一个维度，就像数据立方体与OLAP文章中的立方体，是基于不同维度的交叉，时间维、地域维和产品维交叉在一起分析每个小立方的数据表现，可以通过OLAP的切片（Slice）和切块（Dice）操作查看例如上海市在3月份的电子产品的销售情况，这会帮助我们发现很多在单个维度中无法发现的问题。所以，交叉分析是基于不同维度横向地组合交叉，而不是细分在同一维度的纵向展开。大体大样式如下：
一般以表格呈现：
标签：esc 它的 订单 model 不同类 最大化 特殊 常见 综合
原文地址：https://www.cnblogs.com/wenBlog/p/9389887.html
