企業統一データベースの実装リスク

ER

アーキテクチャジャーナルの８号「データ統合の柔軟なモデル」で良い記事があったのでメモがてら紹介。*1

複数のシステムでばらばらにもっているデータを１つに統合するというアイデアは昔からよく言われているが実際の構築は非常に難しい。これは、個々のシステムで利用するデータや拡張性などが違いあるためだと感じていた。

この点について、「データ統合の柔軟なモデル」では企業統一データベースの利用を企業データの統一サービスとしてとらえいくつかの失敗要因をあげ、実装の課題と緩和策を考察している。

  1. 必要情報が多すぎる
  2. 効率的なバージョニング戦略がない
  3. システムレベルの拡張性がサポートされていない

必要情報が多すぎる

これは、統一サービスが要求する必要条件（情報や厳密度）が高いと統一サービスを採用するための敷居が高くなったり、変更に敏感になったりしたりする。統一サービスのスキーマを緩やかにすることで柔軟性を与えることができる。

効率的なバージョニング戦略がない

統一サービスのスキーマの変更は避けられないもので、すべての利用システムが一度に移行することは難しい。各システムの移行に関係なく、統一サービスのスキーマやデータベースの構造を発展させることができる戦略が必要になる。(ポステルの法則「他人から受けとるものには寛容であれ。自分が送るものには保守的であれ」)
統一サービスのスキーマに新しい項目が追加されても、古いバージョンのスキーマを利用しているシステムは追加項目を無視するだけで問題なく処理できるような仕組みを提供し、クライアントの更新せずにスキーマを拡張できるようにする。(Must Ignoreパターン)

システムレベルの拡張性がサポートされていない

個別システムのスキーマに対するシステム拡張がサポートされていないと、特定のスキーマの更新を必要とするシステムが、統一サービスが更新されるまでまたなければならない。解決策は、統一サービスを利用するシステムが独自の追加情報を利用して拡張できる仕組みを用意する。さらに、他のシステムでも拡張されたデータを利用できるようにするためには、１つの方法として拡張したデータをXMLして、拡張データ用のスキーマを定義して他システムでも利用可能にするアイデアがある。

属性名、値のペアでデータベースに保存する拡張プロパティの利用も有効ではないかと個人的には考える。値はXMLで表現することで任意のデータが表現可能。

*1:特に深い意味はないですが、一部用語を原文とは故意に変えています