参考資料1 - 山口大学
Download
Report
Transcript 参考資料1 - 山口大学
データベース論II
データベース概論
オブジェクト指向データベース
データベース設計論
データ格納方式
同時実行制御
障害回復
データベースプログラミング
2
データベースシステムの利用分野
人事管理システム，在庫・販売管理システム，生産管
理システム．
銀行のオンラインシステム
切符の予約システム
エンジニアリングデータの管理システム
–
CAD、CASE
科学データ管理システム
文書管理
–
–
XML
テキストデータベース（新聞記事）
3
データベースシステムとは？
データベース
–
–
データベース管理システム(DBMS)
–
対象とする現実世界をコンピュータ上に表現したもの。
「複数の応用目的での共有を意図して組織的かつ永続的
に格納されたデータ群」
データベースを管理するソフトウェア
データベースシステム（図1.1）
–
データベース＋DBMS＋ユーザ、アプリケーション
4
データベースシステムを導入する利点
データをアプリケーションから独立させる
–
関連するデータを統合する
–
データの多目的利用を可能とする。
無用な重複、不整合を防ぐ
データの意味、相互関連の把握を容易にする
データの表現方法、管理方法を標準化する
5
DBMSの機能(1)
データモデル
データとそれに対する操作を規定した枠組み
–
リレーショナルデータモデル
–
–
–
データを「表」で表す。
階層データモデル
ネットワークデータモデル
オブジェクト指向データモデル
様々なデータモデルがあり、DBMSによって採用する
データモデルが異なる。
6
DBMSの機能(2)
効率の良いデータアクセス機構
大量のデータから意中のデータを高速に取り出す
–
木構造、ハッシングなどを用いたデータ格納方式
ー＞ 第6章
問い合わせ最適化
–
–
–
一つの検索に対して、複数の処理手続きが存在する
最も効率的な処理手続きを立案し、実行する
第7章
7
DBMSの機能(3)
整合性の維持
データが満たすべき条件(制約)の管理
データモデルを用いてデータの構造や関連を明示的
に管理することで可能となる
8
DBMSの機能(4)
同時実行制御
トランザクション
–
–
ひとまとまりの処理単位
銀行口座から預金を引き出す
口座番号、暗証番号のチェック
残高の確認
引き出す金額と残高の比較
残高の値を更新
これらの処理はひとまとまりとして処理されなければならない。
複数のトランザクションを同時に処理する
–
処理結果に矛盾が生じてはならない
9
DBMSの機能(5)
障害回復
コンピュータは必ず壊れる
障害に対してデータの保護を行う必要がある
–
–
ログファイルを用いた障害回復
第9章
10
データベースシステムの基本概念
スキーマ
–
–
データベース中のデータの構造、形式、関連、整合性制約
を記述したもの
3つの抽象化レベル（ANSI/SPARCモデル）
外部スキーマ、概念スキーマ、内部スキーマ
インスタンス
–
スキーマに基づいたデータ群
11
データモデル
役割
–
DBMSはある一つのデータモデルを採用している
–
現実世界のモデル化のツール
DBMSのインターフェース
「大学」という組織をどうコンピュータで表現するか？
代表的なデータモデル
–
–
–
リレーショナルデータモデル
ネットワークデータモデル
階層データモデル
12
リレーショナルデータモデル
データを「表」で表現
整合性制約（データが満たすべき条件）
–
–
–
–
データ操作はリレーショナル代数（論理）で規定
–
ドメイン制約
キー制約
参照整合性制約
従属性（第4章）
和、差、直積、射影、選択、結合、共通部分、商
実際のデータ操作は、データベース操作言語SQL
13
実世界のデータモデリング
複雑な現実世界をDBMSのデータモデルで直接モデル化する
のは難しい。
DBMSのデータモデルの制約にとらわれない自然な表現機構
を持つことは、データベースの構造や意味を理解する意味で
も有用。
概念設計と概念モデル＆論理設計と論理モデル
概念設計
論理設計
概念モデル記述言語
実世界
データ ベース
管理者
概念
モデリ ング
データ モデル
概念
モデル
データ
モデリ ング
論理
モデル
データ ベース
14
概念設計のためのデータモデル
実体関連モデル（ERモデル）
実体
–
–
存在を認識できる対象を包括的に述べたもの。
大学の科目履修のデータベース
–
–
個々の学生、科目、実習課題などはすべて実体
属性 -> 実体の持つ各種の性質を表すもの
実体集合ごとに属性の集合が決まる。
関連
–
–
–
2つ以上の実体同士の相互関係を表したもの
実体集合「学生」と「科目」の間の関連集合「履修」
テキストpg.24の実体関連図を参照
15
データベース操作言語SQL
http://infux03.inf.edu.yamaguchi-u.ac.jp/~nakata/link2.htmlを参照
16
オブジェクト指向データベースシステム
リレーショナルDBMS
–
ビジネスアプリケーション
–
大量の定型的データ
適用分野の広がりに伴って、問題点も出てきた
CAD
ソフトウェア開発などのエンジニアリングアプリケーション
科学技術アプリケーション
先進的なオフィスアプリケーション
文書データベース
– グループウェア、意思決定支援システムなど
–
–
弱点が整理されている
17
リレーショナルデータベースシステムの弱点
(A) 構造データの表現力の不足
データの構造が複雑
–
–
設計図面
設計階層
部品間の相関関係
例：2次元画面における多角形のデータ(4つのリレー
ション)
–
–
–
–
–
「多角形」 －＞ 色、塗りつぶしのパターン
「多角形構成」 －＞ どの辺をどういう順序で結ぶか?
「辺」 －＞ 各辺の両端点の点
「点」 －＞ 点の座標とその形状
pg.190 図10.1
18
(A) 構造データの表現力の不足
多角形を表現する4つのリレーション
このようにすること
で、すべての多角
形を表現可能
ひとつの多角形と
して認識している
p1が複数のリレー
ションに分割されて
いるため、わかりに
くい。
–
どんな多角形がい
くつある?
多角形
PID
p1
p2
色
赤
青
多角形構成
PID
接続順
p1
1
p1
2
p1
3
...
...
パターン
メッシュ
ストライプ
EID
e1
e2
e3
...
辺
EID VID1 VID2
e1
v1
v2
e2
v2
v3
e3
v3
v1
e4
v3
v4
...
...
...
点
VID 形状
v1
丸
v2
丸
v3 星型
v4
丸
...
...
X
0
0
1
2
...
Y
0
1
1
0
...
19
(A) 構造データの表現力の不足
多角形を表現する4つのリレーション
ばらばらに格納された
データを解釈するの
はユーザの責任。
データの整合性を保
つことが難しい。
点の座標を得るため
に結合演算が必要に
なる。
点の追加、削除時に
多くのデータを変更が
必要。
多角形
PID
p1
p2
色
赤
青
多角形構成
PID
接続順
p1
1
p1
2
p1
3
...
...
パターン
メッシュ
ストライプ
EID
e1
e2
e3
...
辺
EID VID1 VID2
e1
v1
v2
e2
v2
v3
e3
v3
v1
e4
v3
v4
...
...
...
点
VID 形状
v1
丸
v2
丸
v3 星型
v4
丸
...
...
X
0
0
1
2
...
Y
0
1
1
0
...
20
リレーショナルデータベースシステムの弱点
(B) 人工的な主キーの付与
「多角形」、「辺」、「点」
–
–
–
–
ID (Identifier)を持ち、それが主キー
学生に「学籍番号」、科目に「科目番号」は普通に考えられ
る
多角形の識別子？？、辺の識別子？？ ＝＞ 意味不明
いちいち通し番号をつけるのは面倒でもある。
21
リレーショナルデータベースシステムの弱点
(C) データ固有の手続きの欠如
リレーショナルDBMS
–
–
多角形の例では、
–
–
タプルの挿入、削除、修正、検索などの操作を提供
画一的で基本的な操作のみ
「多角形の面積を求める」手続き
多角形を削除する －＞ 「多角形」中のタプルだけではなく、
対応する点、辺などもまとめて削除する手続き
リレーショナルDBMSでは、これらの操作すべてユー
ザがプログラムで作成する必要がある。
22
リレーショナルデータベースシステムの弱点
(D) 拡張性に乏しいデータ型
リレーショナルDBMSのデータ型
–
文字列、数字、ビット列、日時など －＞ 既定である
データ型の拡張を求められることがある
–
「多角形」型のようなデータ型が定義できれば、ユーザはリ
レーションをわざわざ定義することがない。
問い合わせなどにおいても利用できる
C言語の構造体のようなもの
23
リレーショナルデータベースシステムの弱点
(E) 汎化階層
現実世界のモデル化には、ERモデルにおける汎化
階層の概念が有効であるが、リレーショナルDBMSで
はこれを直接表現できない。
–
複数のリレーションに分割して表現
集約階層
–
（A)と同様の問題点を持つ
–
24
リレーショナルデータベースシステムの弱点
(F) インピーダンスミスマッチ
リレーショナルモデル
–
–
–
データ構造は「表（リレーション）」である。
通常のプログラミング言語（たとえばC言語）のデータ構造
とは異なる。
データ型の相違も存在 －＞ char型の配列とstring型
通常はホスト言語形式でプログラミング
–
–
–
データベース操作はSQL、それ以外はC言語などで。
プログラミングが難しくなる。
実行効率も悪くなりがち。
25
弱点の解決策
入れ子型リレーショナルデータモデル
–
グラフデータモデル
–
リレーション間の関係をリンクの概念で表現
拡張リレーショナルデータモデル
–
表の要素の中にさらに表。
汎化階層や集約階層を表現可能なように拡張されたリレー
ショナルデータモデル
オブジェクト指向データモデル
26
オブジェクト指向データモデル
Object-Oriented DBMS (OODBMS, ODBMS)
–
オブジェクト指向言語の研究を背景としている
–
ここ10年ほどで広まってきたデータモデル
C++、Smalltalkなど
オブジェクト指向言語
–
オブジェクト
データとそれに対する操作手続きを一体にしたもの
構造体＋構造体専用の関数
27
pp.193-194の例
製造会社における販売製品のユーザ管理
「製品」オブジェクト
–
–
製品番号、製品名、販売日、製造工場、ユーザなどの属性
値と製品に対する操作手続きを一体化したもの。
操作
売れた製品に関するユーザ登録
販売日からの経過日数の算出
ー＞ 操作をメソッドと呼ぶ
28
オブジェクト指向言語の世界(1)
オブジェクト同士がメッセージをやり取りすることで動
作する
データ
手続き
オブジェクト
データ
手続き
データ
手続き
データ
手続き
データ
手続き
メッセージを受け取った
オブジェクトは対応する
メソッドを実行して返事
を返す
29
オブジェクト指向言語の世界(2)
オブジェクトは型を持つ
–
–
–
「製品型」
同じ型のオブジェクトは、同様の属性(構造体におけるメン
バ)を持つ
この「型」のことをクラスと呼ぶ。
オブジェクトの型は階層を構成できる。
–
クラスAがクラスBを継承するとき、クラスBは少なくともクラ
スAが持つ属性を持つ。
30
永続的なオブジェクトの集まりとしての
オブジェクト指向データベース
オブジェクトの永続的（電源を切っても消えない）な集
まり
オブジェクトの記述、操作の規約
–
–
オブジェクト指向データモデル
オブジェクトモデル などと呼ばれる
リレーショナルデータモデルのような明確な定義、数
学的な裏づけがあるわけではない。
–
満たすべき、いくつかの要件が挙げられている
31
オブジェクト指向データモデルが満たすべき要件
(1) 複合オブジェクト
複雑な内部構造を持つオブジェクト
–
–
–
RDBではタプル（行）の値は単純値
複合オブジェクトでは、タプル（一行）、集合、マルチ集合、
リスト、配列などを値として持てる。
つまり、オブジェクトの中に、ひとつ、あるいは複数の別の
オブジェクトを入れ子状にもてる。
多角形p1の例
[P1：（赤、メッシュ、<(丸, 0, 0)、(丸, 0, 1)、(星型, 1, 1)>）]
– P1はオブジェクト識別子（後述）。
– ()はタプル －＞ 異なる意味を持つ複数の値の集まり。
– <>はリスト －＞ 同様の値の集まり。
32
オブジェクト指向データモデルが満たすべき要件
(2) オブジェクト識別性
オブジェクトの性質にかかわらずに各オブジェクトを
識別する手段が提供されている。
–
オブジェクトの属性値がすべて同じであっても、別のオブ
ジェクトとして認識できる。 －＞ リレーショナルデータモデ
ルでは、すべての属性値が同じである行は一行しか存在で
きない(キー制約)。
オブジェクト識別子
–
–
–
オブジェクトを識別するためにつけられる属性。
DBMSによって自動的に付加される点がリレーショナルモ
デルとの相違点。
オブジェクトがほかのオブジェクトを参照するときに利用可
能
33
オブジェクト指向データモデルが満たすべき要件
(2) オブジェクト識別性
オブジェクト識別子を用いた、オブジェクトの参照
–
–
–
[P1: (赤、メッシュ、<E1,E2,E3>) P1がオブジェクト識別子
[E1: <V1,V2>]、[E2:<V2,V3>]、[E3:<V3,V1>]
[V1: (丸, 0, 0)]、[V2: (丸, 0, 1)]、[V3: (星型, 1, 1)]
図10.1との相違
–
内部構造がタプルのみではない。
–
リストを用いているので順序が表現できる。
–
リストを含む
V1はV2の前
参照関係がオブジェクト識別子を通じてDBMS側に完全に
把握されている。
34
オブジェクト指向データモデルが満たすべき要件
(3) カプセル化
オブジェクトして、属性値と操作を一体化して管理
–
–
–
–
外部（ほかのオブジェクト）には、必要最小限の属性のみを
見せる。
抽象データ型に由来
必要な属性のみを見せることで不整合が起こるのを防ぐ。
例えば、多角形の面積を求めたい場合は、それぞれの辺、
頂点の属性値を見せるのではなく、「面積を求める手続き
（関数）」のみを公開する。
頂点の属性値などを誤って更新される心配がなくなる。
35
オブジェクト指向データモデルが満たすべき要件
(4) 型／クラスと型／クラス階層
型／クラス （以降、クラス）
–
–
–
–
同じ属性値とメソッドをもつオブジェクトをまとめるための枠
組み －＞ 構造体の定義 strcut XXX
あるクラスに基づくオブジェクト －＞ インスタンス
クラスは、オブジェクトの共通部分をまとめたもの、と表現
することもできる。
クラス同士も共通部分を持つことも多い。
「製品」のひとつとして「自動車」を考える
「製品」クラスのオブジェクトは、製品番号、製品名、販売日、製品
工場、ユーザなどの属性とそれらに対する操作を持つ。
36
オブジェクト指向データモデルが満たすべき要件
(4) 型／クラスと型／クラス階層 （２）
「自動車」クラスのオブジェクトも「製品」の一種
–
–
「製品」と同様の属性を持つ
さらに、登録ナンバー、車両登録の操作などが付け加えら
れる
「製品」と「自動車」クラスの関係
–
–
–
汎化階層
「自動車」は特殊な「製品」であると考えられる。
「製品」が上位クラス、「自動車」が下位クラス
製品
U
自動車
37
オブジェクト指向データモデルが満たすべき要件
(4) 型／クラスと型／クラス階層 （３）
単一継承
–
多重継承
–
直接の上位クラスがひとつ
直接の上位クラスが複数
製品
製品
乗り物
U
U
U
自動車
自動車
操作の再定義
–
–
自動車と軽自動車では
登録の手続きが違う。
同じ操作名でも中身が
異なるー＞多重定義
製品
U
自動車 登録手続き
U
軽自動車
登録手続き
38
オブジェクト指向データモデルが満たすべき要件
(5) 計算完備
オブジェクト指向DBMSが提供するデータ操作言語で、
通常のプログラミング言語（例えばC言語）で記述可
能な操作がすべて記述できること。
SQLはデータ操作のみを提供するので、通常のプロ
グラミング言語と併用する。
39
オブジェクト指向データモデルが満たすべき要件
(6) 拡張可能性
ユーザが型／クラスを自由に定義できる。
あらかじめ用意されているデータ型、クラスと区別なく
使用できる。
40
オブジェクト指向データベースシステム
が満たすべき要件
複合オブジェクト、オブジェクト識別性、カプセル化、
クラス、クラス階層、再定義･多重定義･遅延束縛、計
算完備、拡張可能性 ➀～⑧
⑨永続性 －＞ 2次記憶上にオブジェクトを管理する
ことで恒久的に保存する
⑩二次記憶管理 －＞ オブジェクトの物理的格納、索
引管理、問い合わせ処理 （内部スキーマ）
⑪、⑫ 同時実行制御、障害回復 ー＞9章で述べるす
べてのDBMSに必要な機能
41
オブジェクト指向データベースシステムが満
たすべき要件（２）
⑬ アドホックな問い合わせ
–
–
データベースごとに問い合わせのパターンがあらかじめ固
定されることなく、必要に応じて宣言的に問い合わせができ
ること。
その場限りの（一度限りの）お手軽な問い合わせ。
➀～⑧ －＞ データモデルが満たすべき要件
⑨～⑬ －＞ システムが満たすべき要件
42
オブジェクト指向データベースシステムの実
現のアプローチ
リレーショナルDBMSを拡張する方向
–
–
オブジェクト･リレーショナルDBMS
今日ではこちらが一般的
オブジェクト指向プログラミング言語（例えばC++）の
枠組みの中で、永続的なオブジェクトを扱えるように
したシステム。
–
永続的プログラミング言語とも呼ばれる
43
オブジェクト・リレーショナルデータベース管
理システム
PostgreSQL
–
–
–
フリーのオブジェクトリレーショナルDBMS
Linux, Windowsで利用可能
参考文献(URL)
改訂第3版 PC UNIXユーザのためのPostgreSQL完全攻略ガイド、
石井達夫著、技術評論社
PostgreSQLオフィシャルマニュアル、PostgreSQL Global
Development Group著，インプレス
http://www.postgresql.jp/
44
リレーショナルデータベース設計論
ERモデルからのリレーショナルデータベースス
キーマの導出
概念モデルから論理モデルを導き出す方法のひとつ。
概念設計
論理設計
概念モデル記述言語
実世界
データ ベース
管理者
概念
モデリ ング
データ モデル
概念
モデル
データ
モデリ ング
ERモデル
によるモデリング
の結果
論理
モデル
データ ベース
リレーショナルデータ
ベーススキーマ
45
ERモデルからのリレーショナルデータベーススキーマの導出
実体集合の扱い(1)
A) 通常実体集合
–
–
–
–
通常実体集合Eに対してリレーションRを定義し、Eのすべ
ての属性をRの属性とする。
図2.8 pg.28
学生(学籍番号、氏名、専攻、住所)
科目(科目番号、科目名、単位数)
ERモデル図（図2.8 pg.28 ）
氏名
科目名
専攻
住所
学籍番号
学生
N
成績
履修
科目番号
M
U
TA
1
経験年数 内線番号
担当
1
科目
課題番号
単位数
1
実習
N
課題名
実習課題
47
ERモデルからのリレーショナルデータベーススキーマの導出
実体集合の扱い(2)
B) 弱実体集合
–
実体集合E’を識別上のオーナとする実体集合Eに対しては
リレーションRを作成し、Eのすべての属性をRの属性とす
る。さらに、E’に対応するリレーション主キーをRの属性に
加え、これとEの部分キーの組み合わせをRの主キーとす
る。
–
実習課題(科目番号、課題番号、課題名)
48
ERモデルからのリレーショナルデータベーススキーマの導出
実体集合の扱い(3)
C) 汎化階層の扱い
–
–
–
実体集合Eに関する汎化階層があり、Eの上位の実態集合
E’が存在する
E’に対応するリレーションの主キーをEに対応するリレー
ションRに加えてこれをRの主キーとする。
TA(学籍番号、経験年数、内線番号)
49
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(1)
A) 次数2の関連集合
–
[前提] 関連集合により関係づけられる二つの実体集合に
対応するリレーションをR1、R2とする。
➀ 1対1対応の場合
–
R1あるいはR2のいずれかにもう一方のリレーションの主キーおよ
び関連集合の属性を付加する。
TA(学籍番号、経験年数、内線番号、科目番号)
50
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(2)
② 1対N対応の場合
–
R1およびR2がそれぞれ1側およびN側の実体集合に対応
したリレーションであるとする。
科目がR1、実習課題がR2
–
このとき、R2にR1の主キーおよび関連集合の属性を付加
する。
–
実習課題(科目番号、課題番号、課題名)
ここでは、（１）のB)ですでに主キーが挿入されているので変化なし。
51
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(3)
③ N対M対応の場合
–
–
–
R1の主キー、R2の主キー、関連集合の属性からなる新た
なリレーションを定義する。
新たなリレーションの主キーは、R1とR2の主キーの組み
合わせとなる。
履修(科目番号、学籍番号、成績)
52
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(4)
B) 次数3以上の関連集合
次数2の③ N対M対応の場合と同様に新たなリレー
ションを定義する
53
好ましくないリレーションスキーマ
概念モデル（ERモデル）から変換したスキーマ
–
–
理解しやすいか？必要な性質を持っているか？といったこ
とは概念モデルのできに関わってくる。
場合によっては、好ましくないリレーションスキーマが生成
される。
54
好ましくないリレーションスキーマの例
pg.58の例
販売価格
商品
営業
顧客
商品
営業マン
顧客
変換
営業マン
営業
商品番号 顧客番号 社員番号 販売価格
営業の主キー：（商品番号、顧客番号）
リレーション「営業」にいくつかの問題点
55
リレーション「営業」の問題点(1)
(A) 修正不整合
(modification anomaly)
–
–
顧客cが購入する商品ごとに
担当のsの社員番号が繰り返
し格納される －＞ 冗長
担当が替わるときには、全て
の社員番号を変更する必要
がでてくる。
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
i4
c1
s1
150
56
リレーション「営業」の問題点(2)
(B) 挿入不整合 (insertion
anomaly)
–
–
各顧客の営業担当の情報も
格納している。
商品は購入していないが、担
当が決まっている顧客のデー
タを入れることができない。
商品番号が主キーの一部
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
c3
s1
57
リレーション「営業」の問題点(3)
(C) 削除不整合 (deletion
anomaly)
–
–
–
商品を一つだけ購入している
顧客（c4）がいたとする。
c4が購入していた商品を取り
扱い中止にしたとする。
c4の担当がs1であったという
情報まで消えてしまう。
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
i4
c4
s1
150
58
更新不整合（update anomaly）
上記の(A), (B), (C)をまとめて更新不整合と呼ぶ
上記の例で更新不整合が発生する原因
–
–
–
顧客と担当の関係が商品の販売情報の中に紛れ込んでい
るため。
リレーション「営業」には二つの独立した情報が混在してい
る。
これを分割すればよい。
59
更新不整合の解決
「販売」を「販売」と「営業担当」
の二つに分ける。
–
販売
–
商品番号と顧客番号の組み合
わせが主キー
営業担当
販売
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
i4
c1
s1
150
顧客番号が主キー
販売
商品番号 顧客番号 販売価格
i1
c1
100
i1
c2
120
i2
c1
200
i2
c2
210
i3
c1
250
i3
c2
250
i4
c1
150
営業担当
顧客番号 社員番号
c1
s1
c2
s2
60
二つに分けるとなぜ問題が解決するか？
新しい「販売」と「営業担当」は、更新不整合を解消す
るためのある種の「正規形」に分類される形式となっ
ている。
–
様々な種類の正規形が存在する。詳細は後述。
二つに分けても、結合(join)を取ることで、商品、顧客、
担当を関係を一体として捉えることが可能。
–
分解前のリレーションを再現できる
－＞ 無損失結合分解
61
無損失結合分解を用いて正規形に分解することで、
元のスキーマと等価な情報をより管理しやすい形に
変換して管理できる。
4.3節以降の内容
–
–
関数従属性とは？
正規形とは？
リレーションスキーマの表記について
–
–
R(A1, A2, A3, ..., An)
{A1, A2, A3, ..., An} ＜－ リレーション名を省いた表記
62
関数従属性 (functional dependency (FD))
リレーションスキーマR(..., X, ..., Y, ...)が与えられた時（XとY
は単一の属性とは限らず、属性集合の場合もある） 、その任
意のインスタンス中の任意の2タプルに関して、もしそのXの値
が等しいならYの値も等しいという制約が成立する時、関数従
属性X→Yが成立するという。
R
X
a
Y
b
a
b
63
関数従属性を用いた超キーの表現
リレーションスキーマR(A1, A2, ..., An)において属性集合SK
が超キーである。
–
属性集合SKが決まれば、タプル（行）が一意に決まる。
これを関数従属性で表現すると
関数従属性SK→{A1, A2, ..., An} となる。
R
A1
SK
A2
a
An
b
a
b
64
関数従属性の形式的な定義
リレーションスキーマRS、属性集合X,Y⊆RSとすると
–
–
関数従属性が成立する時
–
XはYを関数的に決定するという。
リレーション「営業」では
–
–
(∀t∈R) (∀u∈R) (t[X] = u[X] → t[Y] = u[Y])
t[X]はタプルｔの属性集合Xの属性値
商品番号、顧客番号 －＞ 販売価格
顧客番号 －＞ 社員番号
関数従属性は一つのタプルだけでは判断できない。
リレーションスキーマ全体を見て判断する必要がある。
65
関数従属性を用いたキーの表現
リレーションスキーマRSにおいて属性集合Xが超
キーであるとは、
(1) X → RS
が成立すること。
さらに、
(2)Xのいかなる真部分集合YについてもY－＞RS
は成立しない場合、Xは候補キーである。
66
論理的に含意と閉包
関数従属性A→B、 B→Cが成立するなら、明らかに、
A→Cが成立する。このような時、｛ A→B、 B→C ｝は
A→Cを論理的に含意(logically imply)するという。
関数従属性の集合F
–
–
–
通常は、上記のような含意を含む。
これらを含めて全ての関数従属性をFの閉包(closure)と呼
ぶ。
表記はF+
通常、 F+はたくさんありすぎて数え切れない。
–
F+を論理的に数え上げる規則があれば便利。
67
アームストロングの公理系
X,Y,Z⊆RSとして
① 反射律(reflexivity law)
Y⊆Xのとき、X→Yが成
立する。
② 増加律 (augmentation law)
X→Yのとき、XZ→YZ
(X∪Z→Y∪Z)が成立する。
RS
A
B
C
D
Y
X
RS
A B C D E F
X
Y
Z
68
アームストロングの公理系
③ 推移律 (transitivity law)
X→YかつY→Zのとき、 X→Zが成立する。
健全：関数従属性Fから公理系を利用して求められた全ての従属性はF+の要素で
ある。
完全：F+の全ての要素が公理系を用いて求められる。
RS
A B C D E F
X
Y
Z
69
アームストロングの公理系により、導き出さ
れる規則
① 合併律(union law)
X→YかつX→Zのとき、
X→YZが成立する。
② 擬推移律
(pseudotransitivity law)
X→YかつWY→Zのと
き、XW→Z が成立する。
RS
A B C D E F
X
Y
Z
RS
A B C D E F G H
X
Y
W
Z
70
アームストロングの公理系により、導き出さ
れる規則
③ 分解律 (decomposition law)
X→YかつZ⊆Yのとき、 X→Zが成立する。
RS
A B C D E H
X
Z
Y
71
関数従属性集合Fに関する、属性集合Xの
閉包
ある属性集合Xにより、関数的に決定される属性集
合
–
–
F+は、関数従属性集合Fの閉包
こちらは、関数従属性集合Fがあったとき、属性集合Xに
よって決定される属性の全体
表記はX+
X+ = {A | A∈RS ∧ (X→A)∈F+}
–
–
AはRSに含まれる属性集合
X→Aは、「Xが決まればAが決まる」という関数従属性
72
等価 (equivalent)
関数従属性集合F、Gが与えられた時、
F+ = G+
が一致する時、FとGは等価である。
–
等価であることを調べるには、F+ ⊇ G+ かつF+ ⊆ G+ が成
立することをチェックすればよい。
ある従属性集合に等価な従属性集合のうち、冗長性
のない簡潔なものを求めたいという問題が発生する。
－＞ 極小被覆 (minimal cover)
73
極小被覆 (minimal cover)
関数従属性Fに等価な関数従属性のうち、以
下の条件を満たすMをFの極小被覆と呼ぶ。
(1) M中のすべての関数従属性の右辺は単一の属性
–
X→A ∈ Mのとき、Aは単一の属性（属性集合ではない）
(2) M中のいかなる関数従属性X→Aに対しても、
M – {X→A}とMは等価でない。
–
M中の要素には不要なものが一つも無い
74
極小被覆 (minimal cover)
(3) M中のいかなる関数従属性X→AおよびZ⊂Xに対し
ても、 M – {X→A}∪{Z→A}とMは等価でない。
–
MからX→Aを引いた後に、Z→Aを足しても等価ではない。
RS
A B C D E H
X
Z
A
Y
75
関数従属性Fの極小被覆は複数個存在する。
–
–
–
{A,B,C}
F = {A->BC, B->C, C-> B}
F= {A->B, A->C B->C, C->B} (1)より 分解律
= {A->C, B->C, C->B} (2)より
A->BはA->CとC->Bで表現できる。
–
F= {A->B, A->C B->C, C->B} (1)より
= {A->B, B->C, C->B} (2)より
76
分解
RS={A1, ..., An}に対して、RSi⊆RS(1≦i≦m)なるリ
レーションスキーマの集合ρ（ロウ）={RS1, ..., RSm}で
RS1∪...∪RSm=RSとなるものをRSの分解と呼び、 ρ
を求めることをRSを分解するという。
RS
A
B
A
RS1
B
C
D
RS2
C
A
D
77
分解
分解は更新不整合を解消したリレーションを得
る一つの手法。
分解後のスキーマが元のリレーションスキーマ
と同じ情報を表現することを保証できるか？
－＞ 無損失結合分解
78
無損失結合分解
RSに関する関数従属性集合FとRSの分解
｛RS1, ... ,RSm｝が与えられた時、Fを満足するRSの
全てのインスタンス（実際の行）Rについて、
R RS1 (R) RSm (R) が成立とき、分解ρはRSの
無損失結合分解である。
RS1 (R) は射影 pp.40-41
は自然結合 pg.43
79
無損失結合分解の例
R RS1 (R) RS2 (R) が成立する。
ここで、RS1={氏名、所属、学年}、RS2={氏名、研究室}
R －＞
R －＞
氏名
重永
桑本
RS
所属 学年 研究室
教育
M2 情報処理
教育
4 情報工学
氏名
重永
桑本
RS1
所属
教育
教育
学年
M2
4
RS2
氏名 研究室
重永 情報処理
桑本 情報工学
80
無損失結合分解の性質
RS1 (R) RSm (R) がR中には無かったようなタプ
ルを含まずにちょうどRに一致する。
関数従属性集合Fに応じてどのような分解が無損失
結合分解となるかが決まる。 －＞ 定理4.1
81
定理4.1
ρ={RS1,RS2}をリレーションスキーマRSの分解とし、
FをRSに関する関数従属性集合とする。
このとき、分解ρが無損失結合分解となる必要十分条
件は、
(RS1∩RS2 → RS1－RS2) ∈ F+
または
(RS1∩RS2 → RS2－RS1) ∈ F+
であることである。
82
定理4.1の応用例
販売の極小被覆は、
–
販売
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
...
...
...
...
｛商品番号,顧客番号->販売価格、 顧客番号->社員番号｝
{R1(商品番号,顧客番号,販売価格)、
R2(顧客番号, 社員番号)}は販売の無損失結合分解
–
–
RS1∩RS2=｛顧客番号｝、 RS2－RS1 ={社員番号}
よって、 (RS1∩RS2 → RS2－RS1) ∈ F+が成立
83
定理4.1の応用例
販売の極小被覆は、
–
販売
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
...
...
...
...
｛商品番号,顧客番号->販売価格、 顧客番号->社員番号｝
{{商品番号,顧客番号}, {商品番号,社員番号,販売価
格}}は無損失結合分解ではない。
–
–
RS1∩RS2=｛商品番号｝、 RS1－RS2={顧客番号}、
RS2－RS1 ={社員番号,販売価格}
よって、 (RS1∩RS2 → RS1－RS2) ∈ F+
(RS1∩RS2 → RS2－RS1) ∈ F+のいずれも成立しない。
84
無損失結合分解以外の分解に関する性質
元のリレーションスキーマに関する関数従属性集合と
して表現された整合性制約が、分解により得られたス
キーマ集合に関する関数従属性集合として表現可能
であるか？
–
整合性制約
データが満たさなければならない条件（pp.35-37）
–
–
ドメイン制約､キー制約など
この議論のために､「関数従属性の射影」という概念を導入
する。
85
関数従属性の射影
通常の射影 pp.40-41
スキーマRSとその関数従属性集合Fおよび属性集合
Z⊆RSが与えられた時、
πZ(F) = {X→Y ｜ XY⊆Z ∧ X→Y∈F+}
をFのX上への射影という。
RS={A,B,C}, F={A->B, B->C, C->B}であるとき、
–
πAB(F)={A->B}、 πBC (F)={B->C, C->B}
πAC(F)={A->C} A->CはA->BとB->Cで表現される
86
従属性保存分解
スキーマRSとその関数従属性集合F、RSの分解
ρ＝{RS1,...,RSm}が与えられた時、
任意の関数従属性X->Y∈Fに対して
πRS1(F)∪...∪πRSm(F) |= X→Y
が成立するなら、分解ρはFに関する従属性保存分解
であるという。
–
|= ．．．． 論理的に含意
87
従属性保存分解の例
RS={A,B,C}, F={A->B, B->C, C->B}であるとき、
{RS1(A,B), RS2(B,C)}は従属性保存分解
–
–
–
–
πRS1(F) =πAB(F) = {A->B}
πRS2(F) =πBC(F) = {B->C, C->B}
よって、 πRS1(F)∪...∪πRSm(F) = {A->B, B->C, C->B}
これは、 X->Y∈Fに対して
πRS1(F)∪πRS2(F) |= X→Yである。
88
従属性保存分解の例
RS={A,B,C}, F={A->B, B->C, C->B}であるとき、
{A,B}, {A,C}}は従属性保存分解でない。
–
–
–
–
–
πRS1(F) =πAB(F) = {A->B}
πRS2(F) =πAC (F) = {A->C}
よって、 πRS1(F)∪...∪πRSm(F) = {A->B, A->C}
これは、 X->Y∈Fに対して
πRS1(F)∪πRS2(F) |= X→Yではない。
B->C、C->Bが表現できていない。
89
正規形
もともと、リレーショナルデータモデルにおいては､第1
正規形でなければならない。pp.33-34
–
各属性は分解不可能な単純値でなければならない。
第1正規形では、4.2節のような問題が生じる。
4.2節で挙げられた問題点を伴わないための条件を、
従属性を用いて表現できる。
第一正規形の条件にさらに条件を付け足す。
–
高次の正規化
90
第3正規形
リレーショナルデータモデルの考案者が考えた、最も
基本的な正規形
–
更新不整合を解消する。
91
第3正規形
スキーマRSの属性のうちいずれかの候補キーの構
成要素となる属性を素属性と呼ぶ。
–
–
それ以外を非素属性という。
候補キー：超キーのうち極小なもの(pg.36)。
関数従属性X->A (X⊆RS、 A∈RS, A∉X)が成立す
る場合に、以下のいずれかの条件が常に満たされ
る時、そのスキーマを第三正規形と呼ぶ。
1.
2.
XがRSの超キーである。
Aが素属性である。 －＞ 候補キーの構成要素
92
第3正規形の例（pg.59の図4.1）
営業(商品番号,顧客番号, 社員番号, 販売価格)
–
関数従属性 顧客番号->社員番号が成立
–
候補キーは、唯一｛商品番号,顧客番号｝
–
条件(1)を満たさない。
顧客番号->社員番号 社員番号は候補キーの構成要素で
はない
–
商品番号と顧客番号が決まれば、販売のタプルが決定される。
顧客番号->社員番号 顧客番号は超キーではない。
–
顧客番号が決まれば社員番号が決まる
条件(2)を満たさない。
よって、このリレーションは第３正規形ではない。
したがって、更新不整合を生じる。
93
第3正規形の例
営業を分解して得られるリレーション
販売(商品番号,顧客番号,販売価格)、
営業担当(顧客番号, 社員番号)
関数従属性の最小被覆は、
–
販売
–
商品番号、顧客番号は販売の超キー。 条件(1)を満たす。
営業担当 顧客番号－＞社員番号
商品番号、顧客番号 －＞ 販売価格
営業担当の候補キーは｛顧客番号、社員番号｝．よって、条件(2)を
満たす。
したがって、販売,営業担当は第3正規形である。
–
更新不整合がおきない。
94
第2正規形
第1正規形から第3正規形に至るまでの中間段階。
関数従属性X->A （X⊆RS, A∈RS, A∉X）が成り立つ
場合には、以下の条件いずれかが常に満たされる。
1.
2.
–
XはRSのいかなる候補キーの真部分集合でもない。
Aが素属性である。 －＞ 候補キーの構成要素
(1)は第3正規形の条件(1)を緩めたもの。
第3正規形は、常に第2正規形でもある。
95
更新不整合を起こさないスキーマの設計
すべてのリレーションスキーマを第3正規形とすれば
よい。
–
–
–
第2正規形では不十分。
ただし、第3正規形にすることですべての更新不整合が解
決するわけではない。
さらに高次の正規形が存在する
リレーションスキーマRS、関数従属性集合Fが与えら
れたときに、第3正規形を求めるためのアルゴリズム
が知られている(pg.69)。
96
第3正規形を求めるアルゴリズム (pg.69)
ρ:=φ
M:=Fの最小被覆
if XA=RSなるX->A∈Mが存在 then
ρ:={RS}
else
begin
for each X->A in M do
begin
ρ:= ρ∪{XA}
M:=M-{X->A}
end
if いかなるリレーションスキーマ∈ρもRSの候補キーを含まない then
ρ:= ρ∪{Rの任意の候補キー}
end
97
第3正規形を求めるアルゴリズム
リレーションスキーマRS={I, A, S, P}
–
–
Iは商品番号、Aは販売地域、Sは販売担当者、
Pは商品の製造メーカー
関数従属性集合F={IA->S, I->P, S->A}
商品と販売地域が決まれば、販売担当者が決まる。
商品が決まればメーカーが決まる。
担当者が決まれば販売地域が決まる。
上記アルゴリズムのforループで{{I,A,S}, {I,P},{A,S}}
が得られる。
{A,S}は{I, A, S}の部分集合であるので、実際には、
{{I,A,S}, {I,P}}が解となる。
98
第3正規形を求めるアルゴリズム
本当に{{I,A,S}, {I,P}}が第3正規形であるか?
–
R1(I, A, S)、 R2(I, P)とする。
I->P∈Fであるので、
(RS1∩RS2 → RS2－RS1) ∈ F+となり、定理4.1より、
これは無損失結合分解。
R1,R2の関数従属性集合は{IA->S, I->P, S->A}で、
この分解は従属性保存分解となっている。
{{I,A,S}, {I,P}}は第3正規形の条件を満たしている。
–
確認を各自しておくこと。
99
ボイス･コッド正規形
関数従属性X->A (X⊆RS、 A∈RS, A∉X)が成立する
場合には、以下の条件が満たされる時、そのスキー
マをボイス･コッド正規形と呼ぶ。
1.
XがRSの超キーである。
第3正規形の条件(2)を除外したもの。
–
ボイスコッド正規形のスキーマは、第3正規形でもある。
100
ボイス･コッド正規形
リレーションスキーマRS={I, A, S, P}の分解より得られた
{I,A,S}を考える。
–
Iは商品番号、Aは販売地域、Sは販売担当者、
Pは商品の製造メーカー
その関数従属性集合の最小被覆は、
{IA->S, S->A}であり、候補キーはIA, ISである。
–
{I,A,S}では、IとSの両方が決まらないとタプルが決定されない。
一人の担当者が同じ地区で異なる商品を販売することがある。
関数従属性X->A に対してXがRSの超キーである、という条件
を満たしていないので、ボイス･コッド正規形ではない。
–
担当者ごとに担当地区が決まっているが、このリレーションでは商品ご
とに重複している。 －＞ 更新不整合が生じる(pg.70)
101
ボイス･コッド正規形
二つの属性のみからなるリレーションスキーマは常に
ボイスコッド正規形である。
–
–
定理4.1にしたがってリレーションを分割し続ければ、ボイス
コッド正規形を得ることができる。
pg.71のアルゴリズム
RS={I, A, S, P}の分解
–
–
Iは商品番号、Aは販売地域、Sは販売担当者、
Pは商品の製造メーカー
{{I,A,S}, {I,P}}
{{I,A}, {A,S}, {I,P}}
102
ボイス･コッド正規形
これらの分解は、無損失結合分解である。
–
分解前と同じ情報を表現している。
しかし、従属性保存分解にはなっていない。
–
–
分解前に表現していた従属性のうち表現できないものが存
在する。
IA->S 商品と販売地域が決まれば、担当者が決まる。
これが表現できていない。
ボイス･コッド正規形は第3正規形のもつ更新不整合
を解決できるが、すべての関数従属性を表現できる
とは限らない。
103
多値従属性
{プロジェクト番号、社員番
号、ミーティング日}
–
各プロジェクトに対して、メン
バの社員番号と定例ミーティ
ングの日が決まる。
「プロジェクト」はすべての属
性の組み合わせを唯一の
候補キーとするボイス･コッ
ド正規形である。
しかし、更新不整合が生じる。
プロジェクト
プロジェクト番号 社員番号 ミーティング日
p1
e1
月曜日
p1
e2
月曜日
p1
e1
木曜日
p1
e2
木曜日
p2
e1
月曜日
p2
e3
月曜日
p2
e1
金曜日
p2
e3
金曜日
104
多値従属性
プロジェクト番号がきまれば社員番号が決まる。
プロジェクト番号が決まればミーティング日がきまる。
–
–
–
これらをひとつのリレーションに含んでいるのは冗長である。
ミーティング日に変更があると、多数のタプルを変更する必
要が出てくる。 －＞ 修正不整合
ミーティング日が決まっていないプロジェクトは挿入できな
い。 －＞ 挿入不整合
このような問題は関数従属性の範囲では扱うことが
できない。 ＝＞ 多値従属性の概念
105
多値従属性
リレーションスキーマRSと属性集合X, Y⊆RSが与え
られたとき、RSの任意のインスタンス（タプル）におい
て、
(∀t∈R) (∀u∈R)
(t[X]=u[X] -> (∃v∈R) (∃w∈R)
(t[X]=u[X]=v[X]=w[X] ∧ t[Y]=v[Y]∧t[RS-XY]=w[RS-XY]
∧u[Y]=w[Y]∧u[RS-XY]=v[RS-XY]))
が成立するとき多値従属性X->>Yが成立すると呼ぶ。
106
多値従属性
パターンtおよび、uにマッチ
するタプルが存在するなら
ば、パターンvおよびwにマッ
チするタプルも存在しなけれ wt
ばならない。
v
t[X]=u[X]=v[X]=w[X] ∧
t[Y]=v[Y]∧t[RS-XY]=w[RS-XY]
∧u[Y]=w[Y]∧u[RS-XY]=v[RSXY]))
プロジェクトはこの条件を満たして
いる。
プロジェクト番号->>社員番号
X
Y
RS-XY
プロジェクト
プロジェクト番号 社員番号 ミーティング日
p1
e1
月曜日
p1
e2
月曜日
p1
e1
木曜日
p1
e2
木曜日
u
p2
e1
月曜日
p2
e3
月曜日
p2
e1
金曜日
p2
e3
金曜日
w(X)
t(RS-XY)
107
多値従属性の性質
YとRS-XYを入れ替えてもよい。
X->>YならばX->>RS-XYである。
プロジェクト番号->>社員番号であるので、
プロジェクト番号->>ミーティング日が成立する。
関数従属性は多値従属性の特別な場合
–
X->YであればX->>Yである。
108
定理4.2
ρ={RS1,RS2}とリレーションスキーマRSの分解とす
る。このとき、分解ρが無損失結合分解となる必要十
分条件は、
(RS1∩RS2 ->> RS1－RS2)
または
(RS1∩RS2 ->> RS2－RS1)
がRSで成立することである。
109
第4正規形
多値従属性を用いた正規形
リレーションスキーマRSにおいて、多値従属性
X->>Y (XY⊂RS, Y⊈X)が成立する場合には、つねに、
XがRSの超キーである。
–
ボイス･コッド正規形：関数従属性X->A (X⊆RS、 A∈RS,
A∉X)が成立する場合には、XがRSの超キーである。
X->AであればX->>Yが成立
–
第4正規形はボイス･コッド正規形である。逆は成立しない。
110
第4正規形の例
リレーション プロジェクト
プロジェクト番号->>社員番号
プロジェクト番号->>ミーティング日
は成立するが、プロジェクト番号は超
キーではない。
よって、これは第4正規形ではない。
X->>Y (XY⊂RS, Y⊈X)が成立
する場合には、つねに、XがRS
の超キーである。
プロジェクト
プロジェクト番号 社員番号 ミーティング日
p1
e1
月曜日
p1
e2
月曜日
p1
e1
木曜日
p1
e2
木曜日
p2
e1
月曜日
p2
e3
月曜日
p2
e1
金曜日
p2
e3
金曜日
111
第4正規形の例
「プロジェクト」から得られる無損失結合分解
–
{プロジェクト番号、社員番号}
–
{プロジェクト番号、ミーティング日}
プロジェクト番号->>社員番号
プロジェクト番号->>ミーティング日
これらは、第4正規形の条件を満たす。
–
X->>Y (XY⊂RS, Y⊈X)が成立する場合には、つねに、Xが
RSの超キーである。
112
結合従属性
定理4.2
–
ρ={RS1,RS2}とリレーションスキーマRSの分解とする。こ
のとき、分解ρが無損失結合分解となる必要十分条件は、
(RS1∩RS2 ->> RS1－RS2)
または
(RS1∩RS2 ->> RS2－RS1)
がRSで成立することである。
これは、二つのリレーションへの無損失結合分解を
保障する。 －＞ n個のリレーションへ拡張したものを
結合従属性と呼ぶ。
113
結合従属性
リレーションスキーマRSとその分解
ρ={RS1, ..., RSn}が与えられたとき、RSの任意のイ
ンスタンスRにおいて R RS1 (R) RSm (R) が成立
するとき、結合従属性＊(RS1, ..., RSn)が成立すると
いう。
結合従属性を用いて分解したものが第5正規形
–
結合従属性＊(RS1,...RSn)が成立するときは常に各RSi
がRSの超キーである。
114
第5正規形の例
工場はいくつかの種類の部
第四正規形
品の供給を必要とし､工場と
部品供給R
部品の関係はN対Mである。
工場番号 部品番号 業者番号
f1
p1
s1
工場と業者の間には部品供
f1
p2
s1
f1
p2
s2
給契約があり、向上と業者
f1
p3
s2
f2
p1
s1
の関係はN対Mである。
f2
p3
s3
業者はいくつかの部品を供
給可能であり､業者と部品の π
(R) π
(R) π
関係はN対Mである。
工場番号 部品番号
ｆ１
s1
f1
p1
f1
s2
p2
f2
s1
工場ｆが必要とする部品pはf f1
f1
p3
f2
s3
p1
と契約のある業者のうちでp f2
f2
p3
を供給可能な業者全てから
受ける。
工場番号、部品番号
工場番号、業者番号
部品番号、業者番号(R)
p1
p2
p2
p3
p3
s1
s1
s2
s2
s3
115
正規形のまとめ
様々な正規形を考えるこ
とで更新不整合の問題を
解決できる。
従属性に基づく整合性制
約を保存して分解できる
のは第3正規形まで。
それ以上は､更新不整合
は解決できても､表現でき
ない従属性がでてくる。
第1正規形
第2正規形
第3正規形
ボイス･コッド正規形
第4正規形
第5正規形
116
物理的データ格納方式
データベース中のすべてのデータは物理的にビット
列として表現され、なんらかの記憶媒体上に格納さ
れる。
コンピュータの記憶媒体
–
主記憶
–
半導体メモリ アクセス速度が速いが高い
CPUから直接操作可能
揮発性メモリ 電源OFFで情報が消える
二次記憶
磁気ディスク、磁気テープ、光ディスク アクセス速度は遅いが安い
不揮発性メモリ 電源OFFでも情報は消えない
CPUから直接操作不可能
117
データベースにおける記憶媒体
2次記憶装置、特に磁気ディスク装置（ハードディス
ク）
–
–
–
–
データベースのデータ量が多く、主記憶上に保持するとコ
ストが高くなる。
停電やシステムダウンなどの障害に対しても、安定的に
データを保持する必要がある。
現在は、ハードディスクが一般的であるが、大量のデータを
管理する場合は、磁気テープや光ディスクなども用いられ
る。
すべてを主記憶上に管理するオンメモリデータベースなど
も研究開発されている。
118
ハードディスクの構成
プラッタ：円盤（ディスク）
ヘッド：データを読み取る
装置
アーム：ヘッドを移動させる
腕
トラック：プラッタ上の同心
円状の記憶単位
セクタ：512byte程度にト
ラックを細分化したもの
シリンダ：同一半径上にあ
るトラックの集合
119
120
データの読み込みの手順
1.
2.
3.
アームを移動してヘッドを該当するトラックに位置づ
ける。 －＞ この時間を「シーク時間」と呼ぶ。
先頭セクタがヘッドの下に来るのを待つ。ー＞「回転
待ち時間」
先頭セクタから始まる指定された数のセクタを読み、
その内容を主記憶へ転送する。 －＞ 「転送時間」
121
ページ（ブロック）単位でのアクセス
転送時間はシーク時間、回転待ち時間と比べて非常
に小さい。
–
1セクタごとに1,2を行うよりも、ある程度の量のデータをま
とめて処理したほうが効率がよい。
複数の連続するセクタ（ページ、ブロック）ごとに処理
する
122
バッファリング
ディスクのアクセス速度はメモリ（主記憶）のアクセス
速度と比べて非常に遅い。
–
–
プログラムからの要求に応じて毎回直接アクセスしている
とプログラムの実行が非常に遅くなる。
メモリの上に過去にアクセスされたページをためておいて、
同一のページへのアクセス要求がきた場合は、それを利用
する。
あるページのデータがアクセスされた場合は、同一のページ内の
データがアクセスされる可能性が高い。 ＜－ 意味のあるデータは
まとめて管理されることが多い。
バッファリングと呼ぶ
123
レコードとファイル
リレーショナルデータベース管理システム（リレーショ
ナルDBMS）では、タプル（一行）を一つのレコードと
して管理する。
タプルの属性値に対応して、レコードは複数のフィー
ルドを持つ。
販売
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c1
s1 100
フィールド
1リレーション中のレコードの集まりのような、関連し
たレコードの集まりをファイルと呼ぶ
124
固定長レコードと可変長レコード
レコードのサイズはページサイズよりも小さい
–
ページはディスクにおける入出力の単位
1レコードは、あるページの一部分の連続した領域を
割り当てられて格納される。
ファイル中の1ページ
1レコード
領域の割り当て方で2種類のレコードが存在する。
125
固定長レコードと可変長レコード
固定長レコード
–
フィールドサイズが一定でレコードを更新してもレコードの
サイズは変わらない。
可変長レコード
–
フィールドサイズが固定ではなく、更新によってレコードの
サイズが変わる。
–
例えば、「住所」は場所によって文字の数が大きく異なる。
これを固定長レコードで管理すると効率が悪い。
ただし、可変長レコードは固定長レコードと比べて、その管
理が煩雑になる。
–
126
リレーショナルDBMSにおける代表的なファ
イル編成法
ヒープファイル
ハッシュファイル
B木
B＋木
二次索引
127
ヒープファイル
ページにレコードを順次格納したファイル
レコードの挿入
–
現在あるページに空きがあればそこに追加し、なければ新
しいページを確保する。
128
ヒープファイル
レコードの削除
–
ページ中で該当レコードの削除処理を行う。
性質
–
–
–
格納効率がよい。
キー値を用いたレコード探索ができない。
2次索引と併用されることが多い。
129
ハッシュファイル
ハッシュ関数を用いたハッシング
–
–
何か値を入れると、値を返す関数
例えば、「中田」を入れると「10」、「中谷」を入れると「100」
を返すような、漢字から数字を発生させる関数を作り、「中
田」に対応するレコードはページの先頭から10バイト目、
「中谷」に対応するレコードはページの先頭から100バイト
目に記録しておけば、あとから参照するときに高速に参照
できる。
キー値
関数値
ハッシュ関数
130
ハッシュファイル
バケット：レコードが格納される場所。
バケットディレクトリ：バケットのアドレスを格納したも
の
R1：＜中田, 山口市, 山口大学＞
中田
131
ハッシュファイル
キー値を持つレコードの検索が高速
範囲による検索、キー値の順にすべてのレコードを
読むといった操作には対応できない。
ハッシュ関数の作り方が難しく、効率の悪いハッシュ
関数を作ると、同じバケットに複数のレコードが割り
当てられて、バケットがあふれる。
–
–
バゲットのオーバフロー
これが増えると効率が悪くなる。
132
索引付ファイル
データ部と索引部にファ
イルを分けたもの。
データ部
–
レコードをキー値の順に
格納している。
索引部
–
データページの先頭レ
コードのキー値とその
データページへのポイン
タをペアにした索引レ
コードを順に格納してい
る。
レコードの
キー値のみ
133
索引付ファイル
キー値を持つレコードの検索が高速
範囲による検索、キー値の順にすべてのレコードを
読むといった操作にも対応できる。
134
索引付ファイル
レコードの挿入が難しい
–
あらかじめ、空きレコードを
作っておく
33
–
3４
追加専用のページを用意
する。
33
35
36
38
37
135
索引付ファイル
レコードの更新に伴い、データのアクセス効率が低下
する。
–
レコードの削除
–
一定量のデータ更新があった場合は、ファイルの再構成が
必要となる。
データページから該当ページを削除するだけ
索引付ファイルのデータ部のように、あるフィールドの
値の順にレコードを格納したファイルを順次ファイルと
いう。
–
–
フィールドの値の順にレコードを読み出すのに適する。
レコードの追加に問題が生じる。
136
B木
索引付きファイルは各種データアクセス要求に対応
できる。
但し、レコードの挿入が難しい。－＞ 変更の多い
DBMSには向いていない。 －＞ B木にて解決
B木が利用されることは少ない
ー＞B木を改良したB＋木が一般的。
–
B木はB＋木の基礎となるので重要。
137
木構造（ツリー構造）
いくつかの節（node）とそれらを
結ぶ枝(edge)から構成され、親
子関係を持っている。
一番初めの節を根(root)と呼ぶ。
葉
子を持たない節を葉(leaf node)と呼ぶ。
根
親
子
葉
一つの節から出る枝が2本以下
のものを2分木と呼ぶ。
葉
葉
葉
138
B木の定義
1.
正整数dに対して、d次のB木とはページをノードとし、
以下の条件を満たすルート付き木である。
ルートから各リーフノードまでのパスの長さ（辺の
数）は全て同じである。
2.
3.
この条件を満たす木をバランス木と呼ぶ。
ルートからリーフノードまでのパスの長さを木の高さと呼
ぶ。
ルート以外のノードはキー値の順に並んだi個
(d<=i<=2d)のレコードR1, ... , R2を持つ。
ルートはキー値の順に並んだi個(1<=i<=2d)のレ
コードR1, ... , R2を持つ。
139
B木の定義
4.
i個のレコードを持つ非リーフノードNはi+1個の個
ノードポインタPTR1, ... , PTRi+1を持つ。ポインタ
PTRj(1 <= j <= i+1)の指す部分木に格納された全
てのレコードのキー値Kは次の条件を満たす。
(a)
(b)
(c)
j=1のとき K<Key(R1)
i<j<i+1のとき、 Key(Rj -1) < K Key(Rj)
j=i+1のとき、Key(Ri) < K
但し、Key(Rj)はNのレコードRjのキー値を表す。
140
B木の例（1次のB木）
ルートから各リーフノードまでのパスの長さ（辺の
数）は全て同じである。 ー＞ 2
ルート以外のノードはキー値の順に並んだi個
(d<=i<=2d)のレコードR1, ... , R2を持つ。
18 中田 山口 教育
i=2
R1, R2
141
B木の例（1次のB木）
ルートはキー値の順に並んだi個(1<=i<=2d)のレ
コードR1, ... , R2を持つ。
i=1
R1
142
B木の例（1次のB木）
i個のレコードを持つ非リーフノードNはi+1個の個
ノードポインタPTR1, ... , PTRi+1を持つ。
i=1
PTR1, PTR2
143
B木の例（1次のB木）
ポインタPTRj(1 <= j <= i+1)の指す部分木に格納された全
てのレコードのキー値Kは次の条件を満たす。
(a)
(b)
(c)
j=1のとき K<Key(R1) －＞ 18より小さい
1<j<i+1のとき、 Key(Rj -1) < K < Key(Rj)
j=i+1のとき、Key(Ri) < K
R2：ここに入るレコードは右の部分
木の全てのレコード値よりも大きい
R1
50
PTR2
PTR1
144
B木の例（1次のB木）
13というキー値を持つレコードの検索
28というキー値を持つレコードの検索
145
B木におけるレコードの挿入
(1)挿入レコードはリーフノードに格納する。格納すべき
リーフノードNを検索する。
キー値26のレコードを挿入するとすると、
Ｎ
146
B木におけるレコードの挿入
(2) Nに入っているレコード数が2d未満ならそのまま挿
入。そうでないなら(3)へ。
–
この場合は、2dなので(3)へ。
Ｎ
147
B木におけるレコードの挿入
(3) ノードNの分割を行う。
–
–
–
Ｎ’を確保し、挿入レコードを含めた2d+1個のレコードのうち、キー値
の小さい順にd個をＮへ、大きい順にd個をＮ’へ格納する。
中間値キー値を持つレコードRをＮ’へのポインタとペアにして、Ｎの
親ノードへ格納する。
22, 25, 26とあるので、22がＮへ、26がＮ’へ、２５が親へ行く。
Ｎ
Ｎ’
148
B木におけるレコードの挿入
(4) 親ノードではＲとPTR(N’)のペアを挿入レコードとし
て、上記の2,3の手順を行う。ただし、分割がルートま
で波及する場合は、新たなノードをルーとして確保す
る。 －＞ 高さが1増える。
149
B木におけるレコードの削除
(1) 検索対象のレコードを格納したノードNを特定する。
キー値が22と33のレコードを削除する。－＞まず、ノード
を特定。
ノードNがリーフノードか非リーフノードかで処理が異なる。
N
150
B木におけるレコードの削除
Nがリーフノードの時
（２）Nのレコード数がd+1以上なら、Nから対象レコード
を削除して終了。
–
ルート以外のノードはキー値の順に並んだi個(d<=i<=2d)
のレコードR1, ... , R2を持つ。 ＜－ B木の定義
N
25
151
B木におけるレコードの削除
（３）Nのレコード数がd個のときはNと親ノードを共有す
るNの右、左のノードN’を調べる。
–
–
アンダーフローが生じる。 キー値33のレコードを削除する場合
いずれかのノードN’のレコード数(i個)がd+1個以上なら、N
の削除対象レコード以外のd-1個のレコード、N’のi個のレ
コード、親ノード中のその中間値のキー値を持つレコードの
合計d+i個のレコードを再配分する。
25
N’
N
22
28
152
B木におけるレコードの削除
d+i個のレコードの再配置のルール
–
–
–
–
N’をNの左のノードとすると
キー値の小さい順に d 2i 1 個をNに。
d i 1
大きい順に 2 個をNに。
d i 1
2
d i 1
2
は
は
d i 1
2
d i 1
2
以上の最小の整数を表す。（シーリング）
以下の最大の整数を表す。（フロア－）
その中間のキー値を持つレコードは親ノードに。
この例では、d=1, i=2なので両方とも1。
153
B木におけるレコードの削除
（４）Nのレコード数がd個のときはNと親ノードを共有す
るNの右、左のノードN’を調べ、そのいずれのノードも
d個のレコードしか持たない場合。
–
NとN’を融合する。N’をNの左のノードすると、Nの削除対象レコード以
外のd－1個のレコード、N’のd個のレコード、親ノード中のその中間の
キー値を持つレコードRの合計2d個のレコードをまとめてNに格納し、
N’を削除。
後はこのレコードと
ポインタを親から
削除する。
この状態でさらに33を消そうとすると...
28
28
N’
25
N
33
N
25
28
154
B木におけるレコードの削除
親ノードでは、Rを削除対象レコードとして、(2)~(4)の
手続きを行う。
–
但し、ノードの融合が波及し、Nがルートとなった場合は、手続き(2)はルートの
レコード数が2以上の場合のみ行い、それ以外はルートを削除する。
－＞ 木の高さが一つ減る。
R
18
N’
10 18
N
10
28
5
5
7
25 28
13 16
7
13 16
25 28
155
B木におけるレコードの削除
Nが非リーフノードの時
–
–
–
キー値が10のレコード削除
削除対象がN中のｊ番目のレコードRjである時、ポインタ
PTRj+1が指す部分木の最も左のリーフノードN’の先頭レ
コードR’をRjの位置に格納する。
N’はリーフノードであるので、R’を先ほどの手順で削除。
18
N’
N
13
5
7
13 16
レコードを削除
156
B木の特徴
木の高さはレコードの数をnとして、O(log(n))
–
–
オーダーlog(n)と読む。レコードの数をnとしたとき、log(n)
で増えていく。 －＞ レコードの検索時に読み出す必要が
あるページ数もlog(n)のオーダーとなる。
検索が速い。
ルートを除いて、各ページの使用効率は最低でも
50% －＞ 無駄な領域が少ない。
キー値の順にデータを読み出すことが得意ではない。
－＞ B＋木
157
B＋木の定義
DBMS（データベース管理システム）において最もよく
利用されるデータ格納方式の一つ。
–
–
データはすべてリーフノードへ格納。
非リーフノードはデータを検索する時に用いる索引。
キー値のみが入る。 －＞ B木と全く同じ。
158
B＋木の定義
eを2以上の整数として、データ部のリーフノードは
キー値の順に並んだi個のレコードR1, ..., Riを持つ。
e
– i e
2
–
–
リーフノード同士はポインタで結ばれる。
下の図ではe=3である。
159
B＋木におけるデータの検索
ルートを最初のノードとしてキー値に応じて子ノードポ
インタを順次リーフノードまでたどる。
–
–
–
必ずリーフノードまでたどる。
28のキー値を持つレコード
順にデータを参照 －＞ 左から順にたどる。
160
B＋木におけるデータの挿入
（１） 挿入レコードのキー値を用いてレコードを格納すべ
きリーフノードNを特定する。
（２）Nのレコード数がe未満であれば、Nの適当な位置
に挿入レコードを格納。
–
キー値30のレコードを挿入。
25 28 30
161
B＋木におけるデータの挿入
（３）Nのレコード数がe個の時は、ノードの分割。
–
–
–
B+木の定義より、リーフノードにはe個までのデータしか入らない。
新たなノードN’を確保し、挿入レコードも含めたe+1個のレコードのうち、
1
キー値の小さい順に e 2
個をNに残りをN’に格納する。
N’の先頭レコードのキー値KとN’へのポインタPTR(N’)を、Nをさす索引
部の親ノードへ挿入。
この処理は、B木への挿入と同じ操作。
30
162
B＋木の特徴
キー値の順での全レコードの読み出しが簡単
指定された範囲のキー値を持つレコードの検索も容
易。
索引部にはキー値しか格納されないので、レコードそ
のものを格納するよりも多くのポインタを格納できる。
–
–
B木、B＋木では、一つのノードは1ページ。ページのサイズ
は決まっている。
よって、B木よりも低い木を構成でき、アクセス数を軽減で
きる。
必ず、リーフノードまでアクセスする必要がある。
163
2次索引
ハッシュファイル、索引付きファイル、B木、B+木
–
–
キー値とレコードの格納位置を直接結びつける索引構造を
提供 ＝＞ 索引を用いて高速にレコードにアクセス可能。
但し、レコードに対するキー値は一つとは限らない。
–
–
学生（学籍番号、氏名、住所） －＞ 学籍番号だけではなく、氏名も
超キーにはなる。
上記のファイル編成法は主に主キー用のもの。
－＞ 主索引と呼ぶ。
－＞ 主キー以外のキーにも索引をつけて高速にアクセス
したい。
2次索引。
164
2次索引と主索引の違い
データレコード自体はこれまでのファイル編成を持つ
データファイルにあるので、二次索引はデータレコー
ドへのポインタである。
指定した索引フィールド値を持つデータレコードは、
ファイル中に複数存在し得る。
165
２次索引の使用例
よ学
る籍
主番
索号
引に
レデ
コー
ー
ドタ
aa bb
c dd ee
o q
s uu
v x
s
c
o
v
よ
る住
２所
次
索に
引
166
同時実行制御
トランザクション
–
–
アプリケーションにおけるひとまとまりの処理を構成する
データベース操作。
例：「預金口座Aから別の講座Bに1万円を送金する」処理
read(A,x)
read(B,y)
x=x-10000
y=y-10000
write(A,x)
write(B,y)
<-- Aの残高を変数ｘへ代入
<-- Bの残高を変数yへ代入
<-- 変数ｘの内容をAの残高として記入
<-- 変数ｙの内容をBの残高として記入
一
つ
の
ト
ラ
ン
ザ
ク
シ
ョ
ン
167
データベースの実行単位
それぞれの書き込み、読み込みではなく、トランザク
ションを実行の単位としなければならない。
–
–
「送金」の手続きは、前ページのように複数の操作から構
成される。
一部だけ実行されるということは許されない。
トランザクション管理
–
–
複数のトランザクションが同時に実行されることもありえる。
障害発生時にもトランザクション単位でデータの整合性を
考える必要がある。
168
トランザクションのACID特性
原子性(atomicity)
–
トランザクション中のデータ操作は、全てが実行されるか、
全てが取り消されるかのどちらかでなければならない。
–
–
一部だけ実行することは許されない。
全てのデータ操作が実行されて、データベースに反映され
ることを、トランザクションの「コミット」と呼ぶ。
全てのデータ操作がキャンセルされて、データ操作がデー
タベースに全く反映されないことを、トランザクションの「ア
ボート」と呼ぶ。
169
トランザクションのACID特性
整合性(consistency)
–
整合が取れたデータベースに対して実行されたトランザク
ションの実行後のデータベースの状態は、再び整合性の取
れたものでなければならない。
正しいデータベースに対してデータ操作した結果は正しくなければ
ならない。
隔離性(isolation)
–
複数のトランザクションを並行処理した場合でも、トランザク
ションは同時に処理されているほかのトランザクションの影
響を受けず、その結果はトランザクションを何らかの順序で
逐次処理した場合と一致しなければならない。
単独で実行しても、同時に複数実行しても結果が同じ。
170
トランザクションのACID特性
耐久性(durability)
–
一旦、コミットしたトランザクション中のデータ操作は、その
後の障害などで消滅してはならない。
171
トランザクションに関する命令
アプリケーションプログラムはDBMSに対してトランザ
クションの開始、コミット、アボートを通知する必要が
ある。
アプリケーション
(成績処理)
(切符予約)
(座席販売)
DBMS
データベース
begin
トランザクションの開始を宣言
commit トランザクションのコミットを要求
abort
トランザクションのアボートを要求
172
トランザクションの状態
アクティブ
–
コミット処理中
–
コミットの処理が終了した状態。
アボート処理中
–
commit命令が呼び出され、その処理を行っている。
コミット済み
–
トランザクションの実行中
abort命令が呼び出され、その処理を行っている。
アボート済み
–
アボートの処理が終了した状態
173
トランザクションの状態
begin
アクティブ
commit
コミット
処理中
コミット
処理済
アボート
処理中
アボート
処理済
abort
トランザクションは、必ずコミット済みかアボート済み
に移行する必要がある。
174
補償トランザクション
一旦コミットしたトランザクションは、取り消すことが出
来ない。
間違った値でデータを変更した場合などは、もとに戻
すための一連の操作を行う必要がある。
–
補償トランザクション。
175
トランザクションの並行処理
DBMSは複数の応用目的で共有されるデータを管理
する。
–
–
–
多くのトランザクションを処理する必要がある。
トランザクションの処理には入力待ちなどの「待ち時間」が
発生する。 ＝＞ 待ち時間はCPUは遊んでいる。
複数のトランザクションを部分的に分割して、待ち時間がな
いように実行。
トランザクションの並行処理
176
トランザクション処理がない場合の不整合
トランザクションT1
read(A,x)
x=x+10000
トランザクションT2
read(A,y)
y=y-10000
write(A,y)
write(A,x)
トランザクションT2の更新が反映されない。
177
トランザクション処理がない場合の不整合
トランザクションT1
トランザクションT2
read(A,z)
z=z-10000
write(A,z)
s=0
read(A,x)
s=s+x
read(B,y)
s=s+y
read(B,w)
w=w+10000
write(B,w)
トランザクションT1は
誤った合計値を算出す
る。
トランザクションT2がす
べて終了してから合計
を行う必要がある。
178
トランザクションの管理
トランザクションを並行処理する場合に、不整合が生
じないように制御することを同時実行制御という。
179
直列可能性
不整合が生じないための基準
–
–
–
トランザクションT1、T2、…、Tnを並行処理したときの結果
と、それらを何らかの順序で逐次処理したときの結果が一
致すること。
直列可能性と呼ぶ。
ただし、T1,T2,...Tnの処理内容には制限を設けない。
どのような処理でもよい。
並行処理においては、直列可能性を保証する必要が
ある。
180
スケジュール
データベース処理の基本操作
–
–
–
–
Ri(A):トランザクションTiにおける項目Aのread
Wi(A):トランザクションTiにおける項目Aのwrite
Ci:トランザクションTiのcommit
Ai: トランザクションTiのabort
同じ項目に対する複数回のreadやwriteはしない。
スケジュール
–
T1,...Tnの基本操作を同じトランザクションTiに属する基本
操作の前後関係は保持するという条件の下で、インター
リーブして（それぞれを挟み込んで）一列に並べたもの。
181
スケジュールの例
トランザクションT1とT2
–
–
T1 : R1(A)R1(B)
T2 : R2(A)W2(A)R2(B)W2(B)
スケジュールの例
–
R2(A) W2(A) R1(A) R1(B) C1 R2(B) W2(b) C2
182
直列スケジュールと非直列スケジュール
直列スケジュール
–
非直列スケジュール
–
対象のトランザクション群を何らかの順序で逐次処理する
場合のスケジュール
直列スケジュール以外のスケジュール
直列可能スケジュール
–
直列スケジュールと等価なスケジュール。
183
同時実行制御の方針
並列処理において直列可能性を保証する必要があ
る。
並列処理における直列可能性を保証するには、トラ
ンザクション処理のスケジュールが直列可能スケ
ジュール（直列スケジュールと等価）であることが必要。
等価とは?
–
–
競合等価
ビュー等価
184
競合等価
同じトランザクション集合に対する二つのスケジュー
ルS1、S2は以下の条件を満たす場合、競合等価。
–
–
S1においてRi(A)（あるいは、Wi(A)）がWj(A)（あるいは、
Rj(A)）に先行するならば、S2においても同様の関係が成り
立つ。
S1においてWi(A)がWj(A)に先行するならば、S2において
も同様の関係が成り立つ。
185
競合等価
異なるトランザクションに属する二つのread, wirteは、
それらが同じ項目を対象とし、そのいずれかがwrite
のとき競合するという。
–
–
T1: R1(A) R1(B)
T2: R2(A)W2(A)R2(B)W2(B)
競合する基本操作の実行順序が同じである場合
ー＞ 競合等価
186
ビュー等価
同じトランザクション集合に対する二つのスケジュー
ルS1、S2は以下の条件を満たす場合、ビュー等価。
–
–
–
S1においてRi(A)により読まれるA値が、Wj(A)によって書
かれた値またはAの初期値ならば、S2においても同様の関
係が成立する。
各項目Aに関して、S1において最後にA値を書くのがWi(A)
ならば、S2においても同様のことが成立する。
各readが同じ値を読み、かつ最後のデータベースの状態
が同じである場合 －＞ ビュー等価である。
187
例
S1:R1(A) W2(A) C2 W1(A) C1 W3(A) C3
S2:R1(A) W1(A) C1 W2(A) C2 W3(A) C3
これらは、ビュー等価ではあるが競合等価ではない。
–
競合等価の条件➁が成立しない。
一般に、競合等価なスケジュールはビュー等価なス
ケジュール。逆は成立しない。
188
競合直列可能とビュー直列可能
あるスケジュールが、別のある直列スケジュールと競
合等価なとき、そのスケジュールは競合直列可能で
あるという。
あるスケジュールが、別のある直列スケジュールと
ビュー等価なとき、そのスケジュールはビュー直列可
能であるという。
競合直列可能スケジュールはビュー直列可能である
が、その逆は成立しない。
189
先行グラフ
あるスケジュールSが競合直列可能であるかを判定
するためのグラフ。
1.
2.
3.
Sに参加する各トランザクションTiに対してノードN(Ti)を作
成する。
Ri(A)がWj(A)に先行する場合（あるいは、Wi(A)がRj(A)
に先行する場合）有向エッジN(Ti)→N(Tj)を引く。
Wi(A)がWj(A)に先行するとき、有向エッジN(Ti)→N(Tj)を
引く。
先行グラフにサイクルがなければ、そのスケジュー
ルは競合直列可能である。
190
先行グラフの例
R1(A) R1(B) R2(A) R2(C) W1(B) C1 R3(B) R3(C)
W3(B) C3 W2(A) W2(C) C2
この先行グラフは
T1
T2
T3
であり、直列スケジュール：
R1(A) R1(B) W1(B) C1 R3(B) R3(C) W3(B) C3
R2(A) R2(C) W2(A) W2(C) C2と競合等価
191
ここから
192
スケジュールの諸性質
スケジュール中にはアボート（トランザクションの中
止）が含まれることがある。これが発生したときの性
質も考える必要がある。
回復可能性
–
–
スケジュールSにおいて「Ri(A)で読まれるA値がWj(A)に
よって書かれた値であり、Tiがコミットするときには、CjがCi
に先行する」という条件が常に満たされるとき、Sは回復可
能であるという。
W1(A) R2(A) C2 A1
A1（トランザクション１がアボートしたとすると、R2(A)で読んだ値も
変ってしまう） －＞ 回復不可能
193
スケジュールの諸性質
連鎖的アボートの回避
–
W1(A) R2(A) A1 C2のばあいは、Tiをアボートすることに
より、T2もアボートしてしまえば問題ない。ただし、アボート
が連鎖的に発生することになる。
–
–
連鎖的アボート
DBMSの処理能力に大きな影響を与えるので避ける必要
がある。
「Ri(A)で読まれるA値がWj(A)によって書かれた値であると
きには、CjがRi(A)に先行する」という条件が常に成立して
いれば連鎖的アボートを回避する。
確定した値のみを読み込む。W1(A) C1 R2(A)
194
厳格性
スケジュールSにおいて、「Ri(A)またはWi(A)よりも
Wj(A)が先行するときには、CjまたはAjがそのRi(A)
またはWi(A)に先行する」という条件が常に満たされ
るとき、そのスケジュールは厳格であるという。
–
–
決定した値しか読み書きしない。
厳格なスケジュールは連鎖的アボートを回避する。
W1(A) W2(A) C2 A1は厳格でない。
–
W1(A)がW2(A)よりも先行するのに、C1またはA1が
W2(A)の後ろにある。
195
回復可能性、連鎖的アボート回避、厳格性、
直列可能性の関係
R1(A) W2(A) W2(B) C2 R1(B) C1
–
–
–
–
厳格ではあるが直列可能ではない。
直列スケジュールは以下の二つが考えられる。
R1(A) R1(B) C1 W2(A) W2(B) C2
W2(A) W2(B) C2 R1(A) R1(B) C1
上記のスケジュールはこのいずれにも、競合等価でもなく、
ビュー等価でもない。
よって、ビュー直列、競合直列ともに不可能
－＞ 直列可能ではない。
196
回復可能性、連鎖的アボート回避、厳格性、
直列可能性の関係
ビュー直列可能
競合直列可能
回復可能
連鎖的アボート回避
直列
厳格
197
ロックを用いた同時実行制御
ロック
–
–
並行処理のおける直列可能性の保証
アボートにかかわる問題の解決
を行う一般的な方法
排他的ロック
–
–
–
–
–
–
もっとも単純なロック。
データベース中の項目Aに対する排他的ロック。
Aにロックをかけれるのは1トランザクションのみ。
それ以外のトランザクションの項目Aに対する要求は待ち状態となる。
各トランザクションはAにアクセスする場合は必ずAをロックする。
競合を回避できる。
198
共有ロックと専有ロック
排他的ロックはAにアクセスするときは必ずAをロック。
–
–
読み取るときは共有ロック
–
ほかの共有ロックと項目Aを共有する。
両立性行列
書き込むときは専有ロック
–
アクセスにはreadとwriteがある。
readに関しては競合は発生しないので、readのときにも排
他的ロックをかけるのは必要以上の制約。
両立性行列
–
共有
専有
共有
Y
N
専有
N
N
項目Aを専有する。
共有ロックと専有ロックの両立性
を表すもの
199
ロックの変換
トランザクションの中では、データの値を読み出して
確認してから、データを変更することが多い。
–
–
このときに、はじめから専有ロックをかけるとほかのトラン
ザクションが走れない。
はじめは共有ロックをかけておき、必要になってからその
ロックを専有ロックへと変換する。
–
ロックのアップグレード
専有ロックをかけていたものを共有ロックにする。
ロックのダウングレード
200
ロッキングプロトコル
ロックのかける操作と解く操作の規約
–
–
これをきちんと考えないと、整合性を保つことができない。
記法
SLi(A)
XLi(A)
ULi(A)
Aに対して共有ロックをかける。
Aに対して専有ロックをかける。
Aのロックをはずす。
図8.2(b)の順番で、共有ロック、専有ロックをもちいたもの
–
–
XL2(A) R2(A) W2(A) UL2(A) SL1(A) SL1(B) R1(A) R1(B) UL1(A)
UL1(B) C1 XL2(B) R2(B) W2(B) UL2(B) C2
これは、ロックの両立性行列を満たすが、整合性を保つスケジュールで
はない。
201
ロッキングプロトコル
整合性を保証するには、ロックをかける操作と解く操
作に何らかの規約（プロトコル）が必要。
－＞ ロッキングプロトコル
あるロッキングプロトコルに従ったロック操作を行う場
合のスケジュールを、そのロッキングプロトコルにお
いて合法なスケジュールと呼ぶ。
合法なスケジュールが常に直列可能となるロッキン
グプロトコルを、直列可能性を保証するロッキングプ
ロトコルと呼ぶ。
202
デッドロック
ロックをもちいる場合に必ず考える必要がある現象。
T1:XL1(A) XL1(B) W1(A) W1(B) UL1(A) UL1(B)
T2:XL2(B) XL2(A) W2(B) W2(A) UL2(B) UL2(A)
–
これらのスケジュールでXL1(A)のあとにXL2(B)を実行して
しまうと、この二つのトランザクションは永久に待ち状態に
なる。 －＞ デッドロック。
203
直列可能性を保証するロッキングプロトコル(1)
2相ロッキングプロトコル
各トランザクション中のロック操作が以下の部分に分
けられる。
–
–
–
–
ロックをかける操作だけからなる成長相
ロックを解く操作だけからなる縮退相
２相
一度何らかのロックを解くと、そのトランザクションではいか
なるロックも再びかけることはできない。
2相ロッキングプロトコルは競合直列可能性を保証する。
204
直列可能性を保証するロッキングプロトコル(1)
2相ロッキングプロトコル
pg.159の例
XL2(A) R2(A) W2(A) UL2(A) SL1(A) SL1(B) R1(A)
R1(B) UL1(A) UL1(B) C1 XL2(B) R2(B) W2(B) UL2(B) C2
T1に関しては、2相ロッキングプロトコルにしたがっているが、
T2に関しては従っていない。
すべてのトランザクションが2相ロッキングプロトコルに従って
いる場合、それらのトランザクションは競合直列可能性を持つ。
205
直列可能性を保証するロッキングプロトコル(1)
2相ロッキングプロトコル
成長相ではロックをかける以外にロックのアップグレードも可
能。
縮退相ではロックをはずす以外にロックのダウングレードも可
能。
2相ロッキングプロトコルではデッドロックが発生する可能性が
ある。
– T1:XL1(A) XL1(B) W1(A) W1(B) UL1(A) UL1(B)
– T2:XL2(B) XL2(A) W2(B) W2(A) UL2(B) UL2(A)
206
厳格な2相ロッキングプロトコル
トランザクションがアボートする時には、アボート操作
前に専有ロックを解くと問題が生じる。
–
–
–
–
XL1(A) R1(A) W1(A) UL1(A) SL2(A) R2(A) UL2(A) C2
SL3(A) R3(A) A1
この中には、T1,T2,T3があるがいずれも2相ロッキングプ
ロトコルには従っている －＞ 競合直列可能である。
A1によりT3の連鎖的アボートが発生する。
T2はすでにコミット済みなので回復不可能である。
207
厳格な2相ロッキングプロトコル
このような問題が起こらないように、「縮退相における
最初のロックを解く操作はトランザクションのコミットま
たはアボートの操作の後である」という条件を付け足
す。
－＞ 厳格な2相ロッキングプロトコル。
XL1(A) R1(A) W1(A) A1 UL1(A) SL2(A) R2(A)
UL2(A) C2 SL3(A) R2(A)
厳格な2相ロッキングプロトコルのもとで、合法なスケ
ジュールは、競合直列可能であり、上記のような問題
を生じない。
208
直列可能性を保証するロッキングプロトコル(2)
木ロッキングプロトコル
データベース中の項目が木構造に構成され、複数の
項目がアクセスするトランザクションは必ず木のルー
トからリーフ方向にデータをアクセスする場合にもち
いることが可能なロッキングプロトコル。
–
–
競合直列可能性を保証可能。
以降では、簡単化のために専有ロックのみを考える。
209
直列可能性を保証するロッキングプロトコル(2)
木ロッキングプロトコル
(1)
(2)
(3)
(4)
ロック操作が満たすべき条件
Tiにおいて最初にかけるロックは、いずれの項目A
に対して行っても良い。
(1)の場合以外は、項目Aにロックをかける操作は、
Aの親の項目Pにロックをかけているときのみに行う
ことが出来る。
ロックを解く操作はいつ行っても良い。
一度ロックを掛けた後、そのロックを解いた項目を
再びロックすることは出来ない。
210
直列可能性を保証するロッキングプロトコル(2)
木ロッキングプロトコル
以下のような木構造をなす項目をアクセスするT1,T2
は木ロッキングプロトコルに従う。
T1: XL1(A) R1(A) XL1(B) UL1(A) R1(B)
W1(B) XL1(E) UL1(B) R1(E) UL1(E)
T2: XL2(B) R2(B) XL2(D) R2(D) UL2(D)
XL2(E) UL2(B) R2(E) W2(E) UL2(E)
両方のトランザクションが共通にアクセス
する部分木のルートはB。
並行処理において、T1が先にBをロック
したとすると、T2はT1を決して追い抜く
ことはできない。
したがって、T1T2の順で逐次処理した場合と
結果が同じになる。 －＞ 競合直列可能
211
直列可能性を保証するロッキングプロトコル(2)
木ロッキングプロトコル
木ロッキングプロトコルのもとではデッドロックが発生
しない。
但し、writeを行った項目のロックをコミットまたはア
ボート操作より前に解いた場合は、連鎖的アボートが
発生する。
–
厳格でない2相ロッキングプロトコルと同様。
212
ロックの粒度
これまでロックの対象として議論してきた項目とは？
–
–
実際には、様々なデータ単位が考えられる。
データベース全体、 ファイル、 レコード、 フィールド（属性）
粗い
細かい
ロックの対象となる項目の大きさ －＞ロックの粒度
–
ロックの粒度は処理効率の点から重要
細かいと並行処理されるトランザクション同士の不必要な競合を減
らすことが出来るが、細かすぎるとロックの操作が多くなり処理速
度が遅くなる。
大きいとこの逆の状況になる。
213
ロックの粒度
これらの問題を解決するには、トランザクションの処
理に応じて、ロックの粒度を動的に変更できれば良い。
しかし、種々のロックの粒度を許した場合は別の問題
が発生する。
214
種々のロックの粒度を許した場合の問題
T1がファイル1のレコード1を専有ロックしている時に、
T2がファイル1全体に専有ロックを要求したとする。
ファイル1そのものにロックがかかっていなくても、そ
の一部にかかっているので、ロックを許可してはいけ
ない。
215
種々のロックの粒度を許した場合の問題の解決
下位の項目A’をロックする時には、Aに対してインテ
ンションロックをかける
–
Aの下位項目A’にロック（共有、専有）をかける場合に、Aに
対して、「下位項目A’を共有（あるいは専有）目的でロックし
ている」ことを知らせるためのロック。
A
A’を共有ロック
しますよ。
A’
216
インテンションロックの種類
共有インテンションロック
–
専有インテンションロック
–
下位の項目を共有ロックする可能性を表すロック
下位の項目を専有ロックする可能性を表すロック
共有・専有インテンションロック
–
–
部分構造を共有ロックすると同時に、下位の項目を専有
ロックする可能性を表すロック
読み出し用のロック＋下位の項目を専有ロックするかもし
れないことを知らせる。
217
インテンションロックを含めた両立性行列
218
インテンションロックを用いる際に、ロック操
作が満たすべき条件
(1) 項目Aに共有ロックまたは共有インテンションロック
をかける操作は、Aの親の項目を共有インテンショ
ンロックまたは専有インテンションロックしている時
のみ。
(2) 項目Aに専有ロック、専有インテンションロック、また
は共有・専有インテンションロックをかける操作は、
Aの親の項目を専有インテンションロックまたは共
有・専有インテンションロックしている時のみ。
219
インテンションロックを用いる際に、ロック操
作が満たすべき条件
(3) 項目Aのreadを行うことが出来るのは、Aまたはそ
の祖先の項目を共有ロック、専有ロック、または共
有･専有インテンションロックしている時のみである。
(4) 項目Aのwriteができるのは、Aまたはその祖先の項
目を専有ロックしている時のみ。
(5) 項目Aのロックを解く操作は、Aのいずれのこの項目
に対するロックもかけていないときのみ。
–
–
これらに2相ロッキングプロトコルを組み合わせたロッキン
グプロトコルは競合直列可能性を保証する。
ただし、デッドロックの可能性はある。
220
デッドロック
デッドロックの問題を解決する方法
–
–
デッドロックが発生した時に、デッドロックを検出して対処す
る方法。
そもそもデッドロックが発生しないようにする方法。
221
デッドロックの検出
(A) 待ちグラフ
–
(1)
(2)
–
–
デッドロックの発生を検出するグラフ
各トランザクションTiに対応するノードN(Ti)を作成
Tiが他のトランザクションTjがかけているlockが解かれる
のを待っている場合に、有効エッジN(Ti) -> N(Tj)をひく。
待ちグラフがサイクルを持つ場合にデッドロックが起きて
いる。
XL1(A) XL2(B) XL2(A) XL1(B) W1(A) W1(B) ...
T1
T2
デッドロックが発生
222
デッドロックの検出
(B) タイムアウトによる方法
–
–
一定時間以上待ち状態が続いているトランザクションは、
デッドロックに陥っているとしてアボートする。
タイムアウトの時間の設定が重要。
223
デッドロックの回避
デッドロックはトランザクション同士の待ち関係にサイ
クルがあるときに発生
－＞ サイクルが起こらないようにする
(A) 一括ロックする方法
–
–
–
ロックする必要がある項目をトランザクションの開始時に一
括してロックする。
一つでもロックできなければ、全てのロックを止めて、しば
らく後でもう一度ロックを試みる。
2相ロッキングプロトコルとの組合せ
－＞ 保守的2相ロッキングプロトコル
224
デッドロックの回避
(B) データを順序付ける方法
–
–
–
項目間に順序をつける。
ロックをかける順番をこの順番どおりにする。
木ロッキングプロトコルで利用している。
225
デッドロックの回避
(C) トランザクションを順序付ける方法
–
–
–
時刻印(time stamp) TS(Ti)を用いて、トランザクション間に
優先順位をつける。
Tiが項目Aをロックしようとした場合に、Tjがこれと両立しな
いロックをAに対してかけていると以下の方式で処理する。
ウェイト・ダイ方式（ロックをかけようとした方をアボート）
–
TS(Ti)<TS(Tj) ー＞ TiはTjがAのロックを解くのを待つ
TS(Ti)>TS(Tj) ー＞ Tiはアボート
ワウンド・ウェイト方式（ロックをかけていた方をアボート）
TS(Ti)<TS(Tj) ー＞ Tｊはアボート
TS(Ti)>TS(Tj) ー＞ TiはTjがAのロックを解くのを待つ
226
時刻印を用いた同実行制御
ロックを用いない同時実行制御
各トランザクションに発生順に一意な時刻印を与える。
–
時刻印の順にトランザクションを逐次実行する場合と等価なスケジュー
ルが生じるように制御する。
項目に対する時刻印とトランザクションに対する時刻印
–
–
–
RTS(A)：これまでにAのreadを行ったトランザクションの時刻印の最大
値
WTS(A)：これまでにAのwriteを行ったトランザクションの時刻印の最大
値
TS(Ti)：トランザクションTiに対する時刻印
227
時刻印を用いた同実行制御
トランザクションのread、write操作が満たすべき規約
read操作
(1) TS(Ti)<WTS(A)のとき：Tiはアボート
自分より時刻印が大きい（後から始まった）トランザクションによって
値が書き換えられているので。
(2) それ以外のとき：TiはAのreadを行い、
RTS(A)=max(RTS(A), TS(Ti))とする
228
時刻印を用いた同実行制御
トランザクションのread、write操作が満たすべき規約
write操作
(1) TS(Ti)<RTS(A)のとき：Tiはアボート
Tiがwriteを行った後でAを読むべきトランザクションが先にAを読み
込んでいるので。
(2) TS(Ti)>=RTS（A）かつTS(Ti)<WTS(A)のとき：Tiはアボート
他のトランザクションが書き込みを行ってしまっているので。
(3) それ以外：TiはAのwriteを行い、
WTS(A) = max(WTS(A),TS(Ti))とする。
基本時刻印順方式
229
楽観的同時実行制御
トランザクションの競合の可能性が低い場合
–
–
ほとんどのトランザクションがreadだけを行う
複数トランザクションが同時に発生することがあまり無い
とりあえず、競合を無いものとしてトランザクションの
実行を行い、トランザクションの終了の際に本当に競
合が無かったかをチェックする。
ロック、時刻印の操作がいらない分、処理が早い。
230
楽観的同時実行制御
各トランザクションは3つのフェーズからなる
(A) 読み出しフェーズ
–
トランザクション中の処理を実行。readではデータベース中
の項目の値をトランザクション固有の領域へ読み出す。
writeではその作業領域に書き込むだけ。
(B) 確認フェーズ
–
Cの書き込みフェーズでデータベースへの書き込みをした
場合に、競合が起こらないかをチェック。
(C) 書き込みフェーズ
–
確認フェーズをパスした作業領域中のデータをデータベー
スに実際に書き込む。
231
楽観的同時実行制御
確認フェーズと書き込みフェーズは一連の不可分の
基本操作として実行される。
–
確認フェーズの次にすぐ書き込みフェーズ
確認フェーズでのチェック方法
–
–
–
–
–
読み出しフェーズの開始時点の時刻印start(Ti)
確認フェーズの開始時点の時刻印validate(Ti)
読み出しフェーズにおいてreadを行った項目rset(Ti)
読み出しフェーズにおいてwriteを行った項目wset(Ti)
start(Ti)<validate(Tj)<validate(Ti)であるトランザクションTj
について、rset(Ti)∩wset(Tj)=Φが成立していればOK.
232
多段同時実行制御
データベース中の項目Aを変更した場合
–
–
–
通常は、A自身が上書きされ、元の値は消える。
最新の値だけではなく、writeによる過去の値も保存してお
く。 －＞ 複数のバージョン（版）を保持
多段同時実行制御
どのように、複数のバージョンを管理し、整合性を保
つか？
–
–
時刻印を用いて、版を管理する方法
その他にも幾つかある。
233
時刻印を用いた多段同時実行制御
トランザクションTiに発生順に時刻印TS(Ti)を与える。
項目Aを更新すると、新しい版Ajが生成されて、以前
のバージョンと共に管理される。
版Ajがデータの値以外に持つ時刻印
–
–
RTS(Aj): これまでに版Ajの値を読んだトランザクションの
時刻印の最大値
－＞ どのトランザクションが最後にその項目を読んだか？
WTS(Aj): 版Ajを生成したトランザクションの時刻印
234
時刻印を用いた多段同時実行制御
read操作の規約
–
–
–
AjをWTS(Aj)≦TS(Ti)を満たす最大のWTS(Aj)をもつAの
版とする。
TiはAの値としてAjを読む。
RTS(Aj)＝max(RTS(Aj), TS(Ti))
Aj-1
Aj
Aj+1
Aj+2
t
TS(Tj-1)
TS(Tj)
TS(Ti)
TS(Tj+1)
TS(Tj+2)
235
時刻印を用いた多段同時実行制御
write操作の規約
AjをWTS(Aj)≦TS(Ti)を満たす最大のWTS(Aj)をもつAの
版とする。
（１） RTS(Aj)≦TS(Ti)のとき
Tiはwriteで与える値を持つ新しい版Akを生成し、
RTS(Ak)=WTS(Ak)=TS(Ti)とする。
（２） RTS(Aj)＞TS(Ti)のとき
AjはTiより後で始まったトランザクションから読まれている
ので、TiはAjを更新することは出来ない。
ー＞ アボート
–
236
時刻印を用いた多段同時実行制御
条件(1)が満たされれば、版Ajの次が版Amであって
も、Akをその間に挿入できる。
–
後から開始されたトランザク
ションTmがAを書き換えても
トランザクションTiはAを書き
換えることが出来る。
Aj
Ak
Am
t
TS(Tj)
TS(Ti)
TS(Tj+1)