金融公司的数据仓库的结构

1. 数据仓库的技术结构有哪些

? （一）数据源 是数据仓库系统的基础，是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于 RDBMS 中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等等； （二）数据的存储与管理 是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。 （三）OLAP(联机分析处理)服务器 对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：ROLAP（关系型在线分析处理）、MOLAP（多维在线分析处理）和 HOLAP（混合型线上分析处理）。ROLAP 基本数据和聚合数据均存放在 RDBMS 之中；MOLAP 基本数据和聚合数据均存放于多维数据库中；HOLAP 基本数据存放于RDBMS 之中，聚合数据存放于多维数据库中。 （四）前端工具 主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以数据挖掘及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对 OLAP 服务器，报表工具、数据挖掘工具主要针对数据仓库。 ----------------------------- 由安信公司历经 4 年研发的监测数据管理平台，采用独创的技术架构，在 B/S 架构上融入 C/S 模式，囊括了实验室管理系统、监测站办公自动化、监测站综合业务管理系统、监测数据上报系统等诸多系统，把各个系统有机融合在一起，不同的业务科室展现不同工作页面，内部却又实现了数据共享。 系统页面简单大方，操作轻松方便，在不增加实验室工作量的情况下，能够让监测数据进入系统中，原始记录单等诸多实验室报表可协助生成（不完全生成，需人工签字），随后科室比如质控、综合、主管领导即可对数据进行多层次利用查询，并自动生成各类监测报表。 系统采用流程化工作模式，对不同监测任务实施不同工作流，保证工作的科学和严谨，对于单位内部职工每天待办事宜清晰显示，让内部职工对每天工作都一目了然。系统工作流程可自由配置，工作单可根据按照配置流转相应单位，并且可以对工作流程进行追踪查询，作为领导可以查看到每一项安排工作的流转情况、完成情况和监测结果。 系统支持短信功能，对于领导等科室一些紧急任务可在系统下达后，立刻用短信通知相应工作人员，对于单位紧急通知等也可以进行短信通知，让监测站的工作更加快捷高效。 系统提供深层次数据挖掘功能，能够根据监测数据，快速提供某监测点的多方位数据，比如历年来某月COD 的监测数据变化，几年来某项监测数据的月平均值变化等等，为监测站领导决策提供科学依据。 系统生成报表功能强大，除自身已包含众多报表外，可迅速生成 WORD 下各种客户要求的监测报表，并且查阅维护方便。 系统作为平台拓展性强，可以融合其他系统与平台上，并且后期功能升级方便不影响前期功能。 目前系统已经在多个地 方监测站运行，从使用效果来看是比较实用的。

2. 典型的数据仓库系统包括哪几部分

典型的数据仓库系统包括以下几个部分：
数据源
ETL(数据抽取、转换和加载)
数据仓库
数据集市
前端展示（包括报表、多维展示等）

3. 怎样的架构设计才是真正的数据仓库架构

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

• 整合公司所有业务数据，建立统一的数据中心；

• 提供各种报表，有给高层的，有给各个业务的；

• 为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；

• 为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；

• 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；

• 开发数据产品，直接或间接为公司盈利；

• 建设开放数据平台，开放公司数据；

• 。。。。。。



• 上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；


• 其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；


• 建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。


• 整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：


• 逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。


• 我们从下往上看：


• 数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。



• 数据源的种类比较多：



• 网站日志：



• 作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，


• 一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；



• 业务数据库：



• 业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapRece来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。


• 当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。



• 来自于Ftp/Http的数据源：



• 有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；



• 其他数据源：



• 比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；



• 数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。



• 离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapRece要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；


• 当然，使用Hadoop框架自然而然也提供了MapRece接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapRece来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapRece要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》


• 实时计算部分，后面单独说。


• 数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；



• 前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。


• 另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。



• 数据应用

• 业务产品
  



• 业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；



• 报表



• 同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；



• 即席查询



• 即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；


• 这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。


• 即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。


• 当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。



• OLAP



• 目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；


• 这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；


• 比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。



• 其它数据接口
  



• 这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。



• 实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。


• 我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。


• 做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。


• 任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；



• 这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。


• 前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。


• 总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

4. 哪种数据仓库架构最成功

