数据仓库建设思路

数据仓库建设思路

 

数据仓库建设思路

       数据仓库的建设应以数据为驱动，由于数据仓库并不涉及事务处理，而且报表分析也仅占有一小部分，数据仓库的应用程序本质是分析，尤其是针对业务智能的分析。

Online Transaction Processing (OLTP)环境中用户量非常大，但使用到的数据却比较少，在Online Analytical Processing (OLAP)环境中正好相反，少量的用户在使用大量的数据，数据仓库的工作是优化这种不同。

在分析数据源方面，会有大量的旧数据必须进行一致性处理，所以分析数据源及转换是整个数据仓库实现过程中最艰难的一部分，并且这也是整个项目中最重要的一环，可以占到整个项目周期和预算的四分之三，所以数据仓库主要工作是数据分析和转换。

一般情况下，很难在第一次就实现符合要求的最终产品，而在将要分析的数据结构上同样存在这种问题，实现过程会有很多变数，需要不断的改进行，通常我们希望改动的次数降到最低，在一个数据仓库实现过程中，本质是要分析过程毫无差错，这需要DBA的参与。

定义数据仓库是一个探索的过程，而且这个过程要反复进行，很多用户按照自己的理解来处理业务流程，因此这些用户是连接数据和业务处理过程间的桥梁，这个过程需要他们讨论、思考并给出建设性的意见，最后，一定要随时留意用户得出的结论。

数据仓库的建设流程首先是对操作型数据环境进行分析梳理，确定相关主题域。 对相关主题域进行数据仓库建模，建立轻度综合的数据仓库基础数据环境，再基于轻度综合的基础数据环境按部门划分建立高度综合的数据集市；最后基于数据集市建立PC和工作站级的分析数据。 

税务系统相关主题域一般有：纳税人、发票、税票、税务人员、鉴定表、申报表、滞纳金、报表、稽查文书等；数据集市可分为公共数据集市和特定部门数据集市，部门数据集市应基于在公共数据集市建立以提高数据复用度。

数据仓库体系结构

操作型数据与数据仓库本质区别

• n 面向主题

       数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合。

       数据仓库的面向主题性，如下图：

 

传统的操作型系统是围绕企业的应用进行组织的。对于税务系统，应用问题可能是登记受理，纳税鉴定，申报征收，稽查法制。 而主要的主题范围可能是纳税人、发票、票证、税务人员等。

• n  集成

       数据仓库的第二个显著特点是集成的。在数据仓库的所有特性之中，这是最重要的，下图说明了数据由面向应用的操作型环境向数据仓库传达时所进行的集成。应用的设计人员历经多年制定出来的不同的设计决策有许多不同的表达方式，在编码、命名习惯、实际属性、度量等方面不一致，当数据进入数据仓库时，要采用某种方法来消除应用问题中的许多不致性。如下图所示：

操作型数据正规地是一次访问和处理一个记录。可以对操作型环境中的数据进行更新。但数据仓库中的数据显现出非常不同的特性。数据仓库的数据通常是一起载入与访问的，但在数据仓库环境中并不进行一般意义上的数据更新。

• n  非易失性

       数据仓库的第三个重要特性是数据仓库是非易失的。如下图所示：

 

• n  随时间的变化性

       数据仓库的最后一个特性是随时间的变化性。如下图所未，数据仓库中的数据随时间变化的特性表现在以下几个方面：

       数据仓库的数据时间期限要远远长于操作型系统中的数据时间期限。操作型系统的时间期限一般是60~90天，而数据仓库中数据的时间期限通常是5~10年。

       操作型数据库含有“当前值”的数据，这些数据的准确性在访问时是有效的，同样当前值的数据能被更新。而数据仓库中的数据仅仅是一系列某一时刻生成的复杂的快照。

       操作型数据的键码结构可能包含出可能不包含时间元素，如年、月、日等。 而数据仓库的键码结构总是包含某时间元素。

体系结构层次

说明:

体系结构层次的例子

• 操作型:

当前粒度：如纳税人基本信息（TSM01_TPAYER、TSM02_BASE、TSM02_OTHER、TSM02_QUERY、TSM02_SFXY）等数据表及相关代码表。

• ODS:

同操作型

• 原子/数据仓库:

