ER（エンティティリレーションシップ）図、そのパーツ、およびそれを作成するときによくある問題について理解します。
リレーショナルデータベースモデルを作成したことがありますか？それとも、最初のものを作成しようとしていますか？実際の問題をデータベースロジックに変換するのは非常に難しい場合があることをご存知でしょう（またはすぐにわかります）。
役立つ可能性のあるツールの1つは、ER図です。一般的なデータベース設計の知識では、ERダイアグラムが優れているほど、データベースモデルの構築が容易になると考えられています。この重要なアイテムは、将来のすべての欲求不満や成功のトーンを設定します。優れたERダイアグラムがあれば、リレーショナルデータベースモデルの作成は非常に簡単です。もちろん、データベースモデリングのどの段階でも間違いを犯す可能性があります。ただし、優れたERダイアグラムがあると、これらの間違いのいくつかを回避するのに役立ちます。
それでは、ERダイアグラムとは何か、そしてそのよくある間違いを回避する方法を見てみましょう。
ER図とは何ですか？
「ERダイアグラム」（ERD）は、エンティティリレーションシップダイアグラムの略です。モデル化する問題をマップしますが、エンティティ間の関係を示す構造化された方法でマップします。
ER図の構成要素
ER図は次の要素で構成されています：
- エンティティ
- 関係
- エンティティまたは関係の属性
ER図の最初の要素はエンティティです 。エンティティは、情報を保存するオブジェクトまたはオカレンスです。基本的に、それは私たちがデータを収集できるものなら何でもです。たとえば、従業員、学生、教師、購入者、製品、部門、支払い、場所などに関するデータを保存する場合があります。
エンティティができたら、関係を作成する必要があります 。関係は、1つのエンティティが1つ以上の他のエンティティにどのように接続および関連付けられているかを示します。
ER図の最後の要素は、エンティティまたは関係の属性です。 。属性は、エンティティまたは関係に属するプロパティの説明です。属性には値があります。上記のエンティティの属性には、次のようなものがあります。
- 従業員、学生、教師、購入者 – ID、名前、名前、生年月日、住所など。
- 製品 – ID、カテゴリ、説明、色、シリアル番号など。
- 部門 – ID、部門名、部門長、従業員数など。
- 支払い – ID、日時、金額。
- 場所 –都市、郵便番号、地域、国、大陸。
関係の種類
ERダイアグラムに見られる通常の間違いに入る前に、考えられる関係の種類を理解することが重要です。ほとんどのERDミスは、本質的にエンティティ間の誤って定義された関係です。
エンティティ間の関係には次の3つのタイプがあります。
- 1対1（1：1）
- 1対多（1：N）
- 多対多（M：N）
1対1（1：1）の関係
最初の関係タイプは1対1です。 、または 1：1 。この関係では、あるエンティティの単一のインスタンスは、別のエンティティの単一のインスタンスにのみ接続できます（もちろん、その逆も可能です）。
エンティティstudentがあるとします。 属性name および名前 。エンティティidもあります 唯一の属性id 。 1：1の関係は、1人の学生が1つのID番号しか持てないことを意味します。また、1つのID番号が1人の学生にのみ属することができることを意味します。
この関係は、データベースではめったに見られません。 1人の学生と1人のIDしか接続できない場合は、IDを2つの異なるエンティティに分ける必要はありません。
この関係の例を次に示します。
1対多（1：N）の関係
最も一般的なタイプのデータベース関係は、1対多です。 または1：N 。 1対多の関係とは、あるエンティティの各単一インスタンスを別のエンティティの複数のインスタンスに接続できることを意味します。また、2番目のエンティティのすべてのインスタンスを最初のエンティティの1つのインスタンスにのみ関連付けることができることも意味します。
たとえば、エンティティ購入者があります 属性id 、名前 、および名前 。エンティティとの関係を確立したい支払い 属性がidである 、日付 、および値 。 1人の購入者が1回または複数回の支払いを行うことができるため、これは1：Nの関係です。ただし、複数の購入者が1回の支払いを行うことはできません。 1人のバイヤーだけが作ることができます。
例を次に示します。
この関係は、逆の場合にも見られます。この状況では、多対1と呼ばれます またはN：1 。もちろん、これは新しいタイプの関係ではありません。 1：Nと同じですが、反対方向から見ています。
例として、エンティティ employee があるとします。 属性id 、名前 、および名前 。 従業員を設立したい のエンティティとの関係部門 属性がidである および名前 。これら2つのエンティティ間の関係はN：1です。つまり、すべての従業員は1つの部門でしか作業できませんが、複数の従業員は同じ部門で作業できます。
多対多（M：N）の関係
多対多 またはM：N 関係とは、最初のエンティティのすべてのインスタンスを2番目のエンティティの複数のインスタンスに関連付けることができることを意味します。また、2番目のエンティティのすべてのインスタンスを最初のエンティティの複数のインスタンスに関連付けることができることも意味します。
これがエンティティ間でどのように機能するかを見てみましょう学生 および講義 。 学生としましょう 属性idがあります 、名前 、および名前 。エンティティ講義 属性idがあります および名前 。多対多の関係は、次のように解釈できます。1人の学生が1つ以上の講義に参加でき、1つの講義に1人以上の学生が参加できます。
この例の図は次のとおりです。
データベースモデリングでは、このような関係は通常、新しいエンティティを導入することにより、2つ以上の1：NまたはN：1の関係に分割されます。
ER図を作成する際の一般的な間違い
多くのERダイアグラムの間違いは、次の4つのカテゴリのいずれかに当てはまります。
- エンティティ間の不適切な関係
- エンティティの代わりにエンティティインスタンスを使用する
- 属性とエンティティの混同
- 複雑な属性
それぞれを個別に見てみましょう。
エンティティ間の不適切な関係
最も一般的な間違いは、エンティティ間の関係を定義するときに発生します。 。通常、1：1の関係に間違いはありません。ただし、1：Nの関係とM：Nの関係を混同するのは非常に簡単です。これは通常、エンドユーザーが提供する要件を理解していないことに起因します。要件を非常に明確に定義し、データベースが必要な理由とその使用方法を深く理解することが重要です。データが不十分で理解が不十分なERダイアグラムを作成すると、エンティティ間の関係が誤って定義される可能性があります。
例を見てみましょう。銀行のデータベースを作成する場合は、エンティティ clientを使用してER図を作成する可能性があります。 属性idを持つ 、名前 、および名前 。 アカウントというエンティティもあります 属性id およびタイプ 。銀行業界での経験が不足している場合は、クライアント間に常に1：Nの関係があると思うでしょう。 およびアカウント 以下に示すように、エンティティ。
1人の顧客が1つの銀行に複数の口座を持つことができます。ただし、アカウントを所有できるのは1人の顧客のみです。これは実際に本当ですか？多分そうです、多分そうではありません。非常に多くの銀行が、複数のクライアントが使用できる共同口座を提供しています。そのようなサービスを提供する銀行のER図を作成していますか？銀行が共同口座を提供していない場合、あなたは正しいです：クライアント間の関係 およびアカウント は1：Nです。ただし、銀行が共同口座を提供している場合、関係はM：Nです。
エンティティの代わりにエンティティインスタンスを使用する
もう1つのよくある間違いは、エンティティの代わりにエンティティインスタンスを使用することです。エンティティインスタンスは、特定のエンティティの1つのオカレンスです。つまり、実際にはより大きなカテゴリの属性である可能性があります。
たとえば、特定の従業員に携帯電話とラップトップを割り当てる会社で働いているとします。したがって、データベースには、ラップトップというエンティティがあります。 属性id およびモデル およびemployeeというエンティティ 属性id 、名前 、および名前 、 右？
ここに問題があります。ラップトップは実際には実体ではありません。説明する携帯電話もあります。解決策は、エンティティラップトップを置き換えることです 機器などのより一般的なエンティティを使用する 。このエンティティは、属性 IDを持つことができます 、タイプ 、およびモデル 、以下に示すように。 タイプ phoneなどの値で構成できます 、 PC 、タブレット 、およびラップトップ 。このように、機器の種類ごとに個別のエンティティを作成する必要はありません。
ここに例があります：
属性とエンティティの混同
次のよくある間違いは、属性とエンティティを混同することです。 employeeというエンティティを作成することにしたとしましょう。 これは、属性 idで構成されます 、名前 、名前 、 date_birth 、 id_department 、 name_department 、および head_department 。このエンティティは、この特定のエンティティを一意に定義しない属性が多すぎるため、データベースモデルを作成するときに問題が発生します。 。
エンティティは、データを収集できるものとして定義したことを忘れないでください。そのことを念頭に置いて、現在の従業員 エンティティは2つのエンティティに分割できます：従業員 および部門 、以下に示すように。
複雑な属性
ここで説明する最後のよくある間違いは、エンティティに複雑な属性を含めることです。つまり、実際には独自のエンティティである必要がある属性があります。 。
studentというエンティティがあるとします。 これは、次の属性によって定義されます： id 、名前 、名前 、 date_birth 、アドレス 、および Exam_passed 。ここでは、 Exam_passed は、複数の情報、つまり試験IDと日付、および学生のスコアで構成される複雑な属性です。そのままにしておくのは間違いです。代わりに、新しいエンティティを作成する必要があります この複雑な属性から 。新しいエンティティには、 Examsという名前を付けることができます。 次の属性で構成されます： id 、日付 、 student_id 、およびスコア 。
ここに例があります：
ER図の便利なヒントはありましたか？
これらの4種類の間違いは、ER図の作成プロセスで最も一般的な間違いです。もちろん、典型的な間違いや間違いの種類の完全なリストはありません。実生活では、さまざまなミスが発生する可能性があります。計画の欠如、不十分な技術サポート、および急いでいるデータベース設計プロセスはすべて、独自の問題を引き起こします。データベースを作成したり、ビジネス側からデータベースに参加したことがある場合は、おそらくそれらのいくつかを経験したことがあります。これらすべての状況はさまざまな間違いにつながりますが、その中には非常にユニークなものもあります。
あまり良くないER図の独自の例はありますか？それとも、あなたが頻繁に見つける他のいくつかの間違いがありますか？コメント欄で教えてください。