BI搜索有何不同

　　把搜索范围扩大到BI领域之所以比较容易，原因之一就是用户已经知道了搜索他们熟悉的基于Web的搜索引擎。只要稍加培训，用户就能学会如何使用额外选项，这些选项类似Web引擎上的高级搜索特性里面的选项。

　　然而，企业搜索背后发生的一切与Web搜索引擎的运作大不相同。如今，大多数Web查询针对的是非结构化数据，譬如HTML、PowerPoint演示文档和PDF文件。因为这些资源面向文档，所以引擎会对数据具有的意义及相关性作出智能决策(网页甚至有特殊标签，以方便这个过程)。

　　相比之下，结构化数据一般不提供这种上下文信息。打开数据库，看到名为“零件”的一列数字，对这个数指什么(零件号、成本、库存、位置及其他信息)知之甚少。使用元数据最终可以解决这个问题； 通过支持数据库里面的XML，这个问题已得到了解决； 但至于如今绝大部分的结构化数据，根本就没有简单的解决方案。

　　BI软件通过使用模板以及经过培训的分析人员定义的数据关系，从一方面解决了这个问题。正因为如此，如今的许多企业搜索引擎如Google和X1把搜索结构化数据的任务交给了BI软件，然后把结果与来自搜索索引的条目进行联合(即合并)。

　　非结构化数据有自己的难题。第一个就是数量巨大。IBM的信息管理战略项目主任Mark Andrews指出，每个企业用户每个工作日通常需要处理(包括收发)70封电子邮件。如果一家公司有25000名员工，那么每年有近5亿封电子邮件需要保存(为了符合法规遵从)，而且能够易于搜索。另外还有其他格式的各种文档(HTML、文字处理、电子表格和演示文档)，用户会面临严重的存储问题，这本身就是另一大难题。由于许多搜索返回成千上万的结果，如何评定结果的相关性？

　　Google企业部门的产品主管Matthew Glotzbach说: “不像Web搜索，你通常没有试图蒙骗算法的垃圾邮件发送站点，但也没有大量的使用数据(Web和应用服务器自动收集的有关用户访问行为的日志数据)来指导你。”但Google并没有透露它使用何种算法。

　　IBM比较愿意透露自己的算法，它在企业搜索中使用混合的权重因子来评定相关性，其中包括: 用户点击模式、某条目在文档中的格式及位置(标题的相关性高于文本里面的条目)以及元数据(链接内文本的评定不同于文档正文内的类似文本)等等。

　　如今的大多数产品提供了一种方法，可以增加某些文档或者URL的相关性，以便在特定搜索中占据头名位置。(譬如说，“性骚扰”查询经改动后，可以确保公司策略总是返回的第一个条目。)此外，许多产品能够对特定公司的语言进行定制。这样搜索引擎就可以知道: “Region 1”方面的查询是指查询东部安全第一

　　访问功能是BI搜索的核心方面。这个问题分为两方面: 员工如何访问报表所需的所有数据？如何阻止员工查看机密数据？在理想情况下，单次登录(SSO)可以解决第一个问题，使用轻型目录访问协议(LDAP)服务器可以解决第二个问题。问题在具体实施上: 大部分数据位于访问控制并没有得到企业访问机制严格定义的系统上。

问题的实际情况更为糟糕。IBM数据管理部门的工程师Maxime Tiran说: “如果公司的IT部门建立了可以搜索整个企业的工具，他们经常会惊讶地发现: 可以到处访问内联网上的许多机密数据，而且这些数据完全未加保护。”

　　厂商提出的安全方案各不相同，考虑为BI添加搜索功能的网站需要明确自己考虑使用的产品如何处理访问控制。许多产品只是把用户证书传送给BI软件包或者其他后端软件，依靠这些软件，根据内置的访问机制来限制返回结果。Oracle的安全企业搜索产品在这方面做得特别好。

　　初露端倪

　　Information Builders公司负责企业战略的Michael Corcoran预测，BI和搜索的集成会越来越紧密。搜索引擎能够更有效地访问BI数据，BI公司会为这个过程提供方便。譬如说，Information Builders如今从处理中的交易获得数据后，可以提供给Google的企业搜索引擎。

　　Information Builders的一个部门提供大约300个可以查询数据源的连接件，正在积极使用以扩大搜索功能及其BI产品的应用范围。Corcoran说: “更紧密的集成对用户确实会有所帮助。如今，BI仍需要用户知道数据在何处。譬如说，用户仍必须指定‘呼叫中心的数据’。不过，所需数据可以在任何地方，用户也用不着知道来源就能够找到数据。”

　　IBM的Andrews说，下一步需要集成分析功能和搜索功能，能够以各种方式查询数据，寻求可以增加销售额、提高效率的市场机会。不过眼下，只要能更好地访问目前生成的商业信息，大多数企业也就心满意足了。沿海地区。