第２章　データベースのモデル ２．１ 論理表現と3層モデル ２．２ 階層モデル ２．３ ネットワークモデル ２．４ 関係モデル.

Presentation on theme: "第２章　データベースのモデル ２．１ 論理表現と3層モデル ２．２ 階層モデル ２．３ ネットワークモデル ２．４ 関係モデル."— Presentation transcript:

1 第２章　データベースのモデル ２．１ 論理表現と3層モデル ２．２ 階層モデル ２．３ ネットワークモデル ２．４ 関係モデル

2 ２．１ 論理表現と3層モデル 媒体上の格納形式やシステム内の動作手順をとは独立である（ハードウェア独立）
２．１　論理表現と3層モデル データの論理表現： データベースシステムが外部に見せる仕様 媒体上の格納形式やシステム内の動作手順をとは独立である（ハードウェア独立） どの範囲の仕様を外部に見せれば良いか？ これがデータベース研究の中心的な論点

3 使いやすさに関する２つの視点 ①マンマシンインターフェースとして使いやすさ （プログラムとDBMSとのインターフェースを含む） ②現実世界のモデル化をいかに自然に記述できるか （業務を運用・DBMSを構築する立場）

4 論理表現法＝データベースモデル これまでに商用化されたモデル ① 階層型データモデル（hierarchical data model ）
②　ネットワーク型データモデル（network data model） ③　関係モデル（relational model）

5 データベースに必要な記述 ①スキーマ（schema：データ表現の枠組み） モデルに基づいて現実世界をどのように抽象化したかについての記述。 ②インスタンス（instance） 格納された個々のデータ。

6 スキーマの例 ①データ構成 従業員データ＝｛従業員番号, 氏名, 住所, 誕生日, 所属部署｝ ②制約条件 同一の従業員番号は存在しない。 ③データ間の関連 所属（従業員, 部署）

7 インスタンスの例 従業員番号12345, 山田栄一, 東京都田無市, 2002年12月15日, システム開発部

8 ANSI/SPARCの３階層モデルアーキテクチャ （American National Standards Institute/Systems Planning and Requirements Committee） 　スキーマには、その記述レベルがある 　外部レベル （ビュー） 　外部スキーマ 　・・・・ 　外部スキーマ 　概念スキーマ 　概念レベル 　内部レベル 　内部スキーマ

9 それぞれのレベル ①外部レベル（external level）またはビュー（view） 個々の応用ブログラムや利用者の目的に応じて抽象化するデータの枠組みを規定する。 ②概念レベル（conceptual level） 各種のデータモデルに基づいて現実世界の抽象化を行ったもの。結果としてスキーマが保持される。 ③内部レベル（internal level） OSやファイル管理システムとのインターフェースによる物理的なデータの格納形式等を記述したスキーマ記述とそのインスタンスが格納されるレベル。

10 第２章　データベースのモデル ２．１ 論理表現と3層モデル ２．２ 階層モデル ２．３ ネットワークモデル ２．４ 関係モデル

11 ２．２ 階層モデル 学部 学科 学生 代表例：IBMのIMS（Information Management System）
２．２　階層モデル 代表例：IBMのIMS（Information Management System） 階層モデルによるスキーマ表現（階層スキーマ） 学部 レコードタイプ/ セグメントタイプ（IMS用語） 学科 学生

12 階層モデルでのインスタンス例 レコードインスタンス / レコード / セグメント（IMS用語） 工学部 理学部 法学部 ・・・ 建築学科
学部レコードタイプ 建築学科 電気工学科 情報工学科 ・・・ 学科レコードタイプ 佐藤 田中 石原 ・・・ 学生レコードタイプ

13 １対nの関係でない例 任意加入のサークルのような例ではn対mになってしまう。 卓球部 サッカー部 剣道部 ・・・ 佐藤 /1 田中 /1/2
石原 /1/2 木村 /2 山田 /2 学生/活動年数 ・・・

14 木構造にするには レコードを分離する → 学生に付属するデータが複数になる 卓球部 サッカー部 剣道部 ・・・ ・・・ サークル 佐藤 /1
レコードを分離する　→　学生に付属するデータが複数になる 卓球部 サッカー部 剣道部 サークル ・・・ 佐藤 /1 田中 /1 田中 /2 石原 /1 木村 /2 石原 /2 山田 /2 学生/活動年数 ・・・

15 データの重複を避けるには ポインタを用いる（赤い点線矢印がポインタ） 工学部 理学部 法学部 建築学科 電気工学科 情報工学科 卓球部
石原 佐藤 田中 山田 木村 遠山 学生 （付随するデータはここに格納） 卓球部 サッカー部 剣道部 サークル 佐藤 /1 田中 /1 田中 /2 石原 /1 木村 /2 遠山 /2 山田 /2 ・・・ 学生/活動年数

16 論理的親子関係 ポインタのみで実体をもたない親子関係 （論理的親子関係を含めた階層スキーマ） 学部 学科 サークル 学生 論理的親 論理的
学生/活動年数 論理的子

17 第２章　データベースのモデル ２．１ 論理表現と3層モデル ２．２ 階層モデル ２．３ ネットワークモデル ２．４ 関係モデル

18 ２．３　ネットワークモデル ① 階層モデルの拡張 ② 代表例：CODASYL（Conference On Data Systems Language） または提案したデータベース作業グループの名前をとって、 DBTG(Database Task Group)システムと呼ばれる。 ③ このモデルで商用化されたDBMSの代表例として、 Cullinet Software社のIDMS（Integrated Database Management System）がある。

19 階層モデルとの違い ① 子レコード（member）は、任意数の親レコード（owner）を 持つことができる。 ② データベースは通常のレコード集合と、レコード間のリンク の集合（set）からなる。 カッコ内はCODASYL用語である。 なおスキーマの表現を発案者Charles W. Bachmanの名前をとってバックマンダイアグラム （Bachman Diagram）とよぶ。 （Charles W. Bachman、1924年12月11日 ～）

20 バックマンダイアグラムの例 レコードタイプを矩形、セットタイプを楕円形で示す。 学部 学科 サークル 学生 活動年数 構成 所属
所属サークル サークル活動 活動年数

21 インスタンスの例 学生レコード 佐藤 １ 卓球部 田中 １ 2 サッカー部 石原 １ 木村 2 剣道部 遠山 2 山田 2 活動年数レコード
サークルレコード 佐藤 １ 卓球部 田中 １ 2 サッカー部 石原 １ 木村 2 剣道部 遠山 2 サークル活動セット 山田 2 所属サークルセット

22 第２章　データベースのモデル ２．１ 論理表現と3層モデル ２．２ 階層モデル ２．３ ネットワークモデル ２．４ 関係モデル

23 ２．４　関係モデル ① データベースを表の集まりとみなす。 ② 関係代数や関係論理などの数学的基礎に基づく。 ③ データ操作言語は非手続き的で集合操作で行う。 IBMサンホセ研究所の英国人情報工学者エドガー・フランク・コッド（Edgar Frank “Ted” Codd、1923/8/23～2003/4/18）の提唱

24 関係モデルによる表現 表自体を「関係」または「リレーション」という。 学科 → 関係名 / リレーション名 スキーマ→ 属性
学科　→　関係名　/　リレーション名 スキーマ→　 学科ID 学科名 所属学部 E1 建築 工学部 E2 電気電子工学 E3 情報工学 ・ S4 物理学 理学部 属性 ←行 / タプル / レコード インスタンス→　

25 関係モデルによる表現例 複数の表で表現 学生 学科 サークル サークル活動 学科ID 学科名 所属学部 E1 建築 工学部 E2
学科　 学生 学科ID 学科名 所属学部 E1 建築 工学部 E2 電気電子工学 E3 情報工学 ・ S4 物理学 理学部 学生ID 学生氏名 所属学科ID 青田英二 E2 飯田大樹 牛島良平 江田和彦 ・ サークル サークル活動 サークル名 部員数 卓球部 21 サッカー部 32 剣道部 10 ・ 学生ID 学生氏名 活動年数 卓球部 1 野球部 2 サッカー部 剣道部 ・

26 現在のデータベース データ操作が簡潔なので関係モデルが主流 以下、関係モデルの詳細を述べる。
データ操作が簡潔なので関係モデルが主流 以下、関係モデルの詳細を述べる。 IBMサンホセ研究所の英国人情報工学者エドガー・フランク・コッド（Edgar Frank “Ted” Codd、1923/8/23～2003/4/18）の提唱