kok电子竞技

1、对数据仓库进行数据建模IBM2007-11-16 15:00OLTP 与数据仓库-有何差异？在日常生活中，我们要使用大量的应用程序来生成新的数据、变更数据、删除数据，当然在大多数的情况下我们还要查阅和分析数据。就来想象一个收发 email 的简单应用程序吧。我们已经存储了地址信息，可能还存储了一些文档。我们可以决定是否存储已经发送过的邮件，但是也可能隔一段时间后将其删除，或者删除已经发送过的所有邮件。那么我们该如何处理一段时间以前删除或者修改过的地址呢？我们再也不会看到它们了。Email 程序大部分都属于不是很复杂的数据库，但是完全可以将其看作一个在单用户环境下的 OLTP（在线事务处理系统）

2、简单示例。它使用了所有的所谓访问数据的操作 CRUD（创建、读取、更新、删除）。当数据存储达到一定量的时候，规模就会几乎保持不变，因为可以从存储中删除过期数据。数据仓库就完全是一种不同种类的应用程序。它并不是用来运行当前的操作，例如发送邮件。它是用来分析数据并且从现有数据中发现新的价值，主要是用来预测未来的情况。数据仓库并不是解决所有问题的通用结构。它必须集中于某一问题领域，例如航空服务、顾客收益等。数据仓库也有有趣的一面，那就是数据库本身是稳定增长的。数据没有被删除，也不发生变更。我们不需要将冗余数据置于数据库之外（因为加入仓库中的数据经过了数据净化的过程，该过程检查了数据的正确性）来减少复

3、杂性同时增强读取操作的性能。为了能够对数据仓库中的数据进行分析，数据存储于一个多维结构中，叫做星型模式。如果将星型模式扩展，就会得到雪花模式。本白皮书将会阐述如何使用IBM Rational Rose进行星型模式建：脱┗Ｊ浇。飞行服务数据集市的例子为了更好地解释如何对数据仓库建模，本白皮书将使用一个简单数据集市的的例子（即一个数据仓库或者数据仓库的一部分），来分析旅客乘坐航班 Happy Flying and Landing(愉快飞行平安降落)的行为和满意程度。我们将存储乘客信息和每个航班的的相关数据、选择的菜单以及乘客对飞行的满意程度。数据仓库术语表数据仓库引入了新的术语，扩展了数据建

4、模的术语表。为使本文的阐述能够完备，下面我介绍一下最常用的术语。数据仓库数据仓库是一个支持管理决策的数据集合。数据是面向主题的、集成的、不易丢失的并且是时间变量。数据仓库是所有操作环境和外部数据源的快照集合。它并不需要非常精确，因为它必须在特定的时间基础上从操作环境中提取出来。数据集市数据仓库只限于单个主题的区域，例如顾客、部门、地点等。数据集市在从数据仓库获取数据时可以依赖于数据仓库，或者当它们从操作系统中获取数据时就不依赖于数据仓库。事实事实是数据仓库中的信息单元，也是多维空间中的一个单元，受分析单元的限制。事实存储于一张表中（当使用关系数据库时）或者是多维数据库中的一个单元。每个事实包括

5、关于事实（收入、价值、满意记录等）的基本信息，并且与维度相关。在某些情况下，当所有的必要信息都存储于维度中时，单纯的事实出现就是对于数据仓库足够的信息。我们稍后讨论有关缺无事实的情况。维度维度是绑定由坐标系定义的空间的坐标系的轴线。数据仓库中的坐标系定义了数据单元，其中包含事实。坐标系的一个例子就是带有 x 维度和 y 维度的 Cartesian（笛卡尔）坐标系。在数据仓库中，时间总是维度之一。数据挖掘在数据仓库的数据中发现新信息的过程被称为数据挖掘，这些新信息不会从操作系统中获得。分析空间分析空间是数据仓库中一定量的数据，用于进行数据挖掘以发现新信息同时支持管理决策。切片一种用来在数据仓库中

