数据仓库规范

数据仓库规范

一．数据仓库层次结构规范

1.1 基本分层结构

系统的信息模型从存储的内容方面可以分为，STAGE接口信息模型、ODS/DWD信息模型，MID信息模型、DM信息模型、元数据信息模型。

在各个信息模型中存储的内容如下描述：

1) SRC接口层信息模型：提供业务系统数据文件的临时存储，数据稽核，数据质量保证，屏蔽对业务系统的干扰，对于主动数据采集方式，以文件的方式描述系统与各个专业子系统之间数据接口的内容、格式等信息。与该模型对应的数据是各个专业系统按照该模型的定义传送来的数据文件。STAGE是生产系统数据源的直接拷贝，由ETL过程对数据源进行直接抽取，在格式和数据定义上不作任何改变。与生产系统数据的唯一不同是，STAGE层数据具有时间戳。

STAGE层存在的意义在于两点：

（1）对数据源作统一的一次性获取，数据仓库中其他部分都依赖于STAGE层的数据，不再重复进行抽取，也不在生产系统上作运算，减小生产系统的压力；

（2）在生产系统数据已经刷新的情况下，保存一定量的生产系统的历史数据，以便在二次抽取过程中运算出错的情况下可以进行回溯。

2) ODS/DWD层（对应原模型的ODS和DW层）信息模型：简称DWD层是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中。为企业进行经营数据的分析，系统将数据按分析的主题的形式存放，跟STAGE层的粒度一致，属于分析的公共资源。

3) MID 信息模型：轻度综合层是新模型增加的数据仓库中DWD层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计。轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并为满足一些不可预见的需求而进行沉淀；轻度综合层则面向分析型应用进行细粒度的统计和沉淀。

4) DM信息模型：为专题经营分析服务，系统将数据按分析的专题组织成多维库表的形式存放，属于分析目标范畴的数据组织与汇总，属于分析的专有资源。其信息主要来源于DWD 和MID层汇总，反映实

1.3数据库对象命名规范

1.3.2 数据库表空间

数据库表空间命名，原则上以数据仓库的基本分层结构为准，以TBS_作前缀，为避免单个表空间数据量过大，带来管理上的不便或者引起I/O瓶颈，对于STAG和ODS/DWD数据量比较大的层，可采用多个表空间存储数据，单表空间容量不要太大，以便于业务划分和存储管理为原则，建议单表空间容量控制在800G之内，表空间数据文件建议值为4G。

数据表空间

1.3.4 数据库分区表规范

对于海量数据表要考虑设计为分区表。

1.三户日资料保存一个月，按日期主分区按地区子分区，

2.主分区命名为：P两位日期编码(如P01)，

3.子分区命名为：P两位日期编码_SP地区编码(如P01_SP188),并且必须加上月份字段否则没法

区分是那月的资料。

2.三户月资料按帐期主分区按地区子分区，

主分区命名为：P帐期编码(如P200701)，

子分区命名为：P帐期编码_SP地区编码(如P200701_SP188)。

3.视图级日数据表按帐期和地区主分区按日期子分区，

主分区命名为：P帐期编码_地区编码(如P200701_188)，

子分区命名为：P帐期编码_地区编码_SP两位日期编码(如P200701_188_SP01)。

4.视图级月数据表按帐期主分区按地区子分区，

主分区命名为：P帐期编码(如P200701)，

子分区命名为：P帐期编码_SP地区编码(如P200701_SP188)。

5.主体域级数据按帐期主分区按日期子分区，

主分区格式为：P帐期(如P200701)，

子分区格式为：P帐期_SP两位日期编码(如P200701_SP01)。

老杨让把主题域建表分区规范改为：

主体域级数据按帐期和地区主分区按日期子分区，

主分区命名为：P帐期编码_地区编码(如P200701_188)，

子分区命名为：P帐期编码_地区编码_SP两位日期编码(如P200701_188_SP01)

1.3.5 数据库表索引

