数据仓库模型建设规范10

数据仓库模型建设规范

1.概述

数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求、分析、设计、测试等通常的软件生命周期之外，它还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的模型设计异常重要,这也是关系到数据仓库项目成败的关键。

物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基—层层建筑—封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免地要考虑数据库的物理设计。

数据仓库建模的设计目标是模型的稳定性、自适应性和可扩展性。为了做到这一点，必须坚持建模的相对独立性、业界先进性原则。

2.数聚模型架构

在数聚项目实施过程，我们一般将数据仓库系统的数据划分为如下图所示几个层次。

2.1.数据架构图

2.2.架构工作方法规范

2.3.准备层L0

2.3.1.主要数据结构

临时表：从数据源抽取，直接落地到临时表。临时表总是保存这次抽取的数据，不保留历史数据。也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果

是增量抽取的话，就是自从上次修改后的数据。

接口表：从临时表，经过清洗、转换到达接口表。接口表保存历史数据，也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话。

接口表里面也是源系统整个表的数据。

转换表：为了进行清洗和转换建立的中间辅助表。

2.3.2.命名规范

临时表：L0_TMP_源系统_具体业务或 L0_TMP_业务主题_具体业务（对单一源）举例：L0_TMP_POS_SALESORDER

接口表：L0_DCI_业务主题_具体业务表

举例：L0_DCI_SALES_SALESORDER

转换表：L0_MAP_具体业务表

举例：L0_MAP_SALES

2.3.3.开发工作

●开发数据抽取接口，落地TMP区

●开发数据清洗转换程序，落地DCI区，多源系统进行合并

●开发数据装载程序，装载到L1层

2.4.原子层L1

2.4.1.主要数据结构

维度表：整个数据仓库一致的维度

代码表：维度属性，非维度代码等。

原子事实表：根据业务主题，形成原子事实表

汇总事实表：根据分析主题，业务主题形成合并或汇总的事实表。

2.4.2.命名规范

维度表：DW_DIM_维度。

举例：组织维 DW_DIM_ORG 日期维 DW_DIM_DATE.

代码表：DW_CODE_代码。

举例：性别 DW_CODE_GENDER

原子事实表：L1_DW_FACT_分析主题_具体分析

汇总事实表：L1_DM_FACT_分析主题_具体分析

2.4.

3.开发工作

●维护聚集。

●衍生计算，二次指标计算。

2.5.应用层L2

2.5.1.主要数据结构

宽表：根据需求，从L1层抽取成宽表，表现形式为固定报表，仪表盘等等。

立方体：根据分析主题，从L1生成OLAP立方体。

视图：根据需要，从L1，L0层产生L2层的视图。

前端应用，不仅仅可以利用L2层的数据结构，还可以利用L1层的数据结构。对于源系统，还可以利用L0层的DCI区数据，可以做详单和明细查询。

2.5.2.命名规范

宽表： L2_FACT_【应用主题】_【分析主题】_应用。

举例：L2_FACT_FIN_ZCFZB (财务->资产负债表)

立方体：根据分析主题，从L1生成OLAP立方体。

视图：根据需要，从L1，L0层产生L2层的视图。如明细单。

举例：L2_VIEW_原L1层表。

2.5.

3.开发工作

数据从L1层经过计算，汇总，根据前端分析需求，形成可以有效支撑前端应用查询的结构。

3.建模方法

要成功地建立一个数据仓库，必须有一个合理的数据模型。数据仓库建模在业务需求分析之后开始，是数据仓库构造的正式开始。在创建数据仓库的数据模型时应考虑: 满足不同层次、用户的需求;兼顾查询效率与数据粒度的需求;支持用户需求变化;避免业务运营系统性能影响;提供可扩展性。数据模型的可扩展性决定了数据仓库对新的需求的适应能力，建模既要考虑眼前的信息需求，也要考虑未来的需求。

目前两类主流的数据仓库模型分别是由Inmon提出的企业级数据仓库模型和由Kimball提出的多维模型。Inmon提出的企业级数据仓库模型采用第三范式（3NF），先建立企业级数据仓库，再在其上开发具体的应用。企业级数据仓库固然是我们所追求的目标，但在缺乏足够的技术力量和数据仓库建设经验的情况下，按照这种模型设计的系统建设过程长，周期长，难度大，风险大，容易失败。这种模型的优点是信息全面、系统灵活。由于采用了第三范式，数据存储冗余度低、数据组织结构性好、反映的业务主题能力强以及具有较好的业务扩展性等，但同时会存在大量的数据表，表之间的联系比较多，也比较复杂，跨表操作多，查询效率较低，对数据仓库系统的硬件性能要求高等问题。另一方面，数据模式复杂，不容易理解，对于一般计算机用户来说，增加了理解数据表的困难。

Kimball提出的多维模型降低了范式化，以分析主题为基本框架来组织数据。以维模型开发分析主题，这样能够快速实施，迅速获得投资回报，在取得实际效果的基础上，再逐渐增加应用主题，循序渐进，积累经验，逐步建成企业级数据仓库。这也可以说是采用总线型结构先建立数据集市，使所有的数据集市具有统一的维定义和一致的业务事实，这种方法融合了自下而上和自上而下两种设计方法的思想。这种模型的优点是查询速度快，做报表也快;缺点是由于存在大量的预处理，其建模过程相对来说就比较慢。

当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主码由所有维表的主码组成，所以这种维的变动将是非常复杂、非常耗时的。而且信息不够全面、系统欠灵活、数据冗余多。

本规范我们主要针对维度建模的方法来阐述规范。

3.1.维度建模

多维数据建模以直观的方式组织数据，并支持高性能的数据访问。每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。

位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。每个指标实体代表一系列相关事实，完成一项指定的功能。位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。每个维表有自己的属性，维表和事实表通过关键字相关联。

使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。

3.2.建模步骤

第一步：选取建模的业务过程

设计过程的第一步是确定要建模的业务过程或者度量事件。业务过程是在业务需求收集过程明确下来。

在很多的生产活动中，存在着很多价值链，这些价值链就是有一系列的业务过程来组成的。比如在供应链管理中。存在着下面的业务过程：

原材料购买

原材料交货

原材料库存

材料账单

生产制造

将产品运到仓库

制成品库存

客户订单

为客户送货

货品计价

付款

退货

第二步：定义模型的粒度

业务过程被确定下来后，就建模师就必须声明事实表的粒度。清楚地定义事实表的行到底代表什么在提出业务过程维度模型的过程至关重要。如果没有在事实表的粒度上达成一致，那么设计过程就不可能成功地向前推进。

第三步：选定维度

一旦事实表的粒度已经稳固地确定下来，对维的选择就相当简单了。也正是在此时，就可以开始考虑外键的问题了。一般来说，粒度本身就能够确定一个基本或者最小的维度集合，设计过程就是在此基础上添加其他维。这些维在已经声明的事实表粒度都有一个唯一对应的值。

第四步：确定事实

