タグ付けされた質問 「data-warehouse」

まず、これは軽視されている質問/領域であるように思われるので、この質問を改善する必要がある場合は、他の人に利益をもたらすことができる素晴らしい質問にしてください！試してみたいアイデアだけでなく、この問題を解決するソリューションを実装した人々からのアドバイスやヘルプを探しています。 私の経験では、アプリケーションには2つの側面があります。主にドメイン駆動型で、ユーザーがドメインモデル（アプリケーションの「エンジン」）とやり取りする「タスク」側と、ユーザーがタスク側で何が起こるかに基づいてデータを取得します。 タスク側では、リッチなドメインモデルを備えたアプリケーションにはドメインモデルのビジネスロジックが必要であり、データベースは主に永続化のために使用する必要があることは明らかです。懸念の分離、すべての本はそれについて書かれています、私たちは何をすべきか、素晴らしいを知っています。 レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。データベースのデータをデータウェアハウスデータに集約するには、データにビジネスロジックとルールを適用している必要があります。そのロジックとルールはドメインモデルからではなく、データ集約プロセスからのものです。それは間違っていますか？ 私は、ビジネスロジックが広範囲にわたる大規模な財務およびプロジェクト管理アプリケーションに取り組んでいます。このデータのレポートを作成するとき、レポート/ダッシュボードに必要な情報を取得するために多くの集計を行うことが多く、集計には多くのビジネスロジックが含まれています。パフォーマンスのために、高度に集約されたテーブルとストアドプロシージャを使用してこれを行っています。 例として、アクティブなプロジェクトのリストを表示するためにレポート/ダッシュボードが必要だとしましょう（10,000個のプロジェクトを想像してください）。各プロジェクトには、次のような一連のメトリックが必要です。 総予算 これまでの努力 燃焼速度 現在の燃焼速度での予算枯渇日 等 これらのそれぞれには、多くのビジネスロジックが含まれます。そして、私は単に数字の乗算やいくつかの単純なロジックについて話しているのではありません。予算を得るために話しているのは、各従業員の時間（一部のプロジェクトでは、他のプロジェクトでは乗数があります）に1つずつ、500の異なるレートのレートシートを適用し、費用や適切なマークアップなどを適用する必要があることですロジックは広範です。クライアントにとって妥当な時間内にこのデータを取得するには、多くの集約とクエリのチューニングが必要でした。 これは最初にドメインを介して実行する必要がありますか？パフォーマンスはどうですか？単純なSQLクエリを使用しても、クライアントが妥当な時間内に表示するのに十分な速度でこのデータを取得することはほとんどありません。これらすべてのドメインオブジェクトをリハイドレートし、アプリケーションレイヤーでデータを混合および照合して集約する場合、またはアプリケーションでデータを集約しようとする場合、クライアントにこのデータを十分に速く取得しようとすることは想像できません。 これらのケースでは、SQLはデータの処理に優れているように思われますが、使用しないのはなぜですか？ただし、ドメインモデルの外部にビジネスロジックがあります。ドメインモデルおよびレポート集計スキームでビジネスロジックを変更する必要があります。 ドメイン駆動設計と優れた実践に関して、アプリケーションのレポート/ダッシュボード部分をどのように設計するかについて、私は本当に困っています。 MVCはデザインフレーバーデュジュールであり、現在のデザインで使用しているため、MVCタグを追加しましたが、レポートデータがこのタイプのアプリケーションにどのように適合するかわかりません。 本、デザインパターン、グーグルのキーワード、記事など、この分野での助けを探しています。このトピックに関する情報が見つかりません。 編集と別の例 今日出会った別の完璧な例。顧客が顧客営業チームのレポートを望んでいる。彼らは単純なメトリックのように見えるものを望んでいます： 各営業担当者の現在までの年間売上はいくらですか？ しかし、それは複雑です。各販売員は複数の販売機会に参加しました。勝った人もいなかった人もいます。各販売機会には、それぞれの役割と参加ごとに、販売に対するクレジットの割合が割り当てられた複数の販売員がいます。それでは、このためにドメインを通過することを想像してください。すべての営業担当者のデータベースからこのデータを引き出すために必要なオブジェクトの再水和の量： すべての取得SalesPeople- > それぞれが得るために彼らのSalesOpportunities- > 各販売の彼らの割合を取得し、その販売量を算出するために 、すべての彼らの最大の追加SalesOpportunity販売量を。 そして、それは1つのメトリックです。または、迅速かつ効率的に実行し、高速に調整できるSQLクエリを作成できます。 編集2- CQRSパターン CQRSパターンについて読んだことがありますが、興味深いことに、Martin Fowlerもテストされていないと言います。それで、過去にこの問題はどのように解決されましたか。これは、何らかの点で全員が直面していなければなりません。成功の実績を持つ確立されたアプローチまたは使い古されたアプローチとは何ですか？ 編集3-レポートシステム/ツール このコンテキストで考慮すべきもう1つのことは、レポートツールです。Reporting Services / Crystal Reports、Analysis Services、Cognoscentiなどはすべて、SQL /データベースからのデータを想定しています。これらのデータが後であなたのビジネスに届くとは思いません。それでも、彼らと彼らのような人々は、多くの大規模システムのレポートの重要な部分です。これらのシステムのデータソースやレポート自体にもビジネスロジックがある場合、これらのデータは適切に処理されますか？

44 mvc  architecture  domain-driven-design  reporting  data-warehouse 

私は、さまざまなアーティファクトをリンクする迷路のような依存関係を持つ多くのストリームとレイヤーを介して複数のシステムを調達するデータウェアハウスで働いています。ほぼ毎日、このような状況に陥ります。何かを実行しますが、機能しません。大量のコードを調べますが、数時間後には、今わかっていることのごく一部のプロセスマップを概念化することができました。後日必要になるので、誰かに尋ねて、この他のストリームを最初に実行する必要があることと、ここでチェックした場合（他のコード化された依存関係の巨大なスタックの一見arbitrary意的な部分を示す）、これを見た。とてもイライラします。 再帰的なレベルのコードや、さらにはデータにオブジェクトを深く埋め込むのではなく、オブジェクト間の依存関係をより明確に見えるようにするためにもっとや​​った方がいいだろうとチームに提案できた場合おそらく、よく知られ、試行され、テストされたソフトウェアパラダイムを参照することで、別のストリームが存在するために存在する必要があります。 私のチームにこの利点を説明するのはちょっと難しいです。彼らは物事をありのままに受け入れる傾向があり、システム全体を新しい方法で概念化できる利点を見るという点で「大きく考える」ことはしません。巨大なシステムをモデル化できるなら、効率的な場合、メモリの非効率性、ストリーム停止の一意の制約、重複キー、ナンセンスデータに遭遇する可能性が低くなります。元のビジョンに沿って設計する方がはるかに簡単で、後でこれらすべての問題に遭遇することはありません私たちは現在、過去の仕事では珍しいことを知っていますが、彼らは避けられないと考えているようです。 では、依存関係を強調し、理想の長期的な順守を確保するために、システムの一般的な概念モデルを促進するソフトウェアパラダイムを知っている人はいますか？現時点ではかなり混乱しており、すべてのスプリントは「こことこことここにこのものを追加するだけ」であるように見えます。

26 readability  paradigms  data-warehouse  modeling  dependency-analysis