3

現在、MS Access 2003 を使用してデータベースを開発していますが、循環参照の問題に行き詰まりました。基本的には、次の三角形の関係になります (これは、私の関係表を単純化したものです)。

                     Positions
                 oo            oo
                /                \
               /                  \
              /                    \
             /                      \
            /                        \
           /                          \
          /                            \
         /                              \
        /                                \
       /                                  \
      oo                                  oo
  Employees  oo -------------------- oo Software,

ここで、Positions、Employees、および Software はテーブルであり、"oo-------...-------oo"それらの間の多対多の関係を表示します。

つまり、企業内のすべての従業員は特定の役職に割り当てられ (一部の従業員は複数の役職に割り当てられています)、その役職に基づいて特定のソフトウェアを使用する権限を持っています。ただし、例外があり、一部の従業員は、役職に応じて許可されているものに加えて、いくつかの他のソフトウェア パッケージを使用することが許可されています。

問題は、この種のデータベースで循環関係を許可してもよいかということです。非正規化を必要としない回避策はありますか?

よろしくお願いします、VS。

4

4 に答える 4

1

すべてのエンティティ間の N:N 結合テーブルを省略したという意味で、図は楕円形です。これらは、循環関係の副作用に関して大きな違いをもたらします. CASCADE DELETE をオンにした直接の 1:N 関係は、実際の問題や潜在的なデッドロックを引き起こす可能性があります。ただし、間に N:N テーブルがある場合、CASCADE DELETE は 1 つのテーブルから N への「下り坂」のみを実行し、N:N テーブルから別のテーブルへのチェーンをバックアップしないため、その問題は発生しないはずです。親テーブル。

これは一般的な問題であり、住所の問題と同形であるように思えます。つまり、人は個人の住所を持ち、雇用主から住所を継承することができます.@Saif Khanの、地位からのソフトウェアの継承を排除する解決策は、 2 つの複雑なエンティティ関係を 1 つにまとめたという点で、非正規化の方法です。これをモデル化する方法がわかりません。潜在的な循環関係のためではなく、UNION を必要とするすべてのソフトウェア/アドレスの単一の結果セットを組み立てることから生じるパフォーマンスの問題 (および編集不可能性) のためです。トリガーを使用して、その人物とソフトウェアを関連付ける記録を持つ地位から継承されたソフトウェアを複製したくなるでしょう。

A2010 より前は、これは Access/Jet/ACE のエンジン レベルでは不可能でしたが、A2010 では、トリガーと同等の実装に使用できるテーブル レベルのデータ マクロが追加されました。これは、その新機能により、トリガーを使用してこの構造を実装できる場合があります。

しかし、トリガーを使用すると、複製されたデータをエンジンレベルで同期させることができますが、データの複製に慣れているかどうかはわかりません。

于 2010-09-27T18:12:41.930 に答える
0

このデータベースの設計は、例外の処理方法のために複雑になりすぎていると思いますが、

「一部の従業員は、職位に応じて許可されているものに加えて、いくつかの他のソフトウェア パッケージを使用することが許可されています。

従業員をソフトウェアに直接リンクしようとしないでください。

この場合の位置の主な目的はソフトウェアアクセスを決定することであるため、別の位置を作成するだけです。1 人の人が固有のソフトウェア リストを持っていたとしても、将来その人は入れ替わり、その人は同じポジションに割り当てられる可能性があります。

クエリがより簡単になります。David-W-Fenton が指摘したように、多くのユニオンを使用して、誰がどのソフトウェアを使用できるか、またはその逆を確認する必要があります。

于 2010-09-27T21:11:57.057 に答える
0

DB を適切に正規化する必要があります。IMHO - ポジション テーブルでリレーションシップを使用しません。これが私がすることです

テーブル

  • 従業員
  • ソフトウェア
  • 従業員ソフトウェア
  • 位置

あなたの場合の「POSITIONS」テーブルは、あなたの役割だと思います。DB はストレージとして使用し、最小限のビジネス ロジックをそこに配置する必要があることに注意してください。そうは言っても、...続けさせてください

Employee と EmployeeSoftware (empid は EmployeeSoftware の外部キーとして存在します) の間には関係があります。Software と EmployeeSoftware (EmployeeSoftware の外部キーとして存在する softid) についても同じです。

アプリケーションは、レコードを挿入する前に、まず人物が適切な位置 (POSITIONS) テーブルにあるかどうかを確認します。追加の DB チェックについては、EmployeeSoftware にチェック制約を追加して、POSITIONS DB をチェックすることができます...その後、ソフトウェアとポジションの間の関係が必要になります。

于 2010-09-27T13:12:34.283 に答える
0

例外ごとに新しい位置を生成することで回避できます。必要に応じて、実際の位置と例外を生成する位置を区別するために、ブール フラグを位置に追加することができます。

于 2010-09-27T13:04:47.163 に答える