<HOME　　<お願い事項　　<Access2000 TOP　　　<Access97 TOP　　　<サイト内検索
MS-Access2002チョ〜入門＞知っておきたい「データベース的考え方」

知っておきたい「データベース的考え方」

ちょっとお話はそれますが・・・・。
一般的に「データベース」というものがどういうものなのか、ざっくり考えてみます。
何かの参考にしていただければと、思います。

「データベース」とは「情報の集まり」のことです。
といっても無作為に情報が集まっているということではなくて、意味のある集まりのことを指します。
「電話帳」は「電話番号を調べやすくするために集められた情報」ですよね。
「時刻表」は「電車の発着時刻を調べるために集められた情報群」です。

なんでそんな情報の集まりがあるかというと・・・・。
電話番号を調べたい、電車の発着時刻を知りたい、という人がたくさんいるからですよね。
でもって、ある程度決まった形で一覧表にできたりする。
「データを提供する人と必要とする人」がいて、はじめて「データベース」っていうものが成り立ちます。
「世界中の赤いものを集めた情報群」なんていうデータベースがあったとしても、それは・・・。
どういう人が利用します？？？

誰かこういう情報を集めて提供してくれる人がいますか・・・。
提供する人がいなければデータベースは出来上がらないし、需要がなければ提供する人も現れないですよね。
「データの提供側と受け側がいる」・・・それがまずひとつめのポイントになります。

情報は常に成長しています。
ダイヤ改正が行われたら、時刻表も新しいものに作り変えないとなりません。
ダイヤ改正が行われたら家に置いてある時刻表も自動的に一番新しいものになってくれればありがたいですが、そんな不気味なことは起こりませんので、必要に応じて新しいものを買ってくる必要がありますよね。
今まで家に置いていた時刻表は消えてなくなってくれるわけではないので、処分しないとなりません。
処分し忘れると、時刻表が2冊あることになります。
間違えて古いほうを見ちゃって古いダイヤで発着時刻を確認してから駅に行ったら電車に乗り遅れた、なんてことになっちゃうかもしれません。
そりゃ間違える人が悪いんですけど、時刻表の大きさも厚さも同じようなもんだし、わかりにくいですよね。
何度も何度もダイヤ改正が行われそのたびに新しいのを買ってくるので、古い時刻表がいっぱいたまっちゃって場所を取ります。
改正になったページだけ差し替えにしてくれれば、いちいち買いなおさなくてもいいのに・・・とも思うんですが、差し替えがまためんどくさい。
ページがバラバラになっちゃったら、元に戻すのが大変。めんどくさいので誰も差し替え作業をせず、この時刻表が新しいダイヤに対応しているのかどうか、誰にもわからなくなってしまいます。
時刻表の差し替えが大変だからダイヤ改正はしない、なんてのは、ますますもって本末転倒・・・。
情報は常に変わっていきます。
いつ、どう変わっていくかは予測がつかない。
データベースは「できるだけ正しい情報を提供しなくてはならない」という使命を背負っているのです。
これがふたつめのポイントです。

電話帳、広げてみるとものすごくたくさんの電話番号が書かれてますよね。
皆さんは、どうやって電話番号を探します？
１ページめからめくっていって探さないとならない場合もありますが、たいていは、「○○市の○×株式会社の電話番号」とか、相手の名前がわかってると思いますから、そこんとこを見ればすぐ探せるはずです。
ということは、この電話帳は、「地区別、名前の順」で並んでれば、探しやすいわけです。
電話番号調べるのに電話番号順に並んでても意味ないでしょう。
っていうか、電話番号順に並んでるってことに、意味ありますかね？？？あんまり・・・ないですよね・・・。
「どういう状態ならもっとも探しやすいのか、すばやく探すことができるのか」、これが、みっつめのポイントです。


時刻表や電話帳なら、誰でも必要なときに簡単に調べられたほうがいいですけれど、会社の給与の支払いなんて情報は、誰でも簡単に見られちゃったら困るものですよね。
「利用者を制限しなくてはならない」場合もあるわけです。これがよっつめのポイントになります。

実は、時刻表は、うちの会社に一冊しかありません。
誰かが自分の席に持ってって調べてたら、その人が元の場所に時刻表を戻すまで他の人は時刻表を見ることができません。
同時に二人の人が時刻表を開いて、別々のページを調べてるなんてことも、忙しい会社では見られる光景かもしれませんが、たいていは、他の人が調べ終わるまで待ちます。

でも、社員が500人いて500人が一日に最低でも500回は時刻表を調べなくちゃならないような会社で、時刻表が1冊しかなかったら、つねに500人が小さな時刻表の端っこをつかんで自分が調べたいページを無理やり開けようとして他の人とかち合って手が当たったりページが破けたり・・・・。
仕事になりません。