6、将一个维度中的分析空间限制为数据子集的技术。切块一种用来在数据仓库中将多个维度中的分析空间限制为数据子集的技术。星型模式一种使用关系数据库实现多维分析空间的模式，称为星型模式。星型模式将在本白皮书中稍后进行进一步讨论。雪花模式不管什么原因，当星型模式的维度需要进行规范化时，星型模式就演进为雪花模式。使用 IBM Rational Rose 进行星型模式建模星型模式的基本形式必须实现多维空间（常常被称为方块），以使用关系数据库的基本功能。首先，我们需要理解多维空间。多维分析空间几何学中的方块是指一个三维空间，其中每个维度的尺寸都相同。想象一个立方体，每个维度都有三个单元，我们即得到相同结构的33

7、27个单元。图1 一个具有 x、y、z 维度的方块多维分析空间（或者数据仓库方块）与几何空间中的方块仅仅存在细节上的差异。维度不仅限于 3 维。不过，处理很多维度的立方体也不是件轻松的事情，这会导致大多数的实现被限制于 6 或者 7 维。不要期盼使用图形可以很好地表示超过 4 的维度-如果您有幸能发现一种方法，别忘了告诉我一下。 维度并不具有相同的规：偷ピ。规模从几个单元到几百万个单元，差别巨大。单元可以是一天、一位顾客、部门等。 单元，相当于子方块（111等），包含事实。 图2 一个三维数据立方体数据立方体需要很大的内存以存储所有事实。无论是否包含事实，都必须要预留单元。这就是为什么使用关

8、系数据库和星型模式的原因。使用它们能够优化存储并且保持数据结构的灵活性。星型模式星型模式的基本思想就是保持立方体的多维功能，同时也增加了小规模数据存储的灵活性。图3 一个星型模式在图3中，星型模式使用事实 Flight 表示了一个 4 维方块（Passenger、Menu、Flight Schedulet 和 Time）。基本上，事实必须指定一个维度，以将其放入立方体的单元中。我们的例子中的维度是：Passenger，描述了飞行航程中的每位乘客，由经常飞行号（frequent flyer number）指定。不是经常乘坐飞机的乘客不是数据仓库的一部分。 Flight Schedule，是指所有

9、常规飞行的日程。 Menu，是用于飞行的菜单。只有对菜单进行基本的分类才会对数据挖掘有重要意义。 Time，是指飞行的时间。 事实 Flight 描述了乘客在唯一的 Time 的单程飞行上选择 Menu。分析空间可以是完整的方块，或者我们可以根据维度将分析空间分割成小片。每个维度根据一个对象进行描述，对象可以用类表示，这些类就是有关业务主题的名称。这一点对于成功建立数据仓库来说是很重要的，因为仓库的用户（经理、分析员、市。┒杂谛畔⒓际醯氖跤锊⒉皇呛苁煜。事实本身就是商业智能的另一个对象，仍然通过类进行表示。事实指每个维度。事实与维度的关联常常是一对任意，这也就意味着每个事实都与单个维度的一个

10、单元准确对应，而维度的每个单元（每个Passenger、Time等）可以与任意数量的事实发生关联（包括0个事实）。使用 Rational Rose 将对象模型转换为数据模型即完成了星型模式的实现。这里我们可以看到转换后的结果。图4 使用Rational Rose实现星型模式在图4中，没有显示自动创建的主键和外键约束。星型模式的维度是独立的表。当对象模型转换为数据模型时，Rational Rose 可以生成维度的主键。事实表指从维度表中使用键迁移的维度，当生成数据模型时 Rational Rose 可以生成外键。在星型模式中切片和切块是对维度的限制（选择）。这是一个运行时问题，而不是建模问题，但

11、是模型必须分辨其需要。雪花模式基本的星型模式并不能满足数据挖掘的所有需要。我们需要更复杂的维度，例如时间。分析员希望根据周、月、季度等识别模式。维度必须进行规范化。我们不需要冗余的维度表，这只会使数据切片变得更加复杂。这种过程中我们得到的模式被称为雪花模式。我们来看一个简单的雪花模式例子。我们将时间维度规范化为周、月和季度。图5 规范化的 Time 维度我们希望能够使用附加的规范化维度将立方体切片：周、月和季度。在本例中，我们假定季度是月的平行层次，这也就意味着我们不能将季度假定为若干月的聚合。由于这个原因，我们将使用一张范化表（是对 OLAP 查询的一项简单附加）预先选择时间维度。最终雪花模