轻度综合级：纳税人基本信息仅有（NSR_NSRJBXX）一张实体表及其相关维表。

• 部门/数据集市:

高度综合级： 建立在原子/数据仓库基础之上的汇总数据，在建立部门集市前应先建立通用数据集市，再根据具体需求建立部门集市

Ø  通用数据集市

集市A0001：【主管税务机关、税务所、时间、行业大类、行业小类、纳税人状态，纳税人户数】

集市B0001：【主管税务机关、税务所、时间、税种，税款，税项，税目，入库金额】

Ø  财产税数据某集市：

分析： 财产税包括税种有：房产税、城镇土地使用税、车船税、契税、耕地占用税等，可以在“集市B0001”基础上构建，只需取税种=（房产税、城镇土地使用税、车船税、契税、耕地占用税）的即可。

Ø  行为税数据某集市：

分析：行为税包括税种有：城市维护建设税、印花税、固定资产投资方向调节税、土地增值税、屠宰税等，也可以在“集市B0001”基础上构建，只需取税种=（城市维护建设税、印花税、固定资产投资方向调节税、土地增值税、屠宰税）的即可，提高数据复用度。

• 个体级:

       高度综合级：暂时的、特定的数据，如: 分析各行业的纳税户数变化趋势 限定条件为年入库金额>=500万。 为了达到数据最大复用度， 应该在“集市A0001”和“集市B0001”的基础上构建数据，相关数据应包含:  【主管税务机关、税务所、行业大类、时间、入库金额最小值、入库金额最大值、户数】，并添加“集市B0001”按年度汇总入库金额>=500万的纳税人， 集市A0001的主管税务机关、税务所、时间与集市B0001的主管税务机关、税务所、时间关联即可快速获取相关数据。

数据仓库用户

       数据仓库的用户称为DSS分析员。他首先是个业务人员，其次才是技术人员，DSS分析员的主要工作是定义和发现在企业决策中使用的信息。

       了解DSS分析员的想法及他们对使用数据仓库的理解很重要。 DSS分析员有一种想法即“给我看一下我说我想要的东西，然后我告诉你我真正想要什么”，换句话说， DSS分析员在发现模式下工作。 直到看到报表或屏幕上数据时，他们才开始探讨是否有必要进行DSS分析。

       DSS分析员的态度之所以重要的理由如下

•          他是合理的

•          他是广泛的

•          他对数据仓库的开发方法和系统怎样使用被开发的数据仓库有深远的影响

传统的系统开发生命周期(SDLC)不适用于DSS分析领域。SDLC假设在设计之初需求是已知的。 但是， 在DSS分析员眼中， 在DSS开发生命周期的最后才发现真正的需求。 与数据仓库相关联的是一种完全不同的开发生命周期。

数据仓库软件生命周期

       操作型数据通常是非集成的，而数据仓库数据必须是集成的。在操作层与数据仓库层的数据和处理存在几个重要区别， 操作层和数据仓库层之间内在的区别关系到系统开发生命周期，如下图所示。

数据仓库环境下的系统开发生命周期与传统的SDLC几乎完全相反

       上图显示传统的系统开发生命周期支持操作型环境，数据仓库运行于一个与之完全不同的生命周期下，有时称为CLDS(与SDLC顺序相反)。 传统的SDLC是需求驱动的，为建立系统，你必须首先理解需求，然后进入到设计和开发阶段。而CLDS几乎是刚好相反。CLDS由数据驱动，一旦数据到手就集成数据， 然后，如果数据有偏差，就检验看看数据存在什么偏差。再针对数据写程序，分析程序执行结果，最后，系统需求才得到理解。

       CLDS是典型的数据驱动开发生命周期， 而SDLC是典型的需求驱动开发生命周期。 试图采用不适当的开发工具和技术只会导致浪费和混乱。 比如，CASE领域是由需求驱动分析所支配的，试图将CASE工具和技术用于数据仓库领域是不明智的，反之亦然。

体系结构设计环境的层次

       在体系结构设计环境中有四个层次，分别是操作层、ODS层、轻度综合层的原子或数据仓库层、高度综合层的部门层、个体层；

数据操作层只保存原始数据并且服务于高性能事务处理领域。

