设为首页收藏本站 开启辅助访问
 找回密码
 立即注册

QQ登录

只需一步,快速开始

用新浪微博登录

只需一步,快速搞定

μKettle 首页 商业智能 查看内容

数据仓库中的概念

时间: 2015-4-10 18:04

作者: 小白

 查看:(3872)  评论:(0)

摘要: ODS:ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。同样也可以看出ODS是介于DB和DW 之间的一种数据存储技术,和原来面向应用的分散的DB相比,ODS中的数据组织方式和数据仓库(DW ...

ODS:
ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。同样也可以看出ODS是介于DB和DW 之间的一种数据存储技术,和原来面向应用的分散的DB相比,ODS中的数据组织方式和数据仓库(DW)一样也是面向主题的和集成的,所以对进入ODS的数据也象进入数据仓库的数据一样进行集成处理。另外ODS只是存放当前或接近当前的数据,如果需要的话还可以对ODS中的数据进行增、删和更新等操 作,虽然DW中的数据也是面向主题和集成的,但这些数据一般不进行修改,所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。

[@more@]

数据仓库:
数据仓库是一个支持管理决策的数据集合。数据是面向主题的(Subject-oriented)、集成的(Integrated)、相对稳定(Non-volatile)的且是记录历史的(Time-variant)。Z与其他数据库应用不同的是,数据仓库更像一种过程,对分布在企业内部各处的业务数据的整合、加工和分析的过程。而不是一种可以购买的产品。
“主题”是一个较为抽象的概念,是指用户使用数据仓库进行决策时所关心的重点方面。从信息管理的角度看,主题是在一个较高的管理层次上对数据进行综合、归类所形成的分析对象;从数据组织的角度看,主题就是一些数据集合,这些数据集合对分析对象作了比较完整的、一致的描述,这种描述不仅涉及到数据本身,还涉及到数据之间的关系。
“面向主题”则表明了数据仓库中数据组织的基本原则,是指数据仓库内的信息是按主题进行组织的,而不像传统事物处理系统那样单一地按照业务功能及性能要求进行组织。 
“集成”是指数据仓库中的信息并不是对各个数据源简单的选择、抽取,而是首先进行一系列的加工、整理和转换等来消除源数据中的不一致;同时按照本行业的逻辑模型设计便于查询及分析的数据仓库。然后按照组织或企业的需求,针对不同的主题对数据进行某种程度的综合、概括和聚集,将源数据加载进数据仓库。经过这样的处理,数据就具有了集成性,可以用于决策分析。 
“反映历史变化”是指数据仓库内的信息并不只是反映企业当前的状态,而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。而信息本身相对稳定,是指一旦某个数据进入数据仓库以后,一般很少进行修改,更多的是对信息进行查询操作。 
“相对稳定”是指数据一旦进入数据仓库,一般情况下会被长期保留,所涉及的数据操作也主要是查询、分析,很少会被修改或删除,通常也只需要定期地加载和刷新。相对稳定性保证了数据仓库中的数据能够真实地反映历史变化。

数据集市:
他主要面向部门级业务,并且只面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。数据集市可以依赖于数据仓库,也可以和数据仓库没有关联。

OLAP(OLAP Online Analytical Processing ):
联机分析处理(OLAP)的概念最早是由关系数据库之父E.F.Codd于1993年提出的。当时,Codd认为联机事务处理(OLTP)已不能满足终端用户对数据库查询分析的需要,SQL对大数据库进行的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果,而查询的结果并不能满足决策者提出的需求。因此Codd提出了多维数据库和多维分析的概念,即OLAP。

Codd提出OLAP的12条准则来描述OLAP系统:
准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力推测
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次ROLAP

OLAP系统按照其存储器的数据存储格式可以分为关系OLAP(RelationalOLAP,简称ROLAP)、多维OLAP(MultidimensionalOLAP,简称MOLAP)和混合型OLAP(HybridOLAP,简称HOLAP)三种类型。
  a.ROLAP
  ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存,只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询,优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化,比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。
  b.MOLAP
  MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式,形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围,而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构,从物理层实现起,因此又称为物理OLAP(PhysicalOLAP);而ROLAP主要通过一些软件工具或中间软件实现,物理层仍采用关系数据库的存储结构,因此称为虚拟OLAP(VirtualOLAP)。
  c.HOLAP
  由于MOLAP和ROLAP有着各自的优点和缺点(如下表所示),且它们的结构迥然不同,这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP(HOLAP)被提出,它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止,对HOLAP还没有一个正式的定义。但很明显,HOLAP结构不应该是MOLAP与ROLAP结构的简单组合,而是这两种结构技术优点的有机结合,能满足用户各种复杂的分析请求。

DSS:
决策支持系统(Decision Support System),相当于基于数据仓库的应用。决策支持就是在收集所有有关数据和信息,经过加工整理,来为企业决策管理层提供信息,为决策者的决策提供依据。

ETL:
数据抽取(Extract)、转换(Transform)、清洗(Cleansing)、装载(Load)的过程。构建数据仓库的重要一环,用户从数据源抽取出所需的数据,经过数据清洗,最终按照预先定义好的数据仓库模型,将数据加载到数据仓库中去。

EIS:
领导信息系统(Executive Information System),指为了满足无法专注于计算机技术的领导人员的信息查询需求,而特意制定的以简单的图形界面访问数据仓库的一种应用。

BPR:
业务流程重整(Business Process Reengineering),指利用数据仓库技术,发现并纠正企业业务流程中的弊端的一项工作,数据仓库的重要作用之一。

BI:
商业智能(Business Intelligence),指数据仓库相关技术与应用的通称。指利用各种智能技术,来提升企业的商业竞争力。

CRM:
客户关系管理(Customer Relationship Management),数据仓库是以数据库技术为基础但又与传统的数据库应用有着本质区别的新技术,CRM就是基于数据仓库技术的一种新应用。但是,从商业运作的角度来讲,CRM其实应该算是一个古老的"应用"了。比如,酒店对客人信息的管理,如果某个客人是某酒店的老主顾,那么该酒店很自然地会知道这位客人的某些习惯和喜好,如是否喜欢靠路边,是否吸烟,是否喜欢大床,喜欢什么样的早餐,等等。当客人再次光临时,不用客人自己提出来,酒店就会提供客人所喜欢的房间和服务。这就是一种CRM。

Meta Data:
元数据,关于数据仓库的数据,指在数据仓库建设过程中所产生的有关数据源定义,目标定义,转换规则等相关的关键数据。同时元数据还包含关于数据含义的商业信息,所有这些信息都应当妥善保存,并很好地管理。为数据仓库的发展和使用提供方便。

体系架构:
数据仓库的方法学,数据仓库体系架构可以分为五个层次。这五个层次反映了应用运行的基本逻辑结构和过程。每层都具有自己的技术实现方式及相应的评价准则。这五个应用层次是:
设计建模层:该层次是整个分析应用系统的起点,主要完成对现有业务系统数据源的分析,按照数据仓库建模理论完成数据仓库结构设计。
数据获取层:确定项目实施所需的数据清洗工具,定义出数据从原业务系统到数据仓库系统的ETL技术方案,最终完成数据清洗、转换、加载的工作
数据存储层:通过对数据仓库数据量的估计,和客户访问数的估计对数据仓库主平台所需的软件和硬件作出评估,确定主平台的系统配置情况。
数据展现层:主要根据客户需求选定前端数据展现的软件,同时根据客户需求决定数据展现方式,进行数据展现的开发。
元数据管理层:主要完成对整个数据仓库实施中的元数据进行管理的功能,包括:逻辑到物理模型的映射、数据访问的授权、用户安全控制等等。


事实:
事实是数据仓库中的信息单元,也是多维空间中的一个单元,受分析单元的限制。事实存储于一张表中(当使用关系数据库时)或者是多维数据库中的一个单元。每个事实包括关于事实(销售额,销售量,成本,毛利,毛利率等)的基本信息,并且与维度相关。在某些情况下,当所有的必要信息都存储于维度中时,单纯的事实出现就是对于数据仓库足够的信息。

维度:
维度是用来反映业务的一类属性,这类属性的集合构成一个维度。例如,某个地理维度可能包括国家、地区、省以及城市的级别。一个时间维度可能包括年、季、月、周、日的级别。

级别:
维度层次结构的一个元素。级别描述了数据的层次结构,从数据的最高(汇总程度最大)级别直到最低(最详细)级别(如大分类-中分类-小分类-细分类)。级别仅存在于维度内。级别基于维度表中的列或维度中的成员属性。

数据清洗:
对数据仓库系统无用的或者不符合数据格式规范的数据称之为脏数据。清洗的过程就是清除脏数据的过程。

数据采集(数据抽取):
数据仓库系统中后端处理的一部分。数据采集过程是指从业务系统中收集与数据仓库各指标有关的数据。

数据转换:
解释业务数据并修改其内容,使之符合数据仓库数据格式规范,并放入数据仓库的数据存储介质中。数据转换包括数据存储格式的转换以及数据表示符的转换(如产品代码到产品名称的转换)。

Data Mining:
数据挖掘,Data Mining是一种决策支持过程,它主要基于AI、机器学习、统计学等技术,高度自动化地分析企业原有的数据,做出归纳性的推理,从中挖掘出潜在的模式,预测客户的行为,帮助企业的决策者调整市场策略,减少风险,做出正确的决策

切片:
一种用来在数据仓库中将一个维度中的分析空间限制为数据子集的技术。

切块:
一种用来在数据仓库中将多个维度中的分析空间限制为数据子集的技术。

星型模式:
是数据仓库应用程序的最佳设计模式。它的命名是因其在物理上表现为中心实体,典型内容包括指标数据、辐射数据,通常是有助于浏览和聚集指标数据的维度。星形图模型得到的结果常常是查询式数据结构,能够为快速响应用户的查询要求提供最优的数据结构。星形图还常常产生一种包含维度数据和指标数据的两层模型。

雪花模式:
指一种扩展的星形图。星形图通常生成一个两层结构,即只有维度和指标,雪花图生成了附加层。实际数据仓库系统建设过程中,通常只扩展三层:维度(维度实体)、指标(指标实体)和相关的描述数据(类目细节实体)超过三层的雪花图模型在数据仓库系统中应该避免。因为它们开始像更倾向于支持OLTP 应用程序的规格化结构,而不是为数据仓库和OLAP应用程序而优化的非格式化结构。

粒度:
粒度将直接决定所构建仓库系统能够提供决策支持的细节级别。粒度越高表示仓库中的数据较粗,反之,较细。粒度是与具体指标相关的,具体表现在描述此指标的某些可分层次维的维值上。例如,时间维度,时间可以分成年、季、月、周、日等。数据仓库模型中所存储的数据的粒度将对信息系统的多方面产生影响。事实表中以各种维度的什么层次作为最细粒度,将决定存储的数据能否满足信息分析的功能需求,而粒度的层次划分、以及聚合表中粒度的选择将直接影响查询的响应时间。

度量值:
在多维数据集中,度量值是一组值,这些值基于多维数据集的事实数据表中的一列,而且通常为数字。此外,度量值是所分析的多维数据集的中心值。即,度量值是最终用户浏览多维数据集时重点查看的数字数据(如销售、毛利、成本)。所选择的度量值取决于最终用户所请求的信息类型。

Iceberg query:
中文一般翻译为“冰山查询”,冰山查询在一个属性或属性集上计算一个聚集函数,以找出大于某个指定阈值的聚集值。
以销售数据为例,你想产生这样的一个顾客-商品对的列表,这些顾客购买商品的数量达到3件或更多。
这可以用下面的冰山查询表示:
Select P.cust_ID, P.item_ID, SUM(P.qty)
From Purchase P
Group by P.cust_ID, P.item_ID
Having SUM(P.qty)>=3
这种在给出大量输入数据元组的情况下,使用having字句中的阈值来进行过滤的查询方法就叫做冰山查询。输出结果可以看作“冰山顶”,而“冰山”是输入数据。
这种冰山查询在数据仓库的数据概况分析阶段、数据质量检查阶段和数据挖掘的购物篮分析中都经常使用。而且,冰山查询也是面试中出现频率非常高的一道题,经常用来检测SQL能力。

Oper Mart:
中文一般翻译为“操作集市”,操作集市是为了企业战术性的分析提供支持,它的数据来源是操作数据存储(ODS)。它是ODS在分析功能上的扩展,使用户可以对操作型数据进行多维分析。
一个操作集市应该有如下特征:
1.操作集市是ODS的子集,数据来源于ODS,用于战略分析和报表。
2.操作集市中的数据和ODS中的数据同步更新。
3.操作集市以多维技术进行建模,即星型结构。
4.操作集市是一个临时的结构,当不在需要时会清掉所有数据,即不保存历史数据。
操作集市和数据集市很相似,但是它不能用来取代用于战略性分析的数据集市。由于操作集市的数据来源于ODS,所以它的数据比数据集市的数据要新。但是出于容量的考虑,操作集市中不保存历史数据,是一个临时的结构。

Surrogate key:
中文一般翻译为“代理关键字”。代理关键字一般是指维度表中使用顺序分配的整数值作为主键,也称为“代理键”。代理关键字用于维表和事实表的连接。代理关键字的称呼有surrogate keys,meaningless keys,integer keys,nonnatural keys,artificial keys,synthetic keys等。与之相对的自然关键字的称呼有natural keys,samat keys等。

在Kimball的维度建模领域里,是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字,而不应该使用自然关键字或者智能关键字(Smart Keys)。数据仓库中的主键不应该是智能的,也就是说,要避免通过主键的值就可以了解一些业务信息。当然,退化维度作为事实表的复合主键之一时例外。

使用代理关键字,有很多优点。
1.使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。也就是说,当数据仓库需要对来在多个操作型系统的数据进行整合时,这些系统中的数据有可能缺乏一致的关键字编码,即有可能出现重复,这时代理关键字可以解决这个问题。
2.使用代理关键字可以带来性能上的优势。和自然关键字相比,代理关键字很小,是整型的,可以减小事实表中记录的长度。这样,同样的IO就可以读取更多的事实表记录。另外,整型字段作为外键联接的效率也很高。
3.使用代理关键字可以建立一些不存在的维度记录,例如“不在促销之列”,“日期待定”,“日期不可用”等维度记录。
4.使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是数据仓库设计的实施中非常重要的一部分。Kimball的缓慢变化维处理策略的核心就是使用代理关键字。

当然,使用代理关键字也有它的缺点,代理关键字的使用使数据加载变得非常复杂。使用代理关键字是一个从长远考虑的策略。

multivalue dimension:
中文一般翻译为“多值维度”,多值维度有两种情况,第一种情况是指维度表中的某个属性字段同时有多个值。举例来说,一个帐户维度表中,帐户持有人姓名,可能会有多个顾客。这样,一个帐户对应多个顾客姓名,一个顾客也可以有多个帐户,它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客,所以不能直接将顾客ID放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。

多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来说,对于一个健康护理单分列项事实表来说,它的粒度是一个健康护理单,但是该护理单却有可能有多次诊断,即该事实表与诊断维度的是一对多的关系。这个与事实表粒度不匹配的诊断维度也称之为多值维度。

处理多值维度最好的办法是降低事实表的粒度。如第二种情况中,将健康护理单分列项事实表的粒度降低到具体的诊断粒度上,这样就避免了多值维度的出现。这种处理方式也是维度建模的一个原则,即事实表应该建立在最细粒度上。这样的处理,需要对事实表的事实进行分摊。

但是有些时候,事实表的粒度是不能降低的,多值维度的出现是无法避免的。如第一种情况中,事实表是月帐户快照事实表,这张事实表与顾客维度没有直接的关系,不能将数据粒度进行细分,即使细分的话帐户余额也很难分摊。这时,可以采用桥接表技术进行处理。在帐户维度表和顾客维度表之间建立个帐户-顾客桥接表。这个桥接表可以解决掉帐户维度和顾客维度之间的多对多关系,也解决掉的帐户维度表的多值维度问题。

总之,多值维度是应该尽量避免的,它给数据处理带来了很大的麻烦。如果多值维度不能避免的话,应该建立桥接表来进行处理。

Factless Fact Table:
中文一般翻译为“非事实型事实表”。在事实表中,通常会保存十个左右的维度外键和多个度量事实,度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实,只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。

第一类非事实型事实表是用来跟踪事件的事实表。例如:学生注册事件,学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度,而事实表是由这些维度的主键组成,事实只有注册数,并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题,主要是回答各种情况下的注册数。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如:促销范围事实表。通常销售事实表可以回答如促销商品的销售情况,但是对于那些没有销售出去的促销商品没法回答。这时,通过建立促销范围事实表,将商场需要促销的商品单独建立事实表保存。然后,通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围,其中没有任何事实度量。

merged fact table:
也做consolidated fact table,中文一般都翻译为“合并事实表”。合并事实表是将不同事实表的事实合并到同一张事实表的建模方法,合并的事实要保证在相同的粒度。
这种建模方法通常被用来横跨多个业务主题域来建立数据集市,Kimball将这样的数据集市称为第二级的数据集市。使用合并事实表技术,可以避免性能较差的交叉探察操作。但是,这种合并事实表和使用交叉探察操作还有着细微的不同,在一些基础表中没有记录的时候,合并事实表中可能会存储一条记录,字段值保存为零。
合并事实表可以给数据仓库带来很大的性能提升,提供的跨主题的事实数据也给用户带来了很大的方便。但是,合并事实表给ETL工作带来了较大的麻烦。对于合并事实表中涉及到的维度,需要在数据准备区保证它们是一致性维度。

Slowly Changing Dimensions:
中文一般翻译成“缓慢变化维”,经常被简写为SCD。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维,并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题,有时也简称为处理SCD的问题。

处理缓慢变化维的方法通常分为三种方式。
第一种方式是直接覆盖原值。这样处理,最容易实现,但是没有保留历史数据,无法分析历史变化信息。第一种方式通常简称为“TYPE 1”。
第二种方式是添加维度行。这样处理,需要代理键的支持。实现方式是当有维度属性发生变化时,生成一条新的维度记录,主键是新分配的代理键,通过自然键可以和原维度记录保持关联。第二种方式通常简称为“TYPE 2”。
第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列,来记录该属性变化前的值,而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值,缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE 3”。

在实际建模中,我们可以联合使用三种方式,也可以对一个维度表中的不同属性使用不同的方式,这些,都需要根据实际情况来决定,但目的都是一样的,就是能够支持方便的分析历史变化情况。

Ad hoc queries:
中文一般翻译为“即席查询”。即席查询是指那些用户在使用系统时,根据自己当时的需求定义的查询。

即席查询生成的方式很多,最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是,将数据仓库中的维度表和事实表映射到语义层,用户可以通过语义层选择表,建立表间的关联,最终生成SQL语句。

即席查询与通常查询从SQL语句上来说,并没有本质的差别。它们之间的差别在于,通常的查询在系统设计和实施时是已知的,所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询,使这些查询的效率很高。而即席查询是用户在使用时临时生产的,系统无法预先优化这些查询,所以即席查询也是评估数据仓库的一个重要指标。

即席查询的位置通常是在关系型的数据仓库中,即在EDW或者ROLAP中。多维数据库有自己的存储方式,对即席查询和通常查询没有区别。

在一个数据仓库系统中,即席查询使用的越多,对数据仓库的要求就越高,对数据模型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同的,这也是维度建模的一个优点。

以星型模型和雪花模型为例,星型模型中,一个事实表周围有十个左右的维度表与之关联。这些维度表都是直接于事实表关联,对这个事实表的数据进行查询时,不管是用什么条件来进行约束,都可以一步联接到该约束的维度表,这样查询SQL关联的表少,效率高,维度表是对称的,可以建索引等进行优化。
假如将其中的一个维度表进行雪花处理,那么查询的约束条件在这个维度表中的话,就需要多关联一个表,效率要差,这个维度表与其他的维度表就不是对称的。
以此类推,3NF建模的数据仓库没有这种对称关系,模型表示的是数据关系,如果不预先知道查询SQL的话,很难预先优化。

Drill Across:
中文一般翻译为“交叉探查”。在基于总线架构(Bus Architecture)的维度建模中,大部分的维度表是由事实表共有的。比如“营销事务事实表”和“库存快照事实表”就会有相同的维度表,“日期维度”、“产品维度”和“商场维度”。这时,如果有个需求是想按共有维度来对比查看销售和库存的事实,这时就需要发出两个SQL,分别查出按维度统计出的销售数据和库存数据。然后再基于共有的维度进行外连接,将数据合并。这种发出多路SQL再进行合并的操作就是交叉探查。
当这种交叉探查的需求很常用时,有一种建模方法可以避免交叉探查,就是合并事实表(Consolidated Fact Table)。合并事实表是指将位于不同事实表中处于相同粒度的事实进行组合的一种建模方法。即新建立一个事实表,它的维度是两个或多个事实表的相同维度的集合,事实是几个事实表中感兴趣的事实。这个事实表的数据和其他事实表的数据一样来自Staging Area。
合并事实表在性能和易用性上都比交叉探查要好,但是被组合的事实表必须处于相同的粒度和维度层次上。

Role-playing dimensions:
中文一般翻译为“角色模仿维度”。角色模仿维度是为了处理一个维度在一个事实表中同时出现多次而使用的一种技术处理手段。
在建立了角色模仿维度以后,在底层只有一个物理表存在,但是针对这个物理表会建立多个角色提供给数据访问工具,而且对数据访问工具来说这多个角色是不同的。例如对与累计快照事实表中会出现多个日期字段联接到日期维度。这时就可以针对日期维度建立多个角色模仿维度。
角色模仿维度的建立方法通常是使用视图来完成。例如订单日期维度表如下所示:
CREATE VIEW order_date(order_date_key, order_day_of_week, order_month, … ) 
AS SELECT data_key, day_of_week, month, … FROM DATA
使用同样的方式还可以建立多个不同日期的角色模仿维度。

需要补充的一点是,目前市场上的大部分展现工具,都提供了对一个表选择多次的功能。也就是说,角色模仿维度的功能展现工具自己就可以实现。这样,就不需要我们在数据库中建立角色模仿维度的视图了,而直接使用展现工具完成即可。

Degenerate Dimension:
中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号,如订单编号、发票编号等。这类编号需要保存到事实表中,但是不需要对应的维度表,所以称为退化维度。
退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,尤其是对维度建模的入门者。
退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中,事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说,需要销售单编号和产品来共同作为主键,而不能用销售日期、商场、产品等用来分析的维度共同作为主键。
退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。

Bus Architecture:(即一致性维度架构)
中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构(MD)中的三个关键性概念之一,另两个是一致性维度(Conformed Dimension)和一致性事实(Conformed Fact)。
在多维体系结构(MD)的数据仓库架构中,主导思想是分步建立数据仓库,由数据集市组合成企业的数据仓库。但是,在建立第一个数据集市前,架构师首先要做的就是设计出在整个企业内具有统一解释的标准化的维度和事实,即一致性维度和一致性事实。而开发团队必须严格的按照这个体系结构来进行数据集市的迭代开发。
一致性维度就好比企业范围内的一组总线,不同数据集市的事实的就好比插在这组总线上的元件。这也是称之为总线架构的原因。
实际设计过程中,我们通常把总线架构列表成矩阵的形式,其中列为一致性维度,行为不同的业务处理过程,即事实,在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵(Bus Matrix)。
总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础,也建立了一套可以逐步建立数据仓库的方法论。由于总线架构是多维体系结构的核心,所以我们有时就把多维体系结构直接称为总线架构。

声明: 本文仅代表作者观点,其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。如果本文内容有侵犯你的权益,请发送信息至service@ukettle.org,我们会及时删除
2

鲜花
16

握手

雷人

路过

鸡蛋

刚表态过的朋友 (18 人)

最新评论

  • 大数据技术 未来发展前景及趋势分析
  • 待我一袭袈裟,许你相思放下
  • 青春—怒放的生命
  • 印象·上海(一)
  • 商业智能BI的三个层次

相关分类

127

推荐阅读

更多+
大数据技术 未来发展前景及趋势分析
大数据技术 未来发展前景及趋势分析
流大数据分析· Storm: Apache Storm是一种开源的分布式实
待我一袭袈裟,许你相思放下
待我一袭袈裟,许你相思放下
待我君临天下,许你四海为家;待你君临天下,许谁四海为家
青春—怒放的生命
青春—怒放的生命
  想象中的春季里,应该阳光明媚,而最先感觉到季节变化
130

手机版|小黑屋| μKettle ( 沪ICP备14044064号 )     

GMT+8, 2017-12-14 10:08 , Processed in 0.178919 second(s), 43 queries , File On.

Powered by Discuz!  uKettle

Copyright © 2014 Comsenz Inc.

返回顶部