四步设计过程的最后一步是仔细选择适用于业务过程的事实和指标。事实可以从度量事件中采用物理手段捕捉，或者也可以从这些度量中导出。对于事实表粒度来说，每个事实都是必须设计存在的，不要将那些明确声明的粒度不相匹配的其他时间段的事实或者其他细节层次的事实混杂进来。

4.维度表设计

维度表包含内容：

1)代理键：整型，不可重复，唯一标识每一条记录，不包含任何商业信息。（必选）

2)代理键有效开始时间和结束时间。（必选）

3)当前有效标志。（必选）

4)主键：传统意义的业务键，包含相应的商业信息，如员工编号。（必选）

5)名称：数据分析时显示的内容，如员工名称等；（必选）

6)排序键：自定义序列。（可选）

7)自定义汇总：利用自定义表达式进行特定的数据运算。可选）

8)父键：父子维度中用来标识主键的上级。（可选）

9)一元运算符：在父子维度中用来定义上下级的汇总关系。（可选）(详细)

10)属性：属性包含有关维度的信息。例如，Customer 维度可以包含 Name、Phone

Number、Gender、City、State 等属性。属性通过属性层次结构显示出来。维度中的属性层次结构同时包含可选的 (All) 级别和该属性的非重复成员。例如，Customer 维度可以包含具有两个级别的 Name 属性层次结构：(All) 级别以及为每个姓名包含一个成员的级别。父子层次结构的处理方式有所不同。属性不一定要具有属性层次结构。如果未创建属性层次结构，多维数据集的空间将与属性无关。例如，通常不会为 Phone Number 属性创建属性层次结构，因为通常不会按电话号码导航维度。如果没有为属性创建属性层次结构，则该属性可用作成员属性，但不能用作用户层次结构中的级别。属性可以通过前端展示软件进行展现。（可选）

11)属性层次结构：属性层次结构完全定义多维数据集的空间。多维数据集是由多维数

据集的属性层次结构的交集产生的多维空间。（可选）

4.1.时间维度

时间维度是必不可少的一个维度，可以参考如下的模板：

4.2.层级维度

层级维度也是我们模型设计最常遇见的维度，比如组织结构，区域，产品树，行业结构等等。在设计时，可以采用如下模板：

针对数据存储时，采用自关联的结构：

针对数据展现时，将自关联的结构展开，以列存储层次：根据需要可以把组织层级具体化。

4.3.缓慢变化维

缓慢变化维定义

数据会发生缓慢变化的维度就叫”缓慢变化维”。

举个例子就清楚了：

在一个零售业数据仓库中，事实表保存着各销售人员的销售记录，某天一个销售人员从北京分公司调到上海分公司了，那么如何来保存这个变化呢？也就是说销售人员维度要怎么恰当的处理这一变化。先来回答一个问题，为什么要处理，或保存这一变化？如果我们要统计北京地区或上海地区的总销售情况的时候，这个销售人员的销售记录应该算在北京还是算在上海？当然是调离前的算在北京，调离后的算在上海,但是如标记这个销售人员所属区域？这里就需要处理一下这个维度的数据，即我们缓慢变化维需要做的事情。

处理缓慢变化维一般按不同情况有以下几种解决方案：

4.3.1.新数据覆盖旧数据

此方法必须有前提条件，即你不关心这个数剧的变化。例如，某个销售人员的英文名改了，如果你不关心员工的英文名有什么变化则可直接覆盖(修改)数据仓库中的数据。

4.3.2.保存多条记录，并添加字段加以区分

这种情况下直接新添一条记录，同时保留原有记录，并用单独的专用的字段保存区别。如：

(以下表格中Supplier_State表示上面例子中所属区域，为描述清晰，不用代理键表示)

以上两种是添加数据版本信息或是否可用来标识新旧数据。

下面一种则是添加记录的生效日期和失效日期来标识新旧数据：

空的End_Date表示当前版本数据，或者你也可一用一个默认的大时间 (如: 12/31/9999)来代替空值, 这样数据还能被索引识别到.

4.3.3.不同字段保存不同值

这种方法用不同的字段保存变化痕迹.但是这种方法不能象第二种方法一样保存所有变化记录,它只能保存两次变化记录.适用于变化不超过两次的维度。

4.3.4.另外建表保存历史记录

即另外建一个历史表来表存变化的历史记录，而维度只保存当前数据。

这种方法仅仅记录一下变化历史痕迹，其实做起统计运算来还是不方便的。

4.3.

5.混合模式

这种模式是以上几种模式的混合体，相对而言此种方法更全面，更能应对错综复杂且易变化的用户需求，也是较为常用的。

此中方法有以下几条优点：

1.能用简单的过滤条件选出维度当前的值。

2.能较容易的关联出历史任意一时刻事实数据的值。

3.如果事实表中有一些时间字段(如：Order Date, Shipping Date, Confirmation

Date)，那么我们很容易选择哪一条维度数据进行关联分析。

其中Row_Key和Current Indicator字段是可有可无的，加上去更方便，毕竟维度表的数据都不大，多点冗余字段不占太大空间但能提高查询效率。

这种设计模式下事实表应以Supplier_key为外键，虽然这个字段不能唯一标识一条维度数据，从而形成了事实表与维表多对多的关系，因此在做事实和维度做关联时应加上时间戳字段(或Indicator字段)。

4.3.6.非常规混合模式

上面说到第五种实现方式有点弊端，那就是事实表和维表不是多对一关系，而是多对多关系，这种关系不能在建模时解决只能在报表层面，在报表运行时解决，且在BI语意层建模时需要添加时间过滤条件，比较繁琐。

下面这种解决方案可以解决此多对多关系，但是得修改一下事实表：

此方案中向维表中的当前数据版本号始终为0，即插入维度数据时先将老版本的数据的version_number改成1（递增），然后再插入当前数据，此时才能保持当前数据版本号始终为0。

事实表中插入数据时所有的维度数据版本号始终全部为0。

因此此方案完全可解决事实表和维表多对多关系问题，另外还有个优点是能保证事实表和维表的参照完整性，而且我们在用ERwin,PowerDesigner等建模工具建模时，Version_Number和Supplier_key可作为复合主键在两实体间建立链接。

5.事实表设计

事实表中一般要包含2部分：一是由主键和外键所组成的键部分，另一部分是用户希望在数据仓库中所了解的数值指标，这些指标是为每个派生出来的键而定义和计算的，称为事实或指标。由于事实是一种度量，所以事实表中的这种指标往往需要具有数值化和可加性的特征。但是在事实表中，只有那些具有完全可加性的事实才能根据所有的维度进行累加而具有意义。而事实表有一些事实表示的是某种强度，这类事实就不具有完全加法性，而是一种半加法性。例如，账目余款反映的是某个时间点的数据，它可以按照地点和商品等大多数维度进行累加，但是对于时间维度则例外，将一年中每个月的账目余款进行累加是毫无意义的，而决策者则可能需要了解所有地区和所有商品账目余款的累加值。在事实表中还有一些事实是非加法性的，即这些事实具有对事实的描述

特性，在这种情况下一般要将这些非加法性事实转移到维度表中

5.1.事务事实表

