0

別の会社によって作成された新しいデータベースに対してETL作業を行う必要があるプロジェクトが実行されています。開発者から提供されたデータベース図を調べ​​ていると、4つのテーブルに循環参照があることがわかりました。

ダイアグラムをアップロードできませんが、テーブルの一般的な構造は次のとおりです。

場合

  • ID（PK）CaseStatusInfo（FK）
  • SignOffPlanning（FK）
  • SignOffReportReview（FK）
  • SignOffQuarterlyReview（FK）

CaseStatusInfo

  • ID（PK）
  • CaseId（FK）

SignOffPlanning

  • ID（PK）
  • CaseId（FK）

SignOffReportReview

  • ID（PK）
  • CaseId（FK）

SignOffQuarterlyReview

  • ID（PK）
  • CaseId（FK）

ケーステーブルにリンクされたこれらの情報テーブルがどのように使用されるかは、各情報テーブル内に主キーを格納することにより、ケースの履歴ステータスを格納することです。これは本当に論理的には理にかなっていますが、これらのテーブルをさらに正規化して、これらの正規化されたテーブルに履歴データを保持する方がよいと思います。

私の質問は、テーブルをさらに正規化する代わりに、このタイプのデータベース構造を使用するとどのような問題が発生する可能性があるかということです。

4

1 に答える 1

0

これらのテーブルとの 1 対 1 の関係が本当に必要なようです。各テーブルには他のプロパティのヒープがある可能性があると想定しているため、それらを巨大な CASE テーブルに結合したくない理由を理解できました。その場合... PK/FK を組み合わせて 1 対 1 の関係を強制することもできます...

場合

  • ID（PK）
  • CaseStatusInfo (外部キー)
  • SignOffPlanning (FK)
  • SignOffReportReview (FK)
  • SignOffQuarterlyReview (FK)

CaseStatusInfo

  • CaseId (PK、FK)

サインオフ計画

  • CaseId (PK、FK)

サインオフレポートレビュー

  • CaseId (PK、FK)

サインオフ四半期レビュー

  • CaseId (PK、FK)
于 2013-01-29T10:09:58.760 に答える