私はData warehouseの新しいメンバーです。私はモデルのスタースキーマを変更しています。 私は2つのテーブルを持っています：契約テーブル&不平テーブル。 1つの契約は、クレームテーブルに1つ以上の値を持つことができます。下の2枚の写真を見ることができます。データウェアハウスで1対多の関係を解決しますか？
facttableでは、1件の契約は1行しか持たない。 complainテーブルは、各contract_idに対して1つ以上の値を持つことができます。私はブリッジテーブルを試しましたが、それは十分ではありませんでした。あなたは、ファクト表とディメンション表が混乱している
dinhhungdigital： はすべて
http://prntscr.com/fgdnpb（Conplainテーブル）
http://prntscr.com/fgdorh（契約テーブル）
マイスカイプをありがとうございました。あなたの次元は "契約"でなければならず、ファクトテーブルはContract_Idに1対多の（開始スキーマが必要とする）ように接続された "クレーム"でなければなりません。
あなたはDimContract & FactContractだけでなく、DimComplaint & FactComplaintを持つ必要があります。
DimContractはContractID（縮退ディメンション）のみで構成されていても構いませんが、ContractIDに依存するように見えるため、ここにコードが含まれることもあります。 FactContractはDimDateContractSigned
DimComplaintはおそらくComplaintIDとコードで構成されています。ウェブサイトがフリーテキストであれば、ここにも含めることができます。ユーザーがリストから選択すると、それは事実になります。 FactComplaintクレームを記述するディメンション属性のすべての接続：
この例では、クレームは契約を参照し、契約は顧客を参照するため、FactComplaintからDimCustomerへの直接参照を必要とせずに顧客とクレームの関係を見ることができます。
いいアイデアですが、私のデータベースではできません。実際には2つのテーブルだけでなく、実際には4つのテーブルがあります：：必要、実行、請求...各契約には、1つまたは複数の値が必要です。請求書...これらのテーブルと契約テーブルの関係は、 -たくさんの。 私は契約テーブルがFactTableになりたいと思っています。 –
あなたが言及している表が何を意味するかをもっと説明できますか？必要、実行する、請求書？あなたがこれまで述べてきたことから、RADOは契約が次元でなければならないと思います。 – Rich
@TrầnĐìnhHưng：スタースキーマ設計について学ぶのに役立つ私の答えへのリンクを追加しました。ご迷惑をおかけして申し訳ありませんが、ファクトとディメンションを自由に指定することはできません。その役割はデータ構造によって定義されています。ファクトテーブルには取引（お客様の場合は苦情）が蓄積され、ディメンションテーブルにはこれらの取引のコンテキストが表示されます（ケース、契約などの顧客、場所、製品など）。ディムテーブルはユニークなキーを持たなければならず、リレーションの「1」側にある必要があります。 – RADO