最初のER図で助けが必要
最初のデータベースコースをオンラインで開始したばかりで、仕様のリストからエンティティ関係図（ERD）を作成するための宿題があります。
仕様は次のとおりです。
会社は部門に分かれています。各部門には、名前、一意の番号、および部門を管理する特定の従業員がいます。従業員が部門の管理を開始した開始日を追跡します。部署には複数の場所がある場合があります。
部署はいくつかのプロジェクトを制御し、各プロジェクトには名前、一意の番号、および単一の場所があります。
各従業員の名前、SSN、住所、給与、性別、DOBを保存します。従業員は1つの部署に割り当てられていますが、同じ部署によって制御される必要がない複数のプロジェクトで作業する場合があります。従業員が各プロジェクトに従事する週あたりの時間数を追跡します。また、各従業員の直属の上司も追跡しています。
保険目的で各従業員の扶養家族を追跡したいと思います。私たちは、各扶養家族の名の性別、DOB、および従業員との関係を維持します。
あなたの最初のデータベースクラスとERダイアグラム（ERD）の最初の試みについて、あなたは素晴らしい仕事をしたと思います！私は、あなたが与えられたような一連の要件を分析し、ドラフト図を作成するために使用するプロセスのコンテキストで、いくつかのフィードバックを提供したいと思います。うまくいけば、このアプローチをとることによって、私はあなたがERモデリングとデータベース設計のスキルを伸ばすのを手助けし、宿題への答えを与えるだけではありません。
エンティティと関係を見つける
ERDの背後にある考え方は、エンティティ-基本的なビジネスにとって重要なものと、それらがどのように関連するかを識別することです。したがって、エンティティ関係図という名前です。この時点での目標はnotデータベースを設計または実装することですが、代わりに、最終的にデータベースのベースとなる対象ドメインのより構造化された理解を発展させることです。エンティティの検索を開始する良い方法は、要件で名詞を探して、人、場所、物、概念、またはイベントであるものを選択することです。次に、それらの名詞をつなぐ動詞を探すことで、ほとんどの関係を見つけることができます。ここに、提供された要件でエンティティと関係を見つける最初のパスを示します。
名詞は明るい緑色で、動詞は明るいピンク色で強調表示しました。ここで、濃い緑色で強調表示されている1つの名詞（supervisor）があることに注意してください。今のところは無視します。私が見つけたものとあなたのERDに置いたものを比較すると、同じページにいます！唯一の違いはlocationも強調したことです。これがなぜあなたのERDから除外されたのかははっきりとわかります。部門タイプとプロジェクトのattribute-エンティティタイプのすべてのエンティティが共有する共通のプロパティまたは特性-と同じくらい簡単に考えることができ、それがモデルの作成方法です。エンティティタイプに昇格した理由は次のとおりです。
部署はseveral場所を持つことができます
これは、各部門が1つ以上の場所に関連付けられることを示しているため、これを独自のエンティティタイプに分割する必要があります。昇格する2番目の理由は、場所をplaceと考えることができるため、名前、住所、都市、都道府県、郵便番号などの独自の属性を持つことになります。昇格する3つ目の理由は、場所が複数のエンティティタイプ（部門とプロジェクト）によって参照されていることです。問題の要素が既に識別されている複数のエンティティによって参照されている場合は、それ自体が関連であり、単に属性ではなく、それ自体がエンティティであると考える必要があります。その他の。しかしこれには科学はありません-それは純粋に判断の呼びかけです。これが、ERダイアグラムが個々の視点に対する主観的な概念レベルである理由です。ある人物のエンティティは、関心のあるドメインへの視点に応じて、別の人物の属性です。
関係については、ピンクで強調したもののリストです：
- 従業員manages部門
- 部署コントロールプロジェクト
- 従業員担当者部門
- 従業員作業日プロジェクト
- 従業員has従属
これらのうち、最初のものを除いてすべてを特定しました。これは、先に述べた上司と一緒に、後で延期する役割の議論に入ります。現在、私達はファンダメンタルズを特定しようとしているだけなので、あなたは正しかったと思います。
関連エンティティ
人間関係を見ると、多対多の少数の関係があります。要件では、従業員は多くのプロジェクトに取り組むことができ、必ずしも同じ部門で制御されているわけではありません。ほとんどのプロジェクトには複数のメンバーがいるため、これは多対多の関係であると想定できます。 ERDでこのような関係がある場合、多対多の関係線を表示することは完全に許容されます。属性をまったく表示しない場合でも、通常は多対多の関係のみを使用します。ここではそれらを示しているため、associative entityを使用して多対多の関係を解決することをお勧めします。現在エンティティに属性がない場合でも、分析が進むにつれて一部が明らかになる場合があります。ただし、従業員とプロジェクトの場合、attributes-勤務時間-その関係のために追加する必要があるため、関連エンティティを作成してmustを解決する必要があります。それらを表示します。したがって、Project Assignmentという名前の関連エンティティを作成します。しかし、まだ終わっていません。要件では、作業時間週あたりを知る必要があります。考えてみると、プロジェクトの存続期間はmany週間であり、そのプロジェクトでその従業員が費やした時間を記録する必要がありますeach week 。したがって、別のエンティティタイプが必要です。これはHours Workedと呼ばれ、プロジェクトの割り当てごとに多数発生します。このエンティティタイプは、週の終了日と勤務時間を保持します。
次に、ロケーションエンティティタイプを作成することにより、部署に複数のロケーションが含まれる可能性があることを示す要件は、1つの部署に多数のロケーションを設定できるという関係が存在することを意味します。 1つの場所で多数の部門が運営されていると想定するのも安全です。したがって、これを示すためにOperating Siteと呼ばれる別の関連エンティティを追加しました。
属性を見つける
属性は、次のようなステートメントで要件にかなり明確にリストされています。
- 各部門には名前、一意の番号、
- 従業員が部門の管理を開始した開始日の追跡
- プロジェクトにはそれぞれ名前、一意の番号、
- 各従業員の名前、SSN、住所、給与、性別、DOBを保存します。
- 従業員が各プロジェクトに従事する1週間あたりの時間数を追跡します。
- 各扶養家族の名の性別、DOB、および従業員との関係を維持します。
この時点で私が行うことは、識別されたエンティティと関係をリストアップし、それが属しているエンティティタイプで識別された属性を配置することです。
- Department-番号、名前
- 従業員-名前、SSN、住所、給与、性別、DOB
- 場所-???
- プロジェクト-番号、名前
- 依存-名、性別、DOB、関係
注：場所のany属性が見つかりません。これは、ビジネスに戻って場所に関するいくつかの追加情報を取得するための危険信号です。
次に、関係とその属性をリストします。
- 従業員manages部門-開始日
- 部門コントロールプロジェクト-
- 従業員担当者部署-
- 従業員作業日プロジェクト-1週間あたりの時間
- 従業員has従属-
- 部署has場所-
これらの最後の2つの関係の場合、動詞hasはあまり説明的ではありませんが、それが要件の言い方でした。エンティティhas属性ですが、なぜこれらが属性にならないのですか？場所をエンティティタイプにすることを選択する理由については、前に説明しました。扶養家族の場合、各従業員にmany扶養家族がいることは明らかなので、選択はより明確であり、したがって、それは独自のエンティティに分割する必要があります。これが完了すると、動詞を改善するために飛躍することができます。おそらく、従業員気遣う従属および部門[で動作する場所のようなものでしょう。
これで図を作成する準備が整いました。これが私が持っているものです： 
これは、 Oracle SQL Developer Data Modeler （無料ダウンロード）を使用して作成されました。これは、データベースの設計と作成にプロセスを継続する場合に最適なツールです。
主キー
主キーを識別しました。技術的には、ERDはキーを考慮する必要さえありません。 ERDをビジネスをモデル化するツールと考える場合、この時点で正確に決定することは重要ではありませんhow各エンティティの発生を一意に識別します。代わりに、後の時点でwillがこれを理解し、代わりにエンティティ、それらの関係、およびそれらの属性のみに焦点を当てると仮定できます。どの属性areはエンティティごとに一意であることに注意してください。これにより、キーの選択に役立ちます。ダイアグラムを完成させ、ビジネスでそれを繰り返すと、戻って正しいキーを選択することで完成させることができます。私の図では、要件で一意であると記載されている2つの番号は、属性名の横にあるUを使用して図上で一意であることにのみ言及しました。
エンティティの役割
次に、前述の濃い緑色で強調表示された監督者について説明します。要件には、「部門にはその部門を管理する従業員がいる」とありました。さらに、「各従業員の直属の上司も追跡しています」と述べています。したがって、ここにあるのは、さまざまな役割を果たしているエンティティ-人-です。従業員はmanagerである可能性があります。従業員はsupervisorである可能性があります。では、これをどのように解決するのでしょうか？まず、managerとsupervisorが同じかどうかを判断する必要があります！部署のmanagerが、それに割り当てられた従業員のsupervisorでもあるのですか？はいの場合、解決策は簡単です。 Assigned Managerと呼ばれる新しいエンティティタイプは、部署から部署、従業員から部署への1対多の関係で作成でき、その従業員がその部署の管理を開始した開始日の単一の属性を持ちます。次に、各従業員の上司は、割り当てられている部門のマネージャーと見なされます。いいえの場合、上司と従業員を表すために、従業員から従業員への再帰的な関係を追加できます。これは最も単純なアプローチですが、同じエンティティタイプに役割が混在することになります。より良いアプローチは、従業員からその2つの1対多の関係を持つAssigned Supervisorと呼ばれる新しいエンティティタイプを追加することです。1つは監督者を表し、もう1つは監視対象を表します。割り当てが開始および終了した日付がある場合、これも追加できます。
結論
うまくいけば、これを開発に使用したプロセスの説明と組み合わせることで、ビジネスプロセスの説明からドラフトERDに至るまでの理解に役立つ学習ツールになりますhowdraftと言いますが、これは単なる出発点です。完了すると、要件の検証、それらの穴の発見、新しいものの発見などの通信手段として機能しますbeforeプログラミングまたはシステム設計が始まります。誤解されている要件を実装するシステムを構築する素晴らしい仕事をすることは失敗であり、動作中のシステムよりもERDを変更する方がはるかに安くなることを忘れないでください！
参考文献
ERダイアグラムの2つの非常に優れたリファレンスは、すばらしい概要であるSteve Hobermanの Data Modeling Made Simple とDavid Hayの Enterprise Model Patterns 。これは、組織を分析するときに見つけた一般的なパターンを非常に詳しく調べることができます。これらの参考資料はどちらも、動詞と前置詞句を使用した関係の説明、関係の識別と非識別、強固なエンティティと弱いエンティティ-私が対処しなかった概念についての詳細を示しています。 Fabian Pascalの Practical Database Foundation Series も優れており、Fabianがデータ要件を決定するプロセス全体を説明しているため、本に対する完全な賛辞である素晴らしい最初の論文があります。 ERダイアグラムはキーと参照のみを表示できることに注意してください。実際、究極のデータベースで調査および実装できるビジネスルールの種類は他にもたくさんあります。
学習の精神で、これは宿題ですので、図を提供せずにフィードバックを提供します。 SqlServer固有の用語もいくつか使用しますが、最小限の調査で私が言っていることを理解できるはずです。
私にすぐに飛びついたのは、PSNとしてのSSNの使用です。理論的には個人を特定できる少しユニークな情報であるため、これは素晴らしいアイデアのように思えます。残念ながら、あなたがそれらを許可した場合、データベース内のデータを悪用する悪い人々が世界中にいます。そのため、重要な情報をプレーンテキストとして保存したくありません。したがって、SSNが暗号化されていることを伝える必要があります。もう1つは、別のテーブルでFKとしてPKをよく使用することです。データが暗号化されていても、機密データをテーブル全体に分散させたくありません。
これは私の次の一般的なアドバイスにつながります。 IDENTITY/GUIDテーブルのPKとしてEmployeeまたはDependantを使用します。トレードオフについてのディスカッション here および here を見ることができます。私は個人的にIDENTITY列を支持する傾向がありますが、多くの正当な理由でそれに同意しない人がたくさんいます。
また、プロジェクトごとの週あたりの時間を考慮していないようです。現状では、EmployeeにはEmployee Weekly Hoursがあります。代わりに、プロジェクトごとに数時間かかる必要があります。
最後に、列名WeeklyHoursまたはweekly_hoursは、実際の読みやすさを向上させるためにスペースを名前のエスケープが必要になるため、Weekly Hoursよりもすべての人にとってはるかに優れています。また、テーブル名を列名の前に付ける必要はありません。つまり、EmployeeSalary bad、Salary goodです。同様に、より包括的な性別/性別オプションが必要な場合を除き、DependentSexはIsMaleよりも劣ります。この場合、オプションを含むテーブルが必要です。
Startの場合、依存テーブル（Identity/Autonumber）の主キーとしてDependent Idが必要です。
従業員が複数のプロジェクトで作業している場合、従業員とプロジェクトのルックアップテーブルが必要です。従業員をプロジェクトに直接リンクしないでください。
Projectと同じように、Departmentに複数の場所がある場合は、場所と部門間のルックアップを維持するために別のテーブルが必要です。
従業員の労働時間を保存するには、タイムシートテーブルが必要です。これには、プロジェクトの外部キーも含まれます。 （作業の開始時刻と終了時刻を入力し、計算フィールドを使用して時間を計算することで、次のレベルに進むことができます。