第4回：データウェアハウスアーキテクチャ(3)：データボルトモデリング

今回は、３つ目のデータウェアハウスアーキテクチャ、「データボルトモデリング」について説明します。以前紹介したインモンモデルやキンボールモデルほど有名ではありませんが１つの考えとして重要なアーキテクチャなので紹介したいと思います。

データ統合せずにそのまま格納する
データボルトモデルの特徴を一言で言えば、すべてのオペレーションシステムから来たデータをそのまま保管するモデリングです。そのままデータを保管するところがポイントです。そのまま保管する理由はもし後で使用がかわった場合に元データがあるのでそれをもとに再構築できるからです。また、最近のオーディットの対応としてもデータが追えるという点で非常に優れています。

今までとりあえず、万が一のためにローデータをファイルで保管していた会社は多いと思いますがいざとなったら使わないし、どういうデータ構造になっているかもわからないで有効に活用できていなかったので現状です。

そこで、データボルトモデリングです。これを利用すれば、リレーショナルデータベースに保管できるので、いざというときに利用できます。確かにすべてを保管するとデータ量が多くなりますが近年ハードは安くなっていますし、データの圧縮技術も進化しています。また、データ分散の技術も進化していますので、ある程度大きな会社であれば、これらの問題は解消できると思います。

モデリングの詳細
では、データボルトモデリングについて説明します。データボルトモデリングは次の３つのコンポーネントから成り立っています。それはずばり、Hubs ハブLinks リングSatellites サテライトの３つです。
それでは１つずつ簡単に説明していきます。

Hubsとはデータの大きな固まりを表したものです。例えば、顧客とか店舗などになります。

次にLinksです。リンクはHubsとHubsのリンクを管理するテーブルです。データボルトモデリングは柔軟性を持たせるために普段はERで定義するリレーションをリンクテーブルで定義しています。これにより第３正規形ではテーブルの設計変更が発生する場合でもリンクのデータをかえることにより柔軟に変更に対応できます。

最後にSatellites.これは通常にデータの属性を保持するテーブルです。もちろん、ハブとリンクさせるのですが、１つのHubやlinkはサテライトを複数持つことができます。

例えば、既存システムで顧客情報をマーケティングシステムおよびセールスシステムのそれぞれで持っていれば、データボルトモデリングでは名寄せやクレンジングはせずにサテライトをそれぞれ１つずつ作って、顧客ハブの下にそれぞれもたつことができます。これですべてのデータをそのまま保持できるのです。

まだ、詳しくは調べていませんが、この設計によりETLの処理もある程度パラレルで処理ができるので高速で処理ができるようです。

ビックデータを保持する時代この技術は非常に有効だと思います。