エンティティ関係図をモデリングしていて行き詰まりました。私の考慮事項が間違っているのか、ERD が私が望むものをモデル化できないのかはわかりません。
Employee、Project、Role の 3 つのエンティティがあります。従業員とプロジェクトの間には関係があります。従業員はプロジェクトに取り組んでいます。しかし、この従業員はこのプロジェクトに取り組んでいるだけでなく、役割として与えられた運用分野を持っています。しかし、関係は属性によって記述されているだけではありませんか? 「従業員がこのプロジェクトで...として働いている」のようなものを作成するにはどうすればよいですか? もちろん、データベースとして設計するので、roleId を属性として使用しましたが、ERD での関係は何ですか?
従業員がプロジェクトごとに 1 つのロールしか持てない場合:
従業員がプロジェクトごとに 1 つ以上のロールしか持てない場合:
2 つの違いは、後者のバージョンでは複合主キーにロールが含まれていることです。3 つの列すべての複合主キーであるため、値の組み合わせは一意である必要があり、次のことが有効になります。
project_id employee_id role_id
---------------------------------
1 1 1
1 1 2
一方、複合主キーにrole_id が含まれていない場合、ユーザーとプロジェクトの組み合わせは1 つしか作成できません。つまり、ユーザーは 1 つのロールしか持つことができません。
CHECK 制約は機能しません。テーブル全体ではなく、行のみをチェックします。トリガーは機能しますが、複合主キーまたは一意の制約を介して関係を強制できるのに、なぜ気にする必要がありますか? CREATE TABLEトリガーは、ERD や、やなどのステートメントでは表示されませんDESC table_name。
データベースを設計する前に、問題を実体関連図としてモデル化したいと思います（Chenの表記法を使用）。この図では、以下のキーと制約を見ずに、従業員とプロジェクトの関係を作成したいと思います。補遺：属性によって拡張される2つのエンティティ間の関係を知っているだけですが、この「3つのエンティティの関係」をモデル化するにはどうすればよいですか？
それは完全に理解でき、非常に正しいです。紙は安価で、データベース内のオブジェクトは変更するのに少し費用がかかります。要件をモデル化し、自信が持てるようになるまで改善を続けてから、実装します。
多くのサイトの問題は、多くの大工が、善意を持っていても、すべての問題を釘と見なし、要求されたモデリング支援ではなくDDLを提供していることです。欠落しているのはコンテキストと意味であるため、最終的には、固定された「キー」を使用したハードで高速な実装になりますが、コンテキストと意味が不足しています。モデリングにより、DDLでどのように表示されるかを気にすることなく、関連するさまざまな側面をモデリングできます。
別の言い方をすれば、OMGは、「従業員がこのプロジェクトに取り組んでいる...」をどのようにモデル化するかという1つの質問に答えています。隔離中; 私はあなたの質問全体に文脈の中で答えています。
論理レベルでは、多対多の関係は正しいです。他の考慮事項のないこのような関係は、物理レベルで連想テーブルとしてレンダリングされます。しかし、繰り返しになりますが、関係のコンテキストと意味をまだモデル化しているため、それを決定するのは時期尚早です。
...それを提供することもSOマークダウン表記の領域内ではありません。IME、Oracle Designerなどのツールは、エンティティを作成した後にそのような図を生成します
ナンセンス。モデリングの全体的な考え方は、コード行を記述したり、プラットフォームを購入したり、DDLを実装したりするずっと前に、図を使用して紙の上で何かを開発および改善することです。コメントは、多くの製品が提供している事後の既存のデータベースを単にリバースエンジニアリングすることに関するものです。
必要なものをモデル化するために、自分にとって意味のある記号を使用してください。もちろん、標準的な記号はもっと普遍的に理解されています。これがあなたのための
ERDです
（「SOマークダウン表記」が事前のモデリングアドバイスを提供する上でどのように制限をもたらすのか私にはわかりません）。発生する可能性のある進行の例を示しました。「正しい」または「間違っている」ものは何もありません。それはすべて紙片です。確認する価値のある要素を決定するまで、次の進行が可能です。
もちろん、出発点は、タイトルごとに、いくつかのことを知っている単純な多対多の関係です。概念的な3方向の関係をモデル化しようとすると、モデル化エラーが発生します。三角関係を解決するには、最初に各当事者間の離散的な関係を個別に識別する必要があります。つまり、すべての関係は双方向のみです。
プロジェクト、従業員、役割のエンティティは明確であり、私たちはそれらについて何か知っています。ここでは、主要なエンティティは「強力」であり、あなたが焦点を当てているものではないため、未開発のままにしておきます。
プログレッションはリレーションのサンプル属性を使用します。独自の属性を使用できます。（私たちのベルギー人の同僚はすでに問題を言葉で特定しています。私はそれを写真で提供しているだけです。）人々が一般的な慣習で行わないこと、彼らがすべきことはたくさんあります。私は、正しいデータモデルに到達するために、上から下へと真のモデリングを行うことを懸念しています。ゴミを取り除き、作業を続けます。
リレーションの属性がエンティティを正当化すると仮定したので、それらを描画しました。ここでは、楕円を使用しました。必要なものをモデル化するために、必要なものをモデル化するために、必要なものすべてにダイヤモンドまたはシェブロンを使用できます。 。
ここで、はっきりとわかるポイントがあります。Project:: Employee :: Roleは必要ありません。これにより、従業員が任意の役割を実行できるようになるためです。従業員は、以前にその役割が承認されている場合にのみ選択されるようにします。したがって、Employee::Roleは「より強く」なりつつあります。
したがって、Employee::Roleはエンティティです。ピンクのThingは、その特定の組み合わせまたはEmployee + Roleの子であり、すべてのEmployeeまたはすべてのRoleの子ではありません。
同様に、私たちは、従業員が可能なプロジェクトで可能な仕事を引き受けることを望んでいません。承認されたプロジェクトで承認された仕事のみを引き受けることを望んでいます。つまり、Project :: Roleは強力なアイデンティティになりつつあり、とにかく属性があります。
したがって、Project::Roleはエンティティです。そして、残りの楕円形は、すべてのプロジェクトではなく、プロジェクトと役割の特定の組み合わせの子です。
ピンクの子は、特定の属性でエンティティステータスを取得します。さらに重要なことに、その制約は、単純なエンティティではなく、以前に制約されたエンティティから派生しています。
データには自然な順序または階層があり、それを念頭に置いて描かれた図は非常に理解しやすいものです。これで、属性を確認する機会があります。それらは同じか、似ているか、混乱しているように見えたかもしれません。一方、コンテキストと階層により、現在は明確な意味があります。
識別子の概念を紹介しましたが、拡張せずに、必要に応じて議論に残しておきます。識別子は実際には非常に重要であり、モデリング演習の通常の部分として公開されていることがわかると思います。
一般的に言えば（私の例の進行とは対照的に、あなたの質問）、正規化に到達すると、3つの最初の楕円は1つまたは2つになるか、3つのオブジェクトのままになる可能性があります。属性のない単純な連想テーブル。または属性を持つ真のエンティティとして...しかし、私たちはそうではなく、今はそれを気にするべきではありません。繰り返しになりますが、この段階では、DDLまたは正規化には時期尚早です。キーが何であるかはほとんどわかりません。それらに関連付けられている属性。そしてそれらとどのような関係にありますか。さらに、私たちは気にしません。例に関しては、はい、エンティティは明確で明確です。
あなたが進歩できるように、フィードバックをお願いします。
編集：図が更新され、複数ページになります。
「データベースを設計する前に、エンティティ関係図として問題をモデル化したい (Chen の表記法を使用)。この図では、従業員とプロジェクトの間の関係を作成したいと考えており、その後のキーと制約を確認する必要はありません。」
2 つ (従業員とプロジェクト) の間の「有効な」関係が多対多であり、かつその関係に、その関係 (の発生) を説明する (/詳細を提供する) 追加の属性がある場合、多くの場合、他の属性はありません。リレーションシップを「インスタンス化」する、つまり追加のエンティティとして定義する以外に選択肢はありません。一部のツールは、任意のリレーションシップに追加の属性を指定できる ERD ダイアレクトをサポートしています (丸みを帯びたボックスでリレーションシップの矢印に向かう) が、これは一般的な方法ではありません。