大牛们~新手求教~数据仓库，数据市集，数据结构的问题!
求教大牛~新手刚入行
1.据我目前理解 数据仓库是对企业级的决策支持和主题 ，数据市集是对部门级的决策支持和主题
如果我的理解对的话，那么问题来了， 数据仓库既然可以对企业级的决策支持，
为什么分出来一个 数据市集针对部门级的呢？ 数据仓库满足不了部门级别的决策支持和主题呢？
这个里面的数据有多大的不同？
2.数据市集的数据 是从 已经收集，过滤好的数据仓库中来的吗？
数据仓库，数据市集都存在的前提下，
3.第三范式 和 星型结构 的关系，
1.第三范式 是数据结构？还是数据模型，或者 数据模式？
2.星型结构 从属 1-5范式的吗？还是其他，或者完全没关系？
刚才发在 数据仓库 那里没人回家，，因为急着做报告，才发到这里
望大牛们~解答！！！
[解决办法]
这个真不懂，oracle板块很冷清的哦
[解决办法]
天呐,你一上来就问这么广泛的问题,我贴个文档给你吧.
N个数据集市才组成数据仓库...你自己看着办
源数据->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的允许情况，还有任何程序都不能保证永不出错，所以我们需要做确保故障出现后能够弥补。
什么是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一样，就好像辩论自上而下还是自下而上一样，就好像争论公司里面工程部和研发部的重要性一样。