ODS层主要体现在将不同类型，不同性质的数据集中以减轻交易系统压力和统数据接口为下一步建立数据仓库做铺垫，比如某企业或机关单位有多个数据库包含有SQLSERVER，DB2，ORACLE和文件系统，建立ODS层将所有数据集中到ODS数据库中，屏蔽原始数据库之间的差异，对数据仓库层提供统一的数据接口。

数据仓库层存储不更新的原始数据，在数据仓库四个层次中占有相当关键的位置，主要特点是面向主题、集成的数据结构，包含历史数据，数据随时间变化，大部分粒度、一些汇总。轻度汇总层最重要的特点是面向主题和集成， 一般而言一个主题对应一个实体表，所以轻度汇总层实体表数量不多， 这个层次中主要体现出数据建立模的重要性。

部门层是在数据仓库层的基础上建立的面向部门级的数据集市，此层次领域狭隘，是典型的部门型【行为税、财产税、所得税等集市】，所以数据仓库中会有很多高度综合级的部门级数据集市，分别对应不同的部门和处室的决策分析需要。

个体级是在高度综合层的基础上建立的面向个人PC和工作站的暂时的、特定的非重复的启发式分析操作，一般由DSS操作员完成大多数启发式的分析操作，数据来源由DSS操作员自己决定，有时可能会跨多个部门集进行综合分析，以发现潜在的需求和知识。

数据仓库和数据模型

       操作型系统与数据仓库之间的数据模型是有差别的，企业模型用到数据仓库中要做相当多的改动。首先要除去纯粹用于操作型环境的数据。然后，在企业模型的键码结构中增加时间元素。最后，操作型系统中的数据关系在数据仓库中转变为“人工关系”。人工关系（Artifacts）是3NF数据仓库建模中一种非常关键的实现方式，它的主要是对历史信息进行保存。和Kimball的缓慢变化维策略保存历史信息很相似，但也有些不同。以纳税人和专管员为例，通常对于某一个时间点，一个纳税人只有一个专管员，纳税人和专管员是一对一关系，但是在数据仓库中，考虑到纳税人的专管员可能会改变，所以在数据仓库建模时需要保存纳税人和专管员这种特殊的一对多关系。而这种特殊的一对多的对应关系的保存称为人工关系（Artifacts）。建立人工关系通常有两种方式，第一种是快照方式，即在固定的时间间隔将这种人工关系保存入数据仓库中。第二种建立人工关系的方式是将变化时的历史记录保存下来。

 

数据模型的反复开发

数据仓库设计者的工作是要物理地组织好数据，以便返回最大数量的记录，这些数据是执行物理I/O时产生的；例如，程序要取5个记录，如果这些记录是在存贮器中不同的数据块上，那么就需要五次I/O操作，但是如果程序员能够预测到这些数据将成组的访问，将其并列地放在同一个物理块中，那么这就只需要一次I/O操作，这样使用程序的运行效率更高。

       关于数据仓库中数据存放的问题还有一个缓和因素：数据仓库里的数据一般不更新。这样设计可以自由地采用物理设计技术，这些技术在数据需要经常更新的情况下很可能就不能接受。

       在所有情况下数据仓库最好是反复建造的。下面就是为什么说反复建造是很重要的理由：

•       业界成功的经验建议这样做

•        最终用户在第一遍完成以前不能明确地提出需求

•         只有实际结果切实而且明确时，管理部门才能做出充分的承诺

•          需要很快看到可视化结果

为了解释数据模型在反复开发期间所起的作用是，每一遍开发中都起着路标的作用。当第二遍开发继续接着进行时，开发人员相信，他将汇集第一遍开发的成果，因为所有开发都是数据模型驱动的，后续的开发都是建立在前一遍开发的基础上，由于他们都是基于同一个数据模型，各遍开发工作的成果将产生一个内聚的、高度和谐的整体。如果开发是在不同的数据模型之上进行时，就会产生很多重复的工作和很多不连贯的开发和不协调的结果。

