さまざまなデータソースを組み合わせて、レポート要件に役立つデータウェアハウスを作成し始めました。OLTPアプリケーションデータウェアハウスデータ設計を読む
データの潜在的用途を一度まとめてみると、トランザクション処理システムのいくつかがこのデータを有用な方法で参照できるシナリオがいくつか見出されています。当然のことながら、データは期限切れとなり、読み取り専用に最適化されますが、アプリケーションによってはこのシナリオでは問題なく、コアサーバーの負荷が軽減されます。
私の質問は、トランザクションシステムがデータウェアハウスに格納されたデータにアクセスするのは悪い設計と考えられますか？明らかに、私たちの倉庫の主な目的は報告です。これは、他の非報告システムがデータを読み取ることを許可するべきかどうかに疑問を投げかけています。私の本能は、アプリケーションがデータを読み込んで表示することを許可しないように私を誘導します。彼らに耳を傾ける良い理由はありますか？
OLTPシステムがDWデータにアクセスするのに間違いはなく、実際にはシステムが進化するにつれて、トランザクションと情報システムの間のぼやけが見えます。
私も、動作するものを考え出す限り、データ構造についてあまり心配する必要はありません。 3 NFが答えかもしれませんが、多次元データベースから高度に集約されたデータにアクセスすることは、解決しようとしている問題によっては良い解決策になるかもしれません。
最後に、データウェアハウスから取り出そうとしているデータの種類を検討してください。共有されたディメンションデータ（顧客名や住所など）を要約した取引（平均販売額など）ですか？後者の場合、マスターデータ管理戦略とデータウェアハウス戦略を組み合わせることを検討することをお勧めします。
最後に、これらのデータベース間でデータを共有することをなぜ躊躇しているのか理解してみてください。それはあなたの指を置くことができるものなのか、それとも本当にあなたが産業界から訓練されているため、彼らは別々にする必要があると思うのですか？最後に、私たちの仕事は実際にはデータウェアハウスを構築することではないことを忘れないでください&ビジネスインテリジェンスシステム;彼らは信頼性が高く、実用的で費用対効果の高い方法でビジネス上の問題を解決することです。
アプリケーションデータコンシューマと分析データコンシューマのハブをハブにすることは、基本的に間違っています。しかし、ここでいくつか考えてみましょう。
両方のワークロードに必要なレベルの可用性、トランザクション分離および一貫性をサポートする技術的なソリューションが必要です。例えば。アプリケーションがリソースの分析クエリを枯渇させないようにすることができますか？倉庫の負荷中であっても、一貫したタイムリーな方法でアプリケーションでデータを利用できるようにしますか？あなたが今日それをやることができると思っても、あなたはいつでも倉庫を時間外にロードできると仮定するのは賢明ではありません。
倉庫が適切に正規化されていることを確認します（少なくともBoyce-Codd/5th Normal Formまたはそれに近いものを意味します）。それはどの倉庫にとっても良いアドバイスですが、特に非分析クエリーをサポートする必要がある場合は特にそうです。
アプリは倉庫を更新する必要がありますか？そうであれば、残りのETLプロセスとどのように統合するかを検討する必要があります。
アプリに独自のデータマートを付けるかどうかを検討してください。それは最初から安全な選択肢かもしれません。