<HOME　　<お願い事項 　　<Access2002 TOP　　　<Access97 TOP　　　<サイト内検索
MS-Access2000超入門部屋--基本操作をさらに考える

おっ！「第2ステージ」へようこそ（笑）
「基本操作を考える」は征服なさいましたですか？
細かいとこ見ていくとかなり

またいろいろとお話していきますので、がんばりましょうね！
いちおう、ここでは、「基本操作を考える」のところでずっと作ってきたぼちぼち.mdbっていうデータベースを使って、プラスアルファのことをお話していきます。

具体的なお話に入る前に・・・。ちょっとだけ、「考え方」についてお話します。
Accessに限らず、大抵の「データベース」と呼ばれるものは、テーブルがいくつかわかれてます。
っていうか、作るときに分けて作ります。

なんで分けて作るか・・・というところになると、もっと技術的なことからお話しなくちゃならないんですけどモ、要するに

分けて作るもんなんですよ。

もちろん、きちんとその辺のデータベースの知識があった方がいいに決まってますけど、Accessで効率よくシステム開発をするために最低限必要な「考え方」みたいなのを、ここでは少し考えてみようと思います。
Accessは「リレーショナルデータベース」っていう形式のデータベースです。

早い話、テーブルを小分けして、必要なときにつなげて使うタイプのデータベースなんですね。

むやみやたらに分けるんじゃなくて、各テーブルで役割分担してもらうわけです。

例えば、下の図をちょっと見てください。ちょっと大きな図ですけど・・・。

これは、MS-Excelで作った「売上表」です。
どこの会社に、いつ、どんな商品を売ったのか、いくらの売上になったのか、その顧客はどこにある会社で、電話番号は何番か、という具合に、売上管理に必要な情報を横に並べた表です。これを見れば、いつどの商品がいくつくらい売れたのか、一覧として眺めることができます。

こういう売上表とおなじことを「データベース」として考え、Accessでデータ管理していこうとした場合は、

まずこういう構造のテーブルがあって、

そこに、こうして1行ずつデータが入ってくることになります。
表計算ソフトの考え方そのままで考えてしまうと、ところどころ空欄ができてしまいますよね。これでは「データベース」とは言えません。
と、いうお話は、ちょっとだけ「基本操作を考える」のところでもお話しましたよね。

まあ、でも、これでも、この順番にテーブルの中に収まってくれれば、「前の行の顧客名」を参照すればいいわけですから、わけわかんなくなっちゃうというほどのことでもなさそうですね。でも、ところがどっこい。データベースというものは、テーブルに蓄積したデータを並べ替えたり必要なものだけ抽出したりしてこそ存在価値ありってもんなのです。一覧表みたいにデータを並べて眺めるためのものではありません。

したがって、必要に応じて「大トロせんべいは今月、いくつくらい売れた？どこのお客に主に売れてるんだ？」っていう分析をしたい場合に、

無情にもこの2行がこのように取り出されます。
まあ・・・1行目のは、40枚、どこの会社に売れたのか、さっぱりワカリマセンね。

このような「抽出・並べ替え」を目的としつつデータをためるので、テーブルの中の「データの入ってきた順番、並び順」なんてのはさっぱり当てにならない。従って、「前のレコードの顧客名と同じ」なんて話は通用しないってわけです。

データベースは、テーブルの中にデータをため、必要に応じて必要な形で取り出すためのいろいろな仕組みを考えるものです。表計算ソフトは、データを平面に並べて一覧表示させて情報分析などをするためのものであって、本来目的が違います。表計算ソフトと同じようにデータベースを使おうとすると、多分すごく難しいと思う。Accessの操作が難しいのではなくて、Accessをどう使うか、というところでExcelと同じように使おうとするから、難しくなっちゃってるわけです。Accessの難しさを感じている人は、この点が一番ネックになってるのではないでしょうか。

こういう処理の場合は、テーブルをいくつかに分けて考えます。
やみ雲に分けるのではなくて、ちゃんとそれぞれのテーブルに「役割」を持たせるのです。

まず、「売上げたら1行追加される」テーブルを作ります。伝票番号と、日付と、どこのお客に売ったのか、名前がわかるようなテーブルです。

で、そのお客は、どこのお客で、電話番号が何番なのか、ということを知ることができるテーブルを別に作ります。

「顧客名」どうしをくっつければ、伝票番号000001は泪橋株式会社に4月2日に売り上げたことを表していて、泪橋株式会社は港区にあることがわかります。
どうやってくっつけるか、というのは、具体的なAccessの中の操作方法になりますから、後でお話しますけど、とにかくこうして、ひとつのテーブルに情報が集中しないよう、分けて、くっつけて、考えていくのです。

こういう場合、もしかしたら「全く同じ名前の顧客」が存在するかもしれないですよね。なので、できれば、右側の方のテーブルで「顧客番号」みたいなのをつけて、他のテーブルとくっつけるときは「顧客番号」でくっつけるようにするとよいかもしれませんね。こういうのを「主キー」って言うんでしたよね。

こんな具合に、ふたつのテーブルが、とあるフィールドの中の値を基にくっついて、ひとつの大きな情報のかたまりになるような様子を総称してリレーションシップと呼びます。リレーションって、機能とか操作のことじゃないですからね。「考え方」なのです。「伝票テーブルと顧客テーブルは、顧客番号で結びついて、どの伝票がどの顧客当てのもので、その顧客がどこの顧客なのかすぐわかるようになる」ということが、皆さんの頭の中でくっきりしていれば、それがリレーションシップです。

わけわかってないのにやたらとリレーションシップオブジェクトを作ってる人はペケです。そんなの全然リレーションじゃない。
リレーションって何？「関係」ですよ。ふたつのテーブルの関係を明確にしてあげることです。

でもって、000001の伝票の中で、泪橋株式会社に「何をいくつ売ったのか」を知るために、こんな感じのテーブルを作ります。

どのテーブルとどのフィールドの中身を基にくっつければ、「伝票番号000001でどの客に何をいくつ売って、その客はどこの客なのか」というすべての情報を網羅することができるのか・・・これがしっかり設計できるようになれば、Accessはとても使いやすいツールになると思います。
でも、これが全然イメージできず、どうしても表計算ソフトのイメージが頭から離れない・・・となると、Accessってすごく難しいです。Accessに限らず、「リレーショナルデータベース」と名のつくものに対して、多分不満をお持ちになるのではないでしょうか。

でも、こういう設計って、上級者でもほんとに難しいです。
いえ、上級者ほど、具体的に作り始める前の「設計」部分に時間を掛けてじっくり考えると思います。
すぐ理解しよう、と思っても無理なんです。。。。
なので、ちょっとずつ、小さなデータベースを作ってみて、少しずつ理解していくものなんだ、って思ってください。

身につけなくちゃいけないのは、操作方法ばかりではありません。テーブルをどうやって作っていったらいいのか、という「データの持ち方、考え方」も大切です。
どんな場合でも、決して「データベースを作ろう」とか「リレーションをしなきゃ」とか思っちゃいけません。やらなくちゃいけないのは皆さんのお仕事の業務をシステム化することで、Accessはその手段のひとつに過ぎないということを、絶対忘れちゃいけませんよ。リレーションをしたくてAccess使ってるんじゃない。お仕事をしやすく、便利にするためにAccessを使ってるんだということを、絶対に忘れないで・・・。