Free Press

実体関係（ER）データモデルは35年以上前から存在する。 かなり抽象的であり、議論や説明がしやすいので、データベースで使用するデータモデリングに適しています。 ERモデルは容易に関係性に変換できる。 ERスキーマとも呼ばれるERモデルは、ERダイアグラムで表現されます。

ER モデリングは2つの概念に基づいています。

• エンティティ、特定の情報（データ）を保持するテーブルとして定義されます
• 関係、エンティティ間の関連または相互作用として定義されます

ここに、これら二つの概念がどのようにして ERデータモデルで組み合わせられるかという一例があります。 Ba教授（実体）がデータベースシステムコース（実体）を教える（関係）

この章の残りの部分では、COMPANYデータベースというサンプルデータベースを使用して、ERモデルの概念を説明することにします。 このデータベースは、社員、部門、プロジェクトに関する情報を含んでいます。 重要なポイントは以下の通りです。

• 会社にはいくつかの部門があります。
• 部門はいくつかのプロジェクトを管理し、それぞれのプロジェクトは固有の名前、固有の番号、予算を持っています。
• 各社員は名前、識別番号、住所、給料、生年月日を持っています。 社員は1つの部門に配属されますが、複数のプロジェクトに参加することができます。 各プロジェクトにおける従業員の開始日を記録する必要があります。
• 各従業員の扶養家族を記録しておきたいと思います。

エンティティ、エンティティセット、エンティティタイプ

エンティティとは、他のオブジェクトと区別できる独立した存在を持つ、現実世界のオブジェクトのことです。 エンティティは

その強さに基づいて分類されることがあります。

• つまり、他のエンティティとの関係なしでは存在できません。
• その主キーは親エンティティの主キーから派生します。
  • COMPANY データベースの Spouse テーブルは、その主キーが Employee テーブルに依存しているので、弱いエンティティです。 対応する従業員レコードがなければ、配偶者レコードは存在しません。

  関連するすべてのエンティティから分離して存在できる場合、エンティティは強いと見なされます。

• 外部キーのないテーブル、またはヌルを含むことができる外部キーを含むテーブルは強いエンティティです

知っておくべきもう一つの用語は、類似したエンティティのコレクションを定義するエンティティタイプです。 エンティティ関係図（ERD）では，エンティティタイプはボックス内の名前で表現される。 例えば、図8.1では、エンティティタイプはEMPLOYEE.

のERD 存在依存性

エンティティの存在は、関連エンティティの存在に依存します。 必須外部キー（すなわち、NULLにできない外部キー属性）を持っている場合、それは存在に依存します。 例えば、COMPANYデータベースでは、SpouseエンティティはEmployeeエンティティに存在依存します。

Kinds of Entities

また、独立エンティティ、従属エンティティ、特性エンティティなどの異なる種類のエンティティに精通している必要があります。

独立エンティティ

独立エンティティはカーネルとも呼ばれ、データベースの基幹となるものである。 これらは他のテーブルが基づいているものです。

主キーは単純でも複合でもかまいません。

私たちがCOMPANYデータベースを参照する場合、独立エンティティの例には、Customerテーブル、Employeeテーブル、Productテーブルがあります。

依存エンティティ

派生エンティティとも呼ばれる依存エンティティは、その意味を他のテーブルで依存します。

多対多の関係は、少なくとも2つの外部キーを持つ連想テーブルになります。

主キーには3つのオプションがあります。

1. 一意であれば関連テーブルの外部キーの合成を使用する
2. 外部キーと修飾列の合成を使用する
3. 新しい単純な主キーを作成する

Characteristic entities

別のテーブルについての詳細情報を提供するもので、このエンティティは、関連テーブルの外部キーと修飾列の合成を使用します。 これらのエンティティには次の特徴があります。

• 多値の属性を表します。
• 外部キーは、特徴づけられたテーブルをさらに識別するために使用されます。
• 主キーのオプションは次のとおりです：
  1. 外部キーと修飾列の複合を使用する
  2. 新しい単純な主キーを作成する。 COMPANY データベースでは、次のようなものがあります。
     • Employee (EID, Name, Address, Age, Salary) – EID は単純な主キーです。
     • EmployeePhone (EID, Phone) – EID は複合主キーの一部分です。 ここでは、EIDは外部キーでもあります。

Attributes

各エンティティは、一連の属性（例： Employee = (Name, Address, Birthdate (Age), Salary) ）によって記述されます。

それぞれの属性には名前があり、エンティティや法的値の領域と関連付けられています。

図8.2に示す実体関係図では、各属性は内部に名前を持つ楕円で表されます。

Types of Attributes

There are a few types of attributes you need to be familiar with.属性には、いくつかの種類があります。 これらの中にはそのままにしておくものもありますが、リレーショナルモデルでの表現を容易にするために調整する必要があるものもあります。 この最初のセクションでは、属性の種類を説明します。 後ほど、リレーショナルモデルに正しく適合するように属性を修正することについて説明します。

単純属性

単純属性とは、原子値の領域から引き出されたもので、単一値属性とも呼ばれます。 COMPANYデータベースでは、このような例となる。 Name = {John} ; Age = {23}

複合属性

複合属性とは、属性の階層構造からなるものである。 図8.3に示すデータベースの例では、AddressはNumber、Street、Suburbから構成されるかもしれません。 ですから、これは → Address = {59 + ‘Meek Street’ + ‘Kingsford’}

多値属性

多値属性は、各エンティティに対して一連の値を持つ属性です。 図8.4に見られるように、COMPANYデータベースからの多値属性の例は、従業員の学位です。 BSc, MIT, PhD.

派生属性

派生属性は、他の属性から計算された値を含む属性です。 この例は図8.5で見ることができます。 AgeはBirthdate属性から派生させることができます。 この状況では、Birthdateはストアド属性と呼ばれ、物理的にデータベースに保存されます

Keys

エンティティに対する重要な制約にキーがあります。 キーは、エンティティセット内の個々のエンティティを一意に識別するために値を使用できる属性または属性のグループです。

キーの種類

キーにはいくつかのタイプがあります。

候補キー

候補キーは、一意で最小の単純キーまたは複合キーである。 テーブルの2つの行がいつでも同じ値を持つことはないので、一意である。 一意性を達成するためにすべての列が必要であるため、最小である。

COMPANYデータベースの例では、エンティティがEmployee（EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID）の場合、可能なキー候補は以下のとおりです。

• EID, SIN
• First Name and Last Name – 会社に同じ名前の人がいないと仮定して
• Last Name and DepartmentID – 同じ姓の人が同じ部署にいないと仮定して

複合キー

複合キーとは2以上の属性からなりますが、最小でなければなりません。

キー候補のセクションの例を使うと、可能な複合キーは以下の通りです。

• First Name and Last Name – 会社に同じ名前の人がいないと仮定
• Last Name and Department ID – 同じ姓の2人は同じ部署で働かないと仮定

Primary key

主キーとは、データベース設計者がエンティティセット全体の識別機構として使用するキー候補を選択したものである。 テーブル内のタプルを一意に識別しなければならず、NULLであってはならない。 主キーは、ERモデルでは属性に下線を引いて示される。

• 候補キーは、テーブル内のタプルを一意に識別するために設計者によって選択される。 それはヌルであってはならない。
• キーは、エンティティセット全体の識別メカニズムとして使用されるように、データベース設計者によって選択される。 これは主キーと呼ばれる。 このキーはERモデルで属性に下線を引いて示されます。

次の例では、EIDは主キーです。

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

第二キー

第二キーとは検索のために厳密に用いられる属性（複合可）、例えば。

代替キー

代替キーは、主キーとして選ばれなかったすべての候補キーです。

外部キー

外部キー（FK）は、別のテーブルで主キーを参照するテーブルの属性です。

以下のCOMPANYデータベースの例では、DepartmentIDが外部キーです。

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Nulls

ヌルはデータ型とは無関係で、不明または適用不可能という意味の特別な記号です。 ゼロや空白を意味するものではありません。 ヌルの特徴は以下の通りです。

• データ入力不可
• 主キーでは不可
• 他の属性では避けるべき
• 表現可能
  • 不明な属性値
  • 既知だが見つからない。 属性値
  • “該当しない “条件

  COUNT、AVERAGE、SUMなどの関数が使用されると問題が生じる可能性があります

• 関係テーブルがリンクされると論理的問題が生じる場合があります

注意事項(NOTE)。 比較演算の結果は、いずれかの引数がNULLの場合、NULLになります。

NULLの使用例

図8.6のSalaryテーブル（Salary_tbl）を使用して、NULLの使用例を追ってください。 Salary table for null example, by A. Watt.

始めに、Sales（jobName列）の給与とコミッションが3万を超えるすべての従業員（emp#）を見つけます。

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (commission + salary) > 30,000 -> E10とE12

