2

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

次のテーブルを含むSQLServerデータベースがあるとします。

ここに画像の説明を入力してください

とデータ...

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')

つまり、ABC Ltdで働いているDaveが、3日間連続で3つのメッセージを作成したことがわかります。すべてが世界で順調です。

DaveがABCLtdで働いたことがないことが判明したが、実際にはXYZ Ltdで働いていれば問題ない場合は、組織IDを変更します。

しかし、彼がABCで働いていたが、2012年1月2日にXYZ Ltdに変わった場合、私は何をすべきでしょうか。

各組織によって生成されたメッセージの数を尋ねるレポートは、Daves OrganisationIdを変更する前日に実行した場合、ABCの場合は100％、翌日実行した場合はXYZの場合は100％を表示します。間違った、間違った、間違った!!

私の質問は、誰かがこの難問を解決することではありませんが、私が見ることができる主題の方向に私を向けてください。それは私を助けることができます。

私は今日、「データウェアハウジング」、「時間ベースのシステム」、「時制データベース」という用語を検索していて、非常に紛らわしい記事をいくつか読んでいます（私にとっては紛らわしいですが、それらは素晴らしい記事だと確信しています）。

それで、そこにいる誰かが私を正しい方向に動かすことによって私を助けることができますか？このメッセージから、このテーマについての「ダミー向け」ガイドが必要であることがわかると思います。.....そのテーマが何であれ!!!

乾杯。

4

4 に答える 4

1

しかし、彼がABCで働いていたが、2012年1月2日にXYZ Ltdに変わった場合、私は何をすべきでしょうか。

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

データの正規化に関するこのウィキペディアの記事から始めてください。Google画像検索で「多対多の関係」を検索します。画像はいくつかの良い説明にあなたを導きます。

于 2012-04-30T17:11:19.160 に答える
0

時間ごとにレポートする必要がある場合は、その方法でデータを保存する必要があります。したがって、これらを正規化されたテーブルと考えるのではなく、ルックアップテーブルと見なして、必要な値をメッセージテーブルに格納する必要があります。

データは時間とともに変化するため、これは非正規化ではありません。たとえば、どの組織が送信したか、どの従業員が送信したかを知る必要があるというメッセージがある場合は、両方をメッセージテーブルに保存し、従業員と組織の関係について返信しないようにする必要があります（おそらく必要になります）。他のことを知るために。）

場合によっては、ファイナルテーブルにidフィールドを保存するのではなく、実際のテキストデータを保存する必要があります。したがって、メッセージが送信されたときの組織（または個人）の名前を報告する必要がある場合は、従業員名と組織名、およびIDをメッセージテーブルに保存することをお勧めします。これは他のメッセージよりもメッセージの可能性が低いように思われるので、例を挙げましょう。注文アプリケーションがあります。注文詳細テーブルでは、part_numberだけでなく、部品の名前も保存する必要があります（これは時間の経過とともに変更される可能性がありますが、顧客から質問がある場合は、書類を確認します。当時彼に送った）と価格（ほぼ確実に時間とともに変化する）とおそらく他の詳細。

于 2012-04-30T17:20:28.923 に答える
0

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

明らかに、「Daveが現在機能している場所」の関係を使用してメッセージデータをクエリする必要はありません。差し迫った問題を解決する方法は2つ考えられます。メッセージを会社に直接関連付けるか、会社を導き出すために作業履歴をたどる方法です。実際には、この後者のアプローチは非常に複雑になるのを見てきました。そのルートに行くことにした場合は、気になるデータの観点から何かを得ていることを確認してください。確かに、あなたは単純な解決策を取ることを検討し、あなたが気にかけていることがわかっている直接のメッセージ/会社の関係をキャプチャする必要があります。これは、デイブが副業をしている場合にも対応します。

于 2012-04-30T20:08:31.433 に答える
0

この状況をモデル化する非常に簡単な方法は次のとおりです。

ここに画像の説明を入力してください

基本的に、あなたはメッセージを従業員（人）ではなく、特定の雇用期間に結び付けています。これは、次のことを前提として正常に機能します。

  • 失業者をメッセージに関連付けることはできません。
  • あなたは、アプリケーションレベルで時間的関係を強制することに満足しています。たとえばMessage.Created、対応するEmploymentのStartDateとの中に入る必要がTerminationDateありますが、データベース自体はそれを強制しません（少なくとも宣言的には）。
于 2012-04-30T23:43:28.977 に答える