複数正規モデル

大企業の内部をのぞいてみると、たいてい何らかの企業全体の概念モデル中心のグループが存在します。多くはデータ管理グループで、まれに企業全体のサービスの定義を担当している場合もあります。単一のアプリケーションに焦点を当てるのではなく、それらは複数アプリケーションの統合に重点を置いているため、企業全体にまたがっています。

そのようなグループのほとんどは、単一の包括的な企業モデルの作成に重点を置いています。この単一のモデルに基づいてすべてのアプリケーションを運用すれば、企業全体でデータを統合するのがはるかに簡単になり、サイロ化アプリケーションを避けることができます。この考え方の多くは、企業統合に対する共有データベースアプローチに従っています。このアプローチでは、アプリケーションが1つの論理的な企業全体データベースを共有することで統合が行われます。

単一の概念モデルは、扱うのが難しい厄介なものです。まず、うまく行うのは非常に難しいことです。私は、このようなものを構築できる人にほとんど会ったことがありません。単一のモデルを作成できたとしても、他の人が理解するのは困難です。モデルは確かに優れているのに、ほとんどの人が理解できないという不満を何度も耳にしてきました。私は、これが不可欠な問題であると考えています。大企業には、非常に大規模、抽象的、またはその両方のいずれかのモデルが必要になります。そして、大きさと抽象性の両方が理解の難しさを示唆しています。

今日、多くの統合グループは共有データベースアプローチに疑問を呈し、代わりにメッセージングベースの統合アプローチを支持しています。理論的には最適なアプローチではないものの、統合の実際的な問題、特に政治的な問題をより深く認識しているという意味で、私はこの見解に同意する傾向があります。

メッセージングベースの統合アプローチの興味深い結果の1つは、統合の基盤となる単一の概念モデルがもはや必要なくなることです。同僚のビル・ヘガティと話をしていて、私は気付きました

• 単一の正規モデルではなく、複数の正規モデルを持つことができます。
• これらのモデルは重複する可能性があります
• モデル間の重複は同じ構造を共有する必要はありませんが、重複するモデルの部分間には変換が必要になります
• モデルは表現可能なすべてのものをカバーする必要はなく、アプリケーション間で通信する必要があるもののみをカバーすれば十分です。
• これらのモデルは、計画的に前もって構築するのではなく、収穫を通じて構築できます。複数のアプリケーションがペアで通信すると、正規モデルを導入して、n * n変換パスを正規ハブに変換するnパスに置き換えることができます。

結果はモデリングの問題を分解し、技術的にも政治的にもそれを簡略化したと考えています。

しかしながら、これまでのところ、データモデリングコミュニティはこの新しい世界を捉え始めたばかりのようです。これは悲しいことです。なぜなら、データモデラーは正規メッセージングモデルを構築する人々に非常に多くのものを提供できるからです。この活動に参加していないスキルがあるだけでなく、統合の唯一の適切な基盤は企業全体の単一モデルであると主張するため、多くの人がこのアプローチに抵抗しています。