大多数基本事实表和公共事实表都是面向事务的，其粒度是每一行对应个一事务，或者一行对应事务中的一个条目。事务粒度是空间和时间的交点，一个事务粒度上的度量必须在那个时刻为真。

事务数据在其最低层次上一般都有数目巨大的维与之相关联。无论事务事件何时出现，都可以捕捉到有关事务的大量上下文，仅当活动发生时，事务事实表中才会插入一行。一旦事务事实行已经存储，一般不会再次对其进行访问。

如下面的业务过程，就非常适合用事务事实表来表示：

●采购

●下订单

●缴费

●支付

●购买

●拨打电话

5.2.快照事实表

第二种最常见的事实表类型是周期快照。使用周期快照可以得到一组描述，周期快照能够按照一个定义良好的时间周期间隔来捕捉业务过程的执行情况，并且将这些描述装载到事实表中。在预定义好的间隔（如每天、每周或者每月）上，很多描述都是关于相同细节层次的，它们连续不断地进入事实表。

如下面的业务过程，就非常适合用快照事实表来表示：

●银行账户的余额

●财务月报表

6.数据库设计规范6.1.数据库表设计规范

6.2.数据库索引设计规范

6.2.1.维度表索引设计

维度表应当有单独的一列作为主键，这样就可以在该主键上建立唯一索引。如果数据库管理系统支持位图索引（我们一般选用ORACLE），可以为哪些常用作筛选条件的维度属性每列添加一个位图索引。如果数据库管理系统部不支持位图索引，可以创建B-tree索引。

在比较小的维度表上不建议创建联合索引，但在比较大的维度表上，比如客户维度表上，经常有各种各样的查询，比如客户群细分等不涉及事实表的查询需求。可以建立联合索引。

6.2.2.事实表索引设计

事实表逻辑主键的一般是维度表主键的外键联合。所以，在每一个外键上，我们都建议建立位图索引，这样在事实表比较巨大的情况下，可以使索引变得非常小，可以大大节省磁盘空间，更重要的是，这些索引可以全部放到内存里面，从而给查询速度带来很大提高。

6.2.3.装载后分析表和索引

有些数据库引擎在每次装载过程完成之后不会对表和索引自动进行统计和重新计算，有些甚至在重建一个完整的索引之后也不会进行验算。这对任何装载和索引创建过程都是非常重要的步骤。因为查询优化器必须拥有关于表和索引大小的准确信息，以便设计出高效的查询方案。

如在oracle中，我们可以用如下语句进行表和索引的分析。

Analyze table table_name compute statistics .

7.常见表命名规范

数据仓库模型的设计

2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计 进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容 概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界 数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2，确定主要的主题域 在这一步中，要确定系统所包含的主题域，然后对每个主题域的内

数据仓库建设的几点建议.doc

北京甲骨文软件有限公司咨询经理鲁百年博士 一、国内信息化的现状 1、信息化建设的发展历史：在国内信息化建设过程中，基本上是按照当时业务系统的需求进行建设，例如：在一个企业中，财务部门为了减少工资发放的差错，提高发放的效率，先建设一个工资发放和管理程序；为了报账和核对的需求，建设一个财务管理程序；在银行首先为了业务处理的方便，将最基本的手工记帐和处理的业务建成一个系统，过一段时间，如果有新的业务推出，就再建设一个新的系统，或在原系统的基础上增加新的业务处理。这样的结果使每个系统和系统之间缺少真正的信息沟通和信息交换。 2、为何要建立数据仓库：前面我们讲过，业务系统各自为政，相互独立。当很多业务系统建立后，由于领导的要求和决策的需求，需要一些指标的分析，在相应的业务系统基础上再增加分析和相应的报表功能，这样每个系统就增加了报表和分析功能。但是，由于数据源不统一导致了对同一个指标分析的结果不相同。为了解决该问题，Bell Inman提出了数据仓库的概念，其目的是为了分析和决策的需要，将相互分离的业务系统的数据源整合在一起，可以为领导和决策层提供分析和辅助决策。 3、国内企业对数据仓库建设认识的误区： 大家对数据仓库的认识是将业务系统的数据进行数据抽取、迁移和加载（ETL），将这些数据进行整合存放在一起，统一管理，需要什么样的分析就可提供什么样的分析，这就是数据仓库。这样做的结果是花了一年到两年的时间都无法将整个企业业务系统的数据整合在一起，花钱多、见效慢、风险大。一年后领导问起数据仓库项目时，回答往往是资金不足，人力不够，再投入一些资源、或者再延长半年的时间就会见到效果，但是往往半年过后还是仅仅可以看到十几张或者几十张报表。领导不满意，项目负责人压力也很大，无法交待。这时，项目经理或者项目负责人才意识到，项目有问题，但是谁也不敢说项目有问题，因为这样显然是自己当时的决策失误。怎么办？寻找咨询公司或者一些大的厂商，答案往往是数据仓库缺乏数据模型，应该考虑数据模型。如果建设时考虑到整个企业的数据模型，就可以建设成企业级的数据仓库（EDW。什么是数据模型，就是满足整 个企业分析要求的所有数据源。结果会如何，我个人认为：这样做企业级数据仓

数据仓库物理模型设计

数据仓库物理模型设计 数据仓库的物理模型就是数据仓库逻辑模型在物理系统中的实现模式。其中包括了逻辑模型中各种实体表的具体化，例如表的数据结构类型、索引策略、数据存放位置和数据存储分配等。在进行物理模型的设计实现时，所考虑的因素有：I/O存取时间、空间利用率及维护的代价。 为确定数据仓库的物理模型，设计人员必须做这样几方面工作：首先要全面了解所选用的数据库管理系统，特别是存储结构和存取方法；其次了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求等，这些都是对时间和空间效率进行平衡和优化的重要依据；最后还需要了解外部存储设备的特征。只有这样才能在数据的存储需求与外部存储设备条件两者之间获得平衡。 1 设计存储结构 在物理设计时，常常要按数据的重要性、使用频率及对反应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以存放在低速存储设备上。另外，在设计时还要考虑数据在特定存储介质上的布局。在设计数据的布局时要注意遵循以下原则。 l 不要把经常需要连接的几张表放在同一存储设备上，这样可以利用存储设备的并行操作功能加快数据查询的速度。 l 如果几台服务器之间的连接会造成严重的网络业务量的问题，则要考虑服务器复制表格，因为不同服务器之间的数据连接会给网络带来沉重的数据传输负担。 l 考虑把整个企业共享的细节数据放在主机或其他集中式服务器上，提高这些共享数据的使用速度。 l 不要把表格和它们的索引放在同一设备上。一般可以将索引存放在高速存储设备上，而表格则存放在一般存储设备上，以加快数据的查询速度。 在对服务器进行处理时往往要进行大量的等待磁盘数据的工作，此时，可以在系统中使用RAID（Redundant Array of Inexpensive Disk，廉价冗余磁盘阵列）。 2 设计索引策略 数据仓库的数据量很大，因而需要对数据的存取路径进行仔细地设计和选择。由于数据仓库的数据一般很少更新，所以可以设计索引结构来提高数据存取效率。在数据仓库中，设计人员可以考虑对各个数据存储建立专用的索引和复杂的索引，以获取较高的存取效率，虽然建立它们需要付出一定的代价，但建立后一般不需要过多的维护。 数据仓库中的表通常要比联机事务处理系统（OLTP）中的表建立更多的索引，表中应用的最大索引数应与表格的规模成正比。数据仓库是个只读的环境，建立索引可以取得灵活性，对性能极为有利。但是表若有很多索引，那么数据加载时间就会延长，因此索引的建立需要进行综合的考虑。在建立索引时，可以按照索引使用的频率由高到低逐步添加，直到某一索引加入后，使数据加载或重组表的时间过长时，就结束索引的添加。 最初，一般都是按主关键字和大多数外部关键字建立索引，通常不要添加很多的其他索引。在表建立大量的索引后，对表进行分析等具体使用时，可能需要许多索引，这会导致表的维护时间也随之增加。如果从主关键字和外部关键字着手建立索引，并按照需要添加其他索引，就会避免首先建立大量的索引带来的后果。如果表格过大，而且需要另外增加索引，那么可以将表进行分割处理。如果一个表中所有用到的列都在索引文件中，就不必访问事实表，只要访问索引就可以达到访问数据的目的，以此来减少I/O操作。如果表太大，并且经常要对它进行长时间的扫描，那么就要考虑添加一张概括表以减少数据的扫描任务。 3 设计存储策略

