実体関連モデル

実体関連モデル#

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

データモデリング#

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

  1. 概念モデル（Conceptual Data Model）：ある記号系を用いて実世界の構造と意味を表現するモデル。

  2. 論理モデル（Logical Data Model）：概念モデルを実装可能な形式に変換したモデル。

  3. 物理モデル（Physical Data Model）：物理的な観点で記述されるデータモデル。

Note

複数の段階に分けてデータモデルを設計する考え方は、抽象化（abstraction）という。抽象化はコンピュータ科学の基本的な考え方である。

        flowchart TD
    Miniword --> 概念モデル
    概念モデル --> 論理モデル
    論理モデル --> 物理モデル

RDBMSの構築#

        flowchart TD
    Miniword --> 実体関連モデル
    実体関連モデル -->|実体関連図| リレーショナルモデル
    リレーショナルモデル -->|リレーショナルデータベーススキーマ| 物理モデル

概念モデル#

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

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

RDB

記号系

概念モデル

実体関連モデル

論理モデル

リレーショナルデータモデル

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

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

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

Note

Crow’s Footは「鳥の足」という意味で、関連型が「鳥の足」のように見えることから名付けられた。IE記法（Information Engineering記法）とも呼ばれる。

実体と実体型#

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

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

Note

学術的には、「実体型」と「実体」は厳密に区別されるが、実務上は「実体」という用語が「実体型」を指すことが多い。

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

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

        ---
title: CUSTOMER entity
---
erDiagram
    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記法では、以下のように表現される。

        erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
    }
    ORDER ||--|{ LINE-ITEM : contains
    ORDER {
    }
    LINE-ITEM {
    }

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」（任意）を表現する。例えば、注文システムでは顧客が注文を持たない場合もある。

Note

実体間の関連型は基本的に次の三種類がある。

  • One-to-One（1対1、1:1）

  • One-to-Many（1対多、1:N）

  • Many-to-Many（多対多、N:M）

Crow’s Foot記法は、1対多（0以上）、1対1（0または1）などの関連型が表現できる。

Exactly one#

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

  • An university has one president.

  • A president is in charge of one university.

        erDiagram
    UNIVERSITY ||--|| PRESIDENT : has
    UNIVERSITY{
    }
    PRESIDENT{
    }

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.

        erDiagram
    p[PERSON] {
    }
    a["ACCOUNT"] {
    }
    p ||--o| a : has

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.

        erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
    }
    ORDER {
    }

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.

        erDiagram
    ORDER ||--|{ LINE-ITEM : contains
    ORDER {
    }
    LINE-ITEM {
    }

属性#

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

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

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

        ---
title: CUSTOMER entity
---
erDiagram
    CUSTOMER {
            string custNumber PK
            string name
            string sector
        }

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

        ---
title: ORDER entity
---
erDiagram
    ORDER {
            int orderNumber PK
            string deliveryAddress
        }

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

        ---
title: LINE-ITEM entity
---
erDiagram
    LINE-ITEM {
        string productCode
        int quantity
        float pricePerUnit
    }

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

        erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
        string name
        string custNumber PK
        string sector
    }
    ORDER ||--|{ LINE-ITEM : contains
    ORDER {
        int orderNumber PK
        string deliveryAddress
    }
    LINE-ITEM {
        string productCode PK
        int quantity
        float pricePerUnit
    }

弱実体型#

弱実体型（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記法では、所有実体型の主キーを弱実体型の外部キーとして表現する。

        erDiagram
    EMPLOYEE ||--o{ DEPENDENT : has
    EMPLOYEE {
        string employeeNumber PK
        string firstName
        string lastName
        string department
    }
    DEPENDENT {
        string name PK
        string employeeNumber PK, FK
        date birthDate
    }

具体例#

ER図#

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

        erDiagram
    STUDENT {
        string studentID PK
        string firstName
        string lastName
        string address
    }
    ENROLLMENT {
        string studentID PK, FK
        string classID PK, FK
        date enrollmentDate
    }
    CLASS {
        string classID PK
        string className
        string professorID
    }
    STUDENT ||--o{ ENROLLMENT : enrolls
    CLASS ||--o{ ENROLLMENT : contains

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

  • 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図を作成することができる。

  1. draw.ioにアクセスし、「Start」をクリックする。

  2. 「Create New Diagram」をクリックする。

  3. 「Basic」から「Entity Relationship Diagram」を選択する。

  4. 「Create」をクリックする。

  5. こちらを参考にして、ER図を作成する。

Note

この資料に載せているER図は、Mermaid.jsを用いて作成したものである。Mermaid.jsは、MarkdownでER図を作成できるツールである。Mermaid.jsを用いたERDの作成についてこちらに詳しい説明がある。

  1. こちらにアクセスし、使い方を学ぶ。

  2. こちらにアクセスし、「Try Playground」をクリックする。

  3. 下側にある「Code」をクリックし、ER図を作成する。

他にも、Microsoft VisioやLucidchartなどのツールもある。

練習#

  1. 学生、履修、科目の三つの実体型を持つER図をdraw.ioを用いて作成せよ。

  2. A大学では、教員（PROFESSOR）は学生（STUDENT）を指導(advises)する。一名の教員は0人以上の学生を指導する。一名の学生は一名の教員に指導される。教員は、教員番号（professorID）、名前（name）、学部（department）を持つ。学生は、学生番号（studentID）、名前（name）、住所（address）、教員番号（professorID）を持つ。学生の教員番号は教員の教員番号の外部キーである。ER図をdraw.ioを用いて作成せよ。

  3. 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

Contents