12、式添加了规范化维度。图6 带有范化维度的 Time 和事实 Flight 的雪花模式当然，所有的维度都可以像时间例子那样进行规范化，这就导致了比较复杂的数据集市模式的出现。由 Rational Rose 从雪花模式中开发的实现模式（数据模型）是完善的。图7 带有范化 Time 维度的雪花模式的数据模型创建的约束在图中也没有显示。雪花模式中可以存在切片，不仅仅在基本的 Time 维度上，也可以在规范化的 Week、Month 和 Quarter 维度上。多对多关系在一次飞行中，我们不仅仅只吃一顿饭。在长途飞行中可能要多次用餐。在这种情况下，我们认为事实 Flight 和 Menu 维度不是一对多

13、的关联。我们必须使用多对多关联。不过，这种关联不可能在星型模式中实现。雪花模式的一种特殊形式是使用一种必要的数据结构以满足这项要求。首先，我们将模型变更为事实和维度间的多对多关联。使用 Rational Rose，这只是关联基数的变更。图8 Menu 的多对多维度的星型模式我们无法在关系数据库中实现多对多关联。实现多对多关联需要使用另一种雪花模式。在下图中，我们关注一下已经开发的雪花模式的一部分，该部分处理多对多维度。图9 雪花模式解决了 Menu 的多维度Rational Rose 生成了附加的维度表 FlightMenu，它是指 Menu 维度和 Flight 事实。确定关系用于解决多对多

14、关联。对于雪花模式的架构师来说，最重要的一点就是识别多对多关系。简单对象视图可能会使设计员理解概念，而生成的数据视图有助于进一步深入有关实现的问题。层次数据挖掘可以从隐藏在操作系统表面下的数据中发现信息。我们想了解的一个问题就是选定菜单与乘客统计资料之间的依赖关系。乘客统计资料数据可以在 Passenger 维度的层次上构建。乘客可以根据邮政编码分组，然后再按国家进行分组。图10 乘客的层次层次通过使用聚合来指定。聚合定义了所包括的内容。Country 包含了 ZIP 编码，ZIP 编码包含了多名 Passenger 信息。最终通过使用外键实现了聚合。图11 雪花模式实现了 Passenger

15、 维度的聚合生成的约束仍然没有在图中表示出来。使用聚合，维度可以在任何定义的级别上使用。分析空间可以通过 Passenger、ZIP Code或者 Country 进行切片。一致的维度随着数据仓库架构师不断地添加细节内容，雪花模式变得越来越复杂。因此设计过程必须在到达某种程度后停止以保持数据仓库运行良好。星型或者雪花模式仍然仅仅关注于一个事实-在本例中就是Flight。那么复杂关系又是什么情况呢？对于每个事实我们都必须设计其各自的模式。如果我们想要进行复杂查询的话，它们就必须具有共同的维度-我们称其为一致的维度。让我们使用 Pilot 作为一个维度，PilotFlight 作为一个事实来定义第

16、二个星型模式。我们还要使用附加的 Flight Schedule 维度和 Time 维度。图12 Pilot 星型模式第二个模式可以单独使用或者与 Passenger 模式结合使用，从而根据使用一致维度的飞行员维度来查询 Passenger 的满意程度。图13 一致维度Time 和 Flight Schedule即使在使用一致维度的数据仓库的简单结构中，Pilot 与 Passenger 之间的关系也是简单的。在开发数据模型时，数据仓库将大量小型星型模式与雪花模式相结合形成了大型的数据仓库模式。事实与维度的数据我们想要评估乘客对于飞行的满意率。可以使用不满意到很满意几个级别进行评定。评定记录存