建设数据仓库7个步骤

成功实施数据仓库项目的七个步骤 建立一个数据仓库并不是一个简单的任务，不应该由一个人单独完成。由于数据仓库最佳结合了业务惯例和信息系统技术，因此，一个成功的数据仓库实施需要这两方面的不断协调，以均衡其所有的需要，要求，任务和成果。我很乐意与大家分享我在规划和管理任何数据库项目时采用的方法，这些数据库包括交易数据库，数据仓库，和混合型数据库。由于我生活在关系数据库和数据仓库以及用以支撑它们的数据提取，转换和加载(ETL )过程中，所以我会集中在这些领域讨论我的方法。然而，您可以将这些方法扩展到整个栈--OLAP立方体和如报告，特征分析(ad-hoc analysis)，记分卡和仪表盘展示之类的信息传递应用。 我不是吃撑了要告诉一个真正的项目经理( PM )如何做他或她的工作，相反，我写的这些是为那些数据库管理员和开发者，他们没有好运气能与有经验的项目经理一起工作;同样也适合这样的IT专业人员，他们被突然要求：“建立一个数据仓库“，并且需要自己扮演项目经理的角色。我的讨论不会是完整的，但我希望这会给您足够的信息来让您的项目球滚起来。 如图1所示，数据仓库项目有3个轨道(tracks)：数据轨道，技术轨道和应用层轨道。当您在整理任何数据库项目计划时，我建议您以这三个轨道为模板来管理和同步您的活动。当您向技术决策者( TDMs ) ，商业决策者( BDMs ) ，和所有其他该数据仓库项目参与者讲解您的计划时，您也可以把图1当作一个高级的概要图来使用。 使用一种生命周期管理方法 我鼓励您利用您的组织可以提供的资源，比如设计，开发和部署系统和软件的技术和方法。如果贵公司对于这些工作没有采用任何正式的方法，继续前进吧，您可采用我为我自己的数据库项目开发的7D数据库生

数据仓库建设方案详细

第1章数据仓库建设 1.1数据仓库总体架构 专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据，经过一系列综合诊断分析，以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。 根据专家系统数据仓库建设目标，结合系统数据业务规，包括数据采集频率、数据采集量等相关因素，设计专家系统数据仓库架构如下： 数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的容： 数据采集：负责从各业务自系统中汇集信息数据，系统支撑Kafka、Storm、Flume

及传统的ETL采集工具。 数据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。 数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。 数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理和调度，并对外提供数据服务。 1.2数据采集 专家系统数据仓库数据采集包括两个部分容：外部数据汇集、部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层（ODS）；部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。 1.2.1外部数据汇集 专家数据仓库数据源包括列车监控与检测系统（TCMS）、车载子系统等相关子系统，数据采集的容分为实时数据采集和定时数据采集两大类，实时数据采集主要对于各项检测指标数据；非实时采集包括日检修数据等。 根据项目信息汇集要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。 本方案在数据采集架构采用Flume+Kafka+Storm的组合架构，采用Flume和ETL 工具作为Kafka的Producer，采用Storm作为Kafka的Consumer，Storm可实现对海量数据的实时处理，及时对问题指标进行预警。具体采集系统技术结构图如下:

数据仓库的数据模型

业务驱动 任何需求均来源于业务,业务决定了需求,需求分析的正确与否是关系到项目成败的关键所在,从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的. 但是数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求,分析,设计,测试等通常的软件声明周期之外;他还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的物理模型异常重要,这也是关系到数据仓库项目成败的关键. 数据仓库的结构总的来说是采用了三级数据模型的方式: 概念模型: 也就是业务模型,由企业决策者,商务领域知识专家和IT专家共同企业级地跨领域业务系统需求分析的结果. 逻辑模型：用来构建数据仓库的数据库逻辑模型。根据分析系统的实际需求决策构建数据库逻辑关系模型,定义数据库物体结构及其关系。他关联着数据仓库的逻辑模型和物理模型这两头. 物理模型：构建数据仓库的物理分布模型,主要包含数据仓库的软硬件配置,资源情况以及数据仓库模式。 如上图所示,在数据仓库项目中,物理模型设计和业务模型设计象两个轮子一样有力的支撑着数据仓库的实施,两者并行不悖,缺一不可.实际上,我有意的扩大了物理模型和业务模型的内涵和外延.在这里物理模型不仅仅是数据的存储,而且也包含了数据仓库项目实施的方法论,资源,以及软硬件选型等等;而业务模型不仅仅是主题模型的确立,也包含了企业的发展战略,行业模本等等. 一个优秀的项目必定会兼顾业务需求和行业的标准两个方面,业务需求即包括用户提出的实际需求,也要客观分析它隐含的更深层次的需求,但是往往用户的需求是不明确的,需要加以提炼甚至在商务知识专家引导下加以引导升华,和用户一起进行需求分析工作;不能满足用户的需求,项目也就失去原本的意义了. 物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基->层层建筑->封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免的要考虑到数据库的物理设计. 接下来,将详细阐述数据仓库概念模型(业务模型),逻辑模型,物理模型的意义. 概念模型设计 进行概念模型设计所要完成的工作是: 界定系统边界 确定主要的主题域及其内容

数据仓库安全模型分析