命名以IDX+表名+一位流水号.例：IDX_ODS_BUSI_USER_1;如果表名过长可以使用缩写形式

1.3.6 数据库表键值

主键命名以PK+表名+一位流水号(1~9).例: PK_DEPT_1 ;如果表名过长可以使用缩写形式

外键命名以FK+表名+一位流水号(1~9).例: FK_DEPT_1;如果表名过长可以使用缩写形式

1.3.7 数据库字段命名规范

数据库字段名中含有单词选择能够概括表内容的一个或多个英文单词，多个单词间使用下划线分割,单词如果过长可以使用缩写形式。

一些基本字段名示例：

用户id USER_NO

用户数USER_COUNTS

话单数CDR_NUM

通话时长CALL_DURATION

计费次数MOBILE_TIMES

每个字段必须有注释，并且在生成SQL脚本时一并生成，创建表时必须创建注释。

保持字段名和类型的一致性，同一字段名在不同表中必需保持同一数据类型。数据类型长度在定义时应稍大于目前标准的长度，用空间来换取将来变更带来的不便。

1.3.8 数据库存储过程规范

（1）存储过程命名规则：P_目标表。

（2）存储过程要求有注释，注释内容为：列出创建人，创建用途，创建时间。

（3）存储过程日志规范：

每一存储过程均应记录执行存储过程的日志信息。必须调用专用写日志的存储过程，同时有exception时的处理机制。

（4）存储过程修改规范

修改时应注释清楚修改人，修改日期，修改原因和修改内容。

1.3.9 数据库函数命名规范

函数命名规则F_功能，比如F_TRAN_AREA。

1.3.10 据库触发器的命名规范

触发器以TR作为前缀，触发器名为相应的表的别名加上后缀，INSERT触发器加‘_INSERT’，Delete触发器加‘_DELETE’，Update触发器加‘_UPDATE’，如：TR_CUST_INSERT。

1.3.11 序列命名规范

序列以S作为前缀，序列命名规则为S_字段别名。

二．实施流程规范（完善中。。）

(1)规划

对实施计划的规划.

(2)设计

设计实施方案(包括统一模型的修改)。

(3)实施

具体实施过程。

(4)测试

对实施结果测试。

(5)反馈

对实施过程中收集到的相关信息(系统需求、实施中遇到的问题和测试结果等)

反馈到相关部门和人员。

三．数据库安全管理规范

为了规范管理，做好经营分析数据仓库的安全管理工作，实现不同的责任人不同的层次，将用户权限尽可能的管理起来同时又不影响正常工作，需要对数据库进行安全管理。

数据库安全管理从以下几个方面来进行：

3.1. 用户组管理

对用户进行分类，目前经营分析应用用户可以分为如下几部分

?前台程序开发人员

?数据库开发人员

?数据库管理员

?外部使用人员

数据库管理人员由项目经理和数据经理来掌控，一般情况下不得使用DBA角色登陆数据库。

数据人员使用数据库开发人员角色登陆，每个数据人员一个用户，归属数据库开发人员组。

前台程序开发人员，由界面开发人员使用，可以查看所有的表，但是无法进行DDL操作。

外部使用人员，主要是面向联通用户和临时用户

3.2. 用户权限设定

对不同的用户组，在不影响正常工作的情况下，对用户组及用户权限的设定原则为权限越小越好。

3.3. 用户密码管理

对用户密码进行限制，必须由2位以上数字，2位以上字符，2位以上特殊字符组成

不允许用户密码和用户名同名

不允许用户密码和用户名相似

3.4. 用户资源管理

除了系统使用的用户（SRC/ODS/DW）等外

对用户使用的系统资源进行限定

限定用户使用表空间

限定用户使用临时表空间

限定用户使用回滚断

限定用户使用内存

3.5. IP限定

对于普通用户，实行IP和用户名绑定的策略

对于外部开放用户，要进行IP申请，由数据经理或者项目经理审核通过后予以开通3.6. 数据库监控

数据库监控，主要对以下几个方面进行监控：