星型连接

       数据模型作为一种数据仓库的设计基础，在实际应用中还存在许多缺点。如下图所示：

       上图所示的数据模型中四个相互关联的简单实体。如果数据库设计只需要考虑数据模型的话，可以推断所有的实体都是平等关系。换言之，从数据模型的设计角度来看，所有的实体之间的关系是对等的。代表税务机关，专管员，行业大类的实体被稀梳地载入，而代表纳税人的实体则大量地载入。将会有大量的数据载入代表纳税人的实体表中，而其他实体表中载入的数据刚相对较少。因此需要一种不同的设计处理方式。

       用来管理数据仓库中载入某个实体的大量数据的设计结构被称为“星型连接”。如下图给出星型连接的一个简单例子。

          

       可以有任意多个外键与维表相关。当有必要检查外键数据与事实表中的数据时，就创建一个外键。创建和使用星型连接的一个有趣的方面是，文本数据与数值数据是分离开的，文本数据常出现在维表中，数据常出现在事实表中，这种划分似乎在所有情况都会发生。

          

       创建和使用星型连接的好处都可以为决策支持系统的处理优化数据。通过数据预连接和建立有选择的数据冗余，设计者为访问和分析过程大大简化了数据，这正是数据仓库所需要的。应该注意，如果不是在决策支持系统数据仓库环境中使用星型连接，则会有很多缺点。在决策支持系统数据仓库环境以外，常有数据更新，而且数据关系的管理要在秒的一级上进行。在这种情况下星型连接在创建和维护上就是很麻烦的数据结构。但是由于数据仓库是一个装载—访问环境，它包括很多历史数据，且有大量的数据要管理，因此，星型连接的数据结构是十分理想的。

粒度划分

粒度分析

       数据仓库开发者需要解决的最重要的单一设计问题是数据仓库中的粒度确定。当数据仓库的粒度合理确定后，设计和实现的其他问题就会非常容易解决，相反如果没有合理地确定粒度的话，就会影响其他每个方面。我们在这里集中讨论高粒度级别上管理大量数据和存储数据。

       确定合适的粒度级的起点，是粗略估算数据仓库中将来的数据行数和所需DADS(直接存取存储设备)数。毫无疑问，即使在最好的情况下我们也只能做一下估计。但在建立数据仓库之初，所需的只是一个数据级上的估计。

       空间估计法： 首先确定数据仓库中将要创建的所有表，然后，估计每张表中的行的大小，可以估计一个下界和一个上界也可以。接下来，估计一年内表中最少行数和最多行数。

计算公式为

       一年总的最大空间=最大行大小（按字节）* 一年内最大行数

       一年总的最小空间=最小行大小（按字节）* 一年内最小行数

    再对所有已知表重复第以上步骤

一旦估计完一年内数据仓库中数据单位的数量（用以上推测方法），再估算出相关索引数据所占用空间，即是最终数据量。

选择单一或双重粒度

       根据数据仓库环境中具有的总的行数的大小，设计和开发必须采取不同的方法。对于以上粒度分析结果决定粒度的选择是单一粒度还是双重粒度

      

粒度的级别

       完成了一些简单分析之后，下一步就是要精确的确定粒度的级别。开始时需要一些常识和直觉，在很低的细节级上建立轻度汇总的数据级是没有意义的，因为需要太多的资料来处理数据。而在太高的细节级上建立轻度汇总的数据级，刚意味着许多分析必须在真实档案级上进行。因此确定轻度汇总的粒度级的第一件事是进行有根据的猜测。猜测也只是一个开端，还需要一定数据的反复分析来改进这个猜测，对于轻度汇总的数据为确定合适的粒度级别，唯一可行的方法是将数据拿到最终用户的面前，只有当最终用户实际看到数据之后，才能作出确定的回答。经验表明：在第一次的设计周期中，如果50%的工作是正确的，那么整个设计就是成功的。

•      用很小而很快的步伐建立数据仓库的很小的子集并认真听取用户的反馈意见，随时准备做快速的调整

•      如果可以使用原型工具则应用原型法

•     看看别人是怎样确定他们的粒度级别，学习一下他们的经验

•    找一个有经验的用户协同你工作

•    看看机构现在已经有了什么

•    用模拟的输出进行JAD会议

有一点很重要，在典型的需求系统的开发中，在还不清楚大部分需求之前就忙于进行是不明智的。但在数据仓库的建造中，如果已知了至少一半的需求后，还不开始同样也是不明智的，换句话说，在建造数据仓库中，如果开发者想等着大多数需求明了后才开始工作，那么这个仓库是永远建不起来的，尽快启动与DSS分析员的反馈循环是非常重要的。