製品、場所、時間のディメンションに対応するいくつかの事実を保存するアプリケーションを構築しています。たとえば、特定の製品 P1 が特定の月 T1 に店舗 S1 で 10 個販売されたとします。すべてのディメンションには、それらの間に階層を持つレベルがあります。たとえば、時間ディメンションの場合は年/月/週/日です。各レベルのメンバー (メンバーという言葉が正しいかどうかはわかりません) にも、メンバー間に階層があります。他の次元についても同様です。この構造自体を実装することは、階層データを表現するためのオプションを考えると少し難しいです選択は、挿入/更新/削除するデータと選択するデータの頻度と量によって決まります。いくつかの調査を行い、自分のケースに最適なソリューションを選択できます。
しかし、私が現在直面している本当の困難は、事実データが存在する別の空間をモデル化することです。上記の例を参照して、P1 が階層Category/Subcategory/Articleの製品ディメンション レベル "Article" のメンバーであり、S1 が階層Country/City/Storeの store ディメンション レベル "Store" のメンバーであるとします。. ここで、ストア S1 がアイテム P1 を月 T1 に保管していないと仮定し、フラグ IS_ACTIVE を使用してこの決定を表します。つまり、IS_ACTIVE=N はファクトであり、そのコンテキストは {P1,S1,T1} です。また、IS_ACTIVE が属性であり、N がその値であることにも注意してください。ただし、このコンテキスト {P1,S1,T1} 自体は、メタ コンテキスト {Article, Store, Month} のインスタンスです。そして、このメタ コンテキストもアプリケーションに格納する必要があります。その理由は、メタ コンテキスト {Article, Store, Month} に対応する他の可能な属性 (REBATE_OFFERED_PERCENT など) のリストを取得する必要があるアプリケーション内の場所がある可能性があるためです。
私はこれらすべての正規化されたリレーショナル スキーマ設計を考え出しましたが、複雑すぎて、私の意見ではパフォーマンスが向上しません。ここにはいくつかの階層が含まれているため、私のニーズを満たすことができる NoSQL データベースのような代替ソリューションを探しています。または、問題のドメインはリレーショナル スキーマ設計により適していますか?
これは、複数のドメインで発生する標準的な問題のようですが、これに関する記事は見つかりませんでした。また、この問題に関連する抽象数学の分野はありますか? このような問題を説明する標準的な用語はありますか? 解決策を実装する前に、いくつかの理論を読んでみたいと思っています。