17、放在事实表 Flight 中作为一个属性（列）。如果我们想要得出一个平均记录，那么就必须为记录定义值以进行计算。我们可以将记录分为 0 到 10 级。这样就可以得到一个平均记录。平均值应该存储在维度表中，以用于简单的切片，其中我们只想进行一维切片。Rational Rose 根据目标数据库的数据类型生成了实现属性。对象模型是用来定义数据库的数据源的。结束语IBM Rational Rose 是设计数据仓库实现的最佳工具。对象模型定义了有关模式的全局结构的对象，和包括数据源的整体数据仓库。它代表了数据仓库中有关视图的对象，同时隐藏了实施细节。数据模型是数据仓库的实现模型。数据模型可以从对象模型中

18、生成，反之亦然。Rational Rose 是设计星型模式和雪花模式的最理想工具。Rational Rose 是灵活可调整的，足以支持任何所需的数据仓库的概念，同时也提供了数据架构师和数据库管理员需要的功能以对数据仓库进行调整。Rational Rose 为分析业务和开发用来实现数据仓库的需求提供了强大动力。附录资料：不需要的可以自行删除如何构建银行数据仓库数据仓库技术作为一项数据管理领域的新技术，其精髓在于针对联机分析处理(OLAP)提出了一种综合的解决方案，与以往很多技术不同的是，它主要是一种概念，在此概念指导下完成系统的构造。既没有可以直接购买到的现成产品，也没有具体的分析规范和实现方法

19、，也就是说没有成熟、可靠且被广泛接受的数据仓库标准。在以往关系数据库的设计和实现中，不仅有详细的理论推导，还有无数的设计实例，无论你使用的是什么公司的数据库产品、开发工具，只要按照规范做，那么实现同一业务需求的方案都会很相似。而现有数据仓库的实现中，出现了MOLAP方案和ROLAP方案的区别，出现了形形色色的数据仓库建模工具、表现工具，而设计人员的个人经验和素质也会在其中扮演很重要的角色。 数据仓库技术的实现方式 目前在数据仓库技术的实际应用中主要包括如下几种具体实现方式。 1、在关系数据库上建立数据仓库(ROLAP) 2、在多维数据库上建立数据仓库(MOLAP) MOLAP方案是以多维方式来

20、组织数据，以多维方式来存储数据；ROLAP方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表:维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP系统，系统性能成为最大问题。MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定义统计和计算方式，另外能保护在已有关系数据库上的投资。 由于两种方案各有优劣，因此在实际应用中，往往将MOLAP和ROLAP结合使用，即

21、所谓的混合模型。利用关系数据库存储历史数据、细节数据或非数值型数据，发挥关系数据库技术成熟的优势，减少花费，而在多维数据库中存储当前数据和常用统计数据，以提高操作性能。 3、在原有关系库上建立逻辑上的数据仓库 由于目前正在运行的OLTP系统中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。新建数据仓库固然能从功能、性能各方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数据仓库系统。尽管

22、由于原有OLTP系统设计上的局限性，这样的系统可能无法实现很多分析功能，但这样一个系统中数据结构固定、信息分析需求相对稳定成熟，因此数据仓库的建模、实现过程会相对容易、便捷；同时，这样的系统也会成为将来真正数据仓库建设的原型。 信息系统与数据仓库的关系 由于数据量大、数据来源多样化，在商业银行构建管理信息系统时，不可避免地会遇上如何管理这些浩如烟海的数据，以及如何从中提取有用的信息的问题；而数据仓库的最大优点在于它能把企业网络中不同信息岛上的商业数据集中到一起，存储在一个单一的集成的数据库中，并提供各种手段对数据进行统计、分析。因此可以说，在银行使用数据仓库构建管理信息系统，既有压力，又有数据

23、基。侵涞牧凳潜厝坏，难以割舍的。 数据仓库在商业银行的应用范围包括存款分析、贷款分析、客户市场分析、相关金融业分析决策(证券、外汇买卖)、风险预测、效益分析等。 在银行信息系统构建时，由于历史情况和现实需求的不同，存在两种途径: 1、建设新系统 由于目前国内商业银行对银行内部运营的监管，缺乏很好的数据搜集机制，因此可以在构建管理信息系统时，分数据收集录入和数据汇总分析两部分来考虑。这样的系统中由于不需考虑大量历史数据的处理问题，同时考虑到搜集过程中可能存在多个数据来源，因此可以在系统建设的同时构建数据仓库，将搜集来的各种数据通过数据抽取整合到数据仓库中。 2、完善原有系统 而对于已经