3.6.1. 数据库空间占用率

select a.tablespace_name,

free,

total,

round(((b.total-a.free)/b.total),2) 剩余占比

from ( select tablespace_name,round(sum(bytes)/power(1024,3),2) free from dba_free_space

group by tablespace_name

) a,

( select tablespace_name,round(sum(bytes)/power(1024,3),2) total

from dba_data_files

group by tablespace_name

) b

where a.tablespace_name = b.tablespace_name;

3.6.2. 会话情况

select *

from v$session a,

v$sql b

where a.sql_address = b.address;

3.6.3. aix操作系统中杀掉一些进程的脚本

select 'kill -9 '|| p.spid||'',s.sid

from v$session s,v$process p

where s.paddr = p.addr

and https://www.wendangku.net/doc/4a13078732.html,ername is not null

and s.sid = 54

3.6.

4. 查看JOB

SELECT *

FROM User_Jobs

3.6.5. 分区操作

查看分区子分区

SELECT *

FROM ALL_TAB_PARTITIONS

WHERE TABLE_NAME = 'DW_V_USER_MOBILEUSER'；

SELECT *

FROM ALL_TAB_SUBPARTITIONS

WHERE TABLE_NAME = 'DW_V_USER_MOBILEUSER';

增加分区

格式：alter table 表名add partition分区名values less than (值)

如：alter table dm_reinnet_user add partition p200801 values less than ('200802') alter table dm_reinnet_user add subpartition p200801_SP001 values ('002')

删除分区

格式：alter table 表名drop partition partition 分区名

如：alter table dm_reinnet_user drop partition 200801

alter table dm_reinnet_user drop subpartition p200801_SP001

3.6.6. 数据库的无效索引

查看目前数据库中的索引情况

3.6.7. 数据库的无效对象

查看目前数据库的对象有效性，主要针对脚本

3.6.8. 数据库表分区的是否到达限额

查看是否有表分区不满足需求的情况，这项监控根据具体需求来

3.6.9. 数据库内存占用情况

查看目前数据库内存的占用情况

3.6.10.DDL语句的监控

查看各种DDL语句的使用情况，记录操作者的IP，时间，用户名等情况

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

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

数据库与数据仓库的区别是什么

数据库与数据仓库的区别是什么 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。 “与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。 “不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库

建设数据仓库7个步骤

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

数据库和数据仓库的区别

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、

数据仓库项目常见管理问题

1.项目管理问题 1．企业经历过两次失败的数据仓库建设，现在是第三次，人们普遍认为这次也将会失败。项目经理应该作些什么来消除人们对数据仓库的消极看法？ 2．企业的业务系统方，即OLTP方的工作人员对数据仓库方不配合，比如对数据仓库的源数据申请置之不理。项目经理应该如何来应付这种情况？ 3．企业的管理层变动较频繁，支持数据仓库的企业领导可能会离开，面对这种情况，项目经理应该如何应付？ 4．企业雇佣一家咨询公司来实现一个数据仓库，但是企业的CIO认为数据仓库的建设是对其职位和权威的挑战，不断给咨询人员和项目设置障碍。咨询人员应该如何来应付这种情况？ 5．企业管理层希望试验系统（原型系统）具有和生产系统相同级别的数据质量。项目经理应该如何做，才能让管理层相信，试验系统不必和生产系统具有相同级别的数据质量？ 6．用户部门领导对共享数据不配合或者只在表面上配合。他们希望能够控制谁能查看什么数据以及什么时候可以查看。数据仓库团队怎样才能让部门领导把数据的访问权共享出来？ 7．建立好的数据几乎满足所有的成功标准。但是企业的高级管理层对数据仓库的反应很冷淡。数据仓库团队应该如何应付这种情况？ 2.项目需求问题 1．数据仓库项目已经开发了6个月的时间，在项目的开发过程中，数据仓库团队发现业务源系统正在被重写，业务系统在不断的变化，一个新的系统开发出来预计只有8个月的寿命。数据仓库团队应该如何应付这种情况？ 2．源系统和数据仓库系统同期建设。但是源系统在不断的变化中，而且源系统的开发团队没有将变化告知数据仓库团队，数据仓库团队在测试过程中出现故障才发现这些变化。这种没有告知有可能是故意的。数据仓库团队应该如何来应付这种情况？ 3．数据仓库项目开始时，企业制定了一套有效的数据仓库目标。但是，随着时间的流逝，企业又制定了一些决策，采取了一些行动，这些决策和行动与最初的目标背道而驰。数据仓库团队应该如何应付这种情况? 4．数据仓库项目进展十分顺利，但是根本没有办法判断项目将来是否能够成功。要想为数据仓库确立一个完全合适的目标是不可能的。企业应该如何来面对这种状况？

