今回はデータベースの事でざっくりと。
データベースと聞くとなんとなくイメージは浮かぶかと思います。
このデータベースにはそれぞれ目的ごとの情報が入っています。
この情報を検索したりデータを抽出したりなどデータを簡単に
再利用できるようにしたものをデータベース(略してDB)と言います。(たぶん)
そして、このデータベースを管理するシステム(ソフトウェア)を
データベース管理システムといい(そのまんまやんけ)、略してDBMSと
表記したりします。
代表的なDBMSはOracle(オラクル)、SQLServerといった有名どころから
Webプログラマーはみんな知っているPostgreSQLやMySQL等です。
MicrosoftOfficeのお高いエディションに含まれるAccessもそうです。
(Accessは他のDBMSとちょっと違いますが細かい事は気にしない事にしましょうw)
もちろん、これら以外にもたくさんのDBMS製品があります。
で、このデータベースは色々と種類があるんですが、
現在よく使われているものがリレーショナルデータベース(略してRDB)
といわれるもので、データを表のようなイメージで管理しています。
わかりやすく例えるならExcelみたいな感じです。表ですからねw
上で紹介したDBMSもすべてRDBです。
RDBなのでRDBMSといったりもします。
そしてデータを操作したり、表を作ったりするのにSQLという言語を使います。
今回はSQLについては何も書きませんw
需要があれば今後書くかもしれないです。
さて、このデータベースですが膨大なデータの中から瞬時にデータを検索できます。
通常、目でデータを探す場合を考えます。
下の表を見てください。
フリガナ | 名称 | 人口(適当) |
ホンドマチ | 本渡町 | 10000 |
ウシブカマチ | 牛深町 | 7000 |
アマクサマチ | 天草町 | 4000 |
イツワマチ | 五和町 | 5000 |
スモトマチ | 栖本町 | 3000 |
この中で「アマクサマチ」を探します。
人の目で探す場合はパッと見て3行目だというのがわかります。
では、コンピュータはどう探すか?
パッと見るという行為ができませんのでご丁寧に1行目から
「アマクサマチ」と一致する行を1行ずつ比較しながら探します。
データーベースのデータも通常、ハードディスクに入っています。
つまりディスクからデータを読み出して検索を行う必要がありますよね?
しかし、ディスクというのはアクセス速度が遅いのです。
上の表では5件しかありませんので読み出すのは一瞬でしょう。
しかし、データが何万、何十万となってくるとそうはいきません。
その場合、なるべくディスクからの読み出しを減らすようにするには
どうすればいいでしょう?
この問題を解決するのがインデックスという仕組みです。
本の電話帳を思い出してみてください。
たくさんの電話番号から目的の電話番号を探すのに1ページ目から
見て調べていればとてもじゃないですがやってられません。
でも、通常はそんな探し方しませんよね?
そうです、目的の名前の頭文字のページを開いてその部分を探せばいいのです。
インデックスとはまさにそういうイメージなんです。
上の例でいくと、「フリガナ」をインデックスにしたとします。
イメージ的にはこんな感じでしょうか?
ア行 | アマクサマチ イツワマチ ウシブカマチ | 3行目 4行目 2行目 |
サ行 | スモトマチ | 5行目 |
ハ行 | ホンドマチ | 1行目 |
まず、アマクサマチを検索する場合はインデックスのア行を見ればいいわけです。
その中で探すと見つかりやすいですよね?(アイウエオ順に並んでいるので)
また、見つけたら書いてある行数を見てその行を読み出せばいいわけです。
これがインデックスの考え方ですが、あくまでこれは大雑把なイメージであって
DBMSが実際にこのような実装をしているという意味ではないので注意してください。
インデックスがついてない項目で検索すると最初に言ったとおり、上から順番にデータ行を
見ていくので検索は遅いです。
なので、インデックスを増やすと色々な項目での検索を高速に行えます。
・・・が、インデックスを増やしすぎると更新処理が遅くなります。
なぜなら、データを追加したり削除したりした場合はインデックス側も
連動して変える必要があるからです。
インデックスが多いとその作業も多くなり、結果、遅くなるというわけです。
なので検索が多いけど更新は少ない表(テーブルとも言います)ならばインデックスが多少多くても
あまり問題ありません。
このように、インデックスも考えて使用しないといけません。
ややこしいですね。
データベースに関してもまだまだ奥が深いですので今後、時々記事を書いていこうと思います。