BIの周辺技術
パーティション
前回までで、現在に至るまでのBIシステム・アーキテクチャの移り変わりと、主な技術要素を解説してきました。しかし、この中で触れなかった重要な技術要素がいくつかあります。例えば、第1回の最後で軽くふれたパーティション、サマリー・テーブル、OLAP、多次元データベースといったものがそれです。第3回の今回は、これらのBIシステムに欠くことのできない周辺技術を説明します。
BIの発展とともに、RDBがDWH（データ・ウエアハウス）に用いられるようになり、特にDWH用途で求められる機能の強化が行われてきたことは既に述べたとおりです。ここでは、このような背景の下でRDBに加えられた機能のうち、パーティションとサマリー・テーブルという2つの代表的な機能について解説します。
DWHの標準的なデータベース構造であるスター・スキーマにおいて、もっともレコード数が多くなるのがファクト・テーブルです。ファクト・テーブルのレコード数の増大は、しばしばDWHの検索性能の低下をもたらします。この性能低下を、ファクト・テーブルをパーティションと呼ばれる区画に分割し、特定の区画のみを検索対象とすることで防止するのが、パーティション機能です。
パーティション機能には、いろいろな実現方法がありますが、それらの中でもっともDWHで用いられるのが、レンジ・パーティションと呼ばれる方法です。例えば、ファクト・テーブルの年月日カラムに対して、1つの年月ごとにパーティションを設定します。こうすることで、要求されたクエリーが特定の年月を持つレコードを対象とする場合、RDBのエンジンは自動的に、その年月のパーティションのみを検索対象とします。これにより、例えば5年（60カ月）分のレコードを含むファクト・テーブルに対する検索は、理論上60分の1に短縮されることになります。
2010年3月時点でパーティション機能を搭載している主なRDB製品は、図1-1のとおりです。
サマリー・テーブル
DWH用途で追加された機能のもう1つが、サマリー・テーブルです。DWHにおいてRDBに要求されるクエリーでは、レコードを選択する以外に、集計を行う場合が極めて多くなります。この集計にかかわる性能の向上をもたらすのが、サマリー・テーブル機能です。
サマリー・テーブル自体は、一般的なアプリケーション開発で用いられる手法です。例えば、月ごとにレコードを持つ販売実績ファクト・テーブルについて、四半期ごと、年度ごとといったより粗いレベルの粒度で集計されたテーブルの作成をプログラムで実現するということです（図1-2）。
しかし、この方法では、実際の検索の際にサマリー・テーブルにアクセスするためには、検索プログラムで明示的にこのサマリー・テーブルを指定することが必要になります。このような制限はプログラムの複雑性を増すだけでなく、保守性にも大きな影響を与えます。
これに対して、RDBに実装されたサマリー・テーブル機能とは、結果として作成されるサマリー・テーブルは同種のものとなりますが、その作成・更新はRDBによって管理されます。RDBに対して検索の要求を出す際に、サマリー・テーブルを指定する必要がありません。
これは、RDBのサマリー・テーブル機能が、検索の内容を識別し、適切なサマリー・テーブルを使用するよう自動的に検索内容を再構成する、クエリー・リライトという機能を持つためです。
2010年3月時点で、サマリー・テーブル機能を搭載している主なRDB製品は図1-3のとおりです。