数据仓库建设方案详细

第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可实现对海量数据的实时处理，及时对问题指标进行预警。具体采集系统技术结构图如下:

浅谈数据仓库中的元数据管理技术

浅谈数据仓库中的元数据管理技术 孙力君仇道霞方峻峰宋楠 山东省烟草公司信息中心 摘要：数据仓库是数据库的发展方向之一，对企业管理和决策支持起着重要的辅助作用。简要介绍了数据仓库和元数据的基本概念，重点阐述了元数据的概念、作用、CWM标准、来源，并就元数据具体应用进行了初步的研究和探讨。 关键词：数据仓库；元数据； 1. 引言 随着市场竞争的越来越激烈，烟草行业的信息化建设不断的深入发展，全行业形成了“以信息化带动烟草行业现代化建设”的基本共识，明确了“统一标准、统一平台、统一数据库、统一网络”，逐步实现系统集成、资源整合、信息共享的信息化建设总体要求，走过了“由基础性向应用性、由局部性向全局性、由分散性向集中性建设”的三个转变历程，初步形成了“数字烟草”的行业信息化建设格局，既对行业数据中心的建设提出了迫切的要求，也为行业数据中心建设奠定了坚实的基础。 随着数据库技术尤其是数据仓库技术的发展，人类能更容易获得自己需要的数据和信息，由于元数据是数据仓库中非常重要的组成部分，因此讨论和研究元数据在数据仓库中的作用和应用，具有非常重要的意义。 元数据管理是山东烟草数据中心建设的重要组成部分，元数据管理平台为用户提供高质量、准确、易于管理的数据，它贯穿数据中心构建、运行和维护的整

个生命周期。同时，在数据中心构建的整个过程中，数据源分析、ETL过程、数据库结构、数据模型、业务应用主题的组织和前端展示等环节，均需要通过相应的元数据的进行支撑。元数据管理的生命周期包括元数据获取和建立、元数据的存储、元数据浏览、元数据分析、元数据维护等部分。 通过元数据管理，形成整个系统信息数据资的准确视图，通过元数据的统一视图，缩短数据清理周期、提高数据质量以便能系统性地管理数据中心项目中来自各业务系统的海量数据，梳理业务元数据之间的关系，建立信息数据标准完善对这些数据的解释、定义，形成企业范围内一致、统一的数据定义，并可以对这些数据来源、运作情况、变迁等进行跟踪分析。完善数据中心的基础设施，通过精确把握经营数据来精确把握瞬息万变的市场竞争形式，使山东烟草在市场竞争中保持优势。 总的来说，元数据管理平台集成相关的元数据，形成企业的全局数据视图，提供企业级共享元数据的平台，是烟草业务系统的基础设施，对业务系统的发展、应用和数据质量的提升有着深远影响。 2.数据仓库概述 目前有关数据仓库的概念有多种，其中最经典的，引用最为广泛的定义是W.H.Inmon在《Building the Data Warehouse》一书中给出的，他指出：“数据仓库是面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理层的决策过程”。[1] 之所以要引入数据仓库，是因为随着信息时代的到来，如何从大量已存在的数据中提取出自己所感兴趣的信息并进行分析和预测越来越成为企业管理者和决策者所关心的问题。为了更好的进行管理和决策，许多企业都选择了数据仓库，利用数据仓库可以对各种源数据进行抽取、清理、加工

