実体関連モデル - Relational Database

The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.

Edsger W. Dijkstra

データモデリング¶

データベースを構築するには、一般的に以下の三つのデータモデルを順番に設計する。

概念モデル（Conceptual Data Model）：ある記号系を用いて実世界の構造と意味を表現するモデル。
論理モデル（Logical Data Model）：概念モデルを実装可能な形式に変換したモデル。
物理モデル（Physical Data Model）：物理的な観点で記述されるデータモデル。

RDBMSの構築¶

概念モデル¶

リレーショナルデータベースにおいて、概念モデリングのための記号系は実体関連モデル（Entity-Relationship Model, ERモデル）である。実体関連モデルは1976年にピーター・チェン（陳品山）によって提案された。実体関連モデルを図で表現したものを実体関連図（entity-relationship diagram, ER図）と呼ぶ。

リレーショナルデータモデルは論理モデルのための記号系であり、実体関連モデルはリレーショナルデータベーススキーマ（relational database schema）に変換される。

RDB	記号系
概念モデル	実体関連モデル
論理モデル	リレーショナルデータモデル

実体関連モデルと実体関連図¶

実体関連モデルは、実体、関連、属性の三つの要素から構成される。

実体関連モデルを図で表現したものを実体関連図（entity-relationship diagram, ER図）と呼ぶ。Chen記法とCrow’s Foot記法が代表的な記法である。

実体と実体型¶

実体（entity）は、現実世界に存在する物体や事象を表す。実体型（entity type）は、実体集合（entity set）を表す。実体は実体型のインスタンス（instance）である。例えば、個々の顧客は実体であり、抽象化された顧客集合はCUSTOMERという実体型で表される。

実体型は一般的に名詞で、英語の大文字で表現される。STUDENT、CLASS、PROFESSORなどが実体型の例である。

Crow’s Foot記法では、実体型は長方形で表現される。

例えば、顧客を表す実体型CUSTOMERは次のように表現される。

関連と関連型¶

関連（relationship）は、実体間の関係を表す。関連型（relationship type）は、実体型間の抽象化された関係を表す。関連型は一般的に動詞で、英語の小文字で表現される。

例えば、CUSTOMERとORDERとLINE-ITEMという三つの実体型があるとき、CUSTOMERはORDERをplaces、ORDERはLINE-ITEMをcontainsという関連型で結ぶことができる。さらに、これらの関連型には、対応関係を表すための濃度（cardinality）がある。

A CUSTOMER places zero or more ORDERS.
An ORDER is placed by exactly one CUSTOMER.
AN ORDER contains one or more LINE-ITEMS.
A LINE-ITEM is contained in exactly one ORDER.

Crow’s Foot記法では、以下のように表現される。