そうなったら、「500人で1冊の時刻表を同時に見ようとしたら時刻表が破けてしまった。なんとかしてくれ」ってJRの人に言ったり、します？
多分、「もっと買っとけよ」って、思われるだけだと・・・思いますよ。
ねえ。ひとり１冊、持っといた方がいいですよね。それなら。
でも、500人社員がいるけど、時刻表を調べるのなんて月に1回あるかないかくらいで、たまたま「調べようかな」と思ったとき誰か他の人が時刻表を見てたら、「5分くらいしてまた出直してこよう」とか、そんなんだったら、ひとり1冊持ってるのはもったないと、わたしは思います。どっか、共有の本棚にでも1冊置いとけば、十分じゃないでしょうかね。
これって、どっちのケースも簡略化して表現すれば「500人で時刻表を共有している」っていうことになります。
大切なのは、「同時に何人くらいの人が使うことになっちゃいそうなのか」ってことだと思います。
これが、いつつめのポイントです。

これに関連したことになりますが、「500人の社員がそれぞれ２週間に1回くらいずつ時刻表を調べなくちゃならないとしたら、何冊くらい置いとけばいいの？」なんてJRの人に聞いても、なんて答えていいかわからないと思います。
それは・・・社内でルールを作って、みんなで考えることですよね。
500人でワーワー使っても破けたりしないかもしれないし、ひとりで大切に使ってても破けちゃうこともあるかもしれないし。
「どうすれば時刻表が破けないか」なんて、JRの人にも製本会社の人にもわかんないですよ。
「できれば一人でご覧になってください」とか、「破けたときのために予備にもう1冊お求めください」って、言われるくらいじゃないでしょうか。
同時に利用する人が少なければ少ないほどトラブルは少なくなります。
でも、時刻表を見るタイミングがかち合うこともありますよね。大勢で使ってたら・・・。
ほんとうに同時に使用する必要があるのかどうか考える。どれくらいかち合っちゃいそうかきっちり分析する。
これが、むっつめのポイントです。

で、忘れちゃならないのが、こういうことを「コンピュータでやる」っていうことです。
やっぱり、人間の頭で考えるのと同じようには、いかないですよね。多分。そういうところも多々あると思います。
これがななつめのポイントかな。。。

　１）「意味のある情報の集まり」・・・使う人と提供する人がいて、はじめて「データベース」が成り立ちます。
　２）できるだけ修正の手間が省けて、常に正しい情報を引き出せる。
　３）情報量が多くなっても、お目当ての情報をさくっと探せる。
　４）必要に応じて、利用者を制限したり、セキュリティもばっちり。
　５）大勢でひとつの情報を共有できる
　６）大勢でひとつの情報を共有しても、情報を引き出すのに時間がかかったりしない。
　　　ましてや情報が壊れたりするなんてもってのほか。
　７）こういうことを↑コンピュータでやる。どんなコンピュータで？どういうふうに？

すごく漠然としたお話ばっかりですけれど・・・。
こうしたことを学問的にまとめたのが、「データベース概論」です。
（もちろん、こんなちょっせー説明ではなく、もっときちんとしてますけども）
そして、これらを網羅したものがDBMSですね。
んでも、「こうしたことをやってくれるのがDBMS」というわけではありません。
「こうしたことに配慮するための機能を持っているのがDBMS」です。
そうした機能をきちんと使いこなさなければヨタヨタになってしまうのです。

１）については、どっちかというと、DBMSというより使う側の人間が気をつけないとならないことですね。
でもとりあえずいっしょに考えてみます。
１）〜７）を、きっちりとコンピュータにやらせるためには、それなりの知識と経験と技術が必要です。
あと、それなりにお金も掛かります。５）とか６）とかをきっちりやろうと思ったら、やっぱしそれなりのスペックのマシンをそろえないとならないし、ただ高いマシンを買ったところで、DBMの機能を使いこなせてなかったらダメだし、データベース化する業務とかによっても負荷が変わってくるだろうからそういう見積もりも出さなきゃいけないでしょう。
こういうのが、なかなか難しいんですよね・・・。

たまに「どれくらいのスペックのマシンを買えばいいんですか？」なんて聞かれることもあるんですが・・・・それって「何冊くらい時刻表を買っておいたらいいんですか？」って聞いてるのとおんなじ感じですよね。わからないです。
500冊買っとけばいいだろうけれど、ページのめくり方が乱暴だったら何百冊買ったってすぐ破けちゃうでしょうし。
500冊も置いとくとこ確保するの大変だったり、予算がなかったり・・・。
1冊しかなくてもみんながルールを守って丁寧に使ってたら敗れたりはしないんじゃないでしょうか。
あるいは、「じゃあ、2〜3冊買っとこうか」とか・・・。
いろいろ、参考になる事例はあるかもしれないけど、結果的に結論出すのは「使う人」です。

でも、調べる必要があるのに破けるといけないから時刻表を見ないでおくなんてのは本末転倒。
データベースだってだーれも使わなければ、やっすーいパソコンでも十分だし、あんまり技術がなくても時間を割かなくても問題は起きないです。
データベースっていうのは非常に不思議なもんで、「やってみないとわからない」ことばかりなのに「あらかじめ分析や設計が必要」なんです。これをうまいこと埋めるのが、「経験」であり「技術」であり「知識」です。
「どういう業務で」「どれくらいの規模のマシンで」「どういうDBMを用いて」「どういう設計をして」・・・・・というようなことを分析して考えられるようになるためには、試行錯誤を繰り返していかなければならない・・・明確なテンプレートはありません。
なぜなら、皆さんの会社の業務は、この世にふたつと同じものはないから。。。
だから、データベースは難しいのです。

今やもう、「データベース」といったら、上に上げた7つのポイントを実現するための機能をいろいろ持ち合わせたDBMS製品のことを言ってる場合が多いので、DBMSという言葉の意味は、ぼーんやりさせてしまってもいいのかもしれません。
「データベース」って言ったら、OracleなりSQL ServerなりPostgreSQLなりMySQLなりSybaseなり・・・データベース製品の名称がすぐ頭に思い浮かぶという方が、圧倒的に多いと思うし、それが普通になってます。
これらはすべて、開発もとの会社が違えば稼動する環境も異なるし、操作方法も機能も違いますけれど・・・。
でも、根本は同じだと思うんですよね。
すなわちどれも「１」〜７」を実現させるためのいろんな機能を持ち合わせたもの」なわけです。目的はいっしょです。
これを見失って製品の機能や操作方法ばかりに気をとられてしまうと、まるで「Oracleを使うために会社の売上がある」みたくなってしまいます。こうなったら、データベース技術としてはよいのかもしれないですが、会社の業務としてはおまえはすでに死んでいる状態です。
あかんでしょう、それじゃ・・・。

え？OracleとSQL Serverはどっちがいいのかって？
あーまたそういうことを考える・・・。
それは、「皆さんにとって、皆さんの会社の業務にとって、どっちがいいのか」っていう意味の質問疑問でしょう？
そんなの、皆さん以外の人間に答えられるわけないじゃないですか。
ダメですよ、そういうことを簡単に第三者に質問したって、答えは出ないです。
皆さんご自身が答えを見出さなくちゃ。。。これまた、試行錯誤の連続、です。

もちろん、どれも使ってみたことがある人からすれば、主観的な評価は立つと思います。
Oracleはお金がかかるし使いこなすのが大変、できればWindows2000とかNTとかじゃなくてUnix環境で動かしたい・・・とか、SQL ServerはDBMにしてはお任せモードが多くて自由が利かない・・・・・とか・・・。
でも、これはわたしの主観です。
人によってはぜんぜん違う評価を下すでしょう。
だからあんまりこういう話はしたくないのだ。

私は、どっちを使ったところで、結局は「使う側の使いこなし方」次第だと思います。
迷って、DBMSに対して不信感を抱きながら使ってたら、どっち選んでも同じだと思う。
やってみないとわからないこともたくさんありますからね。。。。
どの製品を導入したって、どれだけ検討したって、なんかのときに「やっぱり、あっちを選んでおけばよかったんだ」とか、文句言う人は、どこの世界にもいます。
そういう口先だけの人はほっといて、現状の構成でできることをその都度考えていけばいいのだと思いますよ。

データベースは、OracleやSQLServerが実現させるものじゃあありません。
皆さんが、使う人、作る人が一丸となってはじめて実現するものです。
そういう意味では、製品名に頼ってしまってはよいシステムはできあがらないと思うんです。

どういうDBMを使ってったらいいのかぜんぜん見当がつかない・・・という場合・・・・。
とりあえずMS-Accessで構築してみて、「ああ、やっぱりこれじゃ手狭かな」なんて思うようになったら、他のDBMへの移行を検討してみる、っていう流れも、ありなんじゃないかなって思いますよ。
そりゃ、最初からばっちりなDBMを選ぶことができればそれに越したことはないですが、データベースって、成長しますから、しばらく使ってみないとほんとの姿が見えてこないってこともありますしね。