（数据仓库)数据仓库建模篇（转载）

1. 什么叫数据仓库？数据仓库的特点？
(相信inmon的数据仓库概念的四个特点是最基本的吧，当然需要加上自己的理解)
首先，用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库；
其次，对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。
数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，它用于支持企业或组织的决策分析处理。
2. 什么叫OLAP？用途是什么？
(OLAP指多维数据库了，主要用于多维分析了；包括三种实现方式)
3. 数据仓库和数据库有什么区别？
(事务性数据库和决策支持数据库的区别，当然包括目标、用途、设计等等)
（1）数据是面向事务处的，数据是由日常的业务产生的，常更新；数据仓库是面向主题的,数据来源于数据库或文件，经过一定的规则转换得到，用来分析的。
（2）数据库一般是用来存储当前交易数据；数据仓库存储一般存储的是历史数据。
（3）数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；数据仓库的设计一般是星型的，有利于查询。

4. 数据仓库的基本架构是什么？
(数据源，ETL，data stage，ODS，data warehouse,datamart,OLAP等等，可能为针对每一个结构进行发问啊)
【1】.数据源->【2】.ETL ->【3】.数据仓库存储与管理->【4】.OLAP ->【5】.BI工具
数据源：是数据仓库系统的数据源泉,通常包括企业各类信息,包括存放于RDBMS中的各种业务处理数据和各类文档数据；各类法律法规、市场信息和竞争对手的信息等等；
数据的存储与管理：数据的存储和管理是整个数据仓库的核心，是关键。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。从数据仓库的技术特点着手分析，来决定采用什么产品和技术来建立数据仓库，然后针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。
OLAP服务器：对需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：ROLAP（关系型在线分析处理）、MOLAP（多维在线分析处理）和HOLAP（混合型线上分析处理）。ROLAP基本数据和聚合数据均存放在RDBMS之中；MOLAP基本数据和聚合数据均存放于多维数据库中；HOLAP基本数据存放于RDBMS之中，聚合数据存放于多维数据库中。
前端工具：主要包括各查询工具、数据分析工具、数据挖掘工具、种报表工具以及各种基于数据仓库或数据集市的应用开发工具。
数据分析工具主要针对OLAP服务器。报表工具、数据挖掘工具主要针对数据仓库。
5. 有哪几种模型设计方法？特点分别是什么？

大千世界，表面看五彩缤纷，实质上，万物都遵循其自有的法则。数据仓库的建模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了一种归纳，概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。

范式建模法（Third Normal Form，3NF）
范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :
每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。

根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例。
图 5. 范式建模法

从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：
数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。
以笔者的观点来看，Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。因此，笔者建议读者们在实际的使用中，参考使用这一建模方式。

维度建模法
维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）。

图 6. 维度建模法

上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法，星型模式在性能上占据明显的优势。

雪花模型也是维度建模中的一种选择。雪花模型的维度表可以拥有其他维度表的，虽然这种模型相比星型模型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。雪花模型如下图

 

同时，维度建模法的另外一个优点是，维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。

但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。

另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

因此以笔者的观点看，维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

实体建模法
实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件和说明，如下图所示：

图 7. 实体建模法

 

上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。

从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成 3 个部分：

实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。
事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
说明，主要是针对实体和事件的特殊说明。
由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。

但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。

因此，笔者建议读者在创建自己的数据仓库模型的时候，可以参考使用上述的三种数据仓库得建模方法，在各个不同阶段采用不同的方法，从而能够保证整个数据仓库建模的质量。
6. 模型设计的思路？业务需求驱动？数据驱动？
构造数据仓库有两种方式：一是自上而下，一是自下而上。
Bill Inmon先生推崇“自上而下”的方式，即一个企业建立唯一的数据中心，就像一个数据的仓库，其中数据是经过整合、经过清洗、去掉脏数据的、标准的，能够提供统一的视图。要建立这样的数据仓库，并不从它需要支持哪些应用入手，而是要从整个企业的环境入手，分析其中的概念，应该有什么样的数据，达成概念完成整；（会考虑到很全面的设计）
Ralph Kimball先生推崇“自下而上”的方式，他认为建设数据仓库应该按照实际的应用需求，加载需要的数据，不需要的数据不要加载到数据仓库中。这种方式建设周期较短，客户能够很快看到结果。（针对客户的需求，需求要什么就做什么）
二者都要达到同一个目标：企业级数据仓库。实际上在建设数据仓库的时候，一般都参照这两种方式结合使用没有硬性规定。
7. 模型设计的步骤？
构建企业级数据仓库五步法:
一、 确定主题
即确定数据分析或前端展现的主题(例:某年某月某地区的啤酒销售情况)。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑.
二、 确定量度
确定主题后，需要考虑分析的技术指标(例:年销售额等等)。它们一般为数据值型数据，其中有些度量值不可以汇总；些可以汇总起来，以便为分析者提供有用的信息。量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性指标(KPI)的设计和计算。
三、 确定事实数据粒度
确定量度之后，需要考虑该量度的汇总情况和不同维度下量度的聚合情况.例如在业务系统中数据最小记录到秒，而在将来分析需求中，时间只要精确到天就可以了，在ETL处理过程中，按天来汇总数据,些时数据仓库中量度的粒度就是”天”。如果不能确认将来的分析需求中是否要精确的秒，那么，我们要遵循”最小粒度原则”,在数据仓库中的事实表中保留每一秒的数据，从而在后续建立多维分析模型(CUBE)的时候,会对数据提前进行汇总，保障产生分析结果的效率。
四、 确定维度
维度是分析的各个角度.例:我们希望按照时间，或者按照地区，或者按照产品进行分析。那么这里的时间，地区，产品就是相应的维度。基于不同的维度，可以看到各个量度汇总的情况，也可以基于所有的维度进行交叉分析。
维度的层次(Hierarchy)和级别(Level)。例:在时间维度上，按照”度-季度-月”形成了一个层次，其中”年” ,”季度” ,”月”成为了这个层次的3个级别。我们可以将“产品大类-产品子类-产品”划为一个层次，其中包含“产品大类”、“产品子类”、“产品”三个级别。
我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度；我们也可以使用三张表，分别保存产品大类，产品子类，产品三部分数据,比如产品维度。
建立维度表时要充分使用代理键.代理键是数据值型的ID号码(每张表的第一个字段)，它唯一标识了第一维度成员。在聚合时，数值型字段的匹配和比较，join效率高。同时代理键在缓慢变化维中，起到了对新数据与历史数据的标识作用。
五、 创建事实表
在确定好事实数据和维度后，将考虑加载事实表。业务系统的的一笔笔生产，交易记录就是将要建立的事实表的原始数据.
我们的做法是将原始表与维度表进行关联，生成事实表。关联时有为空的数据时(数据源脏)，需要使用外连接，连接后将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各度量数据，不应该存在描述性信息。
事实表中的记录条数据都比较多，要为其设置复合主键各蛇引，以实现数据的完整性和基于数据仓库的查询性能优化。

8. 谈你对星形模型和雪花模型理解和认识？
星型模型
核心是一个事实表及多个非正规化描述的维度表组成。
雪花模型
它是星型模型的扩展，不同的是维度表被规范化，进一步分解到附加表中。
星座模型
由多个事实表组合，维表是公共的，可以被多个事实表共享。星座模型是数据仓库最常使用的模型。
数据仓库建模 — 星型模式
Example of Star Schema

 

数据仓库建模 — 雪片模式
Example of Snowflake Schema

节省存储空间
一定程度上的范式

 

星形 vs.雪花型

Which one is better？
长期以来的争论
两种观点各有支持者
争论在继续……
目前看来，大部分更加倾向于星型
支持星形维度的论点

事实表总会是很大的，在维度表上节省的空间相对来说是很小的
增加了数据模型的复杂度
查询操作概念上更复杂了
从数据仓库到多维数据库的加载时间会更长
因此，只有当维度表极大，存储空间是个问题时，才考虑雪花型维度
简而言之，最好就用星型维度即可
支持雪花型维度的论点

从数据仓库到多维数据库的加载过程中，雪花型维度的效率更高；
雪花型维度描述了更清晰的层次概念；
只有当最终用户可能直接访问数据仓库时才考虑星形（而这是不被建议的）；
我的个人经验

星形结构效率上优于雪花型；
多数情况下，我会选择星型，但是不排除使用雪花型的情况；
9. 什么叫维度和度量值？(一个是出发点，一个是观察值)
事实表
在多维数据仓库中，保存度量值的详细值或事实的表称为“事实表”。一个按照州、产品和月份划分的销售量和销售额存储的事实表有5个列，概念上与下面的示例类似。

 

在这些事实表的示例数据行中，前3个列——州、产品和月份——为键值列。剩下的两个列——销售额和销售量——为度量值。事实表中的每个列通常要么是键值列，要么是度量值列，但也可能包含其他参考目的的列——例如采购订单号或者发票号。

事实表中，每个度量值都有一个列。不同事实表将有不同的度量值。一个销售数据仓库可能含有这两个度量值列：销售额和销售量。一个现场信息数据仓库可能包含3个度量值列：总量、分钟数和瑕疵数。创建报表时，可以认为度量值形成了一个额外的维度。即可以把销售额和销售量作为并列的列标题，或者也可以把它们作为行标题。然而在事实表中，每个度量值都作为一个单独的列显示。

事实表数据行中包含了您想从中获取度量值信息的最底层级别的明细。换句话说，事实表中对每个维度的最详细的项目成员都有数据行。如果有使用其他维度的度量，只要为那些度量和维度创建另一个事实表即可。数据仓库中可能包含拥有不同度量值和维度的不同事实表。

前面表格中的示例数据行显示了事实表的概念布局。事实是事实表几乎总会使用一个整数值来表示(维度)成员，而不使用描述性的名称。因为事实表往往会包含数量多得无法想象的数据行——在一个中等大小的数据仓库中，事实表动辄包含上百万行数据——使用整数键值可以有效地减小事实表的大小。事实表真正的布局如下所示。

 

在事实表中使用整数键值时，维度成员的名称需要放到另一种表中——也就是维度表。通常，事实表中的每个维度都有一个维度表。

事实表前缀为Fact。

归纳：

每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务。

所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实)，并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性纬度表的主键，而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。

包含在事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。最有用的度量值是可累计的度量值，其累计起来的数字是非常有意义的。用户可以通过累计度量值获得汇总信息，例如。可以汇总具体时间段内一组商店的特定商品的销售情况。非累计的度量值也可以用于事实数据表，单汇总结果一般是没有意义的，例如，在一座大厦的不同位置测量温度时，如果将大厦中所有不同位置的温度累加是没有意义的，但是求平均值是有意义的。

一般来说，一个事实数据表都要和一个或多个纬度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。

维度表
维度表包含了维度的每个成员的特定名称。维度成员的名称称为“属性”(Attribute)。假设Product维度中有3种产品，那么维度表将如下所示。

 

产品名称是产品成员的一个属性。因为维度表中的Product ID与事实表中的Product ID相匹配，称为“键属性”。因为每个Product ID只有一个Product Name，显示时用名称来替代整数值，所以它仍然被认为是键属性的一部分。

在数据仓库中，维度表中的键属性必须为维度的每个成员包含一个对应的唯一值。用关系型数据库术语描述就是，键属性称为主键列。每个维度表中的主键值都与任何相关的事实表中的键值相关。在维度表中出现一次的每个键值都会在事实表中出现多次。例如Mountain-100的Product ID 347只在一个维度表数据行中出现，但它会出现在多个事实表数据行中。这称为一对多关系。在事实表中，键值列(它是一对多关系的“多”的一方)称为外键列。关系型数据库使用匹配的主键列(在维度表中)和外键列(在事实表中)值来联接维度表到事实表。

把维度信息移动到一个单独的表中，除了使得事实表更小外，还有额外的优点——可以为每个维度成员添加额外的信息。例如，维度表可能为每个产品添加种类(Category)信息，如下所示。

 

现在种类是产品的另一个属性。如果知道Product ID，不但可以推断出Product Name，而且可以推断出Category。键属性的名称可能是唯一的——因为每个键只有一个名称，但其他属性不需要是唯一的，例如Category属性可能会出现好几次。这样一来，便可以创建按照产品和类别对事实表信息进行分组的报表。

除了名称外，维度表可以包含许多其他的属性。本质上，每个属性都对应于维度表中的一个列。下面是带有其他额外属性的只有3个成员的Product维度表的示例。

维度属性可以是可分组的，也可以是不可分组的。换句话就是，您是否见过按照哪个属性来分组度量值的报表？在我们的示例中，Category、Size和Color全都是可分组的属性。由此自然会联想到可能在某个报表中按照颜色、大小或种类来分组销售额。但Price看起来不像是可分组的属性——至少它本身不是。在报表中可能会有一个更有意义的其他属性——例如Price Group，但价格本身变化太大，导致在报表上分组意义不大。同样地，按照Product Description属性在报表上进行分组意义也不大。在一个Customer维度中，City、Country、Gender和Marital Status都是可以在报表上按照它们进行有意义分组的属性，但Street Address或Nickname都应当是不可分组的。不可分组的属性通常称为成员属性(member property)。
某些可分组的属性可以组合起来创建一个自然层次结构(natural hierarchy)。例如假设Product有Category和Subcategory属性，在多数情况下，单个产品只会属于单个Subcategory，并且单个Subcategory只会属于单个Category。这将形成一个自然层次结构。在报表中，可能会显示Categories，然后允许用户从某个Category钻取到Subcategories，以及最终钻取到Products。
层次结构——或者说钻取路径——不一定要是自然的(例如，每个低层次的成员会决定下一个高层次的成员)。例如，您可能会创建一个按照Color分组产品的报表，但允许用户根据每个Color钻取到每个不同的Size。因为报表的钻取能力，Color和Size形成了一个层次结构，但是根据Size却没有任何信息可以用来断定产品的Color将是什么。这是一个层次结构，但不是一个自然层次结构——但也不是说它是个非自然层次结构。Color和Size形成一个层次结构并没有什么不对，它只是这样一个简单的事实：相同的Size可以出现在多个Color中。
维度表前缀为Dim。
归纳：
维度表可以看作是用户来分析数据的窗口，纬度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。例如，包含产品信息的维度表通常包含将产品分为食品、饮料、非消费品等若干类的层次结构，这些产品中的每一类进一步多次细分，直到各产品达到最低级别。
在维度表中，每个表都包含独立于其他维度表的事实 特性，例如，客户维度表包含有关客户的数据。维度表中的列字段可以将信息分为不同层次的结构级。
结论:
[1]事实表就是你要关注的内容;
[2]维度表就是你观察该事务的角度，是从哪个角度去观察这个内容的。
例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实表就是销量表，维度表就是地区表。

聚合表
数据是按照最详细的格式存储在事实表中，各种报表可以充分利用这些数据。一般的查询语句在查询事实表时，一次操作经常涉及成千上万条记录，但是通过使用汇总、平均、极值等聚合技术可以大大降低数据的查询数量。因此，来自事实表中的底层数据应该事先经过聚合存储在中间表中。中间表存储了聚合信息，所以被称为聚合表，这种处理过程被称为聚合过程。
————————————————
版权声明：本文为CSDN博主「小六六人儿」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lurrass/article/details/89061562