データベース論（11）

データベースのセキュリティ

大きくまとめると
データの窃取
データベース論（１１）
アクセス権限・ビューによる参照の制約・
暗号化
秘密性の欠如
同上
覗き見・プライバシー
データベースの物理的側面
整合性の欠如・
異常データ書込み
整合性制約機能
利用性（可用性）の
欠如
バックアップ/リカバリ・RAIDなどの二重化
DB-11
データベースの物理的側面
セキュリティ（利用者IDとアクセス権限）

アクセスの権限をユーザごとに制限

どのように物理媒体（ハードディスクなど）に
格納するか？
問題

グループを定義して、そのグループに対して
権限を与えることができる（教p157）

DB-11

GRANT文
GRANT 権限 ON 対象データ TO USER 利用者
権限： SELECT, INSERT, UPDATE, DELETEなど
4

グループ（権限）を作る CREATE ROLE
グループに権限を付与 GRANT … TO グループ
個人にグループ（グループ権限）を与える
GRANT グループ TO 個人A
5

DB-11
アクセス速度・検索速度などの性能
容量のオーバーヘッド～管理情報が小さいか
（安全性～更新途中でクラッシュした場合など）
など
6
記憶階層の概念

記憶階層の概念
ハードウェアアーキテクチャ、ＯＳの授業
バッファする（キャッシング）

大容量・低電力・安価
ＣＰＵが
アクセス
キャッシュ
メモリ
レジスタ
高速
キャッシュ
メモリ
主記憶
最近使った
ブロック
キャッシュのコピー
実効アクセス時間＝
ヒット率×キャッシュアクセス時間
＋ミス率×主記憶アクセス時間
ページイン
実効アクセス時間＝
ヒット率×主記憶アクセス時間
＋ミス率×ディスクアクセス時間
最近使った
ページ
主記憶
ディスク
二次記憶
（ハードディスク）
ページ
ファイルの場合は、
デマンドページングはしないが、
似たような考え方でよかろう
（取り外し可能な
二次記憶）
DB-11
7
DB-11
ファイル編成
ファイル編成
前提イメージ：リレーショナルDBを格納？
リレーション（表）～ファイル
タプル（表の行）～レコード
属性（行の中の欄）～フィールド
ファイル
学生番号
レコード
氏名
媒体（ディスク）の中にレコード
をどのように記録するか

この本では：

年齢

フィールド
9
DB-11
ヒープファイル：レコードを順序に
関係なく格納
格納は簡単、検索は頭から探すし
かない
順次ファイル：キー（１つのフィー
ルド）の順に格納
格納は場所決めと挿入操作が必
要、検索は簡単
ハッシュファイル
キーフィールドにハッシュ関数を適
用して位置決め
格納（位置決め・挿入）も検索も、
そこそこ簡単
削除
順次ファイル
追加
追加
キーフィールドの
順に並べて入れる
ハッシュファイル
‘田中’
キー値
ハッシュ関数

DB-11
（メインフレームＯＳ）順次ファイル・
索引順次ファイル・直接ファイル
ヒープファイル
順次検索

たとえば二分検索

8
4
レコードの
位置を決める
10
インデックス（索引）の利用

なぜインデックス（索引）か？
インデックス（索引）＝キー値と場所の対応表

前提：キーの順序に並んでいると検索が
高速化できる（たとえば２分探索する）
常に検索キーが１つなら、

検索を早くしたい：検索しないor高速に見つける
本の「索引」と同じ考え方（探したい語⇒ページ）
（索引があれば、データの並びは適当でもいい?）
（普通？）対応表はメモリ内に置くこと（高速化）を考える

対応表
インデックス値
データの格納場所
その順で格納しておけばよいだろう
格納時に工夫必要

データ

検索

一般に、検索キーはその場で変わる

11
DB-11
１次：データファイルがキーに対して順序づけら
れていて、そのキーに対して付けたインデックス
２次：順序付けられていないフィールドに対して
付けたインデックス
（健保番号も候補キー）
キー「健保番号」上の２次インデックス
クラスタリングインデックス

整列

キーに対して重複があるレコードに対して、
キーで順序化するとかたまりになる教p166の図
このかたまりを指すインデックス
13
DB-11
社員ファイル
社員名
所属
健保番号
002
山田
総務
1003
007
田中
営業
1025
008
小林
営業
1008
010
伊藤
経理
1042
013
長野
総務
1016
020
佐藤
経理
1022
社員番号
社員名
所属
健保番号
1003
002
山田
総務
1003
1008
007
田中
営業
1025
1016
008
小林
営業
1008
1022
010
伊藤
経理
1042
1025
013
長野
総務
1016
1042
020
佐藤
経理
1022
健保番号
整列
DB-11
順序キー
社員番号
１次インデックス vs ２次インデックス

12
１次 vs ２次インデックス
１次vs２次、クラスタリングインデックス

インデックスの無いキーの検索は全レコードスキャン?
（キーを指定して）インデックスを作ると検索が
高速化できる

DB-11
格納位置を決める手間がかかる、
レコードが増えるので、それへの対応（後ろをずらす?）
ポインタ
14
密集 vs 点在インデックス

教p166図：ページとインデックス?
密集：キー値のすべてに対して
インデックスが存在
点在：一部のキー値だけに対して
インデックスが存在

インデックス
キー
1
5
9
1
2
3
4
15
クラスタリング
インデックス
9
10
11
12
DB-11
欲しい
フィールド値
1
2
3
4
5
＜2は指しているページ
ブロックの中から始まる＞
16
多段インデックス

データファイル
インデックスが大きいと不都合が多い

キー
1
1
2
2

ページ
（ブロック）
ページ
（ブロック）
5
6
7
8
教p166 クラスタリングインデックス

スペースを食う／検索に時間がかかる
多段にしてインデックスを小さくする
ISAMインデックス（参考）
Ｂ＋木インデックス
2
3
3
4
1～4
1～16
1～64
5
5
5
5
1～256
257～512
513～768
768～1024
DB-11
キー
インデックスが存在しないキー値を検索するとき
は、ポイントされた先から（その次のレコードを）
検索してゆく必要がある～その分遅くなる
インデックス（の表）は（全部は持たないから）小さ
くなる
DB-11
データファイル
17
DB-11
65～128
129～192
17～32
33～48
データ
ファイル
1
2
5～8
3
9～12
4
13～16
49～64
193～256
１段のみだと、1024エントリー分の表をロード
５段だと、合計で20エントリー分の表をロード（log4N）
17
4
22
35
1
3
14
2
5
…
18
ISAMインデックス

Ｂ＋木インデックス
データファイルを順次化しておくと、最後の
１段をファイル内のスキャンに置き換えられる
その分は遅くなる

データ
ファイル

Ｂ木（balanced tree）が基本で、
派生形（改良形）としてＢ＊木やＢ＋木
データベースやファイルシステム（Linux, Win）
で広く使われている
1
1～16
1～64
65～128
1～256
129～192
257～512
17～32
33～48
1～4
2
5～8
3
9～12
4
13～16
5
768～1024

7
Ｂ木の原理
…
キー
10
19
検索：昇順を利用～高速に位置発見
20
30
40?
キー
30

キー
60
キー
40
キー
70
キー

分岐数がmを越えたら、ノードを分割する
60
40
DB-11
最大４とすると
20
50
キー
40
キー
70
キー
20
45
を挿入
したい
とき
30
何もしないと
バランスしない

挿入：昇順の場所に挿入、バランスを保つ

キー
30
バランスしないと何が悪いか
キー
20

キー
15
DB-11
Ｂ木の原理
キー
15
キー
60
9
ISAM: Indexed Sequential Access Method
（ファイルのアクセス法として定義）
キー
10
・多分木
・キー（昇順、部分木間の境界）
・木の形をなるべくバランスさせる
分岐数を最大m、最小m/2にする
キー
20
１つのディスク
ブロックに入れる
8
DB-11

（メモリ内でなく）ディスク等ブロック単位での入出力に適する
6
49～64
193～256
513～768

