<HOME　　<お願い事項　　 <Access2002 TOP　　　<Access2000 TOP　　　<サイト内検索
Access97データベース工作室＞郵便番号の検索

横道おしまいです。ここから、都道府県、市区町村による絞込検索の仕組みを考えます。

では次に、ちょっとテーブルの中身について考えてみようと思います。

まず、下の表を見比べてみてください。どこにでもある売上表です。

左の緑色の枠の方の表は、ひとつの表の中に全部の情報を格納します。これがフツウかな・・・。
で、右の方は、ふたつの表に分けて考えています。

売上を立ててるメンツは、きつねとかえるといぬとたぬきなので、まず４人の名前と番号を書き並べたテーブルを作って、オレンジ色の表の方は、各メンバーの番号と、売上日、売上金額を並べるようにしています。
００１が誰かってのは、青い方の表を見ればわかりますから、いちおうこれで役割は果たしますよね。

左の緑色枠の方の表と、右の２つの組み合わせの表、違い、おわかりいただけますか？

今、見出しの部分を除いてデータが１４行ありますんで、左の方の表のマスメの数は５６個。
一方右側は３×１４＋８で、５０個のマスメがあります。

別に対した違いはないですよね。
苦労してメンバー表と売り上げ表と分けましたけども、いったいこれにどんな意味があるっていうんでしょう。

じゃ、１ヶ月たって、４人のメンバーが毎日たくさん活動して、表を広げて見たら５００行データが書き込まれていたとします。
すると、左の方は５００×４で２０００のマスメがあることになります。右の方は５００×３＋８で、１５０８個のマスメ。
ずいぶん差が出てきましたね。

左の方の表をよく見ると、メンバーの名前の部分、きつねとかかえるとか何回も何回も登場しますよね。
ここの部分をうまくまとめたのが右側の表なんです。

まとめてみて、メンバー表と売り上げ表を二つに分けることによって、同じ内容の情報を格納していても、右と左ではマスメの数にかなりの差がでます。
マスメの数＝データ容量というわけにはいかないですけれど、大きなテーブルだったら、明らかに右側の考え方を実行する方がデータ容量は軽く押さえられるはずですよね。

と、いうことは、それだけ入力も少なくなるわけですし、そこから生まれるメリットは数多くあると思います。

これがリレーション･シップの始まりです。

上の表の例でいくと、左はカード型データベースや表計算ソフトの考え方、右はリレーショナル･データベースの考え方。
どっちが正しいということではなくて、利用するソフトウェアによって、右の考え方なのか、左の考え方なのか、変ってくるということですね。
Accessはもちろんリレーショナル･データベース。右の考え方がぱっと思い浮かぶ人向けのソフトウェアなのです。

もちろん左側の考え方でも、Accessを使ってデータベースを作ることはできますけど、できればうまくAccessの特性を生かして使っていきましょう。

さて、下の表を見てみましょう。

じっと見てると毒キノコになっちゃいそうですけど、とりあえすじっくりと［郵便テーブル］を観察してみましょう。

なんか、うまくまとめてテーブルを小分けできないもんですかねぇ。
１４万件ですよ。なんかもっとコンパクトにできないもんか、ちょっぴり時間をかけて考えてもバチあたんないと思います。

ぜんぜん小分けできる要素が見当たらないテーブルじゃしょうがないですけど、なーんかありそうじゃないですか？
だって、ホッカイドウとか北海道とか、なんかおんなじような言葉がいっぱい繰り返し入ってるフィールドもあるし・・・

都道府県の名前は、都道府県テーブルっていうのを別に作ってやってけないでしょうか。都道府県はとりあえず４７。
あんちょこにマスメの数で考えてみて、マスメの数、かなり減らせるような気がしません？
ピンク色で囲ってるところ、都道府県関のフィールドですよね。どうでしょう。イメージ湧きません？

さらに市区町村。「札幌市中央」って、めちゃめちゃたくさん出てきますよね。
きみどり色の部分が、まとまって同じ情報。これもなんかまとめられないですかねぇ。

あ、Accessで「マスメ」とか言うと、専門家に怒られちゃいますね。ここだけの話ですよ。

じゃ、［都道府県テーブル］［市区町村テーブル］［地区テーブル］の３つにテーブルを分けて、都道府県コード、市区町村コードみたいなコードでうまくつながりを持てるような構造を考えてみましょう。

まず、［都道府県テーブル］を作りましょう。どうやって作るかと申しますと、こういうとき活躍するのがいわゆるひとつのテーブル作成クエリーです。

こういうとき使わなくっちゃぁ。

まず、［郵便テーブル］を基にして、ふつうのクエリーを作りましょう。ええと、［都道府県カナ］と、［都道府県］ね。
うーん、カナはいらないかなぁ。。。まあ、いいか。多少の無駄もご愛敬ということで。

で、ちょっと見てみますか。

わはははは〜。
はっきり言ってこれじゃなんにもなんない。北海道だらけだ〜

これじゃだめ。まだ未完成です。デザイン画面に戻りましょう。

こういうとき、役に立つプロパティがあるんですよ。クエリーにもね、ちょっとですけどプロパティがあるんです。見てみましょう。「固有の値」っていうやつなんですけどね。

選んだフィールドの値をずーっと見てみて、重複しているものはいっこだけ表示して後は表示しないって感じになります。

じゃ、改めて実行・・・今度はちっと時間がかかるかもしれません。

と？いかがでしょう。それっぽくなってきましたよね。
んー・・・でもまだなんか変だな・・・。
よく見てみると、都道府県のカナのあるやつとないやつがあるみたい。
で、９４レコードになってます。

あ、そうだ。事業所のテーブルを追加しましたからね。
あっちは都道府県のカナのフィールド持ってないテーブルだったから・・・。

どうしよう・・。

都道府県のカナがからっぽのやつは対象外にしてやれば、何とかなるんじゃないでしょうかね。

そのためには、カナの抽出条件の欄に、こんな風に入力します。

not null （入力後、表示が自動的に Is Not Nullになります）

Nullというのは、「空白の、使われてない、文字の入力のなされた形跡のない」という意味で、ブランクやスペースと、ちょっと違った意味合いなんですけど、とにかく何にも入力されてない状態を除く、という意味になります。

で、どうかというと？？？
おー。ちゃんと４７都道府県を一回ずつ表示するクエリーになりましたね。

で、ここから先なんですが、もし、
「都道府県の表示がアイウエオ順になっていた方が探しやすいわ」
ということなら、これこのままテーブルにしちゃえばいいでしょう。

でも、どうですかねぇ・・・。

［郵便テーブル］は、北海道から始まってましたよね。
北海道→東北→関東甲信越→東海・・・と、なんか北の方から順に県名が並んでいるような気がします。
ぽすたるがいど（郵便局においてある郵便番号の一覧表）もそんな感じの並び順で書いてあるし、アイウエオ順よりその方がわかりやすいですよね。

うーん、どうすればいいのかな・・・。