|
||
| <HOME <お願い事項 <Access2000 TOP <Access97 TOP <サイト内検索 | |
|
|
||
| MS-Access2002チョ〜入門部屋＞基本をマスターしよう | ||
で、改めて、1行ずつきちんとしっかりデータ入力された表を眺めてみると・・・。
「泥沼コーポレーション」あての注文、これ、ダブってるのか、追加注文なのか、どっちなんでしょう？
後になってもう一回電話がかかってきて、おつかいものにするから熨斗紙つけてくれって言われたんですけど、2回入力があるな・・・。
154個だったのを132個に訂正したのか、154個と132個で全部で、ええと、にひゃくー・・・154＋132個の注文があったことになるのか、どっちなんでしょう。この注文の電話を受けた人の記憶ももうおぼろげです。え？そんなこと知るか？
そうですよ。そうなんです。そんなこと聞かれても、MS-Accessには、わからないんです。
仮に、追加注文だったとします。「2月1日の泥沼コーポレーションからの辛口の注文」だけだと、154個の注文のことを言ってるのか132個の注文のことを言ってるのかわかりませんよね。「熨斗紙をつけるは、2月1日の泥沼コーポレーションからの辛口の注文154個」と、ここまで言わないと・・・。
まあ、ゼンゼンそういう必要がない場合もありますけれど、データベースに入力したデータは、後で検索したり抽出したりして使うことを前提にしてます。なので、できれば、ぱしっと一言でそのデータを言い表せるような項目があったほうがよいのです。だっていちいち「2月1日の泥沼コーポレーションからの辛口の154個の注文のデータ」とか言ってたら、じゅげむじゅげむになっちゃいますよ。それに、マジでデータがダブってたのだったら、えらいことになっちゃいます。
ここで大切なことは、結果としてデータがダブってたかどうか、ということではなく、データがダブって入力されるような可能性のあるテーブルなのかどうかということです。
あと、見た目の文字や数字としてのダブりというよりも、もっと業務に密着した、「甘栗注文受け付け業務として、ダブってるかどうか」と考えたほうがいいかも。
たまたま今、
「2月1日の泥沼コーポレーションからの辛口の154個の注文のデータ」と
「2月1日の泥沼コーポレーションからの辛口の132個の注文のデータ」と、
注文数が異なるので、まあこれを手がかりにして
「154個と132個、2回ご注文をお受けしているようですが、両方ともお熨斗紙が必要ですか？それともひとつにまとめてお届けしたほうがよろしいですか？」
みたいな感じでお客様とお話ができます。でも、これ、2回とも注文数が154個だったとしたら、なんかダブり入力くさいですよね・・・。
でも、ほんとに2回注文があって、どっちも154個で、熨斗紙が必要なのは最初に注文したほうだけ、だったとしたら、勝手にダブりと決め付けてはなりません。
こういうとき、皆さんならどう考えます？
わたしなら、「注文番号」みたいな項目をひとつ設けて、これをお客様にお伝えし、自分とこでも控えるようにすると思います。
続き番号である必要はありません。飛び飛びの番号になっても、それは問題ではないです。
注文が取り消される場合もありますからね。
誰か他の人の注文が取り消しになったからといって、「別のお客様でキャンセルがございましたので、先ほどのご注文の注文番号がひとつ繰り上げになって1218から1217に変わりました。ご注意ください」なんか言われたら、お客さん混乱しちゃいますよ。「通し番号」という意味ではなく、1行1行独立させてみたときに、それぞれ識別がつくような番号、という意味です。
それも、「この表の中で」。
テーブルを作って、そのテーブルの中に、どういうときにどういうふうにどんなデータが入ってくるのか（MS-Accessだとかデータベースだとかいうことはちょっと頭から離して）頭の中でシュミレーションしてみたとき、この「注文番号」みたいに、各行をばらばらにしてもちゃんと「その注文だ！」とぱしっと一発で指差せるようなフィールド・・・そして、「このフィールドの中の値は、絶対ダブらないから、大丈夫だよ」ってMS-Accessに約束ができるフィールド・・・それが、主キーにあたります。
だから、データベース的に物事を考えると、主キーって、必要なんです。でも、どっちかというと私たちのためではなく、MS-Accessのために、設けてあげるみたいな感じです。皆さんの都合ではありません。人間さまには、そんなにメリットがあるようには、思えないかもしれないですね。だから分かりにくいのかもしれません。でも、こうした意味合いがあるので、「ただ設ければいい」のではない、ということは、頭に置いておいたほうがいいですね。
当然、主キーにしたフィールドは、ダブりは許されません。
なので、たとえば「注文日」を主キーにしちゃったら、受けられる注文は1日1件になってしまいます。
「届け先」にしちゃったら、各顧客から1回ずつしか注文を受けられません。
「顧客一覧テーブル」とかだったら、顧客名がダブったらいけないでしょうが、「注文テーブル」でこれやっちゃったら、実際の業務と合わないでしょう。まあ、実際にほんとうに1回しか注文もらえないようなまずい甘栗だったとしたらそれでもいいのかもしれないですが・・・でも、結果的にダブってないというのとちょっと意味が違いますので、その辺を理解してください。
もちろん、主キーのないテーブルというのも、作ることができます。
どうしても主キーを設ける意味がわからないのであれば、無理につけるより主キーなしのテーブルにしちゃったほうがまだましかもしれません。表計算ソフトになれていると、逆にこの「一意」の考え方がわかりにくいかもしれませんね・・・。
退屈なお話が続きましたが・・・でも、MS-Accessを、きちんと「データベース」として使っていくなら、この考え方の理解は不可欠です。理解できなくても、単なるソフトウェアとして使い方を覚えることはできると思います。でも、せっかく使っていくのだから・・・・ぜひ、理解を深めていってくださいね。
ここまでお読みいただけたらば、「オートナンバー型のフィールドは、実際には主キーには不向き」というのも、なんとなく理解していただけるんじゃないかと思います。
オートナンバー型というのは、データ型のひとつで、新しくデータを入力するたびに、自動的に番号を採番してくれるという、MS-Accessにお任せのフィールドです。
本来は、どんな業務でも、主キーとなりえる項目って、あると思うんですよね。システム的に、ってことじゃなくて・・・。
今存在しているかということは別として、考え方として、さっきの「注文番号」みたいに、必要に応じて発生してくる項目だってありえると思うんです。
実際、どんな番号がついてもいい、というのなら、オートナンバー型でもいいのかもしれませんが・・・。これは、お好みかな・・・。
わたしは、「その行を識別するために、代表選手として設けるフィールドの内容を、MS-Accessに自動的に生成させる」っていうのが、ちょっと、気持ち悪いっていうか、なんかいやなんですよね・・・。
まあ、「ヤマダ電器さんの甘口18個の注文の番号は、1です」でいいんなら、別にいいと思いますよ。楽だし。
でも、オートナンバー型というのは、「一番最後につけた番号に1足した番号」を付けていくので、たとえば「ケロリン産業さんご注文取消し」で1行削除した場合、2は欠番になります。
もう、このテーブルで、注文番号2をつけることは、できません。オートナンバー型って入力できませんから。
だから、削除した行が使ってた番号をもう一度使いたいような場合は、オートナンバー型にしないほうがいいかもなーって、思うんです。でも、あんまりそういうことは、ないのかな・・・。
つまりは、主キーとはダブったらいけない、そのレコードを識別するための大切なフィールドなので、当然、「からっぽのまま」ってのはだめなんです。なんか入力しないとならない。でも、人間うっかりミスってありますよね。入力し忘れちゃった、なんてことがあるかもしれない。
MS-Accessは、みなさんがどういうお仕事なさってるのか知りませんから、「自分にとって」問題が発生しないようなデータ入力がなされればそれでいいんです。
「主キー」って言われてるのに未入力なのは困る、不本意だけど
こんなメッセージを出して、↑主キーなんだからちゃんと入力すれ!って言ってやらないとならない。
しかも、「あれー？なんだろうこのメッセージ。意味わかんない」とか言ったりしてる。おまえが主キーにしろって言ったから主キーにしたのに、何だその言い草は！！！って、思ってるかもしれません。
こっちだって好きでエラーメッセージなんか出してるわけじゃないわい！そんなに入力し忘れとかダブり入力とかをしょっちゅうやらかすくらいなら、俺が適当な番号付けちゃるからオートナンバー型にせいや！って、そういう感じかなーって、わたしは思ってます。
データベースというものを理解していて、業務の分析ができていれば、主キーは必ず必要になってくるし、なんで主キーは必要なの？なんていう疑問は逆に沸かないはず。わざわざ注文番号に主キーを設定するのではなく、このテーブルの中では注文番号を中心にデータが入ってくるので、注文番号を主キーにしようって、そういう視点で見たほうがいいですね。
さて・・・そういう感じで考えてみると、今作りかけのこのテーブル、どれが主キーにふさわしいでしょうか。
社員の一覧です。
同姓同名の人もいるかもしれません。
じゃあ・・・「社員番号」かな。。。
社員の一覧を作る場合、社員番号って、ダブりますかね。。。多分、ダブんないですよね。
んでは、社員番号の行にカーソルを置いた状態で、ツールバーの「主キー」ツールボタンをクリックしましょう。
さあて、ここまで、オッケーですか？
主キーに関しては、これだけ覚えようと思ってもなかなか理解が深まらないと思います。
焦らずに、いろんなサンプルとか見ながら、じっくり理解をしてってください。
でも、主キーというのは、決して「データベースというものを学問的に捉えたり、データベースソフトの使い方として考えられた」ものではありません。
根底には、皆さんの会社や学校の中にあるいろんな情報の集まりをきちんと分析した結果、自然に発生してくるものです。
では、このテーブルを保存しましょう。
デザインビューと名のつくものは、オブジェクトを設計して作成するための画面なので、今このウィンドウの中に出来上がっているものは、言わば「仮作成状態」なわけです。
これに名前を付けて保存することで、初めて「テーブル」というオブジェクトがひとつできあがります。
んでは、保存の方法を・・・といっても、まあ、案外適当に作業しててもちゃんと保存する機会は与えてくれます。
スタンダードな方法としては、左上のフロッピーディスクのツールボタンをクリックするってことです。
後は、強引にこのデザインビューのウィンドウを閉じようとすると、保存するかどうかメッセージが出てきますので、そのとき「保存する」って指定してやってもいいかもしれません。
まだ名前を付けてない場合は、こんな↓感じのダイアログボックスが出てきます。
んじゃあ、「社員テーブル」ってつけましょうか。月並みですけど。
さっき「名前付け規則」って、確認しましたよね。記号とか使いたい場合は、もう一度ルールを思い出してみてくださいね。
名前を付けることができたらデザインビューは閉じて（あるいは閉じられて）、データベースウィンドウに戻ってまいります。
はあ〜。できましたね。
以上が、テーブル作成に関するいろいろです。
テーブルつくりがパシッとできると、後の作業はすっごく楽です。逆に、テーブルがよたよただと、すごく大変です。
なかなか、よりよいテーブルつくりは難しいんですけれど、がんばりましょうね。
 |
|
 |