24、存在OLTP系统，其中沉淀了大量历史数据，则可以先在原有系统上建立逻辑数据仓库，即使用数据分析的表现工具，在关系模型上构建一个虚拟的多维模型。当系统需求稳定后，再建立物理数据仓库，这样既节省投资，又缩短开发工期。 实现中需要注意的问题 一、模型设计中的问题 模型设计(包括逻辑模型设计和物理模型设计)是系统的基础和成败的关键，在实际操作中，视实现技术的不同应分别对下列问题引起注意。 1、直接构建数据仓库 直接构建数据仓库时，必须按业务分析的要求重组OLTP系统中的数据，并要按不同侧重点分别组织，使之便于使用。 *主题的确定 主题是一个逻辑概念，它应该能够完整、统一地刻画出分析对象所涉及的各项数据

25、以及相互联系。划分主题的根据主要来源于两方面:对原有固定报表的分析和对业务人员的访谈。原有固定报表能较好地反映出以往工作对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。但仅仅满足于替代目前的手工报表还远远不应是构建管理信息系统的目标，还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。只有这样，才能真正了解构建数据仓库模型所需的主题划分。 *分析内容的细化 主题的划分实际上是与分析内容的范围直接相关的，一旦主题划分清楚了，下一步就是细化分析的具体内容以及根据分析内容的性质确定它在数据仓库中的位置。通常维元素对应的是分析角度，而度量对应的是分析关心

26、的具体指标。一个指标究竟是作为维元素、度量还是维属性，取决于具体的业务需求，但从实际操作中可以总结出如下的概念性经验:作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量的是连续型数据，取值无限。如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。 需要特别强调的是，在细化分析内容的过程中，务必解决指标的歧义问题。在不同报表中以及在业务访谈中同一名称的指标，是否是在同样条件限定下，通过同样方法提取或计算得到的，它们之间的相互关系是什么，这些问题都必须从

27、熟悉业务的分析人员那里得到准确、清晰的答案，否则将会影响到模型设计、数据提取、数据展现等多个方面。 *粒度的设计 数据仓库模型中所存储的数据的粒度将对信息系统的多方面产生影响。事实表中以各种维度的什么层次作为最细粒度，将决定存储的数据能否满足信息分析的功能需求，而粒度的层次划分、以及聚合表中粒度的选择将直接影响查询的响应时间。 如果同一个信息系统要在大范围、多层次上同时运行，如部门级和企业级，还应考虑不同层次的数据仓库采用不同的粒度。 *模型设计中的技巧 复合指标尤其是比率类指标的定义，必须注意累加时是先加减后乘除，还是反之。户数、笔数的计算，这类指标在分析或报表中经常出现，但不需要作为单独的

28、指标物理存在于数据库中，但定义分析模型时一定应该准备。度量的时间特性，针对分析指标在时间维上的不同表现，可分为可累加指标、半可累加指标和不可累加指标。 2、在原有数据基础上构建逻辑数据仓库 如果直接使用OLTP系统中的数据进行数据分析处理，会遇到许多麻烦，有时甚至是不可能实现的。这并不是说关系数据库不好，而是因为其设计思路不适应较大规模数据分析。因此在使用这种方法时，需要注意下列问题的处理: *不同的时间单位 这是实现过程中最常遇到的问题，也往往是最难解决的问题。OLTP系统中存储的时间往往采用与实际业务发生相同的时间单位，如帐务数据单位为日期，财务报表单位为月或半年。而面向分析时，往往要将不