この結果にはコミッション列がNULL値なのでE13は含まれません。 null値の行が含まれるようにするためには、個々のフィールドを見る必要があります。 従業員 E13 のコミッションと給与を追加することで、結果は NULL 値になります。 解決策を以下に示します。

リレーションシップ

リレーションシップは、テーブルを一緒に保持する接着剤のようなものです。

リレーションシップの強さは、関連するエンティティの主キーがどのように定義されているかに基づいています。 関連するエンティティの主キーが親エンティティの主キー成分を含んでいない場合、弱い、または識別できない関係が存在します。 企業データベースの例には、

• Customer(CustID, CustName)
• Order(OrderID, CustID, Date)

強い、または識別する関係は、関連エンティティの主キーが親エンティティの主キーコンポーネントを含むときに、存在します。 例：

• Course(CrsCode, DeptCode, Description)
• Class(CrsCode, Section, ClassTime…)

Types of Relationships

以下は、さまざまなタイプの関係についての説明です。

一対多 (1:M) 関係

一対多 (1:M) 関係は、あらゆるリレーショナル データベース設計の標準であり、すべてのリレーショナル データベース環境で見受けられるはずです。 例えば、1つの部門に多くの従業員がいるとします。 図8.7は、これらの従業員の1人と部門との関係を示しています。

1対1（1：1）の関係

1対1（1：1）の関係とは、あるエンティティが他のエンティティ1つだけに関係し、逆もまた同様であることです。 これは、リレーショナル データベースの設計ではまれなことです。 COMPANY データベースの例では、1 人の従業員は 1 人の配偶者と関連付けられ、1 人の配偶者は 1 人の従業員と関連付けられています。

多対多の (M:N) 関係

多対多の関係については、次の点を考慮してください。

• 関係モデルではそのように実装できません。
• 2つの1対M関係に変更することができます。
• 1対Mの関係のセットを生成するために分割して実装することができます。
• 2つ以上の1対M関係を作成します。
• 複合エンティティテーブルは、少なくとも元のテーブルの主キーを含んでいなければなりません。
• リンク・テーブルには、外部キー値が複数回含まれます。
• 必要に応じて追加の属性を割り当てることができます。
• 複合エンティティまたはブリッジ・エンティティを作成すると、M：N関係に固有の問題を避けることができます。 例えば、ビジネス・ルールによっては、従業員が多くのプロジェクトで働くことができたり、プロジェクトが多くの従業員を持つことができます。

図8.8は、従業員がプロジェクトごとに異なる開始日を持つという、M:Nリレーションの別の側面を示しています。 したがって、EID、コード、および開始日を含むJOINテーブルが必要です。 従業員がプロジェクトごとに異なる開始日を持つ例

M：Nバイナリ関係タイプのマッピング例

• 各M：Nバイナリ関係について、2つの関係を識別します。
• AおよびBはRに参加している2つのエンティティタイプを表します。
• Rを表現するために新しい関係Sを作成します。
• SはAとBのPKを含む必要があります。これらは一緒にSテーブルのPKとすることができますし、これらと新しいテーブルRの別の単純な属性を一緒にPKとすることができます。
• 主キー（AとB）の組み合わせがSの主キーになります。

単項の関係（再帰的）

単項の関係は再帰的とも呼ばれ、同じエンティティセットの出現の間に関係が存在するものである。 この関係では、主キーと外部キーは同じですが、異なる役割を持つ2つのエンティティを表しています。

単項の関係にあるいくつかのエンティティでは、同じエンティティセットの主キーを参照する別の列を作成することができます。 単項関係の例

三項関係

三項関係は、3つのテーブル間の多対多の関係を含む関係タイプです。

三元関係タイプのマッピングの例については、図8.10を参照してください。 n-aryはリレーションシップ内の複数のテーブルを意味することに注意してください。 (

• 各N-ary（> 2）関係について、関係を表す新しい関係を作成します。
• 新しい関係の主キーは、N（多）側を保持する参加エンティティの主キーの組み合わせになります。
• N-ary関係のほとんどの場合、参加するすべてのエンティティはmany側を保持しています。

Attribution

データベース設計のこの章（特に断りのない限り画像を含む）は、クリエイティブ・コモンズ・表示・ライセンス3の下でライセンスされたNguyen Kim Anh著「データモデリング Using Entity-Relationship Model」の派生コピーである。0 license

The following material was written by Adrienne Watt:

1. Nulls section and example
2. Key Terms
3. Exercises