初歩的な質問で申し訳ありませんが、私はデータ ウェアハウジングとビジネス インテリジェンスの世界は初めてです。
私が読んだことから、リレーショナル モデルの制限により、多次元データベースが必要であることがわかります。多次元データベースで行う必要があることはすべて、非常に複雑なクエリとパフォーマンスの低い結合および集計操作を使用する通常のリレーショナル データベースで実行できます。
問題は、オブジェクト データベースのビジネス インテリジェンスについて話すときに、同じ概念 (多次元データベース - データ ウェアハウスなど) が必要かということです。オブジェクト間の関係は直接参照によって維持されるため、オブジェクト データベースには結合がありません。
多次元性は、データ ウェアハウジングの重要な機能です。
これは、リレーショナル モデルの制限に対する「回避策」ではありません。これは、複数の重要な次元に関して事実を任意に「スライス アンド ダイス」分析する必要があるデータをモデル化するための最良の方法です。
スター スキーマ クエリはそれほど複雑ではありません。ほとんどの場合、 の形式であるため、実際には非常に単純ですSELECT SUM(MEASURE) FROM FACT JOIN DIM1 ON ... JOIN DIM2 ON ... WHERE...。
結合操作は -- 一般に -- 遅いです。ただし、SQL ウェアハウスではなく、オブジェクト指向コードで結合を行うことができます。
多くの場合、ほとんどのディメンションは実際にはかなり小さく、完全にメモリに収まります。分析クエリは、すべてのファクトの単純なフェッチに続いて、ディメンション属性のインメモリ ルックアップに発展する可能性があります。
残りのケースでは、ディメンション (通常は顧客、患者、またはメンバーのディメンション) が関連するファクト テーブルとほぼ同じ大きさのスノーフレーク スキーマがあります。この場合、データベースのリレーショナル結合が役に立ちます。
「オブジェクト間の関係は直接参照によって維持されるため、オブジェクト データベースには結合がありません。」
完全に真実ではありません。オブジェクト データベースには、オブジェクトからオブジェクトへのナビゲーションがあります。オブジェクトのセットをそれらの関連オブジェクトとともに取得すると、実質的に結合操作が実行されます。
「問題は、オブジェクト データベースのビジネス インテリジェンスについて話すときに、同じ概念 (多次元データベース - データ ウェアハウスなど) が必要かということです。」
はい。多次元性は不可欠です。絶対。オブジェクト データベースは、これをリレーショナル データベースと同様に (または、より適切に) 表現します。ただし、どちらのモデルも、メジャーとそのディメンションの本質的な真実を表している必要があります。
おそらく、いわゆる文書データベースを調べてみるとよいでしょう。CouchDBは人気があり、オープン ソース (無料で入手して分析できます) であり、理解しやすいものです。CouchDB は、すべてのデータをJSON (解析が容易な JavaScript Object Notation) ドキュメントとして保存し、 RESTのみを使用して外部の世界と通信します (初心者の場合は HTTP のみを使用します)。CouchDB の興味深い機能の 1 つは、データの処理と集計に MapReduce パラダイムを使用してデータを選択できることです。
CouchDB を見れば、非リレーショナル データベースの可能性がいくつかわかるかもしれません。CouchDB は、オブジェクト全体ではなく、主にデータ ドキュメントの格納に関係していることを理解してください。一部のデータベースは、プログラム内の特定のオブジェクトの状態を保存する限り、真のオブジェクト データベースです。db4oと比較してください。