データベース設計を簡略化

Question

誰もこの4つのテーブルの良いデザインを提案することはできません。

デザイン

Fields: DesignId (Primarykey), 
Iname..,.... 

表2：入力ファイル

FileId int, 
DesignId , 
FileName, 
Description, 
primary key (FileId,DesignId) 
foreign key(DesignId)... 
//This foreign key here seems to cause insert problems. 

表3：入力データ

DesignId int, 
TestCaseInputId, 
FileId int, 
MaterialType, 
primary key(DesignId ,TestCaseInputId,FileId) 
foreign key(FileId) references InputFiles 
foreign key(DesignId) refernces Design 

質問：

1. 表2、表3の複合キーについてはわかりません。
2. 外国Keys.The外部キーは助けにならない「外部キーは[原文]の挿入に問題を引き起こすように見える」と言っ挿入問題

Answer 1

を引き起こしているようです。何が問題ですか？私はこの問題が外部キーの制約ではなく、データをロードする順序であると推測しています。 IDがであることを確認してから、にデータをロードする必要があります。

ファイルからデータを読み込むとき、私は通常、次の戦略を使用：一時、すべての文字のステージングテーブルにデータをロードし

1. を。
2. 外部キーと型を含むステージング表のデータを検証します。
3. 必要に応じて、欠落している主キーを適切なテーブルに追加します。
4. データを最終テーブルにロードします。

これには、より多くのステップとデータの移動が必要です。しかし、入力データのチェックを適切に行うことで、どれくらいの時間が節約されているかを常に覚えています。

Answer 2

ありません、本当に利用シナリオのように少しの知識から設計を行うことができます1 ...しかし

いくつかの擬似DDL、わからないサーバーは、使用...

create table Design (
    DesignID int not null primary key, 
    Iname nvarchar(32) not null 
) 

create table InputFile (
    FileID int not null primary key, 
    DesignID int not null, -- foreign key referencing Design (DesignID) 
    FileName nvarchar(max) not null, 
    Description nvarchar(max) null 
) 

create table InputData (
    TestCaseInputID int not null primary key, 
    FileID int not null, -- Foreign key referencing InputFile (FileID) 
    MaterialType nvarchar(?) 
) 

主なポイント同じFileIDを持つ複数のファイルを作成しない限り、InputFileの主キー（FileID、DesignID）を作成しないでください。

InputIDにDesignIDを持たせる必要はありません。あなたがそれを置くならば、それがInputFile.DesignIDと一貫していることを保証しなければなりません。この関係が決して変わらないなら、あなたはまだそれを望むかもしれません。それは正規化のヒントです。

次のように、順番にデータを挿入する必要があります

...

1. まず挿入デザイン
2. 次にファイル
3. を挿入し、なぜ別のテーブルには、入力ファイルからの入力データである入力データ

を挿入？各ファイルに複数の入力データ行がある場合は意味があります。

IdentityID、FileID、およびTestCaseInputIDのID列またはサーバーの同等の自動インクリメントIDを作成できます。または、これらのIDが他の場所で取得された実際の情報である場合は、それらを挿入する必要があります。