Inmon vs.Kimball:分析的視点の違いのレビュー

データと分析の世界は常に進化しています。 その単純な日では、典型的なデータ組織は、いくつかのファイル、アプリケーションまたはトランザクションデータベース、データウェアハウス、およびレポーティングデータマートで構成されていました。 データソース、ボリューム、生成速度、収集プロセスが長年にわたって増加しているため、今日のコンピューティング環境では、組織が意思決定の基礎となるパターン、傾向などを明らかにする非常に大きなデータセット(一般に”ビッグデータ”と呼ばれる)に対処する必要があります。

今日のほとんどの組織には、図1で示されているリファレンスアーキテクチャで強調表示されているコンポーネントのすべてではないにしても、多くのコンポーネントがあります–アプリケーション、システム、およびソース、データ転送、エンタープライズデータレイヤー、データサービス、分析、およびレポート、および高度なデータ処理。

図1-Complex Reference Architecture

data warehouseとmartsは28の可能なコンポーネントの一つとして表されているため、一見するとどのように画像に収まるかを理解することは困難です。 しかし、ほとんどの組織は現在、データウェアハウス以上のものに関心を持っています–図1に示すような複雑な環境を凝集的に管理する必要があり

KimballとInmonアーキテクチャは、どちらも複雑な参照アーキテクチャの開発を支援するフレームワークを提供しています。

二つのアプローチのクイックリフレッシャー

キンボールまたはインモンパターンを適用する前に、二つのアプローチの違いを見直す価値があります。 図21と図32では、それぞれの視覚的な表現を確認してください。

それぞれのモデルの創始者であるキンボールとインモンの作品は、お互いに挑戦しました。 両方のアプローチは、主にデータモデルの開発サイクルによって駆動されますが、モデルはボトムアップまたはトップダウンアプローチのいずれかのひたむきな焦点に基づいています。 これらの緊張は、全体的なデータストレージと分析環境の開発で発揮されました。

図2-視覚的なキンボール

View図3-Visual Inmon View

Kimballアプローチは、データウェアハウスとデータマートがビジネスプロセスとビジネス質問によって駆動されることを示しています。 これに対する明白な危険は、定義されているビジネスプロセスに収まらないため、有用なデータが必ずしも分類またはキャプチャされない可能性があ

Inmonアプローチは、メーター、請求書、資産など、トピックの周りのすべてのエンティティに対して設計された論理モデルを持つエンタープライズデータウェアハウスの作成を示します。 課題は、主要なトピックは差別化を表すことができますが、それらをサポートするエンティティは、失われる可能性のある共通性を表す

たとえば、サービスの場所で表されるメーターの場所、請求書で表される請求先住所、および資産の在庫場所または展開場所は、すべて共通の属性を共有で Inmonの下でさえ、サービスの場所、請求先住所、資産、在庫の場所、および資産の展開の場所は、異なるデータマートを持つ組織内の異なる業種をサポートすると考えら

InmonとKimballの両方のアプローチは、概念的なデータモデルを開発し、物理化された形でデータモデルを実装するサイクルによって駆動されます。 このサイクルは、より機敏な開発アプローチをサポートすることができますが、研究の線形性（プロセスまたはエンタープライズトピックに基づく）、概念モデ

次のステップを踏む

アジャイルプロセスは、このタイプの開発活動にサイクルを注入することを困難にする可能性があります。 すべての組織にとっての課題は、InmonとKimballのアプローチから学んだ教訓を取り、新しい文脈でそれらを適用することです。

複雑な環境にパターンを適用する方法の詳細については、このブログシリーズの第二部で来てください–お楽しみに！

それまでの間、企業情報管理（EIM）の正常な実装に関する最近の投稿をチェックしてください。