ERデータモデルの概要

実体関連データモデルのシンプルだが包括的な概要

ザ・実体関連データモデル、 とも呼ばれているER、はさまざまなものの1つですデータモデルデータについて推論するために使用できます。

特に、それは概念データモデル、特定の実装にリンクされていないため。それは論理データモデルに任された仕事です。

ザ・ERデータモデル非常に一般的で高レベルであるため、さまざまなまったく異なる種類のデータベースで実装できます。

実装の詳細については考えず、代わりに考えているだけなので、すばらしいです。あなたのデータとそれがどのように編成されているか。そしてそうしている間、あなたはあなたが前に考えなかった方法で問題を分析することを余儀なくされます。

ERダイアグラムは、データが関係するシナリオの分析に役立つと思います。

ERモデルは、グラフィカルな表記法を使用して、モデル化する必要のあるすべてのデータ、さまざまな種類のデータ間の関係、およびそれに関連する情報を表すためのツールを提供します。

ERモデルを構成する2つのアイテムがあります。

  • インクルードエンティティ
  • インクルード関係

エンティティは、アイテムや人など、共通のプロパティを持つデータのタイプです。

関係は、エンティティ間の関係です。

例を挙げましょう。本とその著者について話しましょう。我々は持っています2つのエンティティ

  • 著者

特定の本は、本エンティティのインスタンスです。

2つのエンティティがあるため、2つの関係それらの間の。 1つは、1冊の本と著者エンティティとの関係です。 1つは、1人の著者と本の実体との関係です。私たちがそれについて考えるならば、wreは持っています:

  • 本には著者がいます
  • 著者は多くの異なる本を書くことができます

エンティティの視覚的表記

この簡単な例を考えると、シナリオのERデータモデルの作成に役立つ視覚的な表記法の導入を開始できます。

注:ER図を描くにはさまざまな方法があります。私はそれを使用します、私の考えでは、より視覚的で、より理にかなっています。

エンティティは長方形として表され、エンティティを識別するためのテキストが含まれています。

Entities

関係の視覚的表記

エンティティ間の関係は、最も基本的な形式で、2つの関係を結ぶ線と、関係のタイプを識別するためのテキストを含むひし形を使用して表されます。

Relation example

「本には著者がいる」と「著者が本を書いた」という2つの関係を作成しなかったことに注意してください。私は本と著者の間に「著者」という単一の関係を作りました。

カーディナリティ

関係ができたら、関係する番号を指定する必要があります。現時点では、多くの質問があります。

  • 本には何人の著者がいますか?
  • 著者は複数の本を書くことができますか?
  • 著者は、著者と呼ばれるために少なくとも1冊の本を書く必要がありますか?
  • 複数の著者が本を書くことはできますか?
  • 少なくとも著者がいなくても本は存在できますか?

これらはすべて質問するのに良い質問です。この場合、答えはかなり明白だと思います。そして、答えが明らかでない場合は、問題について考え、独自の制約を追加することができます。

ダイアグラム上でカーディナリティを視覚的に示すには、さまざまな方法があります。エンティティにリンクするときに線の形状を変更することを好む人もいます。

私は物事をより明確にする数字を好みます:

Cardinality example

上記の数字はこれを意味します:本は1人以上の著者によって執筆されることができます。n任意の数の要素を意味します。

そして、著者は0冊の本(多分今1冊を書いている)から無限の数の本まで執筆することができます。

最初のものはと呼ばれますゼロ対多の関係。 2番目は1対多の関係

私達はまた持つことができます:

  • 1対1の関係
  • 多対多の関係
  • ゼロ対1の関係

属性

各エンティティは、1つ以上の属性を持つことができます。

書店で上記の関係を使用するとします。各著者には、名前、経歴、ウェブサイトのURLがあります。

各本には、タイトル、出版社、発行年、ISBNがあります。必要に応じて、発行者をエンティティにすることもできます。しかし、それを本の属性として定義することもできます。

上記の情報を表す方法は次のとおりです。

Attributes example

識別子の属性

エンティティは一意のキーで識別される必要があります。ブックエンティティは、ISBN属性によって一意に識別できます。すべての本には単一のISBNがあります(本の単一のコピーではなく、本の「タイトル」を表すことを考慮して)。

主キー属性は、それらの基礎となるものによって識別されます。

Key

一方、作成者は現時点では一意の識別子を持っていません。 2人の著者が同じ名前を持つことができます。

したがって、一意のキー属性を追加する必要があります。たとえば、id属性:

id attribute

識別子属性は複数の属性にまたがることができます。

たとえば、パスポートIDと作成者の国は個人を一意に識別し、id追加した属性:

multiple attributes key

どちらを選択しますか?それはあなたのアプリケーションで何がより理にかなっているのかという問題です。書店をモデル化している場合、すべての本の著者の国とパスポートIDを取得することは期待できません。したがって、ランダムを使用しますid各著者を選択して関連付けます。

関係属性

属性はエンティティに固有ではありません。リレーションにも属性を含めることができます。

ライブラリをモデル化する必要があると考えてください。本と著者のエンティティに加えて、リーダーエンティティ、本を借りて読む人。彼らがそれを借りるとき、私たちはその名前とIDカード番号を取ります:

relation without attribute

しかし、私たちはまだ情報を逃しています。特定の本のすべての履歴に関する情報を図書館に保存できるように、その人がいつ本を借りたのか、いつ返却したのかを知る必要があります。この情報は、本または読者のエンティティのいずれにも属していません。それは関係に属します:

relation attributes

弱いエンティティ

上記の主キーと、ヘルプがエンティティを一意に識別する方法について説明しました。

一部のエンティティは、その存在を他のエンティティに依存しており、弱いエンティティ

オンラインショップの注文をモデル化する必要があるとします。

注文ごとに、1から始まり、時間の経過とともに増加する注文ID、注文の日時、顧客に関する情報が保存されるため、請求先と発送先がわかります。

次に、彼らが何を注文したかを知る必要もあります。チェックアウト時にカート内の各アイテムを表す弱いエンティティ「注文アイテム」を作成します。

weak entity

このエンティティは、チェックアウト時のアイテムの価格(したがって、販売中の製品の価格を変更しても、すでに行われた注文には影響しません)、注文されたアイテムの数量、および選択されたオプションを保存します。 Tシャツを販売しているため、注文したTシャツの色とサイズを保存する必要があるとします。

注文されたアイテムエンティティは注文エンティティなしでは存在できないため、これは弱いエンティティです。

漸化式

エンティティは、それ自体と再帰的な関係を持つことができます。個人エンティティがあるとします。このようにして、親子関係をモデル化できます。

recursive relation

1人の子供は0〜n人で、子供には2人の親がいます(最も単純なシナリオを考慮)。

ISA関係

ISAはIS-Aの略で、ERモデルで一般化をモデル化する方法です。

これを使用して、類似のエンティティを共通の傘下にグループ化します。たとえば、本や図書館の例の場合、著者と読者は、personエンティティを使用して一般化できます。

どちらにも名前があるため、personエンティティまで名前を抽出し、対応するエンティティの作成者または読者であるという特性を管理します。

isa relation

非二項関係

すべての関係が厳密にバイナリであるわけではありません。レッスンのシナリオを見てみましょう。

授業は本日10:00に学校の部屋で行われ、先生が物理についてクラスで話します。

そのため、レッスンは1日の特定の時間に行われ、科目、教師、クラス、および部屋が含まれます。

このようにモデル化できます。

non-binary relation


その他のデータベースチュートリアル: