栗原潔の“エンタープライズ・コンピューティング新世紀” 第15回

エンタープライズサーチの真の価値を探る(5)――サーチとBIとのもうひとつの関係

　前回は、BIシステム内のさまざまなオブジェクト（レポート、グラフ、クエリーなど）を、サーチエンジンのクローラーから見えるようにすることで、BIをサーチの世界に取り込むことができ、大きな価値が提供できる可能性があると書いた。これは、BIが、かつてはまったく異なる世界と考えられていたサーチ側に歩み寄っているパターンだ。今回は、いわば、その逆方向、すなわち、サーチがBIに歩み寄るパターンについて考えてみたい。

実はよく似ているサーチとBI

　よくよく考えてみればサーチもBIも基本的な処理パターンは似ている。ユーザーが必要とする情報をシステムに要求すれば、システムが結果を返してくれるというものである。BIの場合には通常、RDBMS、場合によってはMDBMS（多次元データベース、いわゆるキューブ）に情報が構造化された形で格納されているが、サーチの場合には、情報自身は構造化されておらず、それとは独立したインデックス内に情報へのポインターが格納されている──というように仕組みが異なっているだけだ。

　もちろん、BIには定量的な分析処理という局面がある。統計的で複雑な計算処理を行なう利用法である。

　これは、サーチの範疇の外部にあると考えて良いだろう。しかし、現実にBIと呼ばれているアプリケーションの中には、データ検索に限りなく近い利用法のものも多いだろう。単に、企業や製品の名称やコードなどを入力して必要な情報を得るというパターンのアプリケーションだ。

　実はこのようなタイプのアプリケーションは、RDBMSで実装するよりもサーチで実装した方が効率的であることが多い。実際、RDBMSベースの実装をサーチエンジンベースの実装に変更したことで、大きくパフォーマンスを向上できた金融機関の事例もある。

ETLにもサーチのテクノロジーが利用できる

　もう一点、BIとサーチ関連で興味深い動向のひとつが「Extract Transformation ＆ Load」(ETL:抽出・変換・ロード）だ。

　ETLは、その名の通り、さまざまなデータソースからデータを抽出し、必要な変換を行ない、データウェアハウスやデータマートにロードする処理のことを言う。BI系のアプリケーションは何らかのかたちでETLの処理が必須だ。

　ETLにおいてやっかいな問題のひとつに名寄せの問題がある。現実の企業情報システムにおいてはデータベースの内容が常に完全に正しく、整合性が取れているとは限らない。同じ企業を表すデータであっても、「（株）テックバイザージェイピー」「株式会社テックバイザージェイピー」「テックバイザー株式会社」（これはデータが誤っている例）などさまざまなパターンがあり得る。これをひとつのデータとしてまとめることができなければ、正確な情報分析などできるはずもない。

　実は、このような複数の文字列間の類似度を評価するアルゴリズムはサーチエンジンの得意とするところだ。あいまい検索や検索結果のランキング評価において、文字列の類似度を高速に評価しなければならないからだ。このアルゴリズムを活用して、ETLに必須の名寄せ処理を効率的に行なうことができる可能性もあるだろう。