数据仓库安全模型分析 摘要：对数据仓库安全模型进行了分析，讨论了现有的数据仓库安全模型，并对数据仓库安全模型的发展方向进行了展望。关键词：数据仓库数据仓库安全安全模型 数据仓库是在以事务处理为主要任务的数据库基础上发展起来的,但是它与数据库有着根本的不同。数据仓库的主要特征是面向主题的、集成的、与时间相关的、不可修改的数据集合[1]。数据仓库是一种决策支持系统,它主要是对企业决策提供强有力的支持,因此它的安全性更加重要。因为数据仓库中数据的丢失将损害企业的决策,所以数据仓库的安全性相对于数据库来说更为重要。 近几年来,虽然对数据仓库的研究较多,但是控制对数据仓库的访问却是一个正在发展的技术领域,对数据仓库的安全控制方面的研究仍旧涉及很少。对数据仓库的安全控制和对于传统的操作型数据库的安全控制是不同的。数据仓库的控制有着更高的复杂性,原因主要在于数据仓库的建立目的与限制对数据的访问是矛盾的;数据仓库中存在着不同粒度的数据;数据仓库中的数据是以多维的方式存在的。这些因素决定了数据仓库安全的研究是一个复杂的领域。目前对于数据仓库安全性的研究还比较少,国内还处于起步阶段,但是它却有着极其重要的现实意义。本文主要是通过对几个数据仓库安全模型的研究,对数据仓库安全性目前研究的主要内容、现状和发展趋势进行了分析,并给出了一些模型的应用实例。 1 数据仓库安全模型 一个好的安全模型是数据仓库安全性的重要保障。现存的许多数据仓库在设计阶段都没有能够很好地在数据仓库的安全方面进行很好的设计,这使得在数据仓库建成之后再添加关于安全方面的设计时成本大增,而且在数据仓库建成之后再实施安全策略时也比较困难。因此在设计阶段就设计好数据仓库的安全模型对于构建一个安全的数据仓库有着极其重要的意义。本文主要分析了四种关于数据仓库和OLAP的安全模型。 1.1 基于元数据的数据仓库安全模型设计 元数据是描述数据仓库内数据的结构和建立方法的数据。元数据是数据仓库中很重要的一部分,它将会影响数据仓库中所有的层次,常被开发者用来管理控制和开发数据仓库。元数据也是用户访问数据仓库的一部分,它常被用来控制访问控制和分析数据。 通过对元数据的控制来加强数据仓库的安全性,这种情况下与安全主题和客体相关的访问规则被以元数据的形式存储。当一个用户访问数据仓库中的数据时,安全查询机制层将会查询这个访问是否被允许。为了保证查询的正确进行,可通过分析“安全元数据”来分析相应的访问许可机制。 N.Katic于1998年提出一个基于元数据的安全模型[2]。这是通过“安全管理者”的方式来实现的。通过它可以管理、定义、描述用户和用户群体。此外还设置了一个安全查询管理层(SQML),它的作用是通过检查是否允许一个任务的执行来过滤用户的查询。图1描述了这个安全模型。 此模型的主要作用是如果用户企图查询他没有访问权限的数据,则由“安全管理者”和“信息服务器”可以把用户想查询而又没有查询权限的那部分数据过滤掉,而只把他可以访问的那些数据返回给他。这种操作对于用户来说是透明的,用户并不知道还有些数据他没有访问到。数据仓库的信息对于用户来说好像是提供了他所需要的所有数据。这是一个很重要的安全策略,使用户不知道自己被禁止了部分数据,因而他不会去试图访问他原本看不到的数据。这样也极大地增强了数据仓库中数据的安全性。

数据仓库多维数据模型的设计

1、数据仓库基本概念 1.1、主题（Subject） 主题就是指我们所要分析的具体方面。例如：某年某月某地区某机型某款App的安装情况。主题有两个元素：一是各个分析角度（维度），如时间位置；二是要分析的具体量度，该量度一般通过数值体现，如App安装量。 1.2、维（Dimension） 维是用于从不同角度描述事物特征的，一般维都会有多层（Level：级别），每个Level 都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。 1.3、分层（Hierarchy） OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以我们一般会在维的基础上再次进行分层，维、分层、层级的关系如下图：

每一级之间可能是附属关系（如市属于省、省属于国家），也可能是顺序关系（如天周年），如下图所示： 1.4、量度 量度就是我们要分析的具体的技术指标，诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。 1.5、粒度 数据的细分层度，例如按天分按小时分。 1.6、事实表和维表 事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发

生的事情。事实表中存储数字型ID以及度量信息。 维表则是对事实表中事件的要素的描述信息，就是你观察该事务的角度，是从哪个角度去观察这个内容的。 事实表和维表通过ID相关联，如图所示： 1.7、星形/雪花形/事实星座 这三者就是数据仓库多维数据模型建模的模式 上图所示就是一个标准的星形模型。 雪花形就是在维度下面又细分出维度，这样切分是为了使表结构更加规范化。雪花模式可以减少冗余，但是减少的那点空间和事实表的容量相比实在是微不足道，而且多个表联结操作会降低性能，所以一般不用雪花模式设计数据仓库。 事实星座模式就是星形模式的集合，包含星形模式，也就包含多个事实表。

数据仓库建设方案

1.数据仓库概述 经过多年IT的建设，信息对于XXX的日常管理已经日益重要，并逐渐成为重要的信息资产，信息资产的管理已经成为日常管理中一个非常重要的环节。如何管理和利用好XXX内部纷繁的数据也越来越成为信息管理的一项重要工作。 在过去相当一段时间内，XXX业务系统的构建主要围绕着业务的数据展开，应用的构建多是自下而上构建，主要以满足某个部门的业务功能为主，我们称之为业务处理的时代。这样的构建方式造成了一个个分立的应用，分立的应用导致了一个个的静态竖井。由于数据从属于应用，缺乏XXX全局的单一视图，形成了一个个信息孤岛，分立的系统之间缺乏沟通，同样数据的孤岛导致只能获得片面的信息，而不是全局的单一视图。存储这些信息的载体可能是各种异构或同构的关系型数据库，也有可能是XML、EXCEL等文件。因此，构建新一代的一体化平台提上了日程并最终促成全域数据的管理方式，目的是覆盖XXX各个环节的关键业务数据，完善元数据管理，形成全局的数据字典、业务数据规范和统一的业务指标含义，能够灵活的获取XXX业务数据的单一视图（需要保证数据的一致性、完整性、准确性和及时性）。数据的交换和共享主要发生在上下级组织机构之间或同级的不同部门之间。最终，这些数据可以为部队分析、决策支持（多维分析、即席查询、数据挖掘）等应用提供更及时、准确、有效的支持。 数据仓库的目标是实现跨系统数据共享，解决信息孤岛，提升数据质量，辅助决策分析，提供统一的数据服务。同时，数据仓库的构建也面临着各种挑战，比如信息整合在技术上的复杂度、信息整合的管理成本、数据资源的获取、信息整合的实施周期以及整合项目的风险等。

