データベース設計資料

Question

これは以前に尋ねられたと確信していますが、私は非常に混乱しています！

だから

INSERT [dbo].[Organisation] ([id], [name]) VALUES (1, N'ABC Ltd') 
INSERT [dbo].[Organisation] ([id], [name]) VALUES (2, N'XYZ Ltd') 

INSERT [dbo].[Employee] ([id], [name], [organisationId]) VALUES (1, N'Dave', 1) 

INSERT [dbo].[Message] ([id], [text], [employeeId], [created]) VALUES (1, 'My 1st message', 1, '2012 01-01 00:00:00') 
INSERT [dbo].[Message] ([id], [text], [employeeId], [created]) VALUES (2, 'My 2nd message', 1, '2012 01-02 00:00:00') 
INSERT [dbo].[Message] ([id], [text], [employeeId], [created]) VALUES (3, 'My 3rd message', 1, '2012 01-03 00:00:00') 

...私は、次の表

とデータが含まれているSQL ServerのDBを、持っていると言う、我々はそのデイブ、働く男性を見ることができますABC Ltdは3日連続で3つのメッセージを作成しました。すべてが世界ではうまくいきます。

DaveがABC Ltdで働いたことはありませんが、実際にはXYZ Ltdでうまくいくことが判明した場合は、組織IDを変更します。

しかし、彼がABCで働いていたらどうしたらいいですか？しかし、2012-01-02にXYZ Ltdに変更しました。

Daves organisationIdを変更する前の日に実行すると、ABCの場合は100％、XYZの場合は100％が表示されます。間違った、間違った、間違った!!

私の疑問は、誰かがこの難解を解決するのではなく、私が私に助けてくれると思っているかもしれない主題の方向を指しています。

今日私は「データウェアハウス」、「時間ベースのシステム」、「時間データベース」という用語を検索していて、非常に混乱している記事を読んでいます（私には分かりませんが、 ）。

だから、そこにいる誰も私を正しい方向に振って助けてくれますか？私は、このメッセージから、私が対象とする "ダミーのための"ガイドが必要であることを確信しています。

乾杯。

Answer 1

しかし、彼はABCで働いていたのですが、2012-01-02にXYZ Ltdに変更してください。

あなたは多対多の関係を定義しました。従業員は複数の組織で働くことができ、組織には複数の従業員がいます。

Data Normalizationでこのウィキペディアの記事から始めます。 Google Imagesで「多対多の関係」を検索します。イメージはいくつかの良い説明につながります。

Answer 2

OKレポートを時間通りに処理する必要がある場合は、そのようにデータを保存する必要があります。したがって、正規化されたテーブルと同様に考える代わりに、ルックアップテーブルとみなして必要な値をメッセージテーブルに格納する必要があります。

これは、データが時間とともに変化するため、非正規化ではありません。だから、もし私がどの組織がそれを送ったのか、どの従業員がそれを送ったのかを知る必要があるというメッセージがあれば、私はメッセージテーブルに両方を保存し、従業員と組織）

最終的なテーブルにidフィールドを格納することさえしたくないものもありますが、実際のテキストデータも保存しています。したがって、メッセージが送信されたときのように、組織名（または人物）の名前を報告する必要がある場合は、従業員の名前と組織名、およびIDをメッセージテーブルに格納することができます。これは他のものよりもメッセージの可能性が低いようですので、例を挙げましょう。注文アプリケーションがあります。注文詳細テーブルでは、part_numberだけを保存するのではなく、部品の名前を保存することもできます（時間が経つにつれて変更されることもありますが、顧客に質問があるときは、その時に彼を送った）と価格（時間の経過とともにほぼ確実に変わるだろう）とおそらく他の細部。また、PKをパーツに保存して、今すぐ簡単に調べて、交換がどれだけコストがかかるかを確認することもできます。

Answer 3

私はこの同じ問題が何年にもわたって何度も起きているのを見ました。これは「これはDaveが今働いている場所（または私が最後に確認した場所）」が「これはDaveの作業履歴の一部です」という異なる関係であることを認識していないことです。作業履歴の関係は、各関連付けに開始日と終了可能な終了日があるため、ステートフルです。私が初めてこのデザインパターンを見たのは、ヘルスクラブ会員制でした。

明らかに、「どこのDaveが今働いていますか」という関係を使用してメッセージデータを照会する必要はありません。私は直面する問題を解決する2つの方法を考えることができます：メッセージを会社に直接関連付けるか、会社を派生させるために作業履歴に従うかのどちらかです。実際には、私はこの後者のアプローチが過度に複雑になるのを見ました。あなたがそのルートに行くことを決めた場合は、あなたが気にするデータの点でそれから何かを得ていることを確認してください。間違いなく、単純な解決策を取って、あなたが気にかけているダイレクトメッセージ/企業関係をキャプチャすることを検討する必要があります。これはまた、Daveが月明かりになっている場合にも役立ちます。ここで

Answer 4

は、この状況をモデル化するための非常に簡単な方法です：

基本的に、あなたがいない従業員（人）に、しかし、雇用の特定の期間にメッセージを抱き合わせています。これは正常に動作します。

• 失業者は決してメッセージに関連付けることはできません。
• あなたはアプリケーションレベルで時間的関係を強制することができます。たとえば、Message.Createdは対応するEmploymentのStartDateとTerminationDateの中に入るはずですが、データベース自体は少なくとも宣言的にはそれを強制しません。