”的争论一直没有休止，这个问题同时也是企业在建立DW时需要决策的关键问题。Bill Inmon的集线器架构/企业信息工厂架构（Hub and Spoke / CIF – Corporate Information Factory）与Ralph Kimball的数据集市/数据仓库总线架构（Data Mart Bus Architecture/Data Warehouse Bus Architecture）则是DW架构的争论焦点。但是，这些争论一直无法形成统一的结论。到底哪种DW架构最好，不同的BI/DW从业者在不同的项目中，面对不同企业的不同情况时，往往持有不同的说法。2005 年，Thilini Ariyachandra 与Hugh Watson针对DW架构做了一个深入的调查，调查题目为“哪种数据仓库最成功？”，受访者由454位曾在各种不同规模的企业（绝大多数是美国企业）中参与了DW规划与实施的人员组成，受访者根据DW应用实际情况及经验体会做出回答。为了合理设计调查问卷，在调查问卷中合理设置调查对象（参与调查的DW架构）和评判标准（影响DW架构选择的因素及判断DW架构成功的因素等）等内容，Watson和Ariyachandra邀请了20位专家组成专家组设计调查问卷及判断标准等，这20位专家包括了DW领域的两位先驱——赫赫有名的Bill Inmon和Ralph Kimball。因此我们可以认为这份调查的结果是权威可信的。

5. 数据仓库的技术结构有哪些

是这个么
不懂哎
O(∩_∩)O~
(一)
数据源
是
数据仓库
系统的
基础
，是整个系统的数据源泉。通常包括企业
内部信息
和
外部信息
。内部信息包括存放于RDBMS中的各种业务处理数据和各类
文档
数据。外部信息包括各类法律法规、
市场信息
和
竞争对手
的信息等等;
(二)数据的存储与管理
是整个数据仓库系统的
核心
。数据仓库的真正
关键
是数据的存储和管理。数据仓库的组织管理方式决定了它有别于
传统数据库
，
同时
也决定了其对
外部数据
的表现形式。要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的
覆盖范围
可以分为
企业级数据仓库
和部门级数据仓库(通常称为
数据集市
)。
(三)OLAP(联机分析处理)
服务器
对分析需要的数据进行有效集成，按多维
模型
予以组织，以便进行
多角度
、多层次的分析，并发现
趋势
。其具体实现可以分为:ROLAP(关系型在线分析处理)、MOLAP(多维在线分析处理)和HOLAP(混合型线上分析处理)。ROLAP基本数据和
聚合数据
均存放在RDBMS之中;MOLAP基本数据和聚合数据均存放于
多维数据库
中;HOLAP基本数据存放于RDBMS之中，聚合数据存放于多维数据库中。
(四)
前端
工具
主要包括各种
报表工具
、查询工具、数据分析工具、
数据挖掘工具
以数据挖掘及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。

6. 如何建立企业级数据仓库

