複数の正規化モデル

http://martinfowler.com/bliki/MultipleCanonicalModels.html

大企業を一皮めくってみると、企業規模の概念モデリング(enterprise-wide conceptual modeling)を中心に扱うグループに出くわすでしょう。おそらくそれは、データマネージメントグループ(data management group)とかいうやつです。彼らは企業規模のサービス(enterprise-wide services)の定義に関わっていることもあります。 なぜ企業規模なのかというと、単一アプリケーションを中心に扱うよりも、複数のアプリケーションを統合することに専念しているからです。

こういったグループの多くは、単一の包括的企業モデルを構築することに集中する傾向があります。すべてのアプリケーションがこの単一モデル上で動くのであれば、全企業を横断してデータを統合することは、比較的簡単だというのです。ゆえに、ストーブパイプアプリケーション(stovepipe applications)を避けているわけです。 こういった考え方が、共通データベースアプローチによる企業の統合を導きます。単一の企業全体を論理的にカバーするデータベースがあり、それを共有しているアプリケーションの間で統合が起こる、という立場です。

単一の概念モデルを扱うのは厄介です。まず、きちんとモデリングするのが難しいのです（きちんと構築できるひとに会ったことがありません）。以前私が構築したときも、他のひとが理解しにくいものになってしまいました。こういった不満はよく耳にします。モデルはよいものの、誰もそれを理解することができないのです。これは極めて重要な問題だと思います。どんな大企業でも、大きなモデル、もしくは抽象的なモデル、あるいはその両方のモデルが必要となります。大きいということと抽象的ということは、どちらも理解しにくいということを意味します。

このところ多くの統合グループが共通データベースアプローチに疑問に抱いており、代わりにメッセージベースアプローチでの統合を好んでいます。このアプローチは、理論的にベストなアプローチではないかもしれませんが、統合の現実的な問題（特に政治問題）をちゃんと認識しています。こういった意味で、私はこの意見に賛成です。

面白いことに、メッセージベースアプローチによる統合では、統合を下支えする単独概念モデルがもはや必要ではなくなります。同僚の Bill Hegerty と話していて、以下のことに気づきました。

• たったひとつではなく、複数の正規化モデルを作ることができる。
• これらのモデルは重なり合うこともある。
• モデル間の重なり部分は、同一構造を共有している必要はない。その代わり、重なっているモデルの部分は互いに変換されなければならない。
• モデルは、すべてを表現する必要はない。アプリケーション間のやりとりに必要なところを網羅しさえすればよい。
• これらのモデルは、前もって計画されるのではなく、結果を基に構築される。複数のアプリケーションはペアになってやり取りを行うため、n * n 変換パスを正規化ハブへの n パスに変更するよう正規化モデルを導入することができる。

この結果によって、モデリングの問題点は分解されました。技術的にも政治的にも、シンプルになったように思います。

ただ、現段階では、データモデリングコミュニティはこの新しいやり方を使い始めたばかりなのです。悲しいことに、データモデラーたちは、ものすごい勢いで正規化メッセージングモデルを作るよう仕向けているのです（★微妙）。 単にスキルが足りていないからという理由からだけではなく、このアプローチに反対している人も多くいます。そういった人々は単一の企業規模モデルこそが、統合の基盤にふさわしいものだと主張しています。