29、同时间单位的数据统一到同一个结果中，这样就必须存在适当的转换机制才能实现。 *冗余信息 所谓冗余信息，就是指不同关系表中存在的同一含义的字段，而同一含义不仅指这些字段的取得或计算方式一样，还指它们成立的条件一样，例如截止某一时间同一地区的同一贷种的贷款余额。在OLTP系统中，这样的字段往往是基于性能考虑而设计的，而在面向分析设计模型时，为了保证结果的唯一性和准确性，就必须用且只用其中之一的数据产生分析结果。 *表间连接 由于OLTP系统中表的设计面向业务处理，既要保证数据的完整性、一致性，又要考虑响应时间，因此表与表之间既相对独立，又相互依赖。在设计数据仓库逻辑模型时，对表间的连接必须做出相应

30、取舍，既要保证分析数据能通过连接取得或计算出，又要避免出现环路，造成分析数据的歧义。另外，不同的连接途径还会出现不同的查询速度，影响数据分析的响应性能。 *统计表的设计 如果上述问题不能在原有数据库基础上得到很好的解决，那么权益之计就是构建统计表，即简单化的数据仓库，形式类似数据仓库的事实表，定时计算统计数据放入，将时间、冗余、连接等问题摈除，进行简单分析。 二、数据抽取中的问题 数据抽取是一件技术含量不高，但非常烦琐的工作，必须有专人负责数据抽取的工作。在对其进行设计时，要注意的问题有: 1、数据抽取的规则要作为元数据进行规范和管理，抽取过程中的源表、源字段、目的表、目的字段、转换规则以及转

31、换条件都要作好详细记录。这样不仅便于编程人员实现，而且在抽取规则或逻辑模型发生变化时也便于修改。 2、如何记录业务数据库中的变动情况是数据抽取中一个重要的环节。由于数据仓库中按时间保存数据，因此不同时间点之间数据的差异就成为一个关键性因素。通常可以利用数据库管理系统提供的手段在数据库级产生数据变动日志，根据日志再判断数据的变动情况完成抽。庋且桓龃有阅、可操作性以及对原业务系统的影响等多方面综合考虑都比较理想的方法。 3、当数据仓库中同一表中的数据来自于原有系统中不同的表，甚至不同的库时，抽取时务必保证这些数据单位一致，而且都满足同一时间条件。 4、数据抽取不仅要考虑数据的提。挂悸浅

32、取的时间安排和执行方式，这样才是一个完整的数据抽取方案，也才能保证抽取出来的数据准确、可用。 三、后期维护、优化中的问题 数据仓库的建设是一个长期工作，它同其他系统一样需要在运行的过程中不断进行调整、完善。这其中包括两方面的工作: 1、性能 数据仓库涉及海量数据的查询，数据的大量写入读出，不仅对数据库系统的要求很高，而且与OLTP系统的要求极为不同，因此在系统设计、实施和维护的过程中，数据仓库系统的性能都是一个不可忽视的问题。尤其是在运行期间，要密切关注应用对系统资源的消耗情况，针对应用的特点及时对系统进行调整，包括调整数据库参数、数据分片放置、创建特殊索引乃至提高系统配置等。 2、模型 应用

33、与需求是相互促进、不断发展的，随着信息系统建成运行，用户在对系统了解不断加深的过程中，也会对系统提出更新更高的要求。如何在最小投入的前提下满足用户的需求，也是一个值得注意和潜心研究的问题。首先要尽可能挖掘现有系统的潜力，其次考虑，对主题的增加或可在现有系统上增加少量指标就可解决的需求，对系统进行适当调整，最后才考虑对系统进行重构，尽可能减小系统建设中的投入。 数据仓库应用的深化 按照上述方法实现的应用中，主要完成了报表的生成和日常业务的分析，这并不能给企业带来真正的效益，也远远没有发挥出数据仓库的应用价值。随着应用的深入，可以由企业的技术人员与业务人员紧密配合，规划出对企业有实际价值的应用模型，并根据实际业务的发展不断调整模型自身的参数，以期找出企业运作过程中的规律，即在数据仓库上进行数据挖掘，构建DSS系统，这样才能充分体现构建数据仓库的意义，从而最终为企业带来效益。 尽管数据仓库技术还需要不断发展、完善，但只要企业能认识到信息分析的重要性，业务人员和技术人员能真正配合起来，相信不久的将来会有更多的实用成果出现。