随着计算机应用的深入，大量数据存储在计算机中，信息的存储、管理、使用和维护显得越来越重要，而传统的数据库管理系统很难满足其要求。为了解决大数据量、异构数据集成以及访问数据的响应速度问题，采用数据仓库技术，为最终用户处理所需的决策信息提供有效方法。
1 数据仓库
数据仓库是为管理人员进行决策提供支持的一种面向主题的、集成的、非易失的并随时间而变化的数据集合。数据仓库是一种作为决策支持系统和联机分析应用数据源的结构化数据环境。
从目前数据仓库的发展来讲，数据可以存放于不同类型的数据库中，数据仓库是将异种数据源在单个站点以统一的模型组织的存储，以支持管理决策。数据仓库技术包括数据清理、数据集成、联机分析处理（OLAP）和数据挖掘（DM）。OLAP是多维查询和分析工具，支持决策者围绕决策主题对数据进行多角度、多层次的分析。OLAP侧重于交互性、快速的响应速度及提供数据的多维视图，而DM则注重自动发现隐藏在数据中的模式和有用信息。OLAP的分析结果可以给DM提供分析信息，作为挖掘的依据；DM可以拓展OLAP分析的深度，可以发现OLAP所不能发现的更为复杂、细致的信息。OLAP是联机分析处理，DM是通过对数据库、数据仓库中的数据进行分析而获得知识的方法和技术，即通过建立模型来发现隐藏在组织机构数据库中的模式和关系。这两者结合起来可满足企业对数据整理和信息提取的要求，帮助企业高层做出决策。在欧美发达国家，以数据仓库为基础的在线分析处理和数据挖掘应用，首先在金融、保险、证券、电信等传统数据密集型行业取得成功。IBM、oracle、Teradata、Microsoft、Netezza和SAS等有实力的公司相继推出了数据仓库解决方案。
近几年开始流行“分布式数据仓库”，是在多个物理位置应用全局逻辑模型。数据被逻辑地分成多个域，但不同位置不会有重复的数据。这种分布式方法可以为不同的物理数据创建安全区域，或为全球不同时区的用户提供全天候的服务。此外，有由Kognitio发起数据仓库托管服务，即DBMS厂商为客户开发和运行数据仓库。这种最初出现在业务部门，业务部门购买托管服务，而不是使用企业内IT部门提供的数据仓库。
2 数据挖掘技术
数据挖掘（DataMining），又称数据库中的知识发现（KnoWledge Discoveryin Database，KDD），是指从大型数据库或数据仓库中提取隐含的、未知的、非平凡的及有潜在应用价值并最终可为用户理解的模式过程。它是数据库研究中的很有应用价值的新领域，是人工智能、机器学习、数理统计学和神经元网络等技术在特定的数据仓库领域中的应用。数据挖掘的核心模块技术历经数十年的发展，其中包括数理统计、人工智能、机器学习。从技术角度看，数据挖掘是从大量的、不完全的、有噪声的、模糊的、随机的实际数据中，提取隐含在其中的、人们所不知道的、但又是潜在有用的信息和知识的过程。从商业应用角度看，数据挖掘是崭新的商业信息处理技术，其主要特点是对商业数据库中的大量业务数据进行抽取、转化、分析和模式化处理，从中提取辅助商业决策的关键知识。
从技术角度讲，数据挖掘可应用于以下方面：
（1）关联规则发现是在给定的事物集合中发现满足一定条件的关联规则，简单来讲，就是挖掘出隐藏在数据间的相互关系，为业务主题提供指导。
（2）序列模式分析和关联规则发现相似，但其侧重点在于分析数据间的前后关系。模式是按时间有序的。序列模式发现是在与时间有关的事物数据库中发现满足用户给定的最小支持度域值的所有有序序列。
（3）分类分析与聚类分析，分类规则的挖掘实际上是根据分类模型从数据对象中发现共性，并把它们分成不同的类的过程。聚类时间是将d维空间的n个数据对象，划分到k个类中，使得一个类内的数据对象间的相似度高于其他类中数据对象。聚类分析可以发现没有类别标记的一组数据对象的特性，总结出一个类别的特征。
（4）自动趋势预测，数据挖掘能自动在大型数据库里面寻找潜在的预测信息。一个典型的利用数据挖掘进行预测的例子就是目标营销。数据挖掘工具可以根据过去邮件推销中的大量数据找出其中最有可能对将来的邮件推销作出反应的客户。
3 联机分析（OLAP）处理技术
联机分析（OLAP）是数据仓库实现为决策提供支持的重要工具，是共享多维信息，针对特定问题的联机数据访问和分析的快速软件技术。是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来，能够真正为用户所理解，并真实反映企业维特性的信息进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术（OLAP委员会的定义）。OLAP的特性包括：①快速性：系统应能在5s内对用户的大部分分析要求做出反应；②可分析性：能处理与应用有关的任何逻辑分析和统计分析；⑨多维性：多维性是OLAP的关键属性。系统必须提供对数据的多维视图和分析，包括对层次维和多重层次维的完全支持；④信息性：系统应能及时获得信息，并能管理大容量信息。
OLAP的数据结构是多维，目前存在方式：①超立方结构（Hypercube），指用三维或更多的维数来描述一个对象，每个维彼此垂直。数据的测量值发生在维的交叉点上，数据空间的各部分都有相同的维属性（收缩超立方结构。这种结构的数据密度更大，数据的维数更少，并可加入额外的分析维）；②多立方结构（Multicube），即将超立方结构变为子立方结构。面向某特定应用对维分割，它具有强灵活性，提高了数据（特别是稀疏数据）的分析效率。分析方法包括：切片、切块、旋转、钻取等。
OLAP也被称为共享的多维数据的快速分析FASMI，应用在数据密集型行业，如市场和销售分析、电子商务的分析、基于历史数据的营销、预算、财务报告与整合、管理报告、利益率、质量分析等。
4 小 结
采用数据仓库的数据挖掘及联机分析技术实现的决策支持系统，是弥补传统辅助决策系统能力不足的有效途径，具有重要的现实意义。