2. 全域数据库总体架构 边防一体化其他XML Excel Web 服务消息队列文本数据智能传感器 虚拟传感器摄像头全域数据库总体架构 全域数据库总体的层次，最下面是基础架构层，主要包括支撑这一架构运行的主机系统、存储备份系统、网络系统等内容。从下往上看，再上面是数据源层，既包括各个业务的关系型数据源、内容管理数据源也包括半结构化数据源比如XML 、EXCEL 等，也包括各个总队、支队的业务数据源。 数据源层之上是“交换服务体系”，主要包括信息服务总线和服务总线两部分。信息服务总线主要实现数据层的信息整合和数据转换，而服务总线主要实现应用层的信息交换和整合。信息服务总线主要依托联邦、复制、清洗、转换等技术实现，其主要包括信息整合服务和清洗转换加载服务两部分。通过信息服务总线的信息整合服务（数据联邦、复制），可以透明、实时的访问分布在总队和支队的各个业务系统中的

数据仓库建模

背景介绍 熟悉社保行业的读者可以知道，目前我们国家的社保主要分为养老，失业，工伤，生育，医疗保险和劳动力市场这6 大块主要业务领域。在这6 大业务领域中，目前的状况养老和事业的系统已经基本完善，已经有一部分数据开始联网检测。而，对于工伤，生育，医疗和劳动力市场这一块业务，有些地方发展的比较成熟，而有些地方还不够成熟。 1.业务建模阶段 基于以上的背景介绍，我们在业务建模阶段，就很容易来划分相应的业务。因此，在业务建模阶段，我们基本上确定我们本次数据仓库建设的目标，建设的方法，以及长远规划等。如下图： 图8. 业务建模阶段 在这里，我们将整个业务很清楚地划分成了几个大的业务主线，例如：养老，失业，工伤，生育，医疗，劳动力等着几个大的部分，然后我们可以根据这些大的模块，在每个业务主线内，考虑具体的业务主线内需要分析的业务主题。 因此，业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。 同时，业务建模阶段的另一个重要工作就是确定我们数据建模的范围，例如：在某些数据准备不够充分的业务模块内，我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下，我们可以再来考虑数据建模的问题。 2.领域概念建模阶段领域概念建模阶段是数据仓库数据建模的一个重要阶段，由于我们在业务建模阶段已经完全理清相应的业务范围和流程，因此，我们在这个领域概念建模阶段的最主要的工作就是进行概念的抽象，整个领域概念建模的工作层次如下图所示：

图9. 领域概念建模阶段 从上图我们可以清楚地看到，领域概念建模就是运用了实体建模法，从纷繁的业务表象背后通过实体建模法，抽象出实体，事件，说明等抽象的实体，从而找出业务表象后抽象实体间的相互的关联性，保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。 从图上看，我们可以把整个抽象过程分为四个层次，分别为： ?抽象方法层，整个数据模型的核心方法，领域概念建模的实体的划分通过这种抽象方法来实现。 ?领域概念层，这是我们整个数据模型的核心部分，因为不同程度的抽象方法，决定了我们领域概念的不同。例如：在这里，我们可以使用“参与方”这个概念，同时，你也可以把他分成三个概念：“个人”，“公司”，和“经办机构”这三个概念。而我们在构建自己的模型的时候，可以参考业务的状况以及我们自己模型的需要，选择抽象程度高的概念或者是抽象程度低的概念。相对来说，抽象程度高的概念，理解起来较为复杂，需要专业的建模专家才能理解，而抽象程度低的概念，较适合于一般业务人员的理解，使用起来比较方便。笔者在这里建议读者可以选用抽象概念较低的实体，以方便业务人员和技术人员之间的交流和沟通。 ?具体业务层，主要是解决具体的业务问题，从这张图我们可以看出，具体的业务层，其实只是领域概念模型中实体之间的一些不同组合而已。因此，完整的数据仓库的数据模型应该能够相应灵活多变的前端业务的需求，而其本身的模型架构具有很强的灵活性。这也是数据仓库模型所具备的功能之一。 ?业务主线层，这个层次主要划分大的业务领域，一般在业务建模阶段即已经完成这方面的划分。 我们一般通过这种大的业务主线来划分整个业务模型大的框架。 通过领域概念建模，数据仓库的模型已经被抽象成一个个的实体，模型的框架已经搭建完毕，下面的工作就是给这些框架注入有效的肌体。

数据仓库设计文档模板

数据仓库设计与实现 学号 128302106 姓名江晨婷 成绩 教师张丹平 二O一五年四月

数据仓库建设方案设计与实现 摘要：本文以博士学位调查为基础，创建方案，设计与实现数据仓库，通过对当前各种主流数据仓库软件在性能、价格等方面的对比，充分考虑统计业务、单位数量等实际情况，本系统决定采用SQL Server 2005数据仓库软件来构建综合信息分析系统的数据仓库。 关键词：数据仓库；联机分析；数据挖掘；博士学位 一、概述 数据仓库的设计一般从操作型数据开始，通常需要经过以下几个处理过程；数据仓库设计——数据抽取——数据管理。 1.数据仓库设计 根据决策主题设计数据仓库结构，一般采用星型和雪花模型设计其数据模型，在设计过程中应保证数据仓库的规范化和体系各元素的必要联系。 2.数据抽取 根据元数据库中的主题表定义、数据源定义、数据抽取规则定义对异地异构数据源进行清理、转换、对数据进行重新组织和加工，装载到数据仓库的目标库中。 3.数据管理 数据管理分为目标数据维护和元数据维护两方面。目标数据维护是根据元数据为所定义的更新频率、更新数据项等更新计划任务来刷新数据仓库，以反映数据源的变化，且对时间相关性进行处理。元数据是数据仓库的组成部分，元数据的质量决定整个数据仓库的质量。当数据源的运行环境、结构及目标数据的维护计划发生变化时，需要修改元数据。 二、博士学位授予信息年度数据统计分析 1.按主管部门统计 从主管部门的角度，分析在一个时间段（年）内，各主管部门所授予的博士学位信息统计。可回答如“2008，由某部门主管的，博士学位授予一共有多少，其平均学习年限是多少，脱产学习的有多少人?”等问题。具有表格和图形两种方式来展示分析结果。典型报表格式如表1所示

数据仓库模型建设规范1.0

数据仓库模型建设规范 1.概述 数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求、分析、设计、测试等通常的软件生命周期之外，它还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的模型设计异常重要,这也是关系到数据仓库项目成败的关键。 物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基—层层建筑—封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免地要考虑数据库的物理设计。 数据仓库建模的设计目标是模型的稳定性、自适应性和可扩展性。为了做到这一点，必须坚持建模的相对独立性、业界先进性原则。 2.数聚模型架构 在数聚项目实施过程，我们一般将数据仓库系统的数据划分为如下图所示几个层次。

2.1.数据架构图

2.2.架构工作方法规范

