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

全文

(1)

組織情報論

第3回 データベース

2

データベースの設計

1

講師 佐枝三郎

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

(2)

データモデルとは

• データモデルとは、データベース中のデータ形式と、データの操作

を規定するフレームワーク

– 先回の最後でSQLの例であげたリレーショナルデータモデルは、デー

タ形式は表(テーブル)であり、それに対する検索操作は次のように なる

• 表を指定する

• 抽出する項目(列)を指定する

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

• データモデルは、データベースの体系と、格納や検索するために

守るべき規約を定義している

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

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

作を行うかの規約

– データベースのデータが表現している内容から見て、あるべきデータ

間(項目間など)の整合性制約を表現するための規約

• データモデルはいくつかの種類があるが、最も利用されているリ

レーショナルデータモデルに関して、詳細な内容を紹介する

3

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

relational data mode

l)

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

– 簡潔な構造

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

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

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

– データベースはリレーション(relation、関係)の集まりとして、

データを表(テーブル)のようにモデル化する

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

– 列は「学生番号」、「氏名」、「学部」、「サークル」などの表中の

項目であり、データベース用語では「属性(attribute)」と呼ぶ

– 表の各行は個々のデータを表しており、これを「タプル(tuple)」、

あるいはレコードという

– ひとりの学生が1行のデータで表されており、その学生の様々

な属性が数値や文字で示されていることになる

(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

をまとめて一つのリ

(4)

リレーショナルスキーマ

(数学的な表現)

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

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

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

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

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

を「論理式」(

= , >, <, AND, OR

など) で表現する

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

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

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

代数に変換する

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

算(処理)した結果が、人間が求めた答え

7

データべースの概念設計

(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

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

(7)

実体(

Entity

)とは

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

的な単位を「実体(

Entity

)」という

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

学生

教員

教室

講義科目

などが、実体となる

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

顧客

従業

商品

倉庫

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

発注

納品

、代金の

支払

入金

なども実体として取り

扱う

同じ種類の実体を集めたものを「実体集合(

entity

set

)」という

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

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

13

属性(

Attribute

)とは

• それぞれの実体(Entity)が持つ性質(情報)を「属性」という

– 属性はそれぞれの実体集合に対して定める

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

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

• 属性の値は、現実社会の状況や取り決めによって、値の範囲が

制約される場合がある

• 属性の制約範囲を、属性の「ドメイン(domain) = 定義域」という

– 性別の場合は、「男」と「女」の二つの値に限定される

– 年齢の場合は、0以上(非負ともいう)の数値、あるいは0から150まで

の数値などと定義できる

– 学籍番号は、大学に所属する学生に、大学が指定したアルファベット

と数値の組み合わせの文字であり、大学が保有するリストに存在す るもの、ということになる

• 属性のドメイン(定義域)は設計者が定義するものであり、これを

(8)

関連(

relationship

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

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

厳密には、実体集合

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

の部分集合となる

(9)

R

E1

×

E2

×・・・×

En

なる

R

」の解説

具体例による説明

実体集合

E1

2

人の学生の集合とする

E1 = {

山田太郎

,

麻生和子

}

実体集合

E2

は三つの講義科目とする

E1 = {

組織情報論

,

情報学特論

,

情報メディア論

}

関連集合

R

は、どの学生がどの講義科目を履修してい

るかのデータである

E1

×

E2 =

(

山田太郎

,

組織情報論

), (

山田太郎

,

情報学特

), (

山田太郎

,

情報メディア論

), (

麻生和子

,

組織情報論

),

(

麻生和子

,

情報学特論

), (

麻生和子

,

情報メディア論

) }

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

で、関連集合

R

は、このすべての組み合わせの一部と

なる

17

R

E1

×

E2

×・・・×

En

なる

R

」の解説

具体例による説明

山田太郎

麻生和子

組織情報論

情報学特論

情報メディア論

×

学生集合

講義科目集合

山田太郎は組織情報論を履修

山田太郎は情報学特論を履修

麻生和子は情報学特論を履修

麻生和子は情報メディア論を履修

この場合は

2

人とも、

2

科目

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

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

4つの要素となる

(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

経営情

報学部 荒井太郎

佐渡幸助

メディ

ア学部 鳥取裕太

和田幸宗

組織情

報論 荒井太郎

佐渡幸助 情報学

特論

鳥取裕太

和田幸宗 企業原

(11)

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

Chen

E-R

図で表現する

学生

講義科目

学部

個別講義

所属

履修 開講

学籍番号

氏名

科目番号

講義名

開講日

講義内容

成績 合否判定

学部番号

学部名

定員

1 n

n m 1 n

実体

属性

関連 21

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

データベースの論理設計

(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)」という

候補キー制約

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

存在しない

(15)

外部キー(

foreign key

二つの実体集合

E1

E2

がある

– E1の主キーである属性がPKであり、ドメインが定義されている – E2には属性FKがあり、PKと同じドメインで定義されている

– PKとFKは単一の属性である必要はなく、属性の組み合わせで

もよい

– E2のあるタプル(行)のFKの値は、E1にあるいづれかのタプル

のPKの値である、(但し空値であってもよい)

以上の条件が成立した場合、

E2

における属性

FK

を外部

キーという

外部キーの具体的な例

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

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

29

主キーと外部キーの関連

学籍番号 氏名 性別 学部番号 学年

BG16001 会田一郎 男 001 1

BG16002 石田みどり 女 002 1

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 1 BG14120 BG16002 石田みどり 女 002 1 BG14090 BG16003 上村茂 男 002 1 BG14152 BG16004 高木桂子 女 001 2 BG14270 BG16005 谷田四郎 男 003 2 BG14090

外部キー 主キー

31

従属性(

dependency

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

「従属性」という

「関数従属性」

• 二つの属性AとBがあった場合、属性Aの値が等しいタプル(行)の

属性Bの値は必ず等しい

• Bの値 = f(Aの値) ということで「関数従属性」という

「多値従属性」

• 三つの属性A、B、Cがあった場合、属性Bの値は属性Aの値に依存

しているが、属性Cとは独立である場合、属性AとBの関係をいう

「結合従属性」

• ある実体集合(テーブル)を分けて、複数のテーブルを作成しも、そ

れらを結合すると元のテーブルに戻る関係をいう

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

(17)

データモデルの正規化

33

関係の正規化とは

• リレーショナルデータモデルにおける関係(リレーション)の正規化

とは、対象世界から読み取った概念データモデルを、正規化という

手順で整理し直し、論理的に整然としたデータモデルに洗練させ ることである

• 正規化のメリット

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

になる

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

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

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

• 正規化のデメリット

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

ことがある

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

(18)

正規化の種類

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

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

いないもの

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

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

の。

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

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

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

であることをいう

• その他の正規系

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

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

– これらの高次な正規化は、情報科学の理論として定義されているが、

現実には応用例が少なく、第3正規化までを行うことが多い

35

正規化の手順

• 正規化の手順を仮のスーパーのレシートから分析する例で示す • 分析の対象はレシートと売上を記録した資料に記述されたデータ

項目の整理とする

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

(19)

非正規形から第

1

正規形へ

3

枚分のレシートを記録した

EXCEL

の表がある

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

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

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

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

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

37

非正規形から第

1

正規形へ

まず列側の同じ属性(項目)を整理して、列に同じ属性が

現れないようにする

(20)

1

正規形から第

2

正規形へ

商品テーブル (商品マスター)

売上テーブル

1

正規形から第

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

図)

(23)
(24)

47

Updating...

参照

Updating...