数据仓库中元数据的管理

数据仓库中元数据的管理M etadata M anagem en t i n a Data W arehouse 同济大学计算机科学与工程系(上海200092) 史金红　吴永明 【摘要】　介绍了数据仓库中四种基本类型的元数据,说明了不同类型元数据的收集和维护方法,并着重对分布式元数据的集成和管理进行了详细的阐述。 关键词:数据仓库,数据商场,决策支持,元数据 【Abstract】　T h is p ap er in troduces fou r typ es of m etadata and the m ethods of co llecting and m ain tain ing them.It focu ses on the m etadata m anagem en t and in tegrity. Key words:　da ta warehouse,da ta mart, dec ision support,m etada ta 1　引言 随着社会的发展和计算机技术的进步,人们已不满足于用计算机只作简单的数据处理和事务处理。进一步用现有的数据进行分析和推理,从而为决策提供依据的需求导致了决策支持系统(D SS)的出现。90年代以来计算机技术、网络技术和数据库技术的迅速发展为D SS提供了必要的技术环境, OL T P和办公自动化普遍应用积累的大量数据为D SS提供了必要的数据基础,日趋激烈的市场竞争促进了各级管理和决策人员对D SS的实际需求,因此自从1991年W.H.Inm on提出数据仓库的概念和1993年E.F.Codd提出OLA P概念以来,已有许多商品化的数据仓库管理系统和联机分析处理工具软件面市。以上诸因素的共同作用促成许多公司、机构纷纷为提高自己的竞争能力建立数据仓库系统以进行决策支持。 元数据是成功的数据仓库的重要组成部分,它可以帮助数据仓库项目小组明确而全面地理解潜在数据源的物理布局以及所有数据元的业务定义,帮助数据仓库用户有效地使用仓库中的信息,帮助数据库管理员了解某些表的变化将对数据仓库产生怎样的影响以及不同商业过程对应的应用等等。项目小组在开发过程中应当识别元数据并将它收入到元数据商店中,实施适当的过程捕作企业数据结构和应用的变化,从而修改相应的元数据,并向用户提供适当的工具访问元数据。 2　元数据的基本类型 元数据按照其用户可以分为技术元数据和商业元数据。技术元数据提供给数据仓库的技术人员,数据仓库技术人员在仓库的开发和维护中使用这类元数据。商业元数据是商业用户在仓库中寻找他们所需商业信息的一个辅助。但是,技术人员可能也需要访问几种类型的商业元数据,如和商业用户讨论信息需求和建立企业的数据模型。同样,商业用户也需要尝试高水平的技术元数据。 元数据按其内容可以分为四个基本类型: 1)关于数据仓库潜在数据来源的信息,包括现有的业务系统、可得到的外部数据和目前手工维护的信息。例如,一个组织可以从中识别数据来源的潜在仓库数据源有:几个现有的应用程序,由财务部门保存的基于PC机的电子报表,从某一卖主处购买的销售数据,目前由顾客服务部门在纸上保存的顾客联系记录。 2)关于数据模型的信息,包括业务实体、关系、企业规则和企业数据模型。 3)关于业务数据与仓库数据结构间的映射信息。只要那些来源中的一个数据元与仓库建立了映射关系,就应该记录下这些数据元间的逻辑联系以及发生的任何变换或变动。 4)关于数据仓库中信息的使用情况。了解这类信息对更好地调整仓库性能、更多地利用现有查询以及理解仓库中的信息怎样用于解决企业问题是很重要的。 3　元数据的收集和维护 在适当的时间收集适当的元数据是成功实施元数据驱动的数据仓库的基础。为保证较高的准确

数据仓库元数据管理

