<HOME  <お願い事項  <Access2000 TOP   <Access97 TOP   <サイト内検索
 MS-Access2002 なりきりデータベース設計
  1 2 3 4 5



漕げよマイケル 2

毎日毎日、マイケルは休まず働きました。
日々の売上数がデータとして蓄積されてきて、大いに励みになっています。
お客さんの注文を伺いながら、売上を書き留めていたもんですから、ちょっとしたミスにしばらくの間気付きませんでした。
商品名を適当に入力してしまってたもんで、

商品ごとの売上数を集計しようとしても、うまく集計してくれなくなってしまいました。

ありゃりゃ・・・。
コンピュータはアホですからね。「クヌギ」と「くぬぎ」を別物として集計してしまうようです。
ひらがなとカタカナくらいだったら何とかなりそうですが、「くり」と「栗」は、もうどうしようもないかな・・・。

うーん、こういうこともちょっと考慮しておかないと、ゆくゆく、商品の種類が増えてきたときとか、マイケルの頭が爆発してしまうかもしれません。
商品の種類が不特定の場合は仕方がないですけど、マイケルのお店のように、マイケルが拾ってきたどんぐりだけを売ってる場合は、予め「商品の種類」って限られてるわけですよね。
そうしたら・・・直接入力するのではなくて、商品の一覧から「選ぶ」ようにしといたほうがいいかもしれないですね。
どう思います?

かわいそうなマイケルのために、少し知恵を絞ってあげてください。



商品の一覧を別にこしらえておいて、↓こんな風に参照できるようにしてみました。
これなら、商品名をカタカナにしたりひらがなにしたりという「微妙な間違い」がなくなりますよね。

すっきり集計できました。

この、商品の一覧自体がダブりまくってたら、結局同じことなので、この一覧の中身はダブらないようにシッカリとキープしないとならないわけですね。でないと、商品の一覧を設けた意味がなくなってしまいます。

最終的には、マイケル自身が気をつけてときどき商品一覧の内容を確認したりしないとならないですが、データベースとして、何か考慮しておくべきことはないでしょうか・・・。こういうことを考えることが、いわゆる「リレーション」ってやつなんです。
リレーションってのはソフトウェアの機能とか操作のことじゃありませんからね。こういう「考え方」のことです。
だから余計難しいんですけどね。

  ・なぜ商品の一覧を作っておこうと思うに至ったか
  ・なぜ商品の一覧はダブったらマズイのか

を、もう一度考え直してみてください。マイケルのために。

商品の一覧を見ながら、売上の入力をするわけですから、ここで、このマイケルのお店のデータベースに「売上」と「商品一覧」の2種類の情報のかたまりが誕生したことになります。情報のかたまりがふたつできたら、双方がどうやってくっつくのか、どういう関係があるのか・・・を、じっくりと考えてみていきましょう。

こういうのを理解するのには、ある程度訓練が必要だと思います。ほんとにね、難しいんですよ。
なかなか、すぐ理解する、というわけにはいかないとこです。
でも、これすんなり理解できるようになると、データベース作りがすごく楽になるはずなんです。
ここで焦ってしまわずに、ゆっくり理解していくといたしましょう。




忙しくなってきたので、友達のアクセルくんに、ときどきお店番を頼むことにしました。
なんだか態度がでかいです。

でも、この際仕方がありません。
マイケルは商品の説明をしました。が、アクセルくん、何回説明しても、どれがシイの実でどれがクヌギだか区別がつきません。
しかも、どれが何円だか、全然覚えようともしません。
自分がバカなだけなのに、「覚えらんねぇよバーカ」とか言ってます。

たまに、電話で注文を受けることなどもあって、「丸いやつ10個ちょうだい」とかいう言い方をする人(リス)もいるので、商品の名前と値段とがあいまいだとますます混乱しそうです。

そこでマイケルは、商品に番号をつけて、なるべく番号でやり取りをしてもらおうと考えました。

こうしておけば、いずれ商品の種類が増えて、似たような名前の木の実が並んだとしても、アクセルくんでも店番ができるだろうし、木の実に詳しくないお客さんとのやり取りでも値段を間違えたりしなくて済むようになるんじゃないかと思ったわけです。
まあ、どれだけきちんと商品の一覧を完備しても、アクセルくんが間違えちゃったら意味がないんですが・・・。

こんなふうに、商品の番号を売上一覧に入力(あるいは選択)するようにしました。
こうしておけば、売上の集計をした後で売上の金額の計算がすぐにできるようになります。

番号なら、お客さんとのあいだで言い間違いや聞き間違いもなくなるだろうし、マイケルも安心して仕入に出かけることができます。

さて、この図、もう一度よく見てみてください。

左側(売上)と右側(商品一覧)の中の「商品の番号(赤い字)」の数を数えてみてください。
商品一覧では「01」は1つ。売上一覧の方では、01は4回出てきてますよね。
でも、必ず4回と決まっているわけでもなく、01の商品が売れれば、それだけ登場回数も多くなります。
また、まったく売れない場合もあるでしょうから、0回という可能性もあります。
これがいわゆる「一対多」というやつ。耳にしたことがある方もいらっしゃるのではないでしょうか。

ふたつの情報のかたまりは、商品番号が、「商品一覧」に  、「売上一覧」に (  とか  とかいう文字を使うこともアリ) という関係にあるわけです。
ここで若干の注意を・・・先に「一対多」という言葉が先行しちゃうと、わけがわからなくなりがちです。
これは、どんなプロフェッショナルでも同じこと。さまざまな情報のかたまりがあり、お互いに関連があって、そうした関連を考えていった結果、「一対多」という関係が浮かび上がる・・・というわけですからね。「一対多」を作るためにテーブル作ってんじゃないんです。


さて・・・「商品一覧」に商品番号がダブってないことを、私たちは何とかして証明しないとなりません。
相手はコンピュータですからね。商品番号だって言ったって、文字や数字の羅列くらいにしか思ってくれないですよ。ダブってるダブってないの基準をはっきりさせてやらないと。。。。。。

とにかく、今回の場合は、右側のほうの「商品一覧」にダブりがない、ということを、何らかの形で証明しないとならないわけです。
皆さんなら、どうします?

MS-Accessの場合は、「一対多」の「一」の方の商品番号を「主キー」にすることによって、「一」であるという証明をします。
主キーというものはつけりゃあいいってもんじゃありませんのですよ。
こうして、ふたつの情報のかまりの結びつきを考えたときに、必然的に浮かび上がってくるもんなんです。
MS-Accessは「オートナンバー型」なんていう悪どいデータ型がありますから、主キーって正しく理解できない人結構おられるんですけどね。主キーってのは、皆さんのためにつけるんじゃありませんからね。
主キーというのは、MS-Accessのため、コンピュータのためのもの、です。

わけもわからず、「とりあえずオートナンバー型のフィールドを作ってそれを主キーにしとけばいいのかな」なんてことをやらかしちゃうと、ワケのわからないことになりがちです。しかも!たまに、「商品のデータを削除したりしたら、オートナンバー型の番号が飛び飛びになっちゃったので1から振りなおしたい」とか言い出す人がいたりして。おいおい、ますます売上の一覧とつながらなくなっちゃわないかい?主キーは皆さんのためにつけるんじゃありませんからね。皆さんにとっては、見た目、飛び飛びになって気になるかもしれませんが、それはこの際「人間の都合」ということで、↑上のような図を書いてみて、矛盾が生じないかどうか、しっかり検討しておく必要アリ、ですよ。

もちろん、オートナンバー型というデータ型が便利に働いてくれるときもありますよ。
使う側(つまりわたしたちが)ちゃんと理解をして活用していれば、便利っちゃあ便利です。
でも、「主キーってよく分からないからとりあえずオートナンバー型」みたいに、とりあえずビール感覚で付けてると、ワケのわかんないことになりがちですからね・・・。

「一対多」の 多 の方にも、いずれもしかしたら何らかの「主キー」が必要になるかもしれませんが、とりあえず今の時点では、「商品一覧」とシッカリ結びつくようになっていれば、主キーのことは考えなくてもいいでしょう。
とりあえずは、「一対多」の「一」の方にしかるべく主キーの設定をすること・・・。この点を、最終的に、導き出せるようにしてください。

といっても、繰り返しになりますけど、これとっても難しいことですからね・・・。
こういう設計を専門にやってお金取ってる会社とかあるくらいですから。すごく技術のいることなんです。
なかなか、簡単には、いかないです。
マイケルのお店覗きながら、少しずつ理解を深めていって下さい。

こうなると、お客さんの「種類」(種類、って言い方もどうかと思うよマイケル)も、選択できるようにしておいたほうがいいかもしれないですね。
まあ、単なる「コメント」ならば、アカリスでも赤リスでもどっちでもいいですが、後で、「アカリス系の売上数」としてまとめたいときとか、まとめにくいですよね。

後で集計を取りたいときは、きっちりそろえて入力できるような工夫をしておいたほうがよさそうです。

皆さんにとってはマイケルのことなんてどうでもいいかもしれませんが、でも、今までお話してきたことって、すべてのデータベースの基本となる考え方だと思います。マイケルのお店なんかどうでもいいんですが(ごめんよマイケル)、マイケルが日々扱っている情報は、皆さんの会社や学校の中のさまざまな情報の縮図になるんじゃないかな・・・と思うんです。
「一対多」とか「リレーション」とか「テーブルの正規化」とかいう言葉が先に立ってしまうと、どうしても本質が見えづらくなってしまいますから、こういうマイケルの店みたいなしょぼい例で考えてみて、基本を身に付けちゃってください。大掛かりなデータベースを作るとき、きっとこの考え方がお役に立つのではないかな・・・と思います。
マイケルも喜ぶと思います。