Microsoft PowerPoint - basic-2-er.ppt [互換モード]

Transcription

1 データベース設計データモデリング 講師 : 福田剛志 fukudat@fukudat.com データベース設計 (2) 1

2 データモデリング (data modeling) データモデル (data model) の3 要素 1. データ構造を記述するための規約 2. データ構造に対する操作 3. データが満たす制約を記述するための規約 今日は,1と3を中心に議論する. 文脈によっては データモデルの枠組みである実世界の事柄を記述した内容 (i.e., data model の instance) を data model と呼ぶこともある データベース設計 (2) 2

3 データモデルの種類 関係データモデル (relational data model) タプル (tuple) の集合 現在の主流. 今後, 詳しく論じる. ネットワークデータモデル (network data model) CODASYL 階層データモデル (hierarchical data model) IBM IMS データベース設計 (2) 3

4 実世界のデータモデリング 対象実世界 real world 概念設計 conceptual design 概念モデル conceptual model 実体関連 (ER) モデル (entity-relationship model) 論理設計 logical design 論理モデル logical model 関係データモデル (relational data model) データベース設計 (2) 4

5 ER モデル (entity-relationship model) の目的 ER モデル 実体集合 (entity set) と 実体間の関連 (relationship) を用いて実世界の事象をモデル化する手法 データベース設計の概念的な概略を描くことができる. 設計図は ER 図 (entity-relationship diagram) と呼ばれる絵. ER 図はほとんど機械的に関係データベースのスキーマに変換することができる. データベース設計 (2) 5

6 実体集合 (entity sets) 実体 (entity) = もの or こと オブジェクト指向言語の object に似ている 実体集合 (entity set) = 似通った実体の集まり オブジェクト指向言語の class に似ている 属性 (attribute) = 実体集合の特性 (property) 一般に, 一つの実体集合に属す実体はすべて同じ属性を持つ. 属性は単純な値を持つ. 例 ) 整数, 文字列 データベース設計 (2) 6

7 ER 図 (entity-relationship diagram) ER 図では, 各実体集合は矩形で表される. 実体集合の各属性は楕円で表現され, 実体集合に線で結ばれる. 製造元 実体集合 は二つの属性 ( と 製造元 ) を持つ. 実体集合 の各要素 ( 実体 ) はこれら二つの属性を持つ. 例 : (, 製造元 ) ( スーパードライ, アサヒ ) ( 一番絞り, キリン ) ( 越の寒梅, 石本造 ) データベース設計 (2) 7

8 関連 (relationship) 関連 (relationship) は実体集合を関係付ける. 菱形で表現され, 関連付ける実体集合を現す矩形と線で結ばれる. 住所 製造元 呑み屋 売る 呑み屋はを売る 定休日 行きつけ 好き 呑みはが好き 呑み 住所 呑みは呑み屋によく行く データベース設計 (2) 8

9 関連集合 (relationship set) 実体集合 (entity set) の 値 とは, その集合に属する実体 (entity = もの or こと ) の集合 例 ) データベース中の全 呑み屋 の集合 関連集合 (relationship set) の 値 とは, 関連付けられた実体のリストの集合 例 ) 売る 関連集合の場合, 呑み屋つぼ八魚民養老の滝清龍 スーパードライモルツ一番絞りサッポロラガー データベース設計 (2) 9

10 多対多関連 (many-to-many relationships) 2 項関連の一種. 多対多関連では, どちらの実体集合も, もう一方の実体集合の複数の実体と結ばれることができる. 例えば, 呑み屋 と の関連 売る は多対多関連 一つの呑み屋でたくさんの種類のを売る. あるは, いろいろな呑み屋で売られる. データベース設計 (2) 10

11 多対 1 関連 (many-to-one relationships) 2 項関連の一種 1 番目の実体集合の要素は,2 番目の実体集合の ( 高々 ) 一つにしか結び付けられない. しかし, 2 番目の実体集合の要素が結びつく 1 番目の実体集合の要素数に制限はない (0 でも, 1 でも, 複数でもよい ) 例 ) 呑み と の関連 一番好き は多対 1 関連 呑みは ( 高々 ) 一つだけ, 一番好きなを持つ. しかし, は多くの呑みの一番好きなになりえる. データベース設計 (2) 11

12 1 対 1 関連 (one-to-one relationships) 2 項関連の一種. 1 対 1 関連では, どちらの実体集合の要素も, 他方の実体集合の高々 1 つの要素としか結びつかない. 例 1) 製造元 と の関連 ベストセラー 一つのは複数の製造元で作られることはない. 各製造元のベストセラーはただ一つ ( 同率トップは考えない場合 ) 例 2) 野球チーム と 野球監督 の関係 一つのチームには一人しか監督はいない. 一人の監督は ( 普通 ) 一つのチームにしか所属しない. 例 3) 夫 と 妻 の関係 一人の 夫 は一人の 妻 としか結婚できない ( 一夫一婦制の場合 ) 未婚の場合を許すことに注意. データベース設計 (2) 12

13 図示すると... 多対多多対 1 1 対 1 データベース設計 (2) 13

14 多重度 (multiplicity) の表現 多対 1を表現するために, 1 の側に矢印を描く. 1 対 1の場合は, 両方に矢印を描く. 例 ) 呑み には 好きな がある. 複数あってもいいし,0でもいい. しかし, 一番好きな は一つしかない( 一番好きながなくてもよい ). 呑み 好き 一番好き 場合によっては, 必ず 1 であることを表現したい場合がある. そのときは, 丸い矢印を描くことにする. 例 ) 各 は必ず一つ 製造元 がある. 製造元のないはありえない. 製造元 製造 データベース設計 (2) 14

15 多項関連 (multi-way relationships) 場合によっては,3 つ以上の実体集合を関連付ける必要がある. 例えば, ある呑みは, ある銘柄のを, 特定の呑み屋でしか飲まないとする. 2 項関連の組み合わせでは表現できない. 住所 製造元 定休日 呑み屋 呑み屋呑みビール 嗜好 つぼ八太郎生絞りサワー 清龍太郎サッポロラガー 洛花子十四代本丸 呑み 住所 データベース設計 (2) 15

16 関連の属性 関連に属性をつける必要がある場合がある. 例えば 値段 は 呑み屋 と が決まってはじめて決まる や 呑み屋 どちらか一方では決まらない 呑み屋 売る 値段 データベース設計 (2) 16

17 関連の属性を用いない同等の表現 属性の値を表現する実体集合を作る この場合, 値段 その実体集合を, 関連に参加させる. 呑み屋 売る 値段 値段 に単なる値 ( 値段 ) 以外の属性が存在しない場合は, このようなモデルは望ましくない. 値段 データベース設計 (2) 17

18 役割 (roles) 一つの実体集合が一つの関連に複数回, 参加することがある. 関連の菱形と実体集合の矩形の間の線にラベルを振り, 実体集合の関連による役割 (role) を区別する. 夫婦 夫 妻 呑み データベース設計 (2) 18

19 汎化階層 (generalization hierarchy) 1/2 専化 (specialization) = 継承 (inherit) = 特殊な場合 = 少ない実体数 = より多くの属性 オブジェクト指向言語の サブクラス のようなもの 汎化 (generalization) = 専化の逆 オブジェクト指向言語の スーパークラス 例 : 日本 は の専化 すべてのは日本ではないが, 日本はである 日本には 精米歩合 ( 米をどれだけ磨くか ) という一般の にはない属性がある. データベース設計 (2) 19

20 汎化階層 (generalization hierarchy) 2/2 汎化階層は木 (tree) を構成する. 多重継承 (multiple inheritance) は考えない. is-a の三角形を用いて継承関係を表す. 三角形はスーパークラスを指す. 製造元 is-a 精米歩合 日本 ワイン データベース設計 (2) 20

21 実体関連 vs オブジェクト指向 オブジェクト指向の世界では, オブジェクト (object) は必ず一つの クラス (class) にだけ属する. これに対して, 実体関連モデルでは, 実体はすべてのサブクラス (subclass) に属すると考える. 何時, 論理モデルのレコードに変換するかによる. 製造元 is-a 越の寒梅 精米歩合 日本 データベース設計 (2) 21

22 実体集合のキー (keys) キー (key) = 実体集合の属性の集合で, その属性集合に属する 2 つの実体が同じ値をとることがない ( 固有の値をとる ) もの. すべての実体集合はキーが必要. ER 図では キー属性には下線 (underline) を引く. 汎化階層では, 根 (root) の実体集合だけがキーを持ち, それが階層中のすべての実体のキーとなる. 製造元 学部番号時間部屋 is-a 授業 精米歩合 日本 実体の例 : (CS, 101, 火曜日 2 時限, ) 実体の例 : ( 越の寒梅, 石本造, 60%) データベース設計 (2) 22

23 弱実体集合 (weak entity sets) 場合によっては, 実体集合に属する実体を特定 (uniquely identify) するために 助け が必要となることがある. 実体集合 E に属す実体を特定するためには, 一つ以上の 多対 1 関連 をたどった先の実体集合の属性を参照しなければならないとき,E は弱実体集合 (weak entity set) と呼ばれる. 例えば, は 野球選手 実体集合のキーだと考えられるが, 同姓同名の選手が存在することもありえる. 背番号 はキーにはならない. 別のチームには同じ背番号の選手がいるから. しかし, 背番号 と チーム を組み合わせれば, 野球選手 をユニークに特定できる. 野球選手 背番号 弱実体集合は2 重矩形で表す. 弱実体集合の特定に参加する 所属 チーム 多対 1 関連は2 重菱形で表す データベース設計 (2) 23

24 設計のテクニック 1. 冗長さを避けるべし 2. 弱実体集合に頼りすぎてはダメ 3. 属性ですむなら実体集合は使うな データベース設計 (2) 24

25 冗長性は, 1. 冗長さを避けるべし 実体とすべきものを属性で表現すると生じる 同じことを多重に表現しても生じる データのサイズを大きくし, 不整合をおきやすくする 製造元製造元住所 住所 悪い例 住所 製造する 製造元 製造する 製造元 良い例 製造元 悪い例 データベース設計 (2) 25

26 2. 弱実体集合に頼りすぎてはダメ 初心者はつい, どの属性もキーにならないのではと疑ってしまう. すると, ほとんどの実体集合が, 多くの多対 1 関連で支えられる弱実体集合になってしまう. 現実には, ほとんどの実体集合に 固有識別子 (unique ID) を振るのが普通. 例えば, 学籍番号, 車両のナンバープレート, パスポート番号... では, いつ弱実体集合を使えばよいのか? どこにも 固有識別子 を振る権限がないとき. 例えば, すべての 野球選手 にユニークな 背番号 を振ることはできない データベース設計 (2) 26

27 3. 属性ですむなら実体集合は使うな 実体集合は以下の条件を満たさなければならない : 単なる以上の何かであって, キーでない属性を持つ または 多対多または多対 1 の関連の 多 の側にくる 製造元 住所 良い例 製造する 製造元 良い例 製造する 製造元 悪い例 データベース設計 (2) 27

28 演習問題 2.1, 呑み屋, 呑みに関する情報を保持するデータベースのための実体関連図 (ER 図 ) を描け. ただし, 以下の情報を含めることとする. の, 蔵 ( の製造元 ), 蔵の住所, 電話番号 呑み屋の, 住所, 電話番号, 販売しているとその値段 呑み ( 人 ) の, 住所, 電話番号, 好きな ( 複数あってよい ), 一番好きな ( 一つだけ ), 行きつけの呑み屋 ( 複数あってよい ) とそこに出かける頻度 データベース設計 (2) 28

29 考え方 まず, 実体集合 ( 四角 ) で表すべきは何かを考える. この問題の場合は,, 呑み屋, 呑み がまず思い当たる. それらを実体集合 ( 四角 ) で表し, それぞれの属性 ( 楕円 ) を書き加える. その際, の属性として表現するつもりだった 蔵 には住所と電話番号が付属している. 属性に属性は付与できないから, 蔵 も実体集合として表現することにする. 各実体集合のキー ( 実体を特定するために必要な情報 ) は何か考え, その属性に下線を引く. 次に, 実体集合間の関連 ( 菱形 ) を書き加えていく. を製造しているのが蔵だから, 製造 という関連を作成する. あるには製造元が必ず一つだけ存在し, ある製造元は複数のを製造している可能性があるので, これは多対 1 の関連である. したがって, 製造元側は丸矢印としの側は矢印をつけない. 呑みはが好きという関係を表す関連 好き を作成する. ある飲みは複数のが好きかも知れないし, あるは複数の飲みに好かれていると考えられるので, これは多対多の関連である. したがって, 両端には矢印をつけない. 呑みがあるを一番好きであるという関連 一番好きな は, ある呑みには必ず一つだけ一番好きながあると考えられるので, 多対 1 の関連である. したがって, の側を丸矢印とする. 呑み屋でを 販売する という関連は, 多対多の関連であるので, 両端には矢印をつけない. 値段 はの属性でも飲み屋の属性でもなく, この関連の属性であることに注意して, 販売の関連を表す菱形に対して接続する. データベース設計 (2) 29

30 演習問題 2.2 弱実体集合が必要なデータモデルの例を考え, ER 図として描け. データベース設計 (2) 30

31 演習問題 2.3 銀行の顧客と口座の情報を含むデータベースを設計する. 顧客に関する情報は,, 住所, 電話番号, 顧客番号を含み 口座に関する情報は, 口座番号, 口座種類 ( 当座または普通 ), 残高を含むものとし, ある口座は必ず一人の顧客の持ち物であって, 一人の顧客は複数の口座を持つことができるものとする. このデータベースを表現する ER 図を描け. ただし必要に応じて矢印を用いて多重度を適切に表現するとともに, キーには下線をつけよ. 顧客番号 口座番号 種類 住所 顧客 所有 口座 電話番号 残高 データベース設計 (2) 31