DBスペシャリスト受けます。
ネスペ同様にだらだらと勉強内容メモっていきます。
教材はコレ。
9.障害回復機能
9.3.ロギング
章末問題 4/6(66%) やばす。
10.インデックスとアクセス手順
10.1.インデックス
10.1.1.B+Treeインデックス
・いちばん使われてるやつ
・B-Treeインデックスを改良したもの
・バランス木構造
・
http://blog.h13i32maru.jp/entry/2012/07/01/000000 分かりやすい
・B木とB+木の違い
・B木はルートノードからリーフノードまでのすべてのページにデータへのポインタを持つ
連続したデータを読み取る場合に効率的ではない
・B+木はデータへのポインタをリーフノードのみに集約。さらにリーフノード間のポインタを持つことで範囲検索時のインデックス利用効率を向上。
B+木はリーフノードのその他のノードではっきりと役割が違う。ルートや中間ノードをランダムアクセスのための索引組（IndexSet)と呼び、リーフノードをデータアクセスのための順序組(sequence set)と呼ぶ。
10.1.2.ハッシュインデックス
・使われてるのか？これ。
10.1.3.ビットマップインデックス
・キー値の重複が非常に多い場合に有効なIndex
・リーフ以外はB+木と同じ構造を持つ。
・キー値を持つ行を１、持たない行を０としてビットマップを持つ
10.1.4.リンクインデックス
・行同士のリンクを高速に処理するためのインデックス
・各行に対してインデックス情報が付加される。
10.1.5.結合インデックス
・結合キーで検索するときに検索を高速に行うためのインデックス
10.1.6.その他のインデックス
・n-gramインデックス
・全文検索用インデックス。gram=文字
・四分木インデックス
・地図などの空間情報を効率よく検索するためのインデックス。へぇ。
・UB木インデックス
・B+木を改良したもの。複数列のインデックスの場合に、どの列に対しても同じ効果が得られるように改良。
10.2.インデックスの効果と弊害
メリット
・I/O削減とCPU時間の削減
これが一番求める機能だね。
・キー値順の行データ取得によるソート処理削減
なるほど。確かに。
デメリット
・大量データへのランダムアクセスによるI/Oの増加
インデックス経由で参照する行データはランダムアクセス。（非クラスタインデックスの場合）
・データ更新時のオーバーヘッド増加
10.3.クラスタインデックス
キー値の近い行が同じもしくは近いデータページに配置されるよう制御してくれる機構を持つインデックスのこと。
10.4.探索条件と複数列インデックスのサーチ範囲
B+木インデックスなどで複数列がキー項目になっている場合、探索条件（Where）の順番によってサーチ範囲に大きな違いが出る。
10.5.アクセス手順
10.5.1.表のアクセス方法
・インデックスを用いないアクセス方法(表スキャン)
全ての行に順次アクセスする
全ての行を検索する場合や、表に対して検索行数の比率が多い場合に有効。
・インデックスを利用した行データへのアクセス方法(インデックススキャン)
表中のごく一部を検索する場合に使う。
・インデックスだけを参照するアクセス方法(キースキャン)
参照する必要のある列がインデックスを構成する列の中に組み込まれている場合は
行データを参照しなくとも目的の値を取得できる。
・複数のインデックスを利用するアクセス方法(AND)
それぞれのインデックス利用結果を満たす行(ROWID)の集合を作る。
当然１つの複数行インデックスを使った方が効率は上。
・複数のインデックスを利用するアクセス方法(OR)
それぞれのインデックス結果の集合和を使用。
・複数のビットマップインデックスを利用するアクセス方法
それぞれのインデックス結果のビットマップ同士をAND演算もしくはOR演算する。
・ビットマップインデックスとB+インデックスを利用するアクセス方法
・その他のアクセス方法
一度検索した結果を作業表に格納して再度その表を検索する場合がある。（作業表スキャン）
10.5.2.表の結合方法
・入れ子ループ結合(Nested-Loop Join)
一方の表(外表)を検索して1行得られるごとに、その行に対して他方(内表)の行を検索する。
内表に対してインデックスが効かないと非常に大きな負荷になる。
・併合結合(Merge Join)
内表にインデックスがなくても利用可能。双方の表の結合キーを突き合わせながら１つずつ比較していく。
それぞれの表のキー項目ソート処理と作業表の作成が必要となる。
・ハッシュ結合(Hash Join)
内表からハッシュ表を作成してインデックスの代わりに用いる入れ子ループ結合。
章末問題 4/5(80%)正解
11.分散データベースシステム
11.1.分散データベースシステムとは
分散システム：地理的、論理的に分散した複数のシステムが協調して働くシステム
分散データベース：複数のデータベースを結合し、１つのデータベースのように見せるシステム
主な利点は危険分散と負荷分散
・危険分散
災害や災害時に影響を局所化する。
・負荷分散
複数マシンを使うため負荷分散が可能。またスケーラビリティも持つ。
11.2.分散データベースシステムにおける透過性
分散透過性：利用者に複数のシステムから構成されていることを意識させないこと
・アクセス透過性
どこのサイトのデータにも同じ手法でアクセスできること
・位置透過性
データの存在するサイトを知らなくてもアクセスできること
・重複透過性
複数サイトに重複していたりしてもそれを意識させないこと。
・分割透過性
１つの表が複数サイトに分散されていてもそれを意識させないこと。
・移動透過性
表を格納しているサイトを変更してもそれを意識させないこと
・並行透過性
複数サイトから同時に操作できること
・障害透過性
いずれかの要素に障害が発生してもそれを隠ぺいできること
・規模透過性
システムの規模を変更できること
多いわｗ
11.3.分散データベースでの票の結合方法
複数サイトに存在している表の結合が必要になる場合は、通信負荷も考慮する必要がある。
・セミ結合(Semi Join)
通信負荷を小さくするための結合方法。
結合結果を射影して他サイトへ送り、さらに結合した結果を受け取る。
2度結合が必要だが通信量が減る。
・分散入れ子ループ結合
外表の行を1行ずつ送り、受け取った1行ずつに対して結合を行う。
・分散併合結合
結合キーのソート結果を他方に転送し、結合を始める方法
・分散ハッシュ結合
行数が少ない方の検索結果を転送し、ハッシュ表を作成。それを用いてハッシュ結合を行う。
なんとなく雰囲気は分かった。
11.4.２相コミットメントプロトコル
サイト間での矛盾を防ぐ必要がある。
コミット準備フェーズ→コミット指示フェーズの２段階。
セキュアになったあとも通信障害などがあるとサイト間の一貫性を保証することはできない。
サイト内のトランザクションをサブトランザクションと呼ぶ。
サイト全体のトランザクションをグローバルトランザクションと呼ぶ。
なんとなくどっかで読んだことあるなぁ。
11.5.データの分散配置
特定の行ごとで分割したり、列で分割したりする。
通信のオーバーヘッドや負荷、応答時間などを考慮して分割方法を工夫する必要がある。
並列DBエンジンのパーティショニングなども分散配置の一種。
・キーレンジ分割
特定のキー範囲ごとに分割
・ハッシュ分割
キーの値をハッシュ化して格納領域を決定
・ラウンドロビン方式
順番に格納場所を変える
章末問題 6/6(100%)
12.応用技術他
12.1.レプリケーション
レプリカ(複製)を持ち、更新情報を自動的に反映する処理をレプリケーションという。
・複数のDBシステム間で同じデータを使用したい場合
・１つのDBシステム内でオンライン業務とバッチ業務を同時に実行したい場合
・分散システムの場合応答西濃をよくするために複数サイトにレプリカを持つ場合
など。
分散システムの場合は下記２つの更新方法がある。
・同一トランザクションで更新する同期更新(同期レプリケーション)
・トランザクション外で遅延更新する非同期更新(非同期レプリケーション)
一般的には重複透過性のために同期更新を行う。
12.2.OLAP (OnLine Analytical Processing) ：多次元分析
さまざまな集計データを迅速に求め、データを分析する処理のこと。
OLAP = 動的な多次元分析処理機能
多次元分析専用のデータベースとして多次元データベースがある。
しかし主流はRDBを用いた多次元解析。
・多次元DBを用いたもの = MOLAP(Multi-dimensional OnLine Analytical Processing)
・RDBを用いたもの = ROLAP(Relational OnLine～)
・多次元解析の主な手法
・スライシング
２つの軸を選択して特定の面だけを参照する
・ダイシング(サイコロ)
サイコロを転がすように参照するデータの軸を変える
・ドリルダウン
集約データ→詳細データ→より詳細データとたどる方法
・ロールアップ
ドリルダウンの逆
12.3.データ発掘(データマイニング)
大量に蓄積されたデータからデータ間の規則を見つけだすこと。
評価指標には規則信頼度や規則支持度がある。
・規則信頼度＝条件部の条件を満たす件数：結論部の条件を満たす件数
・規則支持度＝全件数：条件部と結論部両方の条件を満たす件数
どちらも高いものがよりよい規則。
12.4.データウェアハウス
業務に必要なデータだけでなく、有効活用できるデータを格納しようとする概念。
・主題指向
業務中心のデータではなくデータ中心でデータを格納する
・統合
データ体系を統一する
名称、コード、単位など
・時系列
過去から最新のデータまで蓄積する
・不変性
参照処理中心（データを更新しない）
データウェアハウスは既存の基幹システムと共存し、戦略情報としてデータを活用するために用いる。
なるほどなぁ。
12.5.メタデータ、データ辞書、リポジトリ
データに関するデータとそれを保持する仕組みとか。
12.6.ストアドプロシージャ
一連の処理をあらかじめ定義してDBMSに登録しておく。
12.7.オブジェクト指向データベース
オブジェクト指向を取り入れたデータベース
・オブジェクト指向データベース
プログラミングのオブジェクト指向と同じっぽい。
・オブジェクト関係データベース
RDBをオブジェクト指向っぽく拡張したもの。
うん、よくわからん。
12.8.XML
タグによるマークアップ(情報の付加)を行うことで下記が可能
・文書を論理的な要素に分割(文書構造)
・各要素に行うべき処理を指定(見せ方)
12.9.ベンチマーク
TPCが制定しているベンチマーク
TPC：Transaction processing Performance Council
システム全体としての性能を評価するもの。
・TPC-C
オンライントランザクション処理向けのベンチマーク
・TPC-H,TPC-R
オンライン分析処理向けのベンチアーク
12.10.Unicode
世界中のすべての文字を１つの文字コード体系で表現するために制定。
章末問題 7/9(77%)
どっかで聞いたことあるようなことばっかやけど多すぎ。
しんどー。