50
40
60
45
入らないので分割する
60
50
追加順序に依る
検索の時間が
一定しない
他の操作は
（挿入や削除）
検索してから
40
30
20
50
21
DB-11
22
Ｂ＋木インデックス

ハッシュインデックス
Ｂ木
末端（葉）ノードは
下へのポインタが
ないから（～置か
ないとすれば）その
スペースが無駄
30
10
15
30
葉にデータ（レコー
ド）を入れる
キー
14
19 25
65
50
33
47
データ
70
10
7
14
55
63
68
75
Ｂ＋木
15
19
30
25

60
33
40
47
65
50
55
63
70
68
75
30
10
15
60
30
40
50
65
70
このリンクを追加
23
DB-11
ハッシュとは

キー値の空間（疎）
ハッシュ
関数
アドレス
長いキー値
キー値の空間
ハッシュ関数
（疎）
アドレス
アドレス
アドレス
レコード
レコード
アドレス
の空間
（密）
DB-11
ハッシュ
関数
先頭のアドレス
キー値をそのままアドレスにすることは長すぎて不可
キー値（キー空間）を圧縮する関数＝ハッシュ関数
重なり（シノニム）を生ずる可能性がある
⇒ 指す先をレコードのリストにする
長いキー値

24
ハッシュとは
「順序に並べ検索」でなく
キー値からレコードアドレスを、直接計算する

ハッシュ法（ハッシュによる検索高速化）を
使ったインデックス構成法
アドレス計算にハッシュ関数を使って、
直接レコードアドレスを計算する
ハッシュとは？ ⇒ 次のページ
データ
教科書の図では
DB-11
40

7
30

60
アドレスの
空間（密）
25
DB-11
レコード
レコード
26
ハッシュインデックス

教p169の[ハッシュ法]の図

問合せの最適化

「パケット」＝シノニム時の複数アドレスのリスト
ここは固定長パケットにし溢れると次のパケット
検索に比べて、一発でアドレス計算可能
シノニムの存在により
キー値の偏りに検索性能が依存
あいまい検索（LIKE, %）には無力
SQL言語（の問合せ）は「非手続き型」

具体的には

DB-11
27
SELECT * FROM 学生,学部
WHERE 学生.所属学部＝学部.所属学部
AND 学生.男女区分＝’女’ AND 学部.場所＝’東京’
選択(学部.男女
区分＝’女’)
（ｂ）
選択(学部.場所＝’東京’)
選択(学部.男女
区分＝’女’)

（ｃ）
結合(学生.所属学部
＝学部.所属学部)

選択(学部.男女選択(学部.
区分＝’女’)
場所＝’東京’)
学生
学生
DB-11
学生
学部
学部

学部
３通り考えられるが、（ｃ）が最適

29
一般的なルール

選択(学生.所属学部
結合(学生.所属学部
＝学部.所属学部)
＝学部.所属学部)
（直積）学生×学部
28
問合せ最適化
例
（ａ）
選択(学部.場所＝’東京’)
問合せ分解（構文解析）、問合せ最適化、
コード生成、問合せ実行、の４ステップ
動的問合せ最適化（実行のたびに最適化処理）
vs 静的問合せ最適化（コンパイル時１回だけ）
DB-11
問合せ最適化～問合せプラン選択

こうしてああして、ではなくて、条件を満たすもの
⇒ 手順はどう組んでもよい
⇒ 手順の組み方を工夫して速くする（最適化）
DB-11
複数の選択演算がある場合、
絞り込み効果が高いほうを出来る限り先に行う
射影演算は、出来る限り先に行う
直積演算は、選択演算を行った後の結合演算に
する
基本的には、インデックスがあれば、インデックス
検索を優先する
⇒ 早めに結果を絞り込む（表を小さくする）
具体的には個々の演算のコスト見積をする
30
演算のコスト（選択（略）、結合）

結合演算のアルゴリズム

DB-11
ネストループ結合表RとSのそれぞれをループ
インデックス付きネストループ結合
右側（S）にインデックスが付いている結合
ソートマージ結合 RとSの両方を、結合値で
ソートしておいてマージする
ハッシュ結合ハッシュインデックスを利用して
RとSにアクセスする
31

Download Report