1.1.1 第一章元数据概论 企业的计算机系统每年会产生很多数据，很多企业面临着这样的困境，难以有效的管理大量的、繁杂的、不一致的数据，并方便地访问、利用这些数据进行辅助决策。 建立数据仓库提供一个方法，把数据转化为有用的、可信赖的信息，支持商业决策。建立数据仓库一个重要的工作是元数据管理。元数据（Metadata）就是数据的数据，用于建立、管理、维护和使用数据仓库。。元数据管理是企业级数据仓库中的关键组件，贯穿于建立数据仓库的整个过程。 元数据使得用户可以掌握数据的历史情况，如数据从哪里来？流通时间有多长？更新频率是多大？数据元素的含义是什么？对它已经进行了哪些计算、转换和筛选等等。在需求不确定情况下，在瞬间万变的商业环境下，元数据可以更好的支持需求的变化，降低项目风险。 通常把元数据分为技术元数据（Technical Metadata）和业务元数据（Business Metadata）。技术元数据是描述关于数据仓库技术细节的数据，这些元数据应用于开发、管理和维护数据仓库；业务元数据从商业和业务的角度描述数据仓库的数据，提供了良好的语义层定义，业务元数据使业务人员能够更好的理解数据仓库分析出来的数据。 元数据贯彻于建立数据仓库的整个过程，不只是ETL过程需要元数据的支持。 图1 元数据的应用 在使用元数据的同时，随着数据仓库市场的发展，业界出现许多数据仓库管理和分析的工具，各种工具使用不同的元数据标准来表示和处理，不同系统之间的迁移、数据交换变得困难。于是，我们希望用一种单一的元数据标准，使得各种组织的元数据具有单一的元模型（MetaModel），因此，需要建立一种标准使得不同的数据仓库和商业智能系统之间可以相互交换元数据。 1.1.2 第二章元数据标准 1.1. 2.1 一、元数据标准CWM OMG于2001年颁布元数据标准CWM 1.0（Common Warehouse Metamodel Version 1.0）。CWM定义一个描述数据源、数据目的、转换、分析的元数据框架，以及定义建立和管理数据仓库的过程和操作，提供使用信息的继承。 目前宣布支持CWM的厂商包括：IBM、Oracle、Hyperion、Dimension EDI、Genesis IONA、HP、NCR和Unisys等。 CWM基于3个工业标准： UML - Unified Modeling Language，OMG建模标准； MOF - Meta Object Facility，OMG建立元模型和模型库的标准，提供在异构环境下的数据交换的接口； XMI - XML Metadata Interchange，OMG元数据交换标准。 UML在CWM中得到充分的应用，担任3个不同的角色： 1），UML用来做为与MOF对应的meta-metamodel。UML相当于MOF Model,，UML Notation和OCL(Object Constraint Language)，被用来做为建模语言、图形符号、约束语言，

数据仓库建设方案

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

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

数据仓库元数据管理

数据仓库元数据管理 余友波 数据仓库之路原创资料 https://www.wendangku.net/doc/4a13078732.html,

1.1.1 第一章元数据概论 企业的计算机系统每年会产生很多数据，很多企业面临着这样的困境，难以有 效的管理大量的、繁杂的、不一致的数据，并方便地访问、利用这些数据进行辅助 决策。 建立数据仓库提供一个方法，把数据转化为有用的、可信赖的信息，支持商业 决策。建立数据仓库一个重要的工作是元数据管理。元数据（Metadata）就是数据 的数据，用于建立、管理、维护和使用数据仓库。。元数据管理是企业级数据仓库 中的关键组件，贯穿于建立数据仓库的整个过程。 元数据使得用户可以掌握数据的历史情况，如数据从哪里来？流通时间有多长？更新频率是多大？数据元素的含义是什么？对它已经进行了哪些计算、转换和筛选等等。在需求不确定情况下，在瞬间万变的商业环境下，元数据可以更好的支持需求的变化，降低项目风险。 通常把元数据分为技术元数据（Technical Metadata）和业务元数据（Business Metadata）。技术元数据是描述关于数据仓库技术细节的数据，这些元数据应用于开发、管理和维护数据仓库；业务元数据从商业和业务的角度描述数据仓库的数据，提供了良好的语义层定义，业务元数据使业务人员能够更好的理解数据仓库分析出来的数据。 元数据贯彻于建立数据仓库的整个过程，不只是ETL过程需要元数据的支持。 图1 元数据的应用 在使用元数据的同时，随着数据仓库市场的发展，业界出现许多数据仓库管理 和分析的工具，各种工具使用不同的元数据标准来表示和处理，不同系统之间的迁 移、数据交换变得困难。于是，我们希望用一种单一的元数据标准，使得各种组织 的元数据具有单一的元模型（MetaModel），因此，需要建立一种标准使得不同的 数据仓库和商业智能系统之间可以相互交换元数据。 https://www.wendangku.net/doc/4a13078732.html,

