4

私は周りを見回して、似たような質問をいくつか見つけましたが、代わりにSQL Serverに関するものでした。

これは、モデル化したい関係を示すためだけに作成した、構造化された小さなデータベースです。基本的には非常に単純で、各年には 12 の期間があり、期間-年のインスタンスは 2 回発生することはありません (2012 年 9 年の期間は 2 回以上発生することはありません)。

複合キー データベース構造へのアクセス

したがって、これをモデル化する最良の方法は、1 から 12 の値を持つ 1 つのフィールドのみを持つテーブル期間、同じロジック (2011、2012...) に従うテーブル年を持つことであり、それは N- to-N 関係 私は、それらを結合して rpt_maintenance_kpi で使用する period_by_year テーブルを作成しました。ここで難しいのは、各組み合わせを一意にするために、複合主キーの period_no と year_no の両方の部分を作成したことです。私の意見では、これは問題をエレガントに解決しますが、rpt_maintenance_kpi (またはその他のテーブル) からこの複合主キーを参照する方法に行き詰まっています。2 つの結合を作成しようとしましたが、うまくいかないようです (2 つ目の rpt_maintenance_kpi テーブルを作成しますが、これではやりたいことを実行できないと思います)。

では、複合主キーへの外部キーをどのように処理できますか?

よろしくお願いします。

4

2 に答える 2

4

メンテナンスで年または期間の関係を作成し、関係線をダブルクリックして関係を編集するか、2 番目の部分 (年または期間に応じて) を [メンテナンス] にドラッグし、関係を編集するかどうか尋ねられたら [はい] を選択します。次のように 2 行目を追加できます。

2 つのフィールドとの関係

于 2012-07-31T09:32:09.247 に答える
1

複合キーはもちろん役に立ち、問題を解決しますが、複合キーの結合を本当に避けたい場合は、必要なことを達成するための別の代替方法として、テーブル構造を少し再設計することができます。最終レポートは常に月と年の組み合わせに基づいて検索されるため、MthYear ディメンション (またはテーブル) があると役立ちます。以下は、そのテーブルのエントリである可能性があります - yymm 形式:

1301 1302 1303 ... ... ... 1312 1401 1402 ... ... など....

2 番目のフィールドのように、1 月 13 日、2 月 13 日など、よりわかりやすい形式で同じテーブルにさらに属性を含めることができます。

MthYear フィールドは、レポートのメインテーブルで MthYear に接続できるプライマリ フィールドにすることができます。これにより、複合主キーの使用が回避されるだけでなく、クエリまたはレポートでワイルドカード文字を使用する必要がある場合に、年または月のみをフィルター処理するのにも役立ちます。これがお役に立てば幸いです......Arvind

于 2013-12-18T05:49:56.283 に答える