BI的相关问题
什么是BI？
Business Intelligence(BI) = Data Warehouse(DW) + OLAP + Data Mining(DM) 商业智能=数据仓库+联机分析+数据挖掘 做BI的目的是帮助用户进行决策分析，从多维的角度来分析现状，给决策者做出正确的决策提供可靠的数据基础与背景，为企业的发展做出正确的导向。然而在国内做BI确走入了一个误区，通常客户拿BI当报表系统来用，这有点大才小用的感觉，还有就是各个公司水平不同，常常有个别公司拿着拿着非BI系统来欺骗客户给BI蒙上了一层不好的印象，总的来说近两年BI在国内的发展还是比较顺利的，有越来越多的企业和机关来开始做自己的BI系统，比如银行、税务、保险等行业。 BI通常的架构或基本架构是： 源数据->ODS->DW->OLAP->前端。
常用源数据类型：关系数据库、文本数据等。 ODS ：操作数据存储（Operation Data Storage）主要用途是将多个数据源的数据集成到一个临时缓冲区中供数据仓库使用。一般情况下ODS的数据不会保留很长时间根据需要1个月或3个月，如果客户有查询要求的话那么ODS可能需要一直保留，通常情况下不用备份。ODS一个好处是在数据仓库与源数据之间做了一个缓冲减轻了源系统压力，我们在用需要操作用户源系统。比如：我们从源数据向数据仓库中加载事实表数据时，这时候我们需要进行聚合操作，如果没有ODS层，那么所有聚合操作的压力是在源系统完成的，这就会给客户源系统带来很大的压力，这是在项目实施过程中经常遇到的一个问题。
DW：数据仓库（Data Warehouse）简单说就是存储事实表和维表数据的数据库而已。 定义：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。 数据仓库一般采用业界主流的关系数据库，如Oracle、DB2、SQL Server等。 维表：存储描述事实表中数据特性的表，它存储用户分析数据的角度，它给OLAP提供旋转、切片的数据基础。 事实表：存储经过一定聚集的历史数据，是星型架构或雪花型架构的中心。每个数据仓库含有一个或多个事实表。 事实表包括索引和数据两部分，索引部分就是描述事实表数据特征的维表的外键，数据就是事实表中要存放的数据，也就是我们通常说的度量值的来源。
OLAP：联机分析处理（On-Line Analytical Process）工具有Essbase，Microsoft analysis等。 OLAP的基本思想是使企业的决策者应能灵活地操纵企业的数据，以多维的形式从多方面和多角度来观察企业的状态、了解企业的变化。使用OLAP工具我们可以将维表和事实表做相应的连接，然后做聚合操作保存成cube从而达到多角度分析数据的目的。 前端展示工具：前端展示工具是辅助用户来多角度，自定义展现报表形式的工具，是对OLAP工具的一个不错，通常OLAP工具只能做简单的数据展示，上钻、下钻等。前端展示工具可以根据用户需求展现曲线图、柄形图等，通过展示工具我们可以做一些个性化设 置，权限控制等等，常用工具BO，Brio,Cognos,BI Office,值得一提的是BI Office是国内一家BI公司的产品，可以是国内前端展示工具的代表。
ETL讨论： BI开发过程中工作量最大的部分也是最难控制部分就是ETL，几乎ETL要占整个系统的60％的工作量。 ETL常用工具：Data Stage、Informatic、Microsoft DTS等。 做ETL工作原则： 1、要对源数据有充分了解，这需要业务系统工程师配合。不只要了解所用到源系统表、字段的意义，还要对数据的质量进行验证。 2、跟客户确认脏数据的处理方式（丢弃还是默认其它），这会直接影响到最后报表的误差率。 3、确认数据存放时长，只有了解数据存放时长，才可以更好的进行事实表的存储方式（比如分区方式等） 4、及时验证数据的准确性，当我们做了一定的历史数据抽取后要及时跟客户验证数据的准确性，否则等系统上线后发现数据不正确，此时悔之晚矣。 5、确定调度方式，调度不同会影响数据抽取完成时间，比如1周的数据安排在1天调度完成跟分成7次调度的响应时间是完全不同，这要根据应用确定。 6、流程监控与故障处理，这是必不可少的，我们监控ETL的允许情况，还有任何程序都不能保证永不出错，所以我们需要做确保故障出现后能够弥补。
度量、指标和指示器之区别？
有位朋友提到什么是KPI（Key Performance Indicator，恐怕这篇文章不可避免地提到英文了，大开杀戒），对此，正好说说度量、指标和指示器的区别。
度量，用中文表示可以是名词，也可以是动词。名词的意思可以是"度量"的结果值或是指"度量"过程。动词就是丈量、衡量这个行为。在英文里面，Measure可以是度量值的意思，也可以是作动词，而"度量过程"这个名词用Measurement来表示。
因此理解度量这个词，可以从其本身意义理解。度量，其相近含义包括丈量、衡量，首先得有个标准，譬如说丈量得有米尺，衡量有杆秤。度量出来的结果，度量值也就必须是有个单位的。例如重15斤，长1.4米等。此处，斤、米就是标准，有了这个标准，不同的度量值才有可能比较，你用15斤和1.4米比较可没什么意义。
度量和维度构成OLAP的主要概念，这里面，对于在事实表或者一个多维立方体里面存放的数值型的、连续的字段，就是度量。这符合上面的意思，有标准，一个度量字段肯定是统一单位，例如元、户数。如果一个度量字段，其中的度量值可能是欧元又有可能是美元，那这个度量可没法汇总。
在OLAP中还有计算度量的说法，用一个总费用除以用户数，得到每户平均费用。但这究竟还算不算度量了呢？我认为已经不是原本意义上的度量了，只是为了称呼方便而已。
这就得说到指标，英文的Metric。在绩效管理软件里面，通常是有这个概念的。如果非得给Metric一个定义，我愿意表述为"它是表示某种相对程度的值"。区别于上面的度量概念，那是一种绝对值，尺子量出来的结果，汇总出来的数量等。而指标至少需要两个度量之间的计算才能得到，例如ARPU，用收入比上用户数，例如收入增长率，用本月收入比上上月收入。当然可能指标的计算还需要两个以上的度量。
而Indicator的字面意思为指示器，在KPI中，最后一个I就是它，但是用中文称呼它的时候，几乎总是叫"关键绩效指标"，而没有叫做"指标器"，也就造成一些混乱。
想想我们身边哪些东西是充当指示器的。红绿灯，提醒行人车辆是否等待或通行；监控室里的警报灯，提醒哪儿出现异常；汽车仪表盘，提醒驾驶员油是否足够，速度如何。它们起到的作用是传递一种宏观的信息，促使人的下一步行动。红灯停绿灯行；看到警报亮起要赶紧派人查看。目前常见的企业绩效管理软件中，仪表盘（有的地方称作驾驶舱）的展示界面也是必不可少，正是用这种直观而比较有象征性的指示器反映企业运营状况。
可以设想提出KPI的初衷，是希望企业通过一些粗略（非细节）的信息（而非数据）来为下一步的决策作出依据。导致不同的决策行为必定是离散的输入，最简单的就是一个开关，是或不是（例如警报灯）。如果说度量和指标是定量话，指示器就是一种定性的。
现实中，大家对于三者的称呼并不那么严格，"指标"是最通用的称呼，"度量"显得有些学术和技术话，而"指示器"很少听人提起。在电信的经营分析中，确实很多都实现KPI，正如上面所言，领导不可能去看细节的数据，他们关注的是宏观面的经营状况，因此需要一些"指示器"来反映。
然而，这些系统中的KPI并非完全上面提到的指示器，很多系统建设称为度量系统或是指标系统。而对一个企业，哪些指标能够充分反映经营活动，这也是需要精心制定的，而不是让技术部门提出一堆似是而非的指标名称，诸如在网用户数、收入之类，这不是KPI。
关于这三者的区别，曾经在数据质量的考虑中应用过，参见《数据质量体系 之 概念》。再总结一下。
"度量"是绝对的定量值； "指标"是基于两个或更多度量计算得出的相对值； "指示器"是基于度量或指标，并依据某个基准值得到的定性结果；
维度是正交的吗？
如果用坐标系来说明正交的含义，是比较清晰的。但如果要说在OLAP分析中，"对于一个"事实"我们可以从"多个不同的正交的角度"来观测,每个角度就是一个"维度""，这句话就有些不妥了。用正交的角度去观测事实，那是理想不过的，但那些维度必定是不正交的，至少目前无法那样。
考虑的极端一些，所有维度不正交，于是形成一个维度——"发生的事"。横坐标就是这个维度，纵坐标是度量值。其实这就可以想象成一个关系型的事实表，表中有多少记录数，这个横坐标上就有多少坐标点。对每个坐标值的描述，可能就是"2005年6月某地某产品的销售量"，其中"2005年6月某地某产品"就是这唯一维度的维成员。这当然不是正交。因此可以将这个维度拆成三个正交的维度，月份、区域和产品维。他们互相之间没有依赖关系。
看，那么事实表的结构也能够体现这点。一般事实表可以用（维ID1、维ID2、维ID3、度量1、度量2）的结构来表示，其中三个维为该表的主键。如果维度是正交的，这三个维ID相互之间没有依赖关系，这张表是遵循第三范式的。如果有一个维其实是依赖另一个维的，例如一个地区维和一个营销案维，营销案只能在某个地区发生，对地区有依赖。显然这就不遵循第三范式。那么可不可以将地区维去掉，直接从营销案维中上钻到地区不就行了？这可能涉及到统计口径的问题，而且，有些营销案可能确实还是所有地区共用的。
姑且先不谈统计口径的问题，为这个事实表再加上一个维度，营业厅维。显然一个营业厅肯定是在某个地区的，它也是依赖地区。如此，即使在这个维表中去掉地区维。营销案维和营业厅维也是不正交的，必定存在某个营业厅不承担某种营销案的情况。对此，如何将这些维度正交化？
故此，我认为正交的的维度是一种理想化的。维度应该是从业务上面考虑观察事实的角度。它更应该贴近业务上的分类，例如对于产品，可以是按照地区划分类别，也可以按照产品类型或者目标客户群来划分。不过现在通常的做法是从数据得到维度，将某一个代码表转换成维表了事。
不过将正交的维度找出来到也是好事，至少想到一个用处，可以估计这个事实表，或者cube的数据量吧。理论上，事实表的记录条数和cube的单元格格数略等于这些正交维度维元素数目的乘积。
数据探索 之 数据源分析？
一位同事正在作数据探索，我问，"数据探索有什么方法？"，答曰，"没有固定的方法，就是看看数据，作作统计"。
不是没有方法，只是没有形成模式。如果一位即将进行此项工作的人，面对一堆数据，他该怎么办？我想第一个问题是"目的是什么？"。如果他对数据不熟悉，答案可能是"搞清楚这些数据结构和关系"。如果他要做的是数据挖掘工作中的一部分工作，这个答案可能是，"哪些客户群是需要关注的？考虑哪些因素？"而对于后者，如果他对于数据还不是非常熟悉的话，恐怕还是得像前者一样，搞清楚数据结构。
曾经做过一些数据源分析的工作，是为了定义生产系统和经营分析系统之间的接口，工作的目的就是搞清楚数据结构。这种目的不算非常强，所以采取的方式是首先确定大范围，再逐个表分析，给出表的定义，约束关系以及和其他表的关系。例如需要分析客户、帐务、业务使用的数据，而资源、数据业务的先不管，缩小范围。一般来说，这个范围可以缩到很小，数量级在20以内是个不错的选择。如果太多数据只会让人产生恐惧，难以入手。但其实最终需要分析的表肯定超出20个，因为沿着表之间的关系，能够引出一些新的需要分析的表。
虽然一般都会有数据字典帮助你理解数据，可几乎这些文档都只是记录了表结构，表名、主键、外键参照等，而字段之间的逻辑关系，表的概念定义很少见到。例如对于一个用户表，到底这个表里面存放的数据表示什么业务含义呢？找不到这样的信息，如果说这张表中存放了所有的用户（假设我们已经给用户一个定义，客户定购某种产品的契约关系），那么这个"所有"是指历史上所有出现过的用户？或是当前活动的用户？
要是对业务熟悉，脑中已经有个概念模型，很快就可以切入重点，三户关系如何设计的？销帐流程是怎样在数据中体现的？预存、托收、赠送费用都如何体现的？带着这些问题去探索数据，当然是事半功倍，可以将这些问题看作为更进一步的探索目的。
在纷繁的表、字段中，你真正关注的为数不多，需要将它们挑选出来，重点描述。例如对于帐务上面的费用字段，他们之间的逻辑关系可一定要搞清楚。对于这种关系，一个好的方法就是选取一些用户的实际数据，观察他们的费用，在帐户上的余额每月如何变化，而帐单上的明细是多少，销帐明细中从哪些帐户上扣掉这些费用。观察了四五个客户，这种关系自然明了。
最终，可以形成一份数据源分析报告，从限定范围内的每个表开始，给出概念定义，以及设计层面与概念层面不相符之处（例如概念上用户表存放的是当前活动用户，而销户的已经转移到另一张表，但其实此表中还是存在已销户用户），将表的字段进行分组，例如在通话详单中，可以分成本方用户信息、对方用户信息、网络信息、通话信息，计费信息等，这可以便于理解。
说了这么多，不还是分析三步曲吗：
1、明确目的——探索数据为了什么？能不能带着问题进去啊？
2、分门别类——根据主题缩小范围，对字段进行分组
3、去芜存菁——挑选重点的字段，用样本观察
上面都是在说如何理解数据结构和含义，也将它叫做"数据探索"的一部分了，当然如果是数据挖掘，其数据探索步骤还有更强的目的性，容以后再谈。
多维分析？
OLAP这个名词是1993年提出来的，可是多维分析不是，早很多年。
最早的多维分析是从什么时间开始的？
最早的多维分析软件产品是什么时间出来的？
最早的ROLAP是什么时间出来？
从OLAP Report的一份资料中，有这些答案，请看http://www.olapreport.com/origins.htm
从不同的角度去分析发生的事实，这是分析问题的本质。虽然我们现在将OLAP和多维分析划上等号，但在93年之前，人们也是在进行多维分析，只是无名而已，人若无名，方可专心练剑。
早在上世纪60年代，也就是四十多年前，已经有人发明一种语言，APL（A语言），使用在大型主机上的。大约十年后，1970年，Express问世，也就是现在Oracle Express的前身；在大约十年后，八十年代初，Comshare的System W出台，这应当是第一个使用"多维立方体"概念的产品，以后的Essbase也是大受其设计理念影响。Express和System W刚开始都是用在大型分时主机系统上的。八十年代后期，开始往DOS、Windows上移植。看，这些厂商命运波折啊，Express在95年卖给Oracle，却停滞了好几年，直到01、02年的时候，Oracle才开始着力发展，将Express集成到Oracle 9i中。而Comshare，于03年卖给Geac，这是一家作ERP的厂家，Comshare的产品也就此消亡。因为Geac竟然舍弃自己的多维数据库产品，而去用Essbase和微软的Analysis Service，真是伤心啊。
Metaphor可以算是第一个ROLAP产品（当然那时并不叫ROLAP），于1984年推出，因为他提出基于关系数据库来模拟多维操作，这个概念也是直到90年代才流行。之后有Metacube、Whitelight和Microstrategy等采取相似概念的产品。可惜，基于这一策略的独立开发商几乎没什么好下场，至今只有MicroStrategy撑了下来。
人们使用多维分析对性能的要求可谓很好，以前的这些产品虽然在性能上做了很多的考虑，例如预先汇总计算、多维存储、聚集表都是能够提高多维查询效率的。到1990年，Cognos推出Powerplay，这是第一个桌面OLAP产品，并且也是第一个基于Windows平台的。桌面OLAP，缩写为DOLAP，其特点是cube数据量小，可以下载到本地，这在十几年前网络带宽不够的情况下，赢得最终用户的青睐。1992年，Arbor推出Essbase，在整个90年代，曾经辉煌一时。98年，微软进入OLAP领域，为了迎接挑战，Arbor便和当时的Hyeprion Software合并，成为现在的Hyperion Solutions。
99年微软发布了其OLAP Sevice产品，也就是现在Analysis Service的前身，2000年改的名。并且积极推进OLAP标准化的进程，OLE DB for OLAP，MDX，以及和Hyerion、SAS联合搞XMLA规范，都显示其野心。
到了新世纪，一些多维分析产品的厂商纷纷合并，各厂家都在联合优势力量朝全面方案解决提供商迈进，因为那些大厂，诸如十八摸、微软都在虎视眈眈盯着这块市场。于是BO、Hyperion、SAS等都纷纷买入公司打扮自己。但这些资本运作是真的壮大他们还是加速死亡呢，说不准。但OLAP走向标准化却是大势所趋。
最后附上OLAP Report的OLAP简要里程碑，见： http://ttnn.c3crm.com/index.php?title=OLAP%E4%BA%A7%E5%93%81%E5%8F%91%E5%B1%95%E7%AE%80%E5%8F%B2 。
OLAP和数据挖掘的区别？
在dwway上看到一封yiyiya的帖子，介绍11月24、25日的BI大会，吸引我点开这封帖子的原因不是这个会议，而是这个日期。
yiyiya对这次会议的评价颇高，其中对于一位香港公司发言人介绍自己先上数据挖掘，再上OLAP和报表有一些疑问，为什么不是先上OLAP再上数据挖掘呢？接着，yiyiya道出自己的理解，像这家香港公司如此成熟的企业，OLAP应用相对低级一些，就不是那么重要了。这种理解我是不大赞同的。OLAP应用就比数据挖掘应用低级吗？
一种应用只有恰当地解决了客户的需求才是好的应用，说这种应用低级，那种应用高级，恐怕还是技术导向的思路。不可否认，OLAP使用技术比数据挖掘简单，前者也就是涉及到维度、度量、层次、cube等一些概念，技术上真的有些傻瓜。而后者好像真的高深很多，一堆算法，什么关联算法、决策树、神经元等等，怪能吓唬人的。为他们两者辩论，就好像辩论Java和.NET一样，就好像辩论自上而下还是自下而上一样，就好像争论公司里面工程部和研发部的重要性一样。
OLAP和数据挖掘都是为决策提供支持，只是侧重点不同，前者提供描述型的模型，告诉你什么样的产品在什么地区的销售额和去年的对比。后者提供探索型的模型，告诉你啤酒和尿布的规律。最后的决策都是人来做。
近几年的大型BI项目几乎都是这种思路，先建数据仓库，上OLAP和报表应用，数据挖掘在二期考虑。出现这样的潮流因素当然非常多，首先一个因素就是它是流行的，跟随潮流是一个非常便宜的决策；再有集成商的原因，他们有没有相应的技术积累；还有客户的原因，是需求导向，还是做大蛋糕。当然肯定还有很多其他的因素，暂时想不到。所以说这家香港公司选择先上数据挖掘应用，可能是一种逆潮流，标新立异，可能是一家有很深数据挖掘积累的集成商来开发的，也有可能客户就是先急迫需要找出一些规律性的东西。当然，这都是猜测。
在做OLAP分析时 ，主题一般是怎么确定的 ？什么样的概念就叫做一个主题？
主题是根据分析需求来的，最好是自上而下，这里的上指的是分析，下指的是数据仓库。例如一个销售部门需要了解各店面每季度每个销售员的销售情况，这就是一个主题。主题（subject）这个词，意义很宽泛，也发生了变化。通常，可以叫一个OLAP Cube作主题，当然也有将一系列Cube，服务于同一类型用户的cube合在一起称为主题，例如"财务分析"主题，就是给财务部门看。
- 我感觉主题的确定比较困难，除非客户有明确的需求；并且主题确定时 还需要考虑现有的源数据都有哪些，必须结合用户需求和源数据才能设计得比较好，不知道我的理解是否正确？
是的，主题的确定最好要知道客户需求，否则可能是白忙活。如果根据需求，发现没有数据支持，只能退而求其次；但如果仅仅根据有哪些数据作哪些主题，不是明智之举。
- 用户可能有多个需求（用户并不了解什么叫做OLAP），但是我们分析以后，这些需求虽然涉及到的维度信息都一样，就只有度量不一样，这样的话，我们就把这些东西作为一个主题，是否正确？；如果正确，是不是可以这样说，我们只要将需求里涉及到的度量和涉及到的维度列出来后，形成矩阵，就可以确定主题是什么？
和客户不需要讲OLAP，这只是一种技术手段。他们的需求是分析一件事，这件事需要从不同的角度，可以变换，可以深入，可以浅出。
如果出现很相似的需求，如你所说，维度相同，度量不一样。这是常见的，不同部门可能关注的分析角度一样，例如都是时间、地区、产品，但有的部门关注量，有的关注利润、成本。可以把他们作为同一个cube，但推向给用户的时候，最好能够分开，因为不必要的信息总是干扰视线的，就像我们现在看电视有太多的频道。
是否需要建立ＯＤＳ？
从一个实际情况来看看操作型存储。
以前，我们大多的项目设计的操作型存储层中，是将数据源的表结构照搬过来，但在这一层面处理数据的维度转换和清洗工作。维度转化是因为曾经使用了大量的代理键（后来发现不必要，但已经很难改正矣），清洗工作是保证在这个层面数据都已经转换成数据仓库认可的数据质量，也就是说，对主键、外键、字段非法等问题，都在这一层清理掉，要不拒绝，要不转换成特定的代码，如"未知"。
原来设想的操作型存储层的目的确实是为了满足即席查询那种诸如名单、详单之类的统计，不过很长一段时间里面。它的作用是混乱的，一方面因为数据仓库层有时候不能满足统计需求，一方面因为大家对整体数据仓库的结构有些不明了。
于是很多可以从数据仓库层出的数据都直接从操作型存储中统计。如此，确实造成很多不必要的重复工作，例如一个统计各地市收入的需求，明明数据仓库层就有这个数据，统计好了放在那里，可有人还是愿意从明细的帐单表中汇总一遍。
后来决定将层次要分清楚，能够不从操作型存储出的数据就不出，尽量根据需求在数据仓库层汇总好。这样，基本上能够满足大部分的统计需求。当然对于某些特定的应用，诸如挖掘，还是得从操作型存储取数，构成自己的挖掘集市。然而即便如此，发现对操作型存储的访问其实大大减少了，例如详单，总觉得将它转换放在表里面没什么作用，反而是浪费转换装载的时间。正好我们采用的是接口文件，于是干脆也不转换，直接保存详单文件，如果需要统计的话，直接用文件建立一个外部表。如此，操作型存储几乎就演变成了数据装载区。 这种应该算作是球派的做法，数据装载区和操作型存储的区分模糊。
在我理解的郁闷派的操作型存储，不一样。在郁先生提出的理论中，操作型存储层要对企业业务模型进行重构，采用第三范式（而球派还是建议采用维度建模）的方式构建此层模型。因此，他的操作型存储也就是一个非常大的、理想的模型，这也符合此派自上而下的理念。很多大公司，诸如十八摸、恩西阿都愿意这样干，因为他们自认为有能力自上而下去构建整个数据仓库，因此这些公司都有自己的概念模型，提出诸如参与方、产品、资源等实体。然而在国内很多实际项目当中，这些概念模型变成一种幌子，根本就无能力去自上而下去设计模型，还是落得个将数据源的表对应到操作型存储的局面，悲哀啊。
质疑ODS- -
目前考虑最多的是ETL的设计实现，但是有个问题在我脑海里隐隐浮现。这个项目实现了一个企业ODS，那么这个ODS究竟是出于什么目的而建设的呢？谁能告诉我，客户在这方面投资人力、物力和财力究竟要得到什么回报呢？这种项目，如果是一个国内集成商，谈下来的可能性很小，即使谈下来，恐怕最后也只有死路一条。为什么，因为你在谈判上面没有竞争力，呵呵，竞争五力模型中有一个就是客户的议价能力。这个能力是相对的，和你自身的竞争力倒是次消彼长的。就像你去一个郊区的批发市场去买东西，你敢狠命地侃价，但是你要去城里的超市买东西，你就乖乖地按照标价付钱。但其实，甚至，你都知道这个超市也是从那个批发市场进的货。
IBM电信业务模型提出的9大概念在这里得以部分体现，依照面向对象的思想去设计关系模型，能够使整个模型更加清晰。但却也造成一定困惑，那些"父类"的关系表如何装载啊？需要装载吗？如果不装载，那么放在模型中仅仅是起到一个便于理解的作用吗？
本项目的ODS走郁闷路线，使用3NF的设计，提供企业级CIF，独立于EDW。但是我想ODS总需要服务于什么吧？现在的应用只有几张简简单单的报表，我不知道现在的模型设计依据是什么？服务于分析应用应该是一个说法，但是对分析来说，怎么着也需要保留历史数据，哪怕是短期的历史数据啊。
可能是自己对系统架构没有理解清楚，不过这到让我想起一个问题。就是对项目成员的培训，模型是核心，更需要向相关人员灌输模型设计的思路。可是一个星期以来，自己还是产生这些的问题。
什么是元数据？
元数据常常称为data about data, or info about info。
在不同的领域有不同的含义，可以指机器可理解的信息；电子资源的记录；等等。
元数据有三种类型：
描述元数据，描述资源内容，用于discovery和标识。作者，摘要，标题，关键字,等等。
结构元数据，描述组成资源的构件之间的关系。如，页如何组织成章节。 管理元数据， 描述资源载体。用于管理。如资源何时被创建，文件类型，访问权限。
元数据有两种存储方式： 与资源对象存储在一起。好处是 防止元数据不丢；消除了元数据与资源之间的链接；与资源一起更新。例如图片文件，mp3文件，等等。缺点是，有些资源无法和元数据放在一起，如人造品。 与资源分开存放。好处是便于管理、搜索、提取。 这是常用的方式。
几个模糊的名词
*什么是业务？
1、业务是企业向其客户提供的服务。
例如银行为客户提供储蓄、贷款服务，这是它的业务，电信提供通讯服务，这是它的业务。
2、业务是组织维持自身运作的所有活动。
包括人事、财务、生产等各个对客户的，对伙伴的，对员工的活动，一般在建模的时候，业务指的是这个意思。
*什么是业务流程？
业务流程是指组织的活动涉及到的人、物，以及活动之间发生的先后顺序、依赖关系。
*什么是业务需求？ *什么是用户需求？
业务需求和用户需求得放在一块说，因为我区分不出来。
它们都是指软件服务的对象提出的对软件的期望。还未成为现实，甚至未被认可，这是需求调研的结果。
*什么是软件需求？
软件需求是对软件系统的规格定义，这个软件是什么，不是什么，为谁服务，如何服务，流程如何。这是需求分析的结果，作为软件设计的输入。
*什么是BI需求？
必爱需求是软件需求的一种，用面向对象术语说，前者是后者的子类，符合软件需求的定义。
数据仓库对模式、理论的选择？
为什么dw使用星型模型，为什么使用关系型数据库？
对于第一个问题，我同意伟平的说法。其实就是实现了维度结构，星型模式是一种比3NF更加形式化的模式，其目的正是为了支撑OLAP的要求，是一种支撑分析应用的模式。特别是针对ROLAP，如果不建立星型模式（或者雪花模式），想建立olap元数据是非常困难的，因为某个维度需要跟物理维表关联起来，维中的级别、属性、钻取体系都要与表中字段对应起来。同样，度量也需要和事实表中某个字段对应。在星型模式中，这种对应关系是匹配的，所以很方便地描述它们。然而如果是基于3NF去映射一个维度结构，当然可以，只是需要额外的工作，因为3NF和OLAP模型是不匹配的。
可以先将这部分工作分成两部分，一是数据模型，二是OLAP应用。如果数据模型用3NF，那么OLAP建模的事情多放在OLAP服务器中进行。而如果使用星型模式，OLAP建模其实部分工作移到了数据建模这边。
这样理解，其实采用星型模式是为了让架构和过程更加规范。当然，代价是数据的冗余。
对于第二个问题，为什么使用关系型数据库。如果不采用RDB，还会有哪些选择呢？多维数据库、面向对象数据库、xml数据库？显然，后者都是一些不成熟的技术，不似RDB，其关系理论已经存在三十年矣。
多维数据库主要面向分析应用，对于存储海量数据当然有其缺陷。更加不用提没有一个标准的接口。至少微软提出的MDX还并没有形成一种访问标准，而在数据存储理论上，各个厂商有各自的一套。而面向对象数据库，虽然也是也是发展多年，但其主要应用还是偏向于一般系统的设计、开发效率，也不擅长数据存储。虽然有一些规范、理论，但大多还没有形成比较权威的形式化理论，还是处于感性阶段。
像sybase的IQ数据库，这玩意儿到底是个什么类型的数据库，我也不是非常确定，但显然他并没有颠覆关系数据，同样有表、字段的概念，只是他颠覆了原来按行存储数据的技术，改用按列存储数据。最后还是同样用SQL来访问数据，所以姑且还是认为他是关系数据库吧。
如此，似乎只有选择关系数据库来存放海量数据，当然可以附加地采用多维数据来存放用于分析目的的数据。未来会不会还是如此，说不一定，但至少在三五年内，还不不会有什么新的变化。
"如果你使用了某种工具，那么就采用该工具支持的架构，方法论"？
如果是这样理解，赞同一半。工具背后包含一些思想，例如你用一个MOLAP服务器，其实并不要求你一定要构建星型模型。如果使用ROLAP，恐怕还是得有。如果你是使用一个企业绩效管理软件，恐怕大多都是先定义指标、设计仪表盘等步骤。显然，并非所有工具针对同一问题都是同样的解决方法。例如对于数据整合，有人ETL，也有人ELT。这些差别正是设计者的思想体现。
所以，zen的针对某种工具而架构的观点，同意。
但思想和方法论还不同，和架构更加不同，方法论是对思想的具体化，而架构更是对方法论的具体化。工具中包含产品，可不一定包含方法论，更加不一定包含架构啊。况且，看现在的BI项目，很少是采用一家产品的（除了一些大厂）的，数据仓库可能是oracle，但不使用他的owl，使用datastage和powercenter，不用express，而用essbase或是cognos。客户的这个想法可能有如下两点考虑。
一是每个模块都要选择最专业的，相比total solution，似乎这更加重要。因此，很多厂家的total solution开始将各种专业工具进行整合，甚至在公司层面进行整合，例如ibm将ascential收入囊中。
二是中国人喜欢"制衡"，都买了一家的产品，不是受人牵制嘛？因此要多搞一些参与方，大家为了利益平衡，都会牺牲一些。当然对于客户来说，这牺牲换来的就不敢说是什么东西了。
早上还和同事谈bi的架构。他认为BI其实没有什么架构，一张图足以搞定，上面有数据源、ETL、DW、DM和若干应用模块就完事了。我看没这么简单。如果说软件的架构，当然有共通的架构技术，例如CORBA、SOA等。但那些都是在架构底层平台，而在具体的业务领域，同样需要针对具体的问题来考虑。这些问题包括诸如ETL流程如何错误恢复，OLAP CUBE如何进行增量刷新，元数据如何同步等。
这些问题大多其实并没有被这些工具形成固定的方法论或是架构，最多只是在它们的best pratice中提及。可见，架构这个东西，还刚上路呢。
从ROLAP到MOLAP- -
记得2000年的时候，在QiDSS中使用的是ROLAP技术。到2003年，全国上下的BI系统几乎都采用MOLAP技术，这是一个很值得思考的现象。表面上看，由于工具厂商市场份额的变化，对产品推广力度不够。在QiDSS中，使用Metacube作为OLAP Server，但是就在那个时候，它已经宣称不再升级甚至不再提供支持了，当时业界提供纯ROLAP产品的厂商已经不多，现在Microstrategy公司依然存在，而且据说在国内有几个客户，很早了解他们就是因为它是ROLAP产品提供商，不过对它们现在的产品线已经不清楚了。
更深一层看，为什么ROLAP产品生存空间不大，必定和用户的需求有关系。用户需要的不是产品，而是在线分析的功能，其中重要的一点就是分析响应速度。
这一点还是MOLAP占了上风。从技术角度来说，ROLAP和MOLAP各有千秋。前者基于关系型数据库，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去。
相比较而言，MOLAP事先将汇总数据计算好，存放在自己特定的多维数据库中，用户的OLAP操作可以直接映射到多维数据库的访问，无需通过SQL访问。可以说ROLAP提供了更大的灵活度，但可能正是这种灵活度，造成对用户使用的不友好印象，确实相比Metacube和Cognos，前者的操作复杂多了，不过这应该不成问题，是可以改善的。
性能的问题却不是非常容易解决的，关键还不在是聚集表快还是多维数据库快。从体系架构上说，采用MOLAP使得OLAP应用和数据仓库分离开，降低了耦合度，这种架构是比较理想的，可以让不同部件专门干自己的事，付出的代价主要是ETL的复杂度。而ROLAP技术直接依赖数据仓库，与之紧密结合，OLAP的性能很大程度上依赖数据仓库模式设计，这一点不是总是被保证的。
不过对于ROLAP，我对之有些信心。别看现在大家都在用Cognos、Essbase什么的，那都是轧堆，十年河东，十年河西。如果在ROLAP上有成熟的方法论用以规范化数据仓库设计的话，以后必定又能大放异彩。
数据仓库中的数据形态
对于数据仓库中的数据，我们一般理解都是记录历史变化的。他的定义中也明确提到这一点，所以数据仓库中的事实表一般都有时间或时间戳字段来支持记录的历史变化，而且不光是事实表，维表也要体现历史变化，其中，代理键就起了一定的作用。但是对于ODS层表，他记录的是最近时间的原子数据，忽略了一些历史信息。
ODS层表的数据形态按反应历史变化情况可以分成两种，一种是快照型的，一种是事件型的。
系统中存在一种数据，如果用ER图表示的话，他们多是被别的数据参照，这种数据不知有没有固定的叫法，这里姑且叫做“主数据”。顾名思义，这些数据是很重要的，是系统的核心数据，被引用的越多越重要。例如产品数据、客户数据，以及一系列的代码数据，都属于主数据。而主数据在ODS层中的存储一般都是选择快照型的形态存储。快照型数据反应的是最近一点时刻，主数据的状态信息，例如客户的状态，客户的信用度等，他们都通过update操作将前次状态或信用度都更新掉了。而另一种数据形态，事件型数据，记录是事件的发生，例如记录一次通话，记录一次开帐等，日志表也属于这种形态，它反应的是对数据的历史操作。这两种形态的数据一个较大的区别就是前者会不断被更新，而后者一般不会做更新操作。
理解这两种数据形态对于数据抽取有一些帮助。因此在数据仓库日常的ETL工作中，不可能总是处理全量数据，那个量就太大了，必须寻找增量。这里的增量不是指增加的数据量，还包括修改的和删除的数据。增量的支持对数据源系统是一个很大的考验，对于快照型数据，数据源在实时变化，如何捕捉一个时间段内所有发生变化的数据？一种方法是加入时间戳，所有插入、更新操作都能反应到时间戳，通过选取时间戳在某个时间周期内，就可以得到该周期内的增量数据。但是这种方式没法得到删除的数据（不过一般而言，对于主数据的删除都是很少发生，因为有别的数据在引用它，多数采取删除标记的做法）。还有一种方式得到快照型数据增量，通过数据变更日志，因为每条日志反应的是记录的变化，一个时间周期内出现在日志中的主数据，就是该周期的增量。这种方式还能处理删除数据，但是到了ODS层，通常也不建议删除任何数据。
通过这两种方式获取快照型数据增量都有一些问题。主要是数据源的支持程度，例如是否有时间戳字段？日志是否记录每种主数据变化？有些系统的答案是否。例如数据源的用户表、客户表就很少有时间戳，而对日志，很可能不能反应所有数据状态变化，以前遇到过一种情况，系统有用户开机日志，停机日志，但这些日志是属于营业模块的，而当另一个信用监控模块对用户作出欠费停机处理后，日志中就没有。如果数据源对这两种方式的增量抽取支持都不够的话，可就得想一些办法了，“宁杀一千，不放一个”。一边是全量处理的性能矛盾，一边是增量支持不力的矛盾，需要一种平衡。比如对于用户增量数据，在用户表中有一系列时间字段，如开户时间、开机时间、停机时间、销户时间等，通过这些时间的判断，也能得出一种增量，只不过略显麻烦，而且也不能保证数据源对这些时间的维护是一致的。
对于事件型数据，处理增量相对直观一些，因为这种数据一般都有时间字段或时间戳。但是增量抽取同样存在一些问题。主要是对历史数据的修改，严格意义上，事件发生了，既成事实，不要在修改这些数据，要修改也只是另外一次事件了。但是数据源存在这种现象去修改历史记录，甚至还有手工修改的，根本无法通过时间信息来获取增量。例如话单重批和帐务调账等操作很多都是修改历史数据。面对这种情况，有时就得作出选择，忽略这些数据变化。
度量对维度的眷恋- -
所有的维度和度量组合都是有意义的吗？显然不是。但是有些度量对于维度有依赖关系确实存在的。
这个问题很早就遇到过了，一直想给这个问题命个名，但是好久都没有找到他的特征。现在，我姑且将它称之为“度量对维度的依赖”。
举个例子来说，有个多维分析，有两个维度，一是月份维，一是费用类型维，包括长途费、漫游费等维成员，另外有一个度量，用户数。通过这个Cube，分析人员想查看每个月份的用户数，好像很简单，只要将费用类型维在展现时不作分析维度即可，但是往往发现分析结果是错误的，会比实际用户数多出一些。再仔细考虑一下，就会发现一个用户一个月即会发生长途费，也有可能发生漫游费。所以在这个Cube中，这个用户数已经带有一些含义了，称作特定费用类型的用户数更恰当一些。如果在分析时没有带上费用类型维，或者没有将费用类型的某个维成员作为过滤条件。那么一个上面提到的这种用户就被count了两次，怎么会不多呢？对于这种情况，就可以说，用户数度量依赖于费用类型度量，它表示用户数度量不能脱离费用类型维度求和（请注意是求和，对于avg/max/min倒不会导致数据错误）。
虽然很早发现这个问题，但是解决它的方法却有些意思。最开始，从客户需求的角度，认为一定要在OLAP分析的时候实现这种去处依赖的功能，所以在DW设计时想尽办法，但发现无法满足这样的需求。深入思考发现，这种依赖不是一个技术问题，而确实是一种业务问题。就拿上面的例子来说，用户数的维度表述的不准确，特定费用类型用户数和用户数不是同一个概念，想在一个Cube中实现本身就是有问题的。
因此，后来，在DW设计时将存在这种度量和维度的事实表分成两个表，一个包含了依赖维度和度量，另一个只有度量，去掉了被依赖的那个维度。这种设计的考虑还是为了满足客户的需求，提供了两个Cube，他们唯一的区别就是是否有那个被依赖维度。但是客户真的需要这两个Cube吗？真的希望能够从特定费用类型用户数上钻到用户数吗？肯定会有。但却无需这样的分表设计。一定要意识到，这两个Cube分析的主题本身就是不一样的，即使只差一个维度。
期间，甚至有一度，我们建议客户不要产生这种有依赖关系的分析，譬如不要分析特定费用类型的用户数，不要分析通话用户数，而分析通话次数，不分析缴费用户数，而分析缴费笔数。有些客户会接受，有些不接受，这还是要感谢那些不接受的客户，没有将这个问题埋没了。
其实这种具有依赖关系的维度和度量应当看作是正常的，有时在Cube中，一个度量还会依赖多个维度，例如通话用户数依赖于漫游类型、呼叫类型等。要想在分析中不会出现最开始出现的那种产生错误结果的数据，不是从设计去修改，而是从前端去修正，OLAP工具能够识别这种依赖关系，当分析人员分析一个度量时，工具能够自动提示分析者无法抛开依赖维度分析此度量，或者自动将依赖维度加入到分析维度或作为过滤条件。
结合另一篇文章，数据形态再探，那里提到数据仓库中，事实表在时间变化上有三种形态，事件型、周期快照型和累积快照型。度量对维度的依赖和这三种形态有一些关系，再看看这三种数据形态的特征。累积快照型数据一般存储实体对象的状态，它包含的实体对象是最全的集合。周期快照型数据存储一段时间内，例如一个月，发生某些事件之实体的状态，他的实体对象不是最全的。而事件型数据只存储那些曾经发生过事件的实体，而没有发生事件的实体必定不存在的。
再来分析一下维度依赖的特点：
1、依赖维度的度量很多是对实体的计数，例如用户数、新增客户数等。可以称之为实体计数度量；
2、还有一种度量依赖是那些时点数度量，例如费用余额等维度，它必定是依赖于日期维的；也就是脱离日期维对这些度量累加是没有意义的；
3、对于实体计数度量，依赖关系多发生在基于事件型和周期快照型数据上，例如特定费用类型的用户数，通话用户数；
4、时点数度量依赖关系多发生在基于周期快照型和累积快照型数据上，因为一般时点度量都是从这两种数据统计得到，请参见数据形态再探。
5、有些度量既是实体计数，又是时点数，兼举这些特征。
对于事件型和周期快照型数据来说，一般实体主键只是它的逻辑主键之一，甚至不是主键。（这里叫做逻辑主键是因为很多系统为了性能等因素考虑会不建物理主键）。例如月帐单的主键包括帐务月份、用户ID、费用类型，缴费流水表的主键可能只是一个流水号。除了这些主键，这些表中还存在一些属性字段，有的处于冗余考虑是依赖于实体ID的，有的是强依赖主键的。前者例如一个套餐属性，他是依赖UserID的；后者例如呼叫类型、缴费类型等属性，都是依赖主键的。由此，可以将他们表示成如下结构：
主键＋实体属性＋主键属性＋其他
其中，主键、实体属性和主键属性可以作为维度出现，而“其他”部分可以作为度量出现，例如费用、时长等。
从上面结构中得到一个Cube，如果包含实体计数度量，那么就可以发现，它会依赖出了实体ID的主键和主键属性衍生出来的维度，而不会依赖实体属性衍生出的维度。例如对于缴费流水表，他的结构可以是如下：
主键（流水号）＋实体属性（用户ID、帐户ID）＋主键属性（缴费类型、营业厅..)＋其他（缴费金额..)
如果基于它统计缴费用户数，而如果又有缴费类型和缴费点维度的话，那么缴费用户数就是依赖于缴费类型和缴费点维度。也就是说，这个度量不能脱离这两个维度中的任何一个求和。当然，对于这种多依赖关系，我认为不值得提倡。当然，如果你没有将所有的主键属性作为维度的话，这个计数度量必定是要通过distinct count求得的。
自动化必定战胜人海战术吗？- -
昨天的21世纪经济报道上说东芝将自己的锂电池事业部整体出售，原因是干不过人家。小日本的东西还是比较先进地，高度自动化的设备。买家是一个台湾人，厂址设在上海莘庄（这个地方名称很熟悉，每次在上海站坐地铁都能听到）。
东芝到底干不过谁，除了小日本其他几个大家伙，索尼、松下等等，还有一个让俺们引以自豪的比亚迪公司，这是一家中国公司，牛比。他的特点就是人海战术，将数以万计的生产环节全部转成人工操作。东芝的那个自动化生产线据说要8300万，而比亚迪的生产线只需要300万，真是比丫狄龙，看来比亚迪的名字起的也好。而中国的人力成本相比较而言，那可算不了什么，因此这种巨大的成本优势，给那些小日本公司带来不少压力，哈哈哈哈。不过问题也是有地，俺们要全面的看待问题嘛。比亚迪的电池质量现在还正收到质疑，毕竟手工操作能够保证产品的稳定性吗。
估计有人会说比亚迪短视，要从长远角度看，自动化当然要比你人工操作成本要低，而且质量更高。但是那要多长远？不可否认比亚迪找到了一个符合中国国情的策略，找到自己的竞争优势。对于质量问题，也可以通过在关键生产环节逐步自动化来达到。
由此，想到我们项目当中也碰到这种类似情况。自动化还是人工操作，这是个问题。在数据仓库项目中，流程的自动化确实是一件非常重要的工作，能够节省很多成本，不过要开发或购买支持流程自动化的工具，那也不是一个小的成本（不过一般国内IT项目的成本核算不是很严）。而且，项目进度带来的压力，迫使项目组成员会选择自己最熟悉的方式开发，所以在没有工具支持或是严格的规范的时候，必然形成广泛的手工操作，这也给系统带来很多隐患。
而对于比亚迪的人海战术，对牛的还是它能够将复杂的流程切分清楚，而且能够达到相对高的质量水平，真是不服不行啊。如果我们也能够将ETL流程切清楚，在找一批人，500块钱一个月，还包吃住，俺们的成本也能降下来啊。
BI项目组织结构- -
对BI项目，采用矩阵型组织结构颇好。可以将它看作是一种中庸之道，当然也存在很多问题，不过却可以降低项目风险。建立一个研发的只能部门，收集各项目组中遇到的技术问题，提供尽可能共通的解决方案；提炼、研发共通的企业业务、数据模型；为项目现场提供技术支持；提炼项目实施的方法论，用于指导项目成员的实施。这些工作能不能在项目组中作，当然也能。但是这又一个依赖，就是需要人的自觉性和自发性。但是如果制定了这样一个制度，让现场的某个人即负责项目实施，有负责技术积累，就是职责不明确，造成的结果可能是什么也没有作。 上面提到建立研发部门主要是从技术积累的角度去看的，如何为项目组提供更好的服务。而从公司发展的角度，研发部门甚至承担更重要的任务。有的企业以技术为核心，那就是它的的核心竞争力，有的可能是以营销作为核心竞争力，虽然不需要技术，但是营销手段不是一拍脑袋就出来的。前几天看到有人评价联想收购IBM PC的事情，提到dell，说dell也没有核心技术。这我认为有些问题，dell的核心并不在于技术，他的技术再牛能牛过IBM吗？但是他依赖的是他的营销模式，构建这个模式需要注重各个细节，这些细节的优化还是需要大量人员投入研发，正是因为这些细节，虽然有很公司去模仿dell模式，却没有那家企业能够在这些细节超过他。 写到这里，得到一个结论。一个企业的研发部门承担的就是对自己核心竞争力所在的细节研究和开发。所以研发部门不总是在研发技术，如果一个以技术为核心的公司，那是如此。但核心竞争力除了技术还有资源、营销模式甚至是人际关系等等，那么研发部门可能就需要承担研究资源的最高利用模式、最融洽的人际关系等等。研发的产出，可能是产品，可能是一种服务，可能是一种方法论。这些职能在各种企业中应该都会有，可能名字不叫研发罢，还有的企业甚至根本没有找到自己的核心竞争力，研发的面太广了，无法集中火力。
请问即席查询与自定义报表之间有何不同和相同的地方？
一般即席查询也是使用BI前端工具开发，由于开发简单，往往客户可以经过简单培训后自己开发使用。 例如，Cognos ReportNet分为Query Studio和Report Studio，一般说来Report Studio能开发出较为复杂的报表，功能更强大，而Query Studio可以开发简单报表和一些列表，其实就是为即席查询准备的，简单、方便。
数据仓库设计：星形模式与雪花模式的优劣
个人认为 星形模式可以提高查询性能降低了维表的复杂度 雪花模式更符合3NF,数据更易于维护，但是可能会牺牲查询的性能，增加了维表的复杂度
大项目一般先雪花再星形, 两者优点皆用上, 可以参考.
实际上大部分时候能简则简，用的都是星星模式！