2.3.准备层L0 2.3.1.主要数据结构 临时表：从数据源抽取，直接落地到临时表。临时表总是保存这次抽取的数据，不保留历史数据。也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果 是增量抽取的话，就是自从上次修改后的数据。 接口表：从临时表，经过清洗、转换到达接口表。接口表保存历史数据，也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话。 接口表里面也是源系统整个表的数据。 转换表：为了进行清洗和转换建立的中间辅助表。 2.3.2.命名规范 临时表：L0_TMP_源系统_具体业务或 L0_TMP_业务主题_具体业务（对单一源）举例：L0_TMP_POS_SALESORDER 接口表：L0_DCI_业务主题_具体业务表 举例：L0_DCI_SALES_SALESORDER 转换表：L0_MAP_具体业务表 举例：L0_MAP_SALES 2.3.3.开发工作 ●开发数据抽取接口，落地TMP区 ●开发数据清洗转换程序，落地DCI区，多源系统进行合并 ●开发数据装载程序，装载到L1层 2.4.原子层L1 2.4.1.主要数据结构 维度表：整个数据仓库一致的维度 代码表：维度属性，非维度代码等。 原子事实表：根据业务主题，形成原子事实表 汇总事实表：根据分析主题，业务主题形成合并或汇总的事实表。

数据仓库建设步骤

数据仓库建设步骤 1.系统分析，确定主题 确定一下几个因素： 操作出现的频率，即业务部门每隔多长时间做一次查询分析。 在系统中需要保存多久的数据，是一年、两年还是五年、十年 用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。 用户所能接受的响应时间是多长、是几秒钟，还是几小时。 2.选择满足数据仓库系统要求的软件平台 选择合适的软件平台，包括数据库、建模工具、分析工具等。有许多因素要考虑，如系统对数据量、响应时间、分析功能的要求等，以下是一些公认的选择标准： 厂商的背景和支持能力，能否提供全方位的技术支持和咨询服务。 数据库对大数据量（TB级）的支持能力。 数据库是否支持并行操作。 能否提供数据仓库的建模工具，是否支持对元数据的管理。 能否提供支持大数据量的数据加载、转换、传输工具（ETT）。 能否提供完整的决策支持工具集，满足数据仓库中各类用户的需要。 3.建立数据仓库的逻辑模型 具体步骤如下： 1)确定建立数据仓库逻辑模型的基本方法。 2)基于主题视图，把主题视图中的数据定义转到逻辑数据模型中。 3)识别主题之间的关系。 4)分解多对多的关系。 5)用范式理论检验逻辑数据模型。 6)由用户审核逻辑数据模型。 4.逻辑数据模型转化为数据仓库数据模型 具体步骤如下： 1)删除非战略性数据：数据仓库模型中不需要包含逻辑数据模型中的全部数据项，某些用于操作 处理的数据项要删除。 2)增加时间主键：数据仓库中的数据一定是时间的快照，因此必须增加时间主键。 3)增加派生数据：对于用户经常需要分析的数据，或者为了提高性能，可以增加派生数据。

4)加入不同级别粒度的汇总数据：数据粒度代表数据细化程度，粒度越大，数据的汇总程度越高。 粒度是数据仓库设计的一个重要因素，它直接影响到驻留在数据仓库中的数据量和可以执行的 查询类型。显然，粒度级别越低，则支持的查询越多；反之，能支持的查询就有限。 5.数据仓库数据模型优化 数据仓库设计时，性能是一项主要考虑因素。在数据仓库建成后，也需要经常对其性能进行监控，并随着需求和数据量的变更进行调整。 优化数据仓库设计的主要方法是： 合并不同的数据表。 通过增加汇总表避免数据的动态汇总。 通过冗余字段减少表连接的数量，不要超过3~5个。 用ID代码而不是描述信息作为键值。 对数据表做分区。 6.数据清洗转换和传输 由于业务系统所使用的软硬件平台不同，编码方法不同，业务系统中的数据在加载到数据仓库之前，必须进行数据的清洗和转换，保证数据仓库中数据的一致性。 在设计数据仓库的数据加载方案时，必须考虑以下几项要求： 加载方案必须能够支持访问不同的数据库和文件系统。 数据的清洗、转换和传输必须满足时间要求，能够在规定的时间范围内完成。 支持各种转换方法，各种转换方法可以构成一个工作流。 支持增量加载，只把自上一次加载以来变化的数据加载到数据仓库。 7.开发数据仓库的分析应用 建立数据仓库的最终目的是为业务部门提供决策支持能力，必须为业务部门选择合适的工具实现其对数据仓库中的数据进行分析的要求。 信息部门所选择的开发工具必须能够： 满足用户的全部分析功能要求。数据仓库中的用户包括了企业中各个业务部门，他们的业务不同，要求的分析功能也不同。如有的用户只是简单的分析报表，有些用户则要求做预 测和趋势分析。 提供灵活的表现方式。分析的结果必须能够以直观、灵活的方式表现，支持复杂的图表。 使用方式上，可以是客户机/服务器方式，也可以是浏览器方式。 事实上，没有一种工具能够满足数据仓库的全部分析功能需求，一个完整的数据仓库系统的功能可能是由多种工具来实现，因此必须考虑多个工具之间的接口和集成性问题，对于用户来说，希望看到的是一致的界面。 8.数据仓库的管理

数据仓库建设对数据量、硬件、软件的要求

