如何构建及分发BI报表

作者：

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 一旦最终的维度结构里面有了实际数据、商业智能工具已经被选择，就需要开始进行商业智能应用的开发。 建立开发环境 一旦有了实际数据，人们总忍不住想马上开始构建报表。但在开始创建报表之前，先要花几天时间建立报表环境，弄清楚整个报表流程。开始先要建立开发环境、创建标准的报表模板。 如果是头一回使用前端工具，就要留意了：安装和配置需要的工作量可能会超过原先的预计。许多报表环境有几个部分，包括开发工具、报表查看器、管理工具以及报表服务器。难上加难的是，报表服务器经常只有安装在自己的机器上时工作效果才最好，而且通常要与Web服务器密切合作。在一些情况下，报表服务器需要数据库或者文件目录来保存有关报表、计划表、事件和分发列表的元数据。确保已把该数据库包括在日常备份工作当中。另外，可能还需要设置另一台测试服务器来支持测试过程，这要取决于用户的商业智能环境的规模和复杂性。 对新的抽取、转换和加载（ETL）项目来说，最佳办法就是根据测试系统来进行开发，以保护生产环境不会出现表锁定和数据消失等问题。这种方法还可以加快及简化开发过程。另一方面，在商业智能报表开发过程中，直接根据生产环境的数据仓库/商业智能数据库来开发报表，这通常是明智之举。这样一来，生产系统受到消极影响的风险性比较小：报表是只读的，通常类似数据库的其他任何特定使用。如果数据仓库/商业智能数据库是为了支持特定查询而设计的，它应当支持报表开发。根据生产数据库构建报表，这提供了及早评估性能、验证报表的机会。这还简化了把报表移到生产环境的过程，因为这些报表已经连接到生产数据库了。 除了安装工具组件外，还需要在开始着手之前采取其他步骤。一些前端工具可能需要定义把用户和数据库隔离开来的元数据层、建立元数据分发和通知的流程以及使用跟踪系统。 创建报表 如果已经做好了准备工作，弄清楚从哪个报表开始着手很简单。正如前文所描述的那样，来自设计阶段的规格包括：按优先级顺序划分的标准报表组成的列表，以及有关报表定义和内容的模型和文档说明。先从列表上的第一个报表开始，其他报表依次类推。 创建报表的第一步就是，定义可填充报表内容的一个或者多个查询。报表规格往往需要由用户提供的查询约束条件，大多数约束条件会利用标准模板里面已经含有的选择列表和参数。在一些情况下，报表可能需要多个数据集。譬如说，一个事实表（fact table）里面可能有收入数据，另一个事实表里面可能有成本数据。为了表明产品的利润，可能需要两个不同的查询来合并这两个数据源。前端工具需要结合两个结果集，那样才能计算出收入扣除成本后的值。 一旦数据集定义完毕，下一步就是根据规格来安排报表内容。这意味着确定哪些元素进入行和列、在报表里面进行哪些计算、应当如何编排报表的格式。准确创建报表所需要的时间可能比想象的要长。还要确保使用了各种分发格式来预览报表，譬如电子表格、PDF、Web、电子邮件和打印。 编排报表格式的指导准则就是，它们应当尽量清晰、不需要加以说明。用户可不愿花时间去别处寻找报表文档说明，也不应该指望他们这样做。确保报表清晰是数据仓库或商业智能队伍在创建标准报表时面临的主要难题之一。不妨在设计模板及初始报表集时请来在图形设计方面有着深厚功底的人。也可以试试其他办法，征求用户的反馈意见，看看哪种方法最有效。在这个阶段多做一点工作会在以后得到巨大回报。 测试准确性和性能 开发过程包括对各种组合的参数进行测试，确保报表返回正确的结果。测试报表内容，以确保计算和约束条件正确无误。检查数字时尽量要认真，把它们与任何已知的其他数据源进行比较，确保就是同一信息。如果数字应当相同，但实际上不同，就要查明原因。如果数字因为在ETL过程中得到改善或者纠正而不同，就要把为什么不同的原因认真记入文档。可能的话，还要标明用户或者审查人员该如何把数据从数据仓库返还到其他数据源的方法。商业智能门户里面应当会有这样的文档说明，报表描述应当提到它。 在大组织里面，由于成千上万的用户不断使用标准报表集，因而有必要把报表部署到与生产环境尽可能类似的测试服务器环境。测试服务器让报表队伍可以对新报表进行压力测试，确保它们不会降低其他报表的性能，然后再把报表移到生产环境。 在中小型组织里面，可能不需要完整的测试服务器环境。报表队伍可以把报表部署到生产报表服务器，然后在上面测试。可以限制对测试报表目录的访问，并且直到测试完毕才把新报表发布到商业智能门户里面，从而尽量减小风险。 这里分几个测试步骤，首先是把项目部署到测试或者生产报表服务器。然后，需要对报表进行审查，确保显示和打印格式合适。如果不是预期的那样，试试增强性能的方法，譬如调整查询、创建报表快照，或者更改服务器配置。要认真重新测试，因为大多数用户在使用数据仓库或商业智能系统时惟一体验到的就是报表。 部署到生产环境 下一步就是把新报表集成到生产流程当中。报表规格应当表明该报表是根据需要执行，还是缓存在基于时间或者基于事件的计划表上。具体如何建立这些程序取决于报表的操作环境。作为部署过程的一部分，应当为系统如何分发报表明确相应指示：把结果缓存起来以便迅速为将来的查询提供结果；用电子邮件把报表发送到分发列表；或者把报表保存到文件系统或者数据库里面。可能需要建立订购流程，好让用户可以选择他们想要经常接收到的报表。如果借助商业智能门户提供报表，需要把这一组新的报表集成到门户里面，这是部署到生产环境的一个环节。 一旦部署到了生产服务器，就需要重复刚才完成的许多步骤，以便把报表移到测试环境，包括计划表、快照、订购和电子邮件分发列表。然而在大多数情况下，部署到生产环境是在测试这个步骤进行的，因为这一步能够揭示更多的信息，如果主要报表接口是通过网站或者门户来实现，更是如此。这种情况下，部署其实更改了安全设置，以便可通过门户访问报表。 管理和维护 一旦商业智能应用投入使用，数据仓库或商业智能队伍就必须让它们保持最新、处于工作良好的状态。随着企业不断发展，一些报表往往变得过时。一旦新产品停止生产，那么为了跟踪该产品而创建的报表再也不受人关注了。报表往往会因为技术原因出现问题。譬如说，技术人员可能会对数据库进行改善，结果导致报表出问题，但可能要到监控报表服务器日志、定期检查结果时，才会意识到这个问题。 由于人员流动频繁，数据仓库或商业智能队伍必须添加及删除涉及个别用户和电子邮件列表的数据驱动型订购。其他分发机制也是如此，譬如文件共享。因为计算机和网络经常会发生变化：会计部门可能要求一组报表分发到其文件服务器上。然后，它买来新的文件服务器，没有告诉技术部门，就关闭了那台旧的文件服务器。这样一来，一组用户就可能收不到所请求的报表了。 扩展应用范围 数据仓库或商业智能队伍还必须提供日常的报表开发资源，要预料到面向新的业务流程维度模型的初始报表和商业智能应用很快就会得到修改及增强。除非近距离展示给用户看，否则他们并不总是知道自己需要哪些报表和分析。然后他们会告诉技术部门他们不需要什么（可能就是技术部门刚创建的报表）。 数据挖掘应用及其他闭环系统很少在数据仓库或商业智能系统的第一个阶段加以实施（除非它们在投资回报分析中可以证明能够带来回报）。开发闭环商业智能系统的过程需要业务人员和数据仓库或商业智能队伍密切合作：前者能够有效地开发业务规则和分析模型，而后者负责编写系统规格、最终确定模型。大部分应用开发工作需要一系列的标准技能，从事操作系统开发的那些开发人员则往往具备这些技能。开发人员需要比较少的专门知识——面向数据挖掘系统的对象模型，就可以对数据库或者数据挖掘模型进行调用。 每过一年到一年半，就要审查整个商业智能系统。评估哪些部分对用户来说运行良好，哪些应当变化。记住，变化是不可避免的，变化也表明系统状况良好。作为这个周期性评估工作的一部分，要考虑更新商业智能门户的外观、布局和内容。 ★ 小经验 报表复制有风险 数据仓库商业智能队伍把一组报表从旧系统复制到新的报表环境，这很常见。虽然这可能很必要，也很合理，因为这样就可以弃用旧环境，但复制现有报表很少具有太大的明显意义。提供给用户的东西，他们都已经有了。此举也具有风险，因为旧报表里面往往嵌入了复杂、没有详细说明的业务规则。准确地复制报表要比想象的困难得多。 如果非要复制一组现有的报表，就要与业务部门合作，共同确认最重要的遗留报表，不过也要添加能够让用户感兴趣、带来更多商业价值的新报表。 让用户参与报表构建过程 如果用户已经知道前台工具或者能够迅速学会，那么商业智能应用开发过程是让他们直接参与数据仓库或商业智能系统建设的大好机会。让重要用户参与进来有几个充分理由。首先，这让这些用户有机会尽早了解相关的工具、方法和数据。其次，一起合作有助于建立更牢固的关系。可能的话，建立测试环境，加入所需要的大量工作站。每一两周，就安排小组定期开会。这些重要用户的早期参与表明了他们具有特殊地位，这有助于让他们树立起自己是报表及整个数据仓库或商业智能系统的主人这种观念。 (end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (10/9/2006)