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

漕げよマイケル　データベース作成　3_1

先に進む前に、このページではでちょっと、「業務分析とデータベースの設計」という話から離れまして、MS-Accessの中の機能などをちょっとだけおさらいしておこうかな・・・と思います。
目新しいお話は何もないですが、よかったら読んでってください。

マイケルは、誰でも簡単に売り上げの入力ができるように、また、後で売り上げ集計をするとき混乱しないように、均一な入力ができるように、いろいろ考えて、売上のテーブルに「商品番号」が入るようにしました。

これは、売上入力のフォームの「商品名」入力のところの、「商品名」のコンボのプロパティをどう設定するか、で、調節ができますね。
プロパティの「連結列」を１にするか２にするか（1列目か2列目か）で、テーブルの中に「商品番号」が入るか「商品名」が入るか決まるわけですから、ここの設定をしっかりやっておけばいけるはずです。
コンボボックスやリストボックスは、こうした「ちょっとしたリレーション」の場面で活躍するコントロールですので、仕組みや役割、プロパティなどをしっかり理解しておくと便利ですよ。ヘルプをチェックしておくといいでしょう。

売上テーブルには、こんなふうに↑商品番号が入ります。

でも・・・こうなると、「商品名」っていうフィールド名だと、なんだかんだと誤解を生みそうですよね。
フィールド名、変えちゃおうかな・・・。

データシートビューでも、フィールド名を変更することはできますよ。
フィールドセレクタをダブルクリックして、直接入力してみてください。

変更できたら、ツールバーの上書き保存ボタンをクリックして、閉じます。

と、ですね。
売上入力フォームの、コンボボックスのコントロールソース欄も、変わってるはずなんですけどね。
チェックしてみてください。
コントロール名は「商品名」のままですが、「コントロールソース」は、「商品番号」に変わってると思います。
Access2002を普通に使ってる方ならこうなってると思います。


これは、「名前の自動修正」という機能が働いているため、です。メニューバーの［ツール］→［オプション］の中に、このパソコンにインストールされているMS-Accessの基本的な動作設定をするところがありまして、この中で設定する機能です。

ヘルプで調べてみると、

名前の自動修正 : フォーム、レポート、テーブル、クエリ、またはフィールドの名前や、フォームやレポートのコントロールの名前を変更するときによく起こる副作用を自動的に修正する機能です。 ただし、名前の自動修正では、名前を変更したオブジェクトへの参照をすべて修復することはできません。

ということです。

つまり、うっかりミスを減らそうという配慮なんですが、これが逆に災いして、いつまでたってもコントロールとコントロールソースの関係が理解できずイージーミスを繰り返してしまう人、結構いるんじゃないかと思うんです。
あくまでもお助け機能なので、これに頼りすぎず、テーブルやクエリとフォームの関係をしっかり理解して、わけのわかんない状態に陥らないようにしてくださいね。

で、改めて「売上テーブル」をデータシートビューで開いてみると・・・。

なんか、さっきと「並び順」が違うような気がしません？
これは改めてお話しすることでもないかもしれないんですが・・・。

「商品名」→「商品番号」にフィールド名を変えたため、「商品番号」というフィールドに「インデックス」という設定がされたのです。
そのため、「商品番号順」に並んで表示されてるわけなんですね。

データベースでは、「テーブルを直接開いて中身を見る」という感覚はほとんどないので、あんまり気にする必要はないんですけどね。
でも、「なんかおかしくなった！！！」「こわれた！！」「バグですか？？！！」と騒ぐ人がたまにいたりするんで・・・仕組みは理解しておかないといけないとは、思います。
前にも申しましたが、リレーショナルデータベースで「テーブルの中でのレコードの並び順」ってほとんど意味をなさないので（そこが表計算ソフトと違うところ）この感覚になじめない人は、ソフトウェアの操作方法を覚えても、根本的にデータベースを扱うのはキツイかもしれないですね。

皆さん、今お財布お持ちですか？ちょっと中を確認してみてください。いや、何も盗りませんよ。
マイケルも財布出してごらん。ほら、早く出しな。なんだいその目は。なんか文句あんの？

お財布の中に入ってるお金、どういう順番で財布に入ってきたか、財布開いてぱっと見てわかります？
その１０円玉は、その財布の中にある小銭やお札やレシートの中で、何番目にその財布の中に入ってた１０円玉ですか？
一番右端にある１円玉が、一番最初にその財布に入ってきた小銭ですか？
というか、財布の中にどういう順番でどのお札が入ってきたか、なんて情報、必要ですか？
データベースも同じです。
そういう、「皆さんのお財布とお金の出し入れ」に近いイメージのお仕事に、MS-Accessを用いるべきですね。
でも逆に、そのままプリントアウトして使うような表とかリストとかだと、１行１行の内容以上に「何行目にどの項目が印刷されて出てくるか」という、レイアウト面が重要になってくるんだと思います。そういうお仕事には、MS-Excel使ったらどうでしょうか。

MS-Accessの場合、「データシートビュー」ってものがあるので、「MS-Excelとどう違うの？」なんてぬかしよる人も結構いるんですが、データシートビューはテーブルの中のデータを確認するための１手段であって、テーブルの姿そのものではありませんからね。


お話を元に戻しまして、インデックスとは「索引」という意味で、本の後ろについている「索引」と同じ役割を担います。
ほら、分厚い解説書なんかだと、巻末に「あいうえお順」とかでキーワードが並んでて、すぐに該当のページを探せるようになってるじゃないですか。まさにあれのことです。
並べ替えや検索をすることが多いフィールドに対して、あらかじめ「そのフィールドごとに並び変わっている一覧」を用意しておくんですね。

テーブルデザイン画面で、「商品番号」フィールドのプロパティを見てみると・・・。

「インデックス」が「はい（重複あり）」になってますね。
これが機能して、このテーブルを単に開いた場合（データシートビュー出開いた場合、ですかね）は商品番号順に並び変わる」ようになったわけです。「重複あり」というのが何か、わかりますよね。重複してますよね。商品番号。
一度注文した商品が二度と注文できない・・・というお店ではないですもん。マイケルの店は。

じゃあ、このプロパティ、いつ設定されちゃったのか・・・という話なんですけどね。
これも、オプション設定の中にあります。
さっきご覧いただいた、メニューバーの［ツール］→［オプション］の中です。

つまり、　○○ID　とか　○○番号　とか　○○コード　とかいうフィールド名前をつけると、それはきっと検索とか並べ替えとかによく使うフィールドだろうからインデックスを作っといてあげよう！という、MS-Accessのおせっかい心遣いなのです。

インデックスを設定すると、並べ替えや検索が速くなります。
皆さんだって、解説書や百科事典の中から調べたい事柄を探すとき、１ページ目から順番に探すより索引を見たほうが早く探せますでしょ。
コンピュータもやってることは同じようなもんなんです。
だから、よく検索に使うフィールドには、インデックスが設定されていたほうがいいんです。
そのフィールドにどういう値がどれくらいの割合で入力されているのか、にもよるので一概には言えないんですがね。インデックスつけてもあんまり意味のない場合も、考えられますので、インデックスがどういう時どういう効果を発揮するか・・・は、そうとうリレーショナルデータベースに詳しくならないとなんとも言えないんです。

でも・・・最近のパソコンは性能もいいし、スピードも速いし・・・それに、1000件2000件くらいのレコード件数では、あまり「うわー！インデックスつけたら速くなったよ！！！」なんて実感、あんまり湧かないと思います・・・。件数だけの問題じゃないとは思いますが・・・。なので、あんまり目くじら立てて「インデックスインデックス」と言わなくても、問題はなさそうな気がします。

ただ、今お話したように、フィールド名のつけ方如何で自動的についちゃいますので、その点は承知しておいたほうがいいかもしれませんよね。

ついていても、別に気にすることはないのですが、インデックス設定した分、mdbのファイルサイズは大きくなります。まあ、テーブルに1列増えたみたいなもんなので、当然といえば当然ですけどね。本だって、巻末に索引があれば、索引の文だけページ数が増えるでしょう？同じこってす。

データベースの設計をするとき、いきなりテーブルを作り始める前にいろいろと「データモデリング」みたいなことをやらなくちゃならないのは、こういうところがなかなか見えてこないからなんですよ。
業務全体を見直してみないと・・・。

後からフィールド名を変更する、なんて、あまり好ましいことではないです。
今回だって、コンボボックスのコントロール名は「商品名」のままですよね。
これ変更すると、それこそあっちこっち影響が出そうな気がしません？

こんなことやってたら作業が増えるばかりです。
さらに、売上のテーブルに、だいたい何件くらいデータが入ってきそうなのか、概算ができてないと、インデックスが必要なのかどうなのかも予測がつきませんしね。


なんにしても、テーブルのデザインを後から変更するってのは、あまり好ましいことじゃないので、できるだけ最初に、ほかのオブジェクトを作り始める前に、フィールド名と主キーとインデックスあたりは確定しておけるように・・・しておきたいものです。
そして、ウィザードや、その他の便利機能に頼り過ぎないこと。これもポイントです。
基本をしっかり理解していれば強い味方になりますが、わけわからないままだと腹立たしい存在でしかありません。
フォーム、テーブル、クエリ、テキストボックスなど各種コントロール・・・これらはみんな「名前」で結びついているということ・・・
これらをしっかり認識しておくとよいと思います。