1、不同数据量级别对服务器硬件、软件的要求 （要考虑到数据的双向传输、压力等状况） （我们目前的数量级别是多少？如果考虑到服务明细数据、三年的增量等） 不同数据量级别对服务器硬件、软件的要求：没什么特别要求，只要保证单台数据查询比较快就OK，数据量级别主要是靠横向扩展机器的台数来满足，只要数据是按照最初设计的存储方式来存储，满足我们查询的速度即可； 目前我们数据量单表每天5000左右的量，整个数据库10g左右，未来三年可能是一年2000万的处理量，三年后数据量可能到达上亿条记录，整个数据库35g左右。 2、Oracle数据库对数据量有没有什么限制？ 在Oracle中，数据库是由实例和物理存储结构组成的。而物理存储结构是指存储在磁盘上的物理文件，包括数据文件（data file）、控制文件（control file）、联机重做日志（online redo log）、参数文件（spfile/pfile）、警告日志（alert log）、跟踪文件（trace file）等众多作用不同的文件所组成的。我们最关注的数据，则是保存在数据文件（data file）中。那我们在创建以及维护数据库时，该如何规划数据文件的大小和数量呢？这里面涉及较多的考量因素。主要有如下几点： 2.1操作系统的限制 数据库是运行在操作系统之上的，操作系统是基础，因此，操作系统所能支持的最大文件容量和数量就成为数据库所能支持的限制。但不同操作系统之间，这个限制也是不同的。 以下是较为常见的几种操作系统对此的限制： 2.1.1 WINDOWS 最大数据块：16K 最大文件数量：20000个（数据块2K时）/40000个(数据块4K时）/65536个（数据块为8K或16K时）最大文件容量：4GB（文件系统为FAT时）/ 64GB（文件系统为NTFS时） 2.1.2 UNIX和LINUX 最大数据块：32K (LINUX_X86为16K) 最大文件数量：65534个 2.2O RACLE数据库的限制 每个数据库可管理的最大文件数量：65533个

数据仓库建模与ETL实践技巧

一、数据仓库的架构 数据仓库（Data Warehouse DW）是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库，它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题的，以OLAP系统的分析需求为目的。 数据仓库的架构模型包括了星型架构（图二：pic2.bmp）与雪花型架构（图三：pic3.bmp）两种模式。如图所示，星型架构的中间为事实表，四周为维度表，类似星星；而相比较而言，雪花型架构的中间为事实表，两边的维度表可以再有其关联子表，从而表达了清晰的维度层次关系。 从OLAP系统的分析需求和ETL的处理效率两方面来考虑：星型结构聚合快，分析效率高；而雪花型结构明确，便于与OLTP系统交互。因此，在实际项目中，我们将综合运用星型架构与雪花型架构来设计数据仓库。 那么，下面我们就来看一看，构建企业级数据仓库的流程。 二、构建企业级数据仓库五步法 （一）、确定主题 即确定数据分析或前端展现的主题。例如：我们希望分析某年某月某一地区的啤酒销售情况，这就是一个主题。主题要体现出某一方面的各分析角度（维度）和统计数值型数据（量度）之间的关系，确定主题时要综合考虑。 我们可以形象的将一个主题想象为一颗星星：统计数值型数据（量度）存在于星星中间的事实表；分析角度（维度）是星星的各个角；我们将通过维度的组合，来考察量度。那么，“某年某月某一地区的啤酒销售情况”这样一个主题，就要求我们通过时间和地区两个维度的组合，来考察销售情况这个量度。从而，不同的主题来源于数据仓库中的不同子集，我们可以称之为数据集市。数据集市体现了数据仓库某一方面的信息，多个数据集市构成了数据仓库。 （二）、确定量度 在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。 量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标（KPI）等的设计和计算。

建设数据仓库的八个步骤

大数据技术部 建设数据仓库的八个步骤2017年04月25日编制

建设数据仓库的八个步骤 摘要：建立数据仓库是一个解决企业问题的过程，业务人员往往不懂如何建立和使用数据仓库，发挥其决策支持的作用；信息部门的人员往往又不懂业务，不知道应该建立哪些决策主题。 关键词：数据仓库元数据 建设数据仓库 建立数据仓库是一个解决企业问题的过程，业务人员往往不懂如何建立和使用数据仓库，发挥其决策支持的作用；信息部门的人员往往又不懂业务，不知道应该建立哪些决策主题，从数据源中抽取哪些数据。因此数据仓库的项目小组应该由业务人员和信息部门的人员共同组成，双方需要相互沟通，协作开发数据仓库。 开发数据仓库的过程包括以下几个步骤。 1.系统分析，确定主题 建立数据仓库的第一个步骤就是通过与业务部门的充分交流，了解建立数据仓库所要解决的问题的真正含义，确定各个主题下的查询分析要求。 业务人员往往会罗列出很多想解决的问题，信息部门的人员应该对这些问题进行分类汇总，确定数据仓库所实现的业务功能。一旦确定问题以后，信息部门的人员还需要确定一下几个因素： ·操作出现的频率，即业务部门每隔多长时间做一次查询分析。 ·在系统中需要保存多久的数据，是一年、两年还是五年、十年。 ·用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。 ·用户所能接受的响应时间是多长、是几秒钟，还是几小时。 由于双方在理解上的差异，确定问题和了解问题可能是一个需要多次往复的过程，信息部门

的人员可能需要做一些原型演示给业务部门的人员看，以最终确定系统将要实现的功能确实是业务部门所需要的。 2.选择满足数据仓库系统要求的软件平台 在数据仓库所要解决的问题确定后，第二个步骤就是选择合适的软件平台，包括数据库、建模工具、分析工具等。这里有许多因素要考虑，如系统对数据量、响应时间、分析功能的要求等，以下是一些公认的选择标准： ·厂商的背景和支持能力，能否提供全方位的技术支持和咨询服务。 ·数据库对大数据量（TB级）的支持能力。 ·数据库是否支持并行操作。 ·能否提供数据仓库的建模工具，是否支持对元数据的管理。 ·能否提供支持大数据量的数据加载、转换、传输工具（ETT）。 ·能否提供完整的决策支持工具集，满足数据仓库中各类用户的需要。 3.建立数据仓库的逻辑模型 具体步骤如下： （1）确定建立数据仓库逻辑模型的基本方法。 （2）基于主题视图，把主题视图中的数据定义转到逻辑数据模型中。 （3）识别主题之间的关系。 （4）分解多对多的关系。

数据仓库dw建设

1. 数据仓库概述 经过多年IT的建设，信息对于企业的日常管理已经日益重要，并逐渐成为重要的信息资产，信息资产的管理已经成为日常管理中一个非常重要的环节。如何管理和利用好企业内部纷繁的数据也越来越成为信息管理的一项重要工作。 在过去相当一段时间内，企业业务系统的构建主要围绕着业务的数据展开，应用的构建多是自下而上构建，主要以满足某个部门的业务功能为主，我们称之为业务处理的时代。这样的构建方式造成了一个个分立的应用，分立的应用导致了一个个的静态竖井。由于数据从属于应用，缺乏企业全局的单一视图，形成了一个个信息孤岛，分立的系统之间缺乏沟通，同样数据的孤岛导致只能获得片面的信息，而不是全局的单一视图。存储这些信息的载体可能是各种异构或同构的关系型数据库，也有可能是XML、EXCEL等文件。因此，构建新一代的一体化平台提上了日程并最终促成全域数据的管理方式，目的是覆盖企业各个环节的关键业务数据，完善元数据管理，形成全局的数据字典、业务数据规范和统一的业务指标含义，能够灵活的获取企业业务数据的单一视图（需要保证数据的一致性、完整性、准确性和及时性）。数据的交换和共享主要发生在上下级组织机构之间或同级的不同部门之间。最终，这些数据可以为部队分析、决策支持（多维分析、即席查询、数据挖掘）等应用提供更及时、准确、有效的支持。 数据仓库的目标是实现跨系统数据共享，解决信息孤岛，提升数据质量，辅助决策分析，提供统一的数据服务。同时，数据仓库的构建也面临着各种挑战，比如信息整合在技术上的复杂度、信息整合的管理成本、数据资源的获取、信息整合的实施周期以及整合项目的风险等。

2. 全域数据库总体架构 核心业务边防一体化其他XML Excel Web 服务消息队列文本数据智能传感器 虚拟传感器摄像头全域数据库总体架构 全域数据库总体的层次，最下面是基础架构层，主要包括支撑这一架构运行的主机系统、存储备份系统、网络系统等内容。从下往上看，再上面是数据源层，既包括各个业务的关系型数据源、内容管理数据源也包括半结构化数据源比如XML 、EXCEL 等，也包括各个总队、支队的业务数据源。 数据源层之上是“交换服务体系”，主要包括信息服务总线和服务总线两部分。信息服务总线主要实现数据层的信息整合和数据转换，而服务总线主要实现应用层的信息交换和整合。信息服务总线主要依托联邦、复制、清洗、转换等技术实现，其主要包括信息整合服务和清洗转换加载服务两部分。通过信息服务总线的信息整合服务（数据联邦、复制），可以透明、实时的访问分布在总队和支队的各个业务系统中的各种同构、异构数据（前提是拥有足够的权限）。信息整合服务在整个企业层面保证