数据仓库建设步骤

数据仓库建设步骤 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个

BI_数据仓库基础

1 BI Business Intelligence，即商业智能，商务智能综合企业所有沉淀下来的信息，用科学的分析方法，为企业领导提供科学决策信息的过程。 BOSS业务运营支撑系 BPM企业绩效管理 BPR业务流程重整 CRM客户关系管理 CUBE立方体 DM（Datamart）数据集市数据仓库的子集，它含有较少的主题域且历史时间更短数据量更少，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。 DM（DataMine）数据挖掘 DSS决策支持系统 EDM企业数据模型 3 ERP Enterprise Resourse Planning企业资源规划。它是一个以管理会计为核心的信息系统，识别和规划企业资源，从而获取客户订单，完成加工和交付，最后得到客户付款。换言之，ERP将企业内部所有资源整合在一起，对八个采购、生产、成本、库存、分销、运输、财务、人力资源进行规划，从而达到最佳资源组合，取得最佳效益。 4 ETL 数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终 按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。 KDD数据库中知识发现 5 KPI 企业关键业绩指标(KPI：KeyProcessIndication)是通过对组织内部流程的输入端、输出端的关键参数进行设臵、取样、计算、分析，衡量流程绩效的一种目标式量化管理指标，是把企业的战略目标分解为可操作的工作目标的工具，是企业绩效管理的基础。 LDM逻辑数据模型 6 MDD 多维数据库（Multi Dimesional Database,MDD）可以简单地理解为：将数据存放在一个n维数组中，而不是像关系数据库那样以记录的形式存放。因此它存在大量稀疏矩阵，人们可以通过多维视图来观察数据。多维数据库增加了一个时间维，与关系数据库相比，它的优势在于可以提高数据处理速度，加快反应时间，提高查询效率。 Metadata(元数据)，它是“关于数据的数据，其内容主要包括数据仓库的数据字典、数据的定义、数据的抽取规则、数据的转换规则、数据加载频率等信息。 MOLAP自行建立了多维数据库，来存放联机分析系统数据 7 ODS（四个特点） (Oprational Data Store)操作型数据存储，是建立在数据准备区和数据仓库之间的一个部件。用来满足企业集成的、综合的操作型处理需要，操作数据存储是个可选的部件。对于一些准实时的业务数据库当中的数据的暂时存储，支持一些同时关连到历史数据与实时数据分

(整理)数据仓库与元数据管理

数据仓库与元数据管理 1. 前言 在事务处理系统中的数据，主要用于记录和查询业务情况。随着数据仓库（DW）技术的不断成熟，企业的数据逐渐变成了决策的主要依据。数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。 本文首先介绍了元数据的定义、作用和意义；然后讨论了数据仓库系统中元数据管理的现状和关于元数据的标准化情况；最后提出了建立元数据管理系统的步骤和实施方法。 2. 元数据 2.1 元数据的概念 按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。 技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息： ●数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义， 以及数据集市的位置和内容； ●业务系统、数据仓库和数据集市的体系结构和模式 ●汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、 预定义的查询与报告； ●由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数 据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。 业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统

数据仓库与数据库

数据仓库与数据库的区别 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM 了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 “面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，

建设数据仓库的八个步骤

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

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

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

从数据库到数据仓库_陈前林

第19卷第3期湖 北 工 学 院 学 报2004年6月Vol.19No.3 Journal of Hubei Polytechnic University Jun.2004 [收稿日期]2004-03-01 [基金项目]国家863项目(2003AA414011)和武汉市重大科技计划项目(20023005133-04). [作者简介]陈前林(1980-),男,湖北大冶人,武汉理工大学硕士研究生,研究方向:数据挖掘. [文章编号]1003-4684(2004)06-0113-03 从数据库到数据仓库 陈前林,陈定方,李和平 (武汉理工大学智能制造与控制研究所,湖北武汉430063) [摘 要]通过对数据库技术发展的追溯,介绍了数据仓库的概念、产生、来源及其与数据库的区别,最后探讨了数据仓库的应用前景. [关键词]数据处理;数据库;数据仓库;数据挖掘;OL AP [中图分类号]T P311.132 [文献标识码]:A 1 数据库技术发展概述 数据处理主要就是对数据的管理[1].它主要完成对数据的分类、组织、编码、存储、检索和维护等功能.这也是数据处理的中心问题.近半个世纪以来,数据管理经历了三个发展阶段,分别是人工管理阶段,文件系统阶段和数据库系统阶段,数据仓库是数据库技术的进一步发展. 20世纪中期以前,计算机主要用于科学计算,计算机本身都不带有存储设备,也没有操作系统的概念,数据处理只有批处理方式.所有数据都不在计算机上保存,由应用程序员管理.应用程序员不仅要规定数据的逻辑结构,而且还要在应用程序中设计物理结构,包括规定数据的存储结构,存取方式等.20世纪50年代后期到60年代中期,数据处理处于文件系统阶段.计算机上出现了磁盘、磁鼓等随机存取设备,文件系统成为了专门的数据管理软件.这样,数据可以长期保存.并且,用文件系统来管理数据,使程序和数据之间有了一定的独立性,尽管这种独立性不是很强.此时的应用程序设计者必须对所用文件的逻辑结构及物理结构有清楚的了解,并且,由于文件系统仅提供了读、写等几个低级的文件操作命令,因而对文件的查询、修改、插入和删除等操作必须在应用程序内编写相应的程序代码来解决.这使得文件也是专门为某一特定的应用程序服务的,且编写应用程序的生产率不高,数据冗余度大. 20世纪60代后期以来,数据管理进入了数据库系统阶段.这一时期,计算机具有了庞大容量的存储设备和高速的信息处理能力.计算机软件、硬件都飞速发展,信息急剧膨胀;数据库技术也不断发展.数据库按照某种数据模型组织数据,不仅文件内部数据彼此相关,而且文件之间在结构上也有机地联系在一起.描述数据时,不仅描述数据本身,也描述数据之间的联系.在数据库中,数据也不再分属于各个应用程序,而是集中存放在数据库中,实行统一控制.这一时期,也出现了专门的数据库系统. 1969年,美国的IBM 公司开发了第一个数据库系统IMS (Information M anagement System ).这是一个层次数据库系统,在数据库系统发展史上有着重要的地位.同年,美国的数据系统语言委员会下属的数据库任务组提出了著名的DBT G 报告,并在1970年提出了该报告的修订版.这分报告定义了数据库操纵语言、模式定义语言和子模式定义语言的概念.数据库操纵语言用于编写操纵概念视图的应用程序,模式定义语言用来编写概念视图和内部视图相结合的模式程序.在20世纪70年代,开发了许多遵循DBTG 报告的网状数据库系统,如IDMS,IDS,DMSIIOO 等.20世纪70年代初,IBM 公司下属的San Jose 研究所的E.F.Codd 发表了题为 大型共享数据库数据的关系模型 的论文.他在论文中提出了关系数据模型的概念.他提出的关系代数和关系演算,使关系数据库从理论到实践都取得了辉煌的成果.在理论上,确立了完整的关系理论,数据