0

テーブルのデザインについて質問です。私の意見ではうまくいくはずの解決策がありますが、うまくいきません。

特定の属性を持つ 2 つのエンティティ "サブジェクト" と "プロセス" を持つことを検討してください。すべての「サブジェクト」は、複数の「プロセス」に関連付けることができます。どの「プロセス」が選択されるかによって、さまざまな数のエンティティ「プロセス プロパティ」があります。言い換えれば、ユーザーが「プロセス」を「サブジェクト」に関連付ける場合、ユーザーは特にそれにリンクされた「プロパティ」のみを編集できる必要があります。

最終的には、ユーザーが 3 つのことを実行できるようにしたいと考えています。

  1. 新しい「プロセス」を作成し、それに関連付けられた「プロパティ」を指定する
  2. 特定の「サブジェクト」に関連付けられた「プロパティ」がない場合でも、その「サブジェクト」のすべての「プロセス」を一覧表示する
  3. 「プロセス」を「サブジェクト」に関連付け、定義済みの「プロパティ」のみを評価できるようにする

したがって、テーブルのデザインは次のようになります。

  • tblSubject={サブジェクトID,...}
  • tblProcess={プロセスID,...}
  • tblProcessProperty={プロパティ ID,...}
  • tblRelationProcessProperty={RelationProcessPropertyID、ProcessID、PropertyID}
  • tblRelationSubjectProcessProperty={RelationID、RelationProcessPropertyID、SubjectID、PropertyValue}

これは、すべての「プロセス」に関連付けられた「プロパティ」がある限り、明らかに機能します。したがって、私の間違いは、「サブジェクト」を「プロセス」に直接リンクすることではありませんが、テーブルのデザインをまっすぐにすることができません。

どんな助けでも大歓迎です。

4

2 に答える 2

1

スキーマに何を保存したいかというアイデアがすでにある場合、スキーマ自体を作成するための優れた戦略は次のとおりです。

  1. 要件を ER ダイアグラムとして描画します ( https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model )
  2. 図を SQL スキーマに変換する
  3. 必要に応じて、第 3 正規形にします ( http://en.wikipedia.org/wiki/Database_normalization ) 。

あなたの場合、ステップ1で次のようなものが必要です

 ______       ___________          _______     _____    ____________
| Subj. |____/ associated \_______| Proc. |___/ has \__| Proc.prop. |
|_______|    \____________/       |_______|   \_____/  |____________|

さまざまな種類のプロセスがある場合は、Process エンティティの特化について考えることができます。すべてのプロセスに対して具体的なプロセス プロパティを本当に選択したい場合は、カーディナリティ m:nのhas -関係を作成する必要があります。

ER図では、別の関係があったとしても、妥当性チェック（あなたの3番目の項目）を行うことはできません. SQL スキーマでは、チェック制約を使用してこれを強制するか、新しいプロセスを挿入する前にアプリケーションに妥当性を処理させることができます。

于 2013-07-17T08:43:28.857 に答える