0

私の人生のためにこれを私の頭から得ることはできません。最初はとてもシンプルに見えましたが、今ではずっと見つめすぎていて、木々の森が見えません。

本質的に、私たちは日区分を持っています、これらは任意です... 

ID  Name    Start  End
1   Name1   1300   1400
2   Name2   13:30  19:30
3   Name3   20:00  21:30

等

これらの日区分の任意の組み合わせで曜日を構成できるようにしたいので、WeekConfigurationsテーブルがあります。

ID  ConfigurationID  DayOfWeek   DayDivisionID   Order
1   1                1           1               1
2   1                1           2               2
3   1                2           2               1
4   1                2           3               2
5   2                1           1               1
6   2                3           2               1
7   2                3           3               1

ここで、他のエンティティ（Person、Officeなど）に特定の週の構成を割り当ててもらいます。そして、これは私が立ち往生しているところです。割り当てたいconfigurationIDは主キーではないため、エンティティと構成の間に参照整合性を適用できません。

誰かが私を正しい方向に向けることができますか？WeekConfigurationテーブルについての何かが私には面白いにおいがしますが、私はそれを見ることができません。

PS：申し訳ありませんが、私は説明するための素晴らしい図を持っていましたが、私は初心者であり、それを追加することはできません

4

2 に答える 2

1

論理レベルでは、その構成の下に「構成」と「構成アイテム」のセットがあります。したがって、構成テーブルを1つだけではなく、次の2つを使用します。

ここに画像の説明を入力してください

この設計では、ConfigurationIdは（テーブルの）主キーConfigurationであるため、外部キーの親エンドポイントとして直接使用できます。

ConfigurationItemPKにより、構成ごとに最大で1日の分割を使用できるようになり、代替キーによりU1、（同じ曜日と構成内で）明確に順序付けられるようになります。

また、の代理PKを回避することを選択しましたConfigurationItem。必要に応じて、簡単に追加（および既存のPKを代替）できます。たとえば、言及していないFKが追加されている場合や、複合PKでうまく機能しないORMを使用している場合などです。

于 2012-06-20T20:00:24.077 に答える
0

はい。 WeekConfiguration2つのテーブルに分割する必要があります。

参照整合性を適用するには、週ごとに1つのレコード（および1つのID）が構成されているテーブルが必要です。このテーブルには、呼び出す列とConfigurationID、おそらく何らかの説明が含まれている必要があります。

もう1つのテーブル（これを呼び出す場合があります`WeekConfigurationDetail）には、詳細レコード、週の構成を構成する日区分を格納する必要があります。列は既存のテーブルに似ていますが、その主キー（ここでも）自体がメインテーブルConfigurationIDへの外部キーになります。WeekConfiguration同様に、他のテーブル（エンティティ）はそのテーブルを外部参照できます。

テーブルに無意味なIDの列が1つしかない場合WeekConfigurationでも、参照整合性を確保するためにテーブルが必要です。

このデータベースデザインパターンは、master-detailまたは親子とも呼ばれます。

于 2012-06-20T19:49:09.970 に答える