Adult-Oriented Punk!

+ データベースの基礎知識メモ

last mod.2020/05/08 

データベースの基礎知識

  • データ基地。データの集まりのこと。少量でも、データが集合してたらデータベース。
  • データベースを上手に管理するための仕組みが、データベース管理システム(DBMS)。
  • 用語DBと用語DBMSを混同するのは「頭痛が痛い」と同じ。

大前提:データを保持し、必要に応じて取り出せること

大量データの○○性を保障する。
  • 完全性 →あるキーから引けるべき全データが引ける
  • 無矛盾性 →あるキーから引けてはいけないデータが引けない
  • 機密性 →アクセス権を詳細に管理し、見せたくないひとに見せない
  • 可用性 →必要なときに必ずアクセスできる

完全性と無矛盾性のために、Atomicアクセスの機能が必要。
Atomicアクセスのために、いわゆるトランザクション機構を利用する。

機密性のために、特権を管理する機能が必要。

可用性のために、高速に動作すること、データ故障に対する耐性が必要。
高速動作のために各種データ検索アルゴリズムを駆使する。
平均サービス時間の短縮は平均待ち時間の短縮につながり、平均応答時間の短縮につながる。
故障耐性のためにバックアップとジャーナル方式を使用する。


いわゆるトランザクション機構:
  • DBの文脈での用語「トランザクション」は、複数のアクセスについて、全部が失敗するか、全部が成功するかの
どちらかのみとし、中途半端な矛盾状態を作り出さないしくみを指す。

ジャーナル方式:
  • データ本体と、更新履歴を持つ。
  • 本体が壊れたら、バックアップと更新履歴から最新データを作り出す。
  • 更新履歴が壊れたら、もっと新しいバックアップを取り直す。
  • 全体が壊れる確率は、片方が壊れる確率の積になるので故障耐性が高まる。





  • さまざまな形のデータをさまざまな構造で保存する。
  • アクセス権の設定が容易にできる。
  • データ操作とデータ構造定義を分離できるので、データ構造の変更が、アプリケーションに影響しにくい。
(→データ構造の変更とは列内容だけでなくインデックスのつけ方を含む)

  • 木構造 →ツリーDBMS
  • ネットワーク構造 →ネットワークDBMS
  • 表構造 →リレーショナルDBMS
  • 構造体+アルファ →オブジェクトDBMS

  • タプル(広義には表を含む)
  • 表{行,列}
  • オブジェクト(表と相互変換するオブジェクト・リレーショナル・マッピングの議論もある)

  • すべてのデータ(行)にはIDがある。
  • インデックスとは、データ(行)IDを一定の順番で並べたもの。
  • データ本体とは別に保持される。

  • インデックス1つには順列方式が1つ対応。
  • インデックスは、1つの表に対し、複数作れる。
  • 複数のインデックスが同一の列に関連づけられる場合もまれにある。
  • 1つのインデックスが複数の表の複数列に関連付けられる場合もある。
例:インデックス1は「表1の列A」を昇順に並べるもの、インデックス2は「表1の列Bと表2の列C」を昇順に並べるもの、など。

さまざまな方式がある。目的のデータに応じて、もっとも適当な方式を選択する。
例:
  • 順列インデックス
  • 二分木インデックス...は、現実には使われないはず
  • バランス木インデックス
  • ビットマップインデックス...行に含まれるデータの属性をあらかじめビットにしておく
  • 逆キーインデックス...?
  • ファンクションインデックス...ユーザ独自のロジックで並べたいときの拡張用



物知りさん向けのコメント:
  • もしコンピュータ科学に詳しく、各種検索アルゴリズムを駆使してデータ管理ライブラリを自作することをいとわない技術者がいたとして、自作データ操作処理をべたでコーディングする場合とDBMSを利用する場合の違いは、データ定義とデータ利用をきれいに分けられるかどうかにかかっている。
  • 抽象的なデータ型の定義を行う作業、およびどの項目にどのように索引付けするかを決定する作業を、本体プログラムのコーディングと独立させ、後から比較的自由に変更できるような仕組みを構築できるならば、市販のDBMSは要らない。逆にそれを可能にするのがDBMSの役割。
  • このような仕組みを実行時コストではなく、コンパイル前の人的作業でのリーズナブルなコストに落とし込めればデータ管理は成功する。