Crow’s Foot記法は、o、|、{の三つの記号を用いて、実体間の関連型を表現する。ここでは、{を鳥の足記号を表現している。

Notation	Meaning
`o`	Zero
`\|`	One
`{`（鳥の足）	Many

これらの記号の組み合わせで、Crow’s Foot記法では以下のような表現もできる。

Notation	Meaning	Type
`o\|`	Zero or one	Optional
`\|\|`	Exactly one	Mandatory
`o{`	Zero or more	Optional
`\|{`	One or more	Mandatory

少なくとも一つの実体が必要な場合は、|を用いて「Mandatory」（必須）を表現する。例えば、大学では少なくとも一人の学長が必要である。一方、実体が存在しなくてもよい場合は、oを用いて「Optional」（任意）を表現する。例えば、注文システムでは顧客が注文を持たない場合もある。

Exactly one¶

UNIVERSITYとPRESIDENTという二つの実体型があるとき、両者の関連をhasという関連型がある。||を用いて、「Exactly one」を表現している。

An university has one president.
A president is in charge of one university.

Zero or one¶

PERSONとCUSTOMER ACCOUNTという二つの実体型があるとき、両者の関連をhasという関連型がある。o|を用いて、「Zero or one」を表現している。

A person has zero or one customer account.
A customer account is owned by one person.

Zero or more¶

例えば、CUSTOMERとORDERという二つの実体型があるとき、両者の関連をplacesという関連型がある。o{を用いて、「Zero or more」を表現している。

A customer can place zero or more orders.
Each order is placed by one customer.

One or more¶

ORDERとLINE-ITEMという二つの実体型があるとき、両者の関連をcontainsという関連型がある。|{を用いて、「One or more」を表現している。

An order contains one or more line items.
A line item is contained in exactly one order.

属性¶

実体型や関連型は、属性を持つことができる。属性（attribute）は、実体や関連の性質を表す。

Crow’s Foot記法では、属性は実体型や関連型の下に記述される。属性は実体型や関連型の性質を表す。属性が主キーである場合、PKと記述される。外部キーである場合、FKと記述される。

実体型CUSTOMERは、属性custNumber、name、sectorを持つ。custNumberは主キーである。

ORDERは、顧客の注文を表す実体型である。属性orderNumber、deliveryAddressを持つ。orderNumberは主キーである。

LINE-ITEMは、注文の明細を表す実体型である。属性productCode、quantity、pricePerUnitを持つ。productCodeは主キーである。

CUSTOMER、ORDER、LINE-ITEMの三つの実体型を持つER図は次のように表現される。

弱実体型¶

弱実体型（weak entity type）は、自身の属性だけでは主キーを持たない実体型である。弱実体型を一意識別するためには、所有実体型（owner entity type）と呼ばれる実体型が必要である。

例えば、EMPLOYEEとDEPENDENTという二つの実体型があるとする。DEPENDENTは弱実体型であり、その所有実体型はEMPLOYEEである。 EMPLOYEEはDEPENDENTの間にhasという関連型を持つ。このような関連型を識別関連型（identifying relationship type）と呼ぶ。

DEPENDENTはname（first name）とbirthDate（date of birth）という属性を持つが、これらの属性だけではDEPENDENTを一意に識別できない。 DEPENDENTのnameとEMPLOYEEのemployeeNumberを組み合わせて、初めてDEPENDENTを一意に識別できる。nameのような属性（集合）を部分キー（partial key）と呼ぶ。部分キーと所有実体型の主キーを組み合わせて、弱実体型を一意に識別する。

Crow’s Foot記法では、所有実体型の主キーを弱実体型の外部キーとして表現する。

具体例¶

ER図¶

学生、履修、科目の三つの実体型を持つER図は次のように表現される。

リレーションナルデータベーススキーマ¶

STUDENT(studentID, firstName, lastName, address)
ENROLLMENT(studentID, classID, enrollmentDate)
CLASS(classID, className, professorID)
ENROLLMENTのstudentIDはSTUDENTのstudentIDの外部キーである。
ENROLLMENTのclassIDはCLASSのclassIDの外部キーである。

draw.ioを用いたER図の作成¶

draw.ioは無料で利用できる作図ツールである。draw.ioを用いたERDの作成についてこちらに詳しい説明がある。

以下の手順でdraw.ioを用いてER図を作成することができる。

draw.ioにアクセスし、「Start」をクリックする。
「Create New Diagram」をクリックする。
「Basic」から「Entity Relationship Diagram」を選択する。
「Create」をクリックする。
こちらを参考にして、ER図を作成する。

練習¶

学生、履修、科目の三つの実体型を持つER図をdraw.ioを用いて作成せよ。
A大学では、教員（PROFESSOR）は学生（STUDENT）を指導(advises)する。一名の教員は0人以上の学生を指導する。一名の学生は一名の教員に指導される。教員は、教員番号（professorID）、名前（name）、学部（department）を持つ。学生は、学生番号（studentID）、名前（name）、住所（address）、教員番号（professorID）を持つ。学生の教員番号は教員の教員番号の外部キーである。ER図をdraw.ioを用いて作成せよ。
A大学の教室管理システムを作成するために、BUILDING、ROOM、CLASSの三つの実体型を持つER図をdraw.ioを用いて作成せよ。BUILDINGは、建物ID（buildingID）、建物名（buildingName）を持つ。ROOMは、部屋番号（roomNumber）、建物ID（buildingID）、部屋種類（roomType）を持つ。CLASSは、科目ID（classID）、部屋番号（roomNumber）、科目時間（classTime）を持つ。主キー、外部キーは適切に設定せよ。
- A building contains zero or more rooms.
- A room is contained in exactly one building.
- A room is used for zero or more classes.
- A class is held in exactly one room.

発展的実習¶

大学管理システムを作成するために、下記の実体型を持つER図をdraw.ioを用いて作成せよ。属性などは適切に設定せよ。

PROFESSOR
SCHOOL
DEPARTMENT
SEMESTER
CLASS
ROOM
BUILDING
COURSE
STUDENT
ENROLLMENT