7. 数据仓库三层结构中的组成部分是

数据仓库数据库

是整个数据仓库环境的核心，是数据存放的地方和提供对数据检索的支持。相对于操纵型数据库来说其突出的特点是对海量数据的支持和快速的检索技术。

数据抽取工具

把数据从各种各样的存储方式中拿出来，进行必要的转化、整理，再存放到数据仓库内。对各种不同数据存储方式的访问能力是数据抽取工具的关键，应能生成COBOL程序、MVS作业控制语言（JCL）、UNIX脚本、和SQL语句等，以访问不同的数据。数据转换都包括，删除对决策应用没有意义的数据段；转换到统一的数据名称和定义；计算统计和衍生数据；给缺值数据赋给缺省值；把不同的数据定义方式统一。

元数据

元数据是描述数据仓库内数据的结构和建立方法的数据。可将其按用途的不同分为两类，技术元数据和商业元数据。

技术元数据是数据仓库的设计和管理人员用于开发和日常管理数据仓库是用的数据。包括：数据源信息；数据转换的描述；数据仓库内对象和数据结构的定义；数据清理和数据更新时用的规则；源数据到目的数据的映射；用户访问权限，数据备份历史记录，数据导入历史记录，信息发布历史记录等。

商业元数据从商业业务的角度描述了数据仓库中的数据。包括：业务主题的描述，包含的数据、查询、报表；

元数据为访问数据仓库提供了一个信息目录（informationdirectory），这个目录全面描述了数据仓库中都有什么数据、这些数据怎么得到的、和怎么访问这些数据。是数据仓库运行和维护的中心，数据仓库服务器利用他来存贮和更新数据，用户通过他来了解和访问数据。

访问工具

为用户访问数据仓库提供手段。有数据查询和报表工具；应用开发工具；管理信息系统（EIS）工具；在线分析（OLAP）工具；数据挖掘工具。

数据集市（DataMarts）

为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是再实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。

数据仓库管理：安全和特权管理；跟踪数据的更新；数据质量检查；管理和更新元数据；审计和报告数据仓库的使用和状态；删除数据；复制、分割和分发数据；备份和恢复；存储管理。

信息发布系统：把数据仓库中的数据或其他相关的数据发送给不同的地点或用户。基于Web的信息发布系统是对付多用户访问的最有效方法。

8. 数据仓库的构造设计

数据仓库具有改变业务的威力。它能帮助公司深入了解客户行为，预测销售趋势，确定某一组客户或产品的收益率。尽管如此，数据仓库的实现却是一个长期的、充满风险的过程。由 DM Review 发布的一项网络调查显示， 51% 受访者认为创建数据仓库的头号障碍是缺乏准确的数据。而其中最重要的一点是无法实时更新所有的数据。
有六项指导原则可帮助企业快速实现数据仓库计划并评估其过程：
·简化需求收集和设计。
公司通常会难以确定，哪些数据重要，哪些使得他们无法利用有价值的非结构化信息来驱动关键业务流程。组织应该检查一下 IT 经理是否深入理解业务计划以及支持计划所需的信息。例如源数据在哪里？需要怎样的转换能让其为关键应用程序所用？
·支持业务和 IT 用户协作。
不完整、过时或不准确的数据会导致可信信息的缺乏。要注意公司是否有一个业务术语表供用户查看、用于协作并根据他们集体业务视角进行调整？
·避免代价高昂的低级错误和返工。
明确公司是否拥有一个包含界定完善的数据模型的实施策略，应用程序提供信息？
·识别匹配信息，创建单一视图。
同一事实的多个版本会导致在管理用户、产品和合作伙伴关系方面出现问题——增加违反法规遵从性的风险。
·使用最快的、最具伸缩性的方法进行转换和发布。
明确公司是否有能够利用并行处理并重用之前转换成果的自动化过程？公司系统能否及时按需将数据发布给用户和应用程序？
·通过信息服务扩展信息可访问性。
明确企业是否能真正将信息用作共有财产？IT 专家能否保存好这些财产并让被授权者使用？信息能否在合适的时间发布到合适的地方和合适的场景下？