数据仓库初体验
数据库仓库架构以前弄的很简单：将各种源的数据统一汇聚到DW中，DW没有设计，只是将所有数据汇聚起来；
ETL也很简单，只是将数据同步到DW中，只是遇到BUG时，处理一些错误数据，例如：字符串中有分隔符，有回车等等。
仔细看了一些概念后，发现DW是需要经过仔细的设计架构的，下面还是纪录，其中很多架构设计部分还是不理解，ETL中的Transform也需要研究，后续其他帖子详细记录。
---------------------------------------------------------------------------------------------------------------------------
构建企业级数据仓库五步法:
一、 确定主题
即确定数据分析或前端展现的主题(例:某年某月某地区的啤酒销售情况)。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑.
二、 确定量度
确定主题后，需要考虑分析的技术指标(例:年销售额等等)。它们一般为数据值型数据，其中有些度量值不可以汇总；些可以汇总起来，以便为分析者提供有用的信息。量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性指标(KPI)的设计和计算。
三、 确定事实数据粒度
确定量度之后，需要考虑该量度的汇总情况和不同维度下量度的聚合情况.例如在业务系统中数据最小记录到秒，而在将来分析需求中，时间只要精确到天就可以了，在ETL处理过程中，按天来汇总数据,些时数据仓库中量度的粒度就是”天”。如果不能确认将来的分析需求中是否要精确的秒，那么，我们要遵循”最小粒度原则”,在数据仓库中的事实表中保留每一秒的数据，从而在后续建立多维分析模型(CUBE)的时候,会对数据提前进行汇总，保障产生分析结果的效率。
四、 确定维度
维度是分析的各个角度.例:我们希望按照时间，或者按照地区，或者按照产品进行分析。那么这里的时间，地区，产品就是相应的维度。基于不同的维度，可以看到各个量度汇总的情况，也可以基于所有的维度进行交叉分析。
维度的层次(Hierarchy)和级别(Level)。例:在时间维度上，按照”度-季度-月”形成了一个层次，其中”年” ,”季度” ,”月”成为了这个层次的3个级别。我们可以将“产品大类-产品子类-产品”划为一个层次，其中包含“产品大类”、“产品子类”、“产品”三个级别。
我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度；我们也可以使用三张表，分别保存产品大类，产品子类，产品三部分数据,比如产品维度。
建立维度表时要充分使用代理键.代理键是数据值型的ID号码(每张表的第一个字段)，它唯一标识了第一维度成员。在聚合时，数值型字段的匹配和比较，join效率高。同时代理键在缓慢变化维中，起到了对新数据与历史数据的标识作用。
五、 创建事实表
在确定好事实数据和维度后，将考虑加载事实表。业务系统的的一笔笔生产，交易记录就是将要建立的事实表的原始数据.
我们的做法是将原始表与维度表进行关联，生成事实表。关联时有为空的数据时(数据源脏)，需要使用外连接，连接后将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各度量数据，不应该存在描述性信息。
事实表中的记录条数据都比较多，要为其设置复合主键各蛇引，以实现数据的完整性和基于数据仓库的查询性能优化。
元数据:
描述数据及其环境的数据。两方面用途:
首先,元数据能提供基于用户的信息,如记录数据项的业务描述信息的元数据能帮助用户使用数据。
其次,元数据能支持系统对数据的管理和维护,如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。
元数据机制主要支持以下五类系统管理功能:
（１）描述哪些数据在数据仓库中；
（２）定义要进入数据仓库中的数据和从数据仓库中产生的数据；
（３）记录根据业务事件发生而随之进行的数据抽取工作时间安排；
（４）记录并检测系统数据一致性的要求和执行情况；
（５）衡量数据质量。
1. 维度(Dimension)
维度是用来反映业务的一类属性，这类属性的集合构成一个维度。如时间、地理位置或产品，
2.粒度
粒度将直接决定所构建仓库系统能够提供决策支持的细节级别。粒度越高表示仓库中的数据较粗，反之，较细。粒度是与具体指标相关的，具体表现在描述此指标的某些可分层次维的维值上。例如，时间维度，时间可以分成年、季、月、周、日等。
3. 指标(Measure)
指标也称关键性能指标、事实或关键事务指标，是沿维度衡量商务信息的工具。每一个指标代表了业务对象所固有的一个可供分析的属性。指标是典型的数量、容量或将通过同标准的比较查明的款项。这些数据点可用于商务性能的定量的比较。
4. 指标组(Relation Measures)
实际上每一组用于分析的业务对象会有若干相互关联的指标，如营业额、纳税额。这些指标之间存在计算关系，往往是作为一个整体用于分析的，这个整体称之为指标组。
5. 元数据(Metadata)
关于数据的数据。元数据用于描述数据仓库中的数据的结构、内容和数据源。
6. 元数据库(Metadata Repository)
一种提供数据详细情况的词典。这些详细的信息包括数据源的目录和它们相关的标准。该数据目录描述的是数据捕捉和数据访问两种环境中可用的数据。该目录还应说明数据最后一次更新的时间和计划将要更新的时间—最起码，要说明数据维护的调度。数据目录还应说明数据的物理属性；也就是说，数据是如何存储的。数据目录帮助数据用户弄清楚“从哪里”可获得“什么样”的数据。
7. 中央数据库(Center Database)
数据仓库中用于存储原始数据的存储介质。此处的原始数据指从业务系统中采集后经过清洗、转换的数据。
8. 指标数据库(Indicator Databases)
数据仓库中用于存放指标数据的存储介质。指标数据库根据数据仓库系统的使用对象划分，通常分成多个。
9. 数据清洗(Data Cleaning)
对数据仓库系统无用的或者不符合数据格式规范的数据称之为脏数据。清洗的过程就是清除脏数据的过程。
10. 数据采集(Data Collection)
数据仓库系统中后端处理的一部分。数据采集过程是指从业务系统中收集与数据仓库各指标有关的数据。
11．数据转换(Data Transformation)
解释业务数据并修改其内容，使之符合数据仓库数据格式规范，并放入数据仓库的数据存储介质中。数据转换包括数据存储格式的转换以及数据表示符的转换（如产品代码到产品名称的转换）。
12.联机分析处理(OLAP Online Analytical Processing )
在线事务处理（on-line transaction processing，简称OLTP）能够提供一些记录级查询功能，现在分析人员要求从各个角度去观察一些统计指标，会对多张表千万条中的数据进行分析和信息综合。这是操作型应用力不从心的。1993年，关系数据库之父E.F.Codd将这类技术定义为在线分析处理（on-line analytical processing，简称OLAP）。
OLAP是一种多维分析技术，用来满足决策用户在大量的业务数据中，从多角度探索业务活动的规律性、市场的运作趋势的分析需求，并辅助他们进行战略发展决策的制定。按照数据的存储方式分OLAP又分为ROLAP、MOLAP和HOLAP。
在客户信息数据仓库CCDW的数据环境下，OLAP提供上钻、下钻、切片、旋转等在线分析机制。完成的功能包括多角度实时查询、简单的数据分析，并辅之于各种图形展示分析结果。
13. 星形图（Star-Schema）
是数据仓库应用程序的最佳设计模式。它的命名是因其在物理上表现为中心实体，典型内容包括指标数据、辐射数据，通常是有助于浏览和聚集指标数据的维度。星形图模型得到的结果常常是查询式数据结构，能够为快速响应用户的查询要求提供最优的数据结构。星形图还常常产生一种包含维度数据和指标数据的两层模型。
14.雪花图（Snowflake-Schema）
指一种扩展的星形图。星形图通常生成一个两层结构，即只有维度和指标，雪花图生成了附加层。实际数据仓库系统建设过程中，通常只扩展三层：维度（维度实体）、指标（指标实体）和相关的描述数据（类目细节实体）超过三层的雪花图模型在数据仓库系统中应该避免。因为它们开始像更倾向于支持OLTP 应用程序的规格化结构，而不是为数据仓库和OLAP应用程序而优化的非格式化结构。