sot03 最近の更新履歴城西国際大学_経営情報学部_組織情報論2017

(1)

組織情報論

第3回データベース 2 ^{データベースの設計}

1

講師佐枝三郎

https://sites.google.com/site/jiusaedasoshikiron2017/

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

(2)

データモデルとは

• データモデルとは、データベース中のデータ形式と、データの操作を規定するフレームワーク

– 先回の最後でSQLの例であげたリレーショナルデータモデルは、データ形式は表（テーブル）であり、それに対する検索操作は次のようになる

• 表を指定する

• 抽出する項目（列）を指定する

• ある条件で抽出したい行を指定する索など、ということになる

• データモデルは、データベースの体系と、格納や検索するために守るべき規約を定義している

– データ構造を記述するための規約

– 規約で構造化されたデータから、どの様にして検索や更新などの操作を行うかの規約

– データベースのデータが表現している内容から見て、あるべきデータ間（項目間など）の整合性制約を表現するための規約

• データモデルはいくつかの種類があるが、最も利用されているリレーショナルデータモデルに関して、詳細な内容を紹介する

3

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

（relational data modeｌ）

• リレーショナルデータモデルの特徴

– 簡潔な構造

– 関係代数という数学的基盤が存在する

– 他のデータモデルよりも、データ独立性が高い

• リレーショナルデータモデルの構造

– データベースはリレーション（relation、関係）の集まりとして、データを表（テーブル）のようにモデル化する

– それぞれの表には行と列がある（EXCELのイメージ）

– 列は「学生番号」、「氏名」、「学部」、「サークル」などの表中の項目であり、データベース用語では「属性（attribute）」と呼ぶ – 表の各行は個々のデータを表しており、これを「タプル（tuple）」、

あるいはレコードという

– ひとりの学生が1行のデータで表されており、その学生の様々な属性が数値や文字で示されていることになる

4

(3)

学生テーブル

番号番号番号

番号氏名氏名氏名氏名性別性別性別性別学部学部学部学部身長身長身長身長体重体重体重体重サークルサークルサークルサークル BG001

BG001BG001

BG001 古溝古溝古溝古溝亮太亮太亮太亮太男男男男経営情報学部経営情報学部経営情報学部経営情報学部 175175175175 62626262 なしなしなしなし BG002

BG002BG002

BG002 菅沼菅沼菅沼菅沼純平純平純平純平男男男男経営情報学部経営情報学部経営情報学部経営情報学部 169169169169 56565656 野球部野球部野球部野球部 BG003

BG003BG003

BG003 青山青山青山青山雄介雄介雄介雄介男男男男経営情報学部経営情報学部経営情報学部経営情報学部 186186186186 83838383 サッカー部サッカー部サッカー部サッカー部 BG004

BG004BG004

BG004 安楽安楽安楽安楽善美善美善美善美女女女女薬学部薬学部薬学部薬学部 158158158158 49494949 なしなしなしなし BG005

BG005BG005

BG005 井前井前井前井前大輝大輝大輝大輝男男男男経営情報学部経営情報学部経営情報学部経営情報学部 174174174174 68686868 なしなしなしなし BG006

BG006BG006

BG006 佐々木佐々木佐々木佐々木裕太郎裕太郎裕太郎裕太郎男男男男薬学部薬学部薬学部薬学部 182182182182 92929292 なしなしなしなし BG007

BG007BG007

BG007 中尾中尾中尾中尾圭佑圭佑圭佑圭佑男男男男経営情報学部経営情報学部経営情報学部経営情報学部 171171171171 72727272 サッカー部サッカー部サッカー部サッカー部 BG009

BG009BG009

BG009 飯島飯島飯島飯島健健健健男男男男経営情報学部経営情報学部経営情報学部経営情報学部 168168168168 56565656 なしなしなしなし BG010

BG010BG010

BG010 角倉角倉角倉角倉スミレスミレスミレスミレ女女女女薬学部薬学部薬学部薬学部 162162162162 53535353 華道部華道部華道部華道部 BG011

BG011BG011

BG011 西村西村西村西村航航航航男男男男経営情報学部経営情報学部経営情報学部経営情報学部 185185185185 78787878 なしなしなしなし BG012

BG012BG012

BG012 伏谷伏谷伏谷伏谷健太健太健太健太男男男男経営情報学部経営情報学部経営情報学部経営情報学部 174174174174 66666666 野球部野球部野球部野球部 BG013

BG013BG013

BG013 北村北村北村北村卓也卓也卓也卓也男男男男経営情報学部経営情報学部経営情報学部経営情報学部 181181181181 82828282 サッカー部サッカー部サッカー部サッカー部

サークル番号サークル名部員数部室番号

S01 野球部 60 101

S02 サッカー部 75 103

S03 テニス部 48 105

S04 華道部 24 210

サークルテーブル

関係－リレーション

属性－アトリビュートレコード－タプル

5

リレーショナルスキーマ（数学的な表現）

• リレーションの数学的定義

– リレーショナルデータベースはリレーション{R1, R2, …, Rn}の集

合である

– 個々のリレーションRiには、属性｛Ai1, Ai2, …, Aim}がある

• リレーショナル代数（関係代数）

– リレーションに対する基本操作を代数演算によって記述する

– 同じ属性を持つ二つのリレーションR, Sをまとめて一つのリ

レーションを得る操作は、集合演算のように「R U S」と記述す

る

• リレーショナル論理（関係論理）

– リレーションに対する基本操作を一階述語論理によって記述

する

– 同じ属性を持つ二つのリレーションR, Sをまとめて一つのリ

レーションを得る操作作は、論理式のように｛t | R(t) V S(t)} と

(4)

リレーショナルスキーマ（数学的な表現）

• リレーショナル代数とリレーショナル論理の関係

– リレーショナル代数は、リレーションに対するデータ操作

を「演算子」を組み合わせた「代数式」で表現する

• 演算子は「加減乗除」のたぐい、コンピュータで処理が簡単

– リレーショナル論理は、リレーションに対するデータ操作

を「論理式」（ = , >, <, AND, OR など）で表現する

• 論理式は「条件」を規定するので、人間が記述しやすい

– 人間は検索したい条件を、論理式で書く。

– データベース管理システムが、論理式をリレーショナル

代数に変換する

– データベース管理システムがリレーショナル代数式を計

算（処理）した結果が、人間が求めた答え

7

データべースの概念設計

8

(5)

データベースを構築するには

• データベース管理システムで管理するデータベースを構築

するために必要なこと

– データベースに格納するデータがどのようなものかを明確にし、データ項目やデータ間の関係を洗い出す

– データベース管理システムのデータモデルに基づいてデータの記述を行う

これを「データベーススキーマの定義」という

• リレーショナルデータベースを構築するには、データベー

スをリレーション、すなわち表（テーブル）の形式で表現す

る必要がある

• データベース化する対象の情報を分析し、スキーマ定義を

行うことをデータモデリングという

• データベースの設計とは、データモデリングを行う作業で

ある

9

データベース設計の手順

対象

の

世界

デ

| タ分析

分析レポ

| ト

概念設計

概念モデル

論理設計

論理モデル

(6)

データベース設計の手順

• データ分析(data analysis)

– データベース化の対象世界を明確にする

– データ項目の洗い出し、データ項目の意味の整理、データ項目間の関連の明確化

• 概念設計（conceptual design）

– データベース管理システムのデータモデルとは別に、データベース中に構築されるべき対象世界の写像がどのようなものであるかを記述する

– 概念設計の結果として得られる記述を「概念モデル

（conceptual model）」という

• 論理設計（logical design）

– 概念モデルからデータベース管理システムのデータモデルによって、対象世界の写像を記述し直す（変換作業を行う） – 記述し直した結果を「論理モデル（logical model）」という

11

E-R（実体関連）モデル

• E-Rは Entity Relationshipの頭文字をとったもの

• 概念設計において利用されるデータモデル

• 1976年にP. P. Chenにより提案された

• データベースに格納するデータが生まれる対象

世界を、「実体（Entity)」と「関連(Relationship)」

の2つの概念を使って記述する

12

(7)

実体（Entity）とは

• データベースに格納するべき、現実世界にある具体

的な単位を「実体（Entity）」という

– 大学の環境をデータベース化する場合は、 ^学生 ^、 ^教員 ^、

教室、講義科目などが、実体となる

– 企業の業務をデータベース化する場合は、 ^顧客 ^、 ^従業

員、商品、倉庫などの具体的なもののほかに、商品の

発注、納品、代金の支払、入金なども実体として取り

扱う

• 同じ種類の実体を集めたものを「実体集合（entity

set）」という

– データベースに格納される「すべての学生」、「すべての

教員」、「すべての講義科目」などは実体集合である

13

属性（Attribute）とは

• それぞれの実体（Entity）が持つ性質（情報）を「属性」という – 属性はそれぞれの実体集合に対して定める

– 「すべての学生」という実体集合には、「学籍番号」、「氏名」、「性別」、

「年齢」、「所属学部」などの属性がある

• 属性の値は、現実社会の状況や取り決めによって、値の範囲が制約される場合がある

• 属性の制約範囲を、属性の「ドメイン（domain) = 定義域」という – 性別の場合は、「男」と「女」の二つの値に限定される

– 年齢の場合は、0以上（非負ともいう）の数値、あるいは0から150までの数値などと定義できる

– 学籍番号は、大学に所属する学生に、大学が指定したアルファベットと数値の組み合わせの文字であり、大学が保有するリストに存在するもの、ということになる

• 属性のドメイン（定義域）は設計者が定義するものであり、これを利用して入力されるデータが妥当なものかをチェックすることができる

(8)

• 二つ以上の実体同士の相互関係をモデル化

したものを「関連」という

– 厳密には、実体集合E1, E2, …, Enが与えられたとき、

R ⊆E1 ×E2×・・・×EnなるR ^{を「関連集合}

（relationship set）」と呼び、Rの要素を「関連」という

– E1, E2, …, Enの中には、同じ実体集合が複数回現

れてもよい

– このときのnを関連集合の「次数（degree）」という

– 実体集合と同様に、関連集合にも属性をつけるこ

とができる

15

「R ⊆E1 ×E2×・・・×EnなるR」の解説

集合論の記述方法による説明

• E1をA,Bを要素とする実体集合、E2をX,Y,Zを要

素とする実体集合として、この二つの実体集合

間の関連集合Rを定義する

– E1 = { A, B }

– E2 = { X, Y, Z }

– E1 × E2 = ｛(A, X), (A, Y), (A, Z), (B, X), (B, Y), (B, Z) }

• 関連集合RはこのE1 × E2 の部分集合となる

16

(9)

「R ⊆E1 ×E2×・・・×EnなるR」の解説

具体例による説明

• 実体集合E1は2人の学生の集合とする

– E1 = {山田太郎,麻生和子 }

• 実体集合E2は三つの講義科目とする

– E1 = {組織情報論,情報学特論,情報メディア論 }

• 関連集合Rは、どの学生がどの講義科目を履修してい

るかのデータである

– E1 × E2 = ｛(山田太郎,組織情報論), (山田太郎,情報学特

論), (山田太郎,情報メディア論 ), (麻生和子 ,組織情報論),

(麻生和子 ,情報学特論), (麻生和子,情報メディア論 ) }

• 学生がすべての講義科目を履修するとは限らないの

で、関連集合Rは、このすべての組み合わせの一部と

なる

17

「R ⊆E1 ×E2×・・・×EnなるR」の解説

具体例による説明

山田太郎麻生和子

組織情報論情報学特論情報メディア論

×

学生集合講義科目集合

山田太郎は組織情報論を履修山田太郎は情報学特論を履修麻生和子は情報学特論を履修麻生和子は情報メディア論を履修

この場合は2人とも、2科目

しか履修していないので関

係集合は部分集合となり、

４つの要素となる

履修集合

(10)

E-R図－実体関連図

( Entity Relationship Diagram )

• ER(実体関連)モデルを図として表現し、設計する際や

他人に説明することに用いるもの

• ERモデルと同様にP. P. Chenにより提案された

• 実体集合を長方形、関連集合をひし形、属性を楕円

を用いて表現する

• 実体集合と関連集合の間の結びつきや、実体集合や

• 実体集合間の対応関係は、以下のように表現する

– ある実体集合の要素一つに、別の実体集合の要素が複

数紐づいている関係の場合 1対n （1:n)

– 二つの実体集合の各要素が、それぞれ相手の複数の要

素と紐づいている関係の場合 n対m (n:m)

19

「1:1」、「1:n」、「n:m」の意味

BG101

学籍番号と学生が対応ある学部に複数の学生が所属複数の講義と学生の履修関係荒井太郎

BG105 佐渡幸助

BG110 _鳥取裕太

「1:1」「1:n」「n:m」

経営情

報学部 ^荒井太郎

佐渡幸助

メディ

ア学部 ^鳥取裕太

和田幸宗

組織情

報論 ^荒井太郎

佐渡幸助情報学

特論

鳥取裕太

企業原和田幸宗論

20

(11)

学生と講義科目などの関係を

ChenのE-R図で表現する

学生講義科目

学部

個別講義

所属

履修開講

学籍番号

氏名

科目番号

講義名

開講日

講義内容

成績 _合否判定

学部番号

学部名定員

1 n

n m 1 n

実体

属性

E-Rモデルにおける整合性制約

• データベースに正しいデータが格納されるための条件を

「整合性制約（integrity constraint）」という

– 実体集合の要素間の対応関係、「1対n対応」「n対m対応」も整合性制約の一つである

• 参加制約（participation constraint）

– 実体集合間に関連が定義されたとき、実体集合にその関連がない要素があってもよいか

• 講義科目をまったく履修していない学生が存在してよいか

• 学部に所属しない学生が存在してよいか

• キー制約（key constraint）

– 実体集合や関連集合の要素は、ユニーク（それぞれが独立で重複はない）でなければならないか

• 学籍番号という属性の値が同じである学生が2人以上いてはいけない

• ある学籍番号の学生が、特定の講義科目を二重に履修し、成績が二つあってはならない

(12)

キーとは（key)

• 実体集合「学生」における「学籍番号」のように、実体集合中の要素を一意に識別できる属性を「キー」という

– 属性はひとつで識別できるものに限らず、複数の属性の組み合わせで一意に識別できてもよい

• 例えば、大学で統一的な学籍番号がなくても、学年と各学年の在籍者の番号で識別できるなど

– いくつかの属性を組み合わせてキーを作る場合は、最低限必要な属性に限定する。これを極小化という

• 統一的な学籍番号がある場合、「学籍番号と学年の組み合わせ」は学生を一意に識別できるが、極小ではないのでキーではない

• キーとなりうる属性（またはその組み合わせ）のことを、「候補キー

（candidate key）」という

– 「学籍番号」、「学内のメールアドレス」などは候補キーである

• 候補キーのうち、データ管理上一番適切なキーを「主キー

（primary key）」という

– ChenのE-R図では、主キーを構成する属性には下線をひく

– 主キーを持たない実体集合のことを「弱実体集合」といい、ChenのE-R 図では2重枠の長方形で表現する

23

データベースの論理設計

24

(13)

論理設計の手順

• データベースの概念設計でE-R図を作成し、以下が分かった

– 対象世界に、どのような実体集合があるかが明らかにされた – 各実体集合の属性とキーとなる属性が明らかにされた

– 実体集合間の関連、また関連が持つ属性が明らかにされた

• データベースの論理設計は、この情報からデータベース管理

システムが効率的に機能ため、厳密で整合性のあるデータ

ベーススキーマを定義する作業である。おもな作業は次の通

りである

– データモデルにおける各種整合性制約を明らかにする

– 各主体集合の主キー、及び他の主体集合との関連で必要となる外部キーを定義する

– 関連を概念設計されたスキーマの属性と関連を吟味し、関係の正規化を行う

– 属性のドメイン（定義域）、データベース上の具体的形式を定義し、これらすべての情報を、データベース定義言語（DML)で記述する – データモデリングツールを利用した詳細E-R図を記述し、ツールで

データベース定義言語（DML)を生成してもよい

25

整合性制約

• データベースに格納するデータが正しいこと

を保証する条件を「整合性制約（integrity

constraint）」という

• リレーショナルデータモデルの主な整合性制

約には以下がある

– ドメイン制約

– キー制約

– 参照整合性制約

– 従属性制約

(14)

ドメイン制約（domain constraint）

• 実体集合の各タプル（テーブルの行）の各属性の値は、

それぞれの属性に定義されたドメイン（定義域）の要

素、または範囲内でなければならない

– 基本的には「整数型」、「文字列型」などの、属性を表現す

るデータ形式（データ型）が、ドメインになる

• 氏名は文字型（全角）で最大20文字

• メールアドレスは文字型（半角英数字と記号）で、最大50文字

• 成績は整数型で、非負かつ100以下

– ドメインが要素が列挙される集合で定義された場合は、そ

の集合に含まれる要素の値

• 性別という属性であれば、ドメインの集合は「男」、「女」の二つ

• 出身県という属性であれば、ドメインは「北海道」～「沖縄」の47県

27

キー制約（key constraint）

• 実体集合の主キー（primary key)は、次の制約条

件を満たす必要がある。これを「キー制約」という

– 主キー制約

• 主キーである属性の値が同一な二つ以上のタプル(行）は存在しない

– 言いかえれば、すべてのタプルの主キーの値は異なっている

• 属性値の値が「空（何もない）」であるタプル（行）は存在しない

– この制約を「実体整合性制約（entity integrity constraint）」という

– 候補キー制約

• 候補キーである属性の値が同一な二つ以上のタプル(行）は存在しない

28

(15)

外部キー（foreign key）

• 二つの実体集合E1とE2がある

– E1の主キーである属性がPKであり、ドメインが定義されている – E2には属性FKがあり、PKと同じドメインで定義されている – PKとFKは単一の属性である必要はなく、属性の組み合わせで

もよい

– E2のあるタプル（行）のFKの値は、E1にあるいづれかのタプルのPKの値である、（但し空値であってもよい）

• 以上の条件が成立した場合、E2における属性FKを外部

キーという

• 外部キーの具体的な例

– 実体集合「学部」の主キーである属性が「学部番号」とする – 実体集合「学生」にある属性「学部番号」は、実体集合「学部」

の主キー「学部番号」を参照した「外部キー」である

29

主キーと外部キーの関連

学籍番号氏名性別学部番号学年 BG16001 会田一郎男 001 １ BG16002 石田みどり女 002 １ BG16003 上村茂男 002 1 BG15001 大島良子女 001 2 BG15002 加藤正幸男 003 2

学部番号学部名学部長定員

001 経営情報学部野澤建次 300

002 国際人文学部東谷仁 400

003 福祉総合学部磯辺文雄 300

004 薬学部秋元雅之 200

005 メディア学部袁福之 200

外部キー学生テーブル

学部テーブル

(16)

参照整合性制約

（referential integrity constraint）

• 参照整合性制約

– 実体集合（テーブル）に対して、ある属性FKが外部キーであると定義した場合、その実体集合のすべての要素（行）の属性FK の値は外部キーに関する条件を満たさなければならない

– 参照整合性制約は二つの実体集合間の整合性として定義されるが、特殊な例として、同じ実体集合の中に、主キーと外部キーがあってもよい

• 下の例は、新入生に上級生がメンター（相談相手）として付いた場合、どちらも学生番号で識別されるため、主キーと外部キーが同一の実体集合（テーブル）に存在する

学籍番号氏名性別学部番号学年メンター

BG16001 会田一郎男 001 １ BG14120 BG16002 石田みどり女 002 １ BG14090 BG16003 上村茂男 002 1 BG14152 BG16004 高木桂子女 001 2 BG14270 BG16005 谷田四郎男 003 2 BG14090

外部キー主キー

31

従属性（dependency）

• 実体集合（テーブル）の複数の属性値間にある関係を

「従属性」という

– 「関数従属性」

• 二つの属性AとBがあった場合、属性Aの値が等しいタプル（行）の属性Bの値は必ず等しい

• Bの値＝ｆ（Aの値）ということで「関数従属性」という

– 「多値従属性」

• 三つの属性A、B、Cがあった場合、属性Bの値は属性Aの値に依存しているが、属性Cとは独立である場合、属性AとBの関係をいう

– 「結合従属性」

• ある実体集合（テーブル）を分けて、複数のテーブルを作成しも、それらを結合すると元のテーブルに戻る関係をいう

• これらの従属性を整理することを関係の正規化という

32

(17)

データモデルの正規化

33

関係の正規化とは

• リレーショナルデータモデルにおける関係（リレーション）の正規化とは、対象世界から読み取った概念データモデルを、正規化という手順で整理し直し、論理的に整然としたデータモデルに洗練させることである

• ^{正規化のメリット}

– データの重複を排除するため、データベースが整理され管理が容易になる

• データの変更が必要な場合、最小限の修正で済む

• 正規化されたデータベースは、複数のシステムから利用が容易になる

• データベースの物理的容量を削減でき、処理効率が向上する

• ^{正規化のデメリット}

– 極端に正規化を行うと、検索する内容によっては、検索効率が落ちることがある

– 正規化をどこまで行うかは、データベースに対してどのような「検索要求」が多いかによる

(18)

正規化の種類

• 第１正規形（first normal form - 1NF )

– あるタプルのある属性の値が一つでなく、複数の値（集合）になっていないもの

• 第２正規形（second normal form - 2NF )

– すべてのキーでない属性が、主キー全体に対して関数従属であるもの。

• 第３正規形（third normal form - 3NF )

– すべてのキーでない属性が、推移的に関数従属でないもの

– 推移的とは、あるキーでない属性が別のキーでない属性と関数従属であることをいう

• ^{その他の正規系}

– ボイス・コッド正規形（Boyce/Codd normal form - BCNF ) – 第４正規形（forth normal form - 4NF )

– 第５正規形 ( fifth normal form - 5NF )

– これらの高次な正規化は、情報科学の理論として定義されているが、現実には応用例が少なく、第3正規化までを行うことが多い

35

正規化の手順

• 正規化の手順を仮のスーパーのレシートから分析する例で示す

• 分析の対象はレシートと売上を記録した資料に記述されたデータ項目の整理とする

• レシートの様式は以下の通り（これが非正規形という）

36

(19)

非正規形から第1正規形へ

• 3枚分のレシートを記録したEXCELの表がある

• 売上には売上番号が、店舗には店舗コードが、商品には

商品コードが付与されている

• 売り上げの記録は、売れた商品ごとに属性（項目）を作り、

顧客によって列の数が違うし、同じ属性が何度も登場する

• これが非正規形のデータ形式！！

37

非正規形から第1正規形へ

• まず列側の同じ属性（項目）を整理して、列に同じ属性が

現れないようにする

(20)

第1正規形から第2正規形へ

商品テーブル（商品マスター）

売上テーブル

第1正規形から第2正規形へ

• それぞれのデータを一意に識別する主キーとなる属

性は、売上番号と商品コード

• 主キーを構成する商品コードと商品名および単価は、

関数従属の関係にある

• 従って商品コード、商品名、単価を、商品コードを主

キーとする別テーブルに移し、売上テーブルから商品

名、単価を削除する

• 商品名、単価を調べる場合は商品コードによって商品

テーブルを参照する

• これが第2正規形と呼ばれるデータ形式

(21)

第2正規形から第3正規形へ

商品テーブル（商品マスター）

売上テーブル

店舗テーブル（店舗マスター）

第2正規形から第3正規形へ

• 主キーではない店舗コードと店舗名も、関数従属の関係にある

• 従って店舗コードと店舗名を、店舗コードを主キーとする店舗テーブルに移し、売上テーブルから店舗名を削除する

– 店舗テーブルには住所などその他のデータも存在する

• 店舗名を調べる場合は店舗コードによって店舗テーブルを参照する

• これが第3正規形と呼ばれるデータ形式

• 同じデータが冗長に存在しないことに意味がある

– 同じデータが複数に存在すると、データの修正や削除の

際に、すべてを直さなければならず、間違えが起きやすい

(22)

データベース設計のツール

• データベースの論理設計には、各種のE-R図作成ツールが用いられる

• 論理設計時のE-R図の表記法はChenの図と異なり、下図のような表記法が中心である

– 実体集合（テーブル）を長方形で記述

– 実体集合（テーブル）間の関連を、それらを結ぶ線で記述

• 関連の対応関係などの記述方法はツールにより異なる

– 実体集合(テーブル）の属性及び主キー、外部キーは長方形の中に記述する

• 次のページの図が、DB Designer というフリーソフトウェアのデータベース設計ツールで、大学関連の業務に関するE-R図を書いた事例である

実体集合（テーブル）名

属性1：属性1のタイプ属性2：属性2のタイプ属性3：属性3のタイプ属性n：属性nのタイプ主キーの属性：属性タイプ外部キーの属性：属性タイプ

実体集合（テーブル）名

属性1：属性1のタイプ属性2：属性2のタイプ属性3：属性3のタイプ属性n：属性nのタイプ主キーの属性：属性タイプ外部キーの属性：属性タイプ

リレーション

（関連）

(1:n)

43

大学業務のデータモデル（E-R図）

44

(23)

45

(24)

47

48

sot03 最近の更新履歴 城西国際大学_経営情報学部_組織情報論2017

組織情報論

第3回 データベース 2 データベースの設計

講師 佐枝三郎

https://sites.google.com/site/jiusaedasoshikiron2017/

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

データモデルとは

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

（relational data modeｌ）

• リレーショナルデータモデルの特徴

• リレーショナルデータモデルの構造

関係 － リレーション

属性 － アトリビュート レコード － タプル

リレーショナルスキーマ （数学的な表現）

• リレーションの数学的定義

– リレーショナルデータベースはリレーション{R1, R2, …, Rn}の集

合である

– 個々のリレーションRiには、属性｛Ai1, Ai2, …, Aim}がある

• リレーショナル代数（関係代数）

– リレーションに対する基本操作を代数演算によって記述する

– 同じ属性を持つ二つのリレーションR, Sをまとめて一つのリ

レーションを得る操作は、集合演算のように「R U S」と記述す

る

• リレーショナル論理（関係論理）

– リレーションに対する基本操作を一階述語論理によって記述

する

– 同じ属性を持つ二つのリレーションR, Sをまとめて一つのリ

レーションを得る操作作は、論理式のように ｛t | R(t) V S(t)} と

リレーショナルスキーマ （数学的な表現）

• リレーショナル代数とリレーショナル論理の関係

– リレーショナル代数は、リレーションに対するデータ操作

を「演算子」を組み合わせた「代数式」で表現する

– リレーショナル論理は、リレーションに対するデータ操作

を「論理式」（ = , >, <, AND, OR など） で表現する

– 人間は検索したい条件を、論理式で書く。

– データベース管理システムが、論理式をリレーショナル

代数に変換する

– データベース管理システムがリレーショナル代数式を計

算（処理）した結果が、人間が求めた答え

データべースの概念設計

データベースを構築するには

• データベース管理システムで管理するデータベースを構築

するために必要なこと

これを「データベーススキーマの定義」という

• リレーショナルデータベースを構築するには、データベー

スをリレーション、すなわち表（テーブル）の形式で表現す

る必要がある

• データベース化する対象の情報を分析し、スキーマ定義を

行うことをデータモデリングという

• データベースの設計とは、データモデリングを行う作業で

ある

データベース設計の手順

対象

の

世界

データベース設計の手順

• データ分析(data analysis)

• 概念設計（conceptual design）

• 論理設計（logical design）

E-R（実体関連）モデル

• E-Rは Entity Relationshipの頭文字をとったもの

• 概念設計において利用されるデータモデル

• 1976年にP. P. Chenにより提案された

• データベースに格納するデータが生まれる対象

世界を、「実体（Entity)」と「関連(Relationship)」

の2つの概念を使って記述する

実体（Entity）とは

• データベースに格納するべき、現実世界にある具体

的な単位を「実体（Entity）」という

– 大学の環境をデータベース化する場合は、 学生 、 教員 、

教室 、 講義科目 などが、実体となる

– 企業の業務をデータベース化する場合は、 顧客 、 従業

員 、 商品 、 倉庫 などの具体的なもののほかに、商品の

発注 、 納品 、代金の 支払 、 入金 なども実体として取り

扱う

• 同じ種類の実体を集めたものを「実体集合（entity

set）」という

– データベースに格納される「すべての学生」、「すべての

教員」、「すべての講義科目」などは実体集合である

属性（Attribute）とは

sot03 最近の更新履歴城西国際大学_経営情報学部_組織情報論2017

第3回データベース 2 ^{データベースの設計}

講師佐枝三郎

関係－リレーション

属性－アトリビュートレコード－タプル

リレーショナルスキーマ（数学的な表現）

レーションを得る操作作は、論理式のように｛t | R(t) V S(t)} と

リレーショナルスキーマ（数学的な表現）

を「論理式」（ = , >, <, AND, OR など）で表現する

– 大学の環境をデータベース化する場合は、 ^学生 ^、 ^教員 ^、

教室、講義科目などが、実体となる

– 企業の業務をデータベース化する場合は、 ^顧客 ^、 ^従業

員、商品、倉庫などの具体的なもののほかに、商品の

発注、納品、代金の支払、入金なども実体として取り

R ⊆E1 ×E2×・・・×EnなるR ^{を「関連集合}

学生集合講義科目集合

E-R図－実体関連図

「1:1」、「1:n」、「n:m」の意味

「1:1」「1:n」「n:m」

学生講義科目

キーとは（key)