第２章 データベースのモデル ２．１ ２．２ ２．３ ２．４ 論理表現と3層モデル 階層モデル ネットワークモデル 関係モデル ２．１ 論理表現と3層モデル データの論理表現： データベースシステムが外部に見せる仕様 媒体上の格納形式やシステム内の動作手順を とは独立である（ハードウェア独立） どの範囲の仕様を外部に見せれば良いか？ これがデータベース研究の中心的な論点 使いやすさに関する２つの視点 ①マンマシンインターフェースとして使いやすさ （プログラムとDBMSとのインターフェースを含む） ②現実世界のモデル化をいかに自然に記述できるか （業務を運用・DBMSを構築する立場） 論理表現法＝データベースモデル これまでに商用化されたモデル ① 階層型データモデル（hierarchical data model ） ② ネットワーク型データモデル（network data model） ③ 関係モデル（relational model） データベースに必要な記述 ①スキーマ（schema：データ表現の枠組み） モデルに基づいて現実世界をどのように抽象化し たかについての記述。 ②インスタンス（instance） 格納された個々のデータ。 スキーマの例 ①データ構成 従業員データ＝｛従業員番号, 氏名, 住所, 誕生日, 所属部署｝ ②制約条件 同一の従業員番号は存在しない。 ③データ間の関連 所属（従業員, 部署） インスタンスの例 従業員番号12345, 山田栄一, 東京都田無市, 2002年12月15日, システム開発部 ANSI/SPARCの３階層モデルアーキテクチャ （American National Standards Institute/Systems Planning and Requirements Committee） スキーマには、その記述レベルがある 外部スキーマ ・・・・ 外部スキーマ 概念スキーマ 内部スキーマ 外部レベル （ビュー） 概念レベル 内部レベル それぞれのレベル ①外部レベル（external level）またはビュー（view） 個々の応用ブログラムや利用者の目的に応じて抽象化す るデータの枠組みを規定する。 ②概念レベル（conceptual level） 各種のデータモデルに基づいて現実世界の抽象化を行っ たもの。結果としてスキーマが保持される。 ③内部レベル（internal level） OSやファイル管理システムとのインターフェースによる物 理的なデータの格納形式等を記述したスキーマ記述とその インスタンスが格納されるレベル。 第２章 データベースのモデル ２．１ ２．２ ２．３ ２．４ 論理表現と3層モデル 階層モデル ネットワークモデル 関係モデル ２．２ 階層モデル 代表例：IBMのIMS（Information Management System） 階層モデルによるスキーマ表現（階層スキーマ） 学部 学科 学生 レコードタイプ/ セグメントタイプ（IMS用語） 階層モデルでのインスタンス例 レコードインスタンス / レコード / セグメント（IMS用語） 工学部 理学部 建築学科 電気工学科 佐藤 田中 法学部 ・・・ 情報工学科 石原 ・・・ 学部レコードタイプ ・・・ 学科レコードタイプ 学生レコードタイプ １対nの関係でない例 任意加入のサークルのような例ではn対mになってしまう。 卓球部 佐藤 /1 サッカー部 田中 /1/2 石原 /1/2 剣道部 木村 /2 ・・・ 山田 ・・・ /2 サークル 学生/活動年数 木構造にするには レコードを分離する → 学生に付属するデータが複数になる 卓球部 佐藤 /1 田中 /1 剣道部 サッカー部 田中 /2 石原 /1 木村 /2 石原 /2 ・・・ 山田 ・・・ /2 サークル 学生/活動年数 データの重複を避けるには ポインタを用いる（赤い点線矢印がポインタ） 工学部 建築学科 石原 法学部 理学部 佐藤 学科 情報工学科 電気工学科 田中 学部 遠山 木村 山田 学生 （付随するデータはここに格納） 卓球部 佐藤 /1 田中 /1 剣道部 サッカー部 田中 /2 石原 /1 木村 /2 遠山 /2 サークル 山田 ・・・ /2 学生/活動年数 論理的親子関係 ポインタのみで実体をもたない親子関係 （論理的親子関係を含めた階層スキーマ） 学部 学科 サークル 学生 論理的親 論理的 親子関係 学生/活動年数 論理的子 第２章 データベースのモデル ２．１ ２．２ ２．３ ２．４ 論理表現と3層モデル 階層モデル ネットワークモデル 関係モデル ２．３ ネットワークモデル ① 階層モデルの拡張 ② 代表例：CODASYL（Conference On Data Systems Language） または提案したデータベース作業グループの名前をとって、 DBTG(Database Task Group)システムと呼ばれる。 ③ このモデルで商用化されたDBMSの代表例として、 Cullinet Software社のIDMS（Integrated Database Management System）がある。 階層モデルとの違い ① 子レコード（member）は、任意数の親レコード（owner）を 持つことができる。 ② データベースは通常のレコード集合と、レコード間のリンク の集合（set）からなる。 カッコ内はCODASYL用語である。 なおスキーマの表現を発案者Charles W. Bachmanの名前をとってバックマンダイアグラム （Bachman Diagram）とよぶ。 （Charles W. Bachman、1924年12月11日 ～） バックマンダイアグラムの例 レコードタイプを矩形、セットタイプを楕円形で示す。 学部 構成 学科 サークル 所属 学生 所属サークル サークル活動 活動年数 インスタンスの例 学生レコード 活動年数レコード 佐藤 １ 田中 １ 2 石原 １ 木村 2 遠山 2 山田 2 サークルレコード 卓球部 サッカー部 剣道部 サークル活動セット 所属サークルセット 第２章 データベースのモデル ２．１ ２．２ ２．３ ２．４ 論理表現と3層モデル 階層モデル ネットワークモデル 関係モデル ２．４ 関係モデル ① データベースを表の集まりとみなす。 ② 関係代数や関係論理などの数学的基礎に基づく。 ③ データ操作言語は非手続き的で集合操作で行う。 IBMサンホセ研究所の英国人情報工学者エドガー・フランク・コッ ド（Edgar Frank “Ted” Codd、1923/8/23～2003/4/18）の提唱 関係モデルによる表現 表自体を「関係」または「リレーション」という。 学科 → 関係名 / リレーション名 スキーマ→ インスタンス→ 学科ID 学科名 所属学部 E1 建築 工学部 E2 電気電子工学 工学部 E3 情報工学 工学部 物理学 理学部 ・ ・ S4 ・ ・ 属性 ←行 / タプル / レコード 関係モデルによる表現例 複数の表で表現 学生 学科 学科ID 学科名 所属学部 学生ID 学生氏名 所属学科ID E1 建築 工学部 1122101 青田英二 E2 E2 電気電子工学 工学部 1122102 飯田大樹 E2 E3 情報工学 工学部 1122103 牛島良平 E2 1122104 江田和彦 E2 ・ ・ S4 物理学 理学部 ・ ・ ・ ・ サークル サークル名 サークル活動 部員数 学生ID 学生氏名 活動年数 卓球部 21 1122101 卓球部 1 サッカー部 32 1122102 野球部 2 剣道部 10 1122103 サッカー部 2 ・ ・ 1122104 剣道部 1 ・ ・ ・ ・ 現在のデータベース データ操作が簡潔なので関係モデルが主流 以下、関係モデルの詳細を述べる。 IBMサンホセ研究所の英国人情報工学者エドガー・フランク・コッ ド（Edgar Frank “Ted” Codd、1923/8/23～2003/4/18）の提唱
© Copyright 2024 ExpyDoc
