<HOME  <お願い事項   <Access2002 TOP   <Access97 TOP   <サイト内検索
 MS-Access2000超入門部屋--基本操作を考える
データベース テーブル フォーム クエリー レポート マクロ&仕上げ
1 1 2 3 4 1 2 3 4 5 6 7 B 1 2 3 4 5 6  8 1 2 3 4 5 1 2 3 4 S



■テーブルを作る 4■

さて・・・。入力の雰囲気、大体つかんでいただけましたですか?

ここで、ちょいとばかりややっこしいお話をします。「主キー」というお話です。

今まで、例えば汎用機とかUNIX系マシンなどで、データベースを操作していた方なら、キーやインデックスというものの存在はごく当り前でしょう。
ですが、表計算ソフトを中心に使っていた方から見ると、「主キーって何のために作るの?」という疑問が常に頭にあるんじゃないかと思うんです。

少々乱暴な解説になってしまいますが、データベースに「主キー」たるもの当り前であると、いちおうそう思ってください。
その上で、主キーについてお話をします。
あくまでもこれは「操作方法」じゃなくて「考え方」なので、皆さんなりにゆっくりと考えて、身に付けていってください。


データがいっぱい入りました。

Accessのテーブルには、データの件数の限界というものはありません。

このテーブルのサイズが1GB以内であれば、何万件でも入力できます。

(mdbファイルのサイズの限界が2GBなので、最終的には他のテーブルとかも含めたサイズを見てかなきゃなんないですけど・・・)
すごくざっくりした値なので、実際には下のテーブルにあと何件データの入力ができるのか、お釈迦様にもわからないです。

あ、わたし、ずっと「データ」というあいまいな表現で解説書いてきちゃいましたけど、この言葉のちゃんとしないといけないですね。
上の表、もう一度じっくり見てください。

「社員番号」「名前」「所属」「売上」「くさや」というのが、テーブルを構成している「フィールド」というやつですね。
で、このテーブルには今、12件データが入力されてます。

この1行分のデータのことを「レコード」と呼びます。このテーブルには12レコード入ってます。

で、このテーブルにあと何レコード入力できるかは、テーブルサイズが1GB以内ならオッケーなので、実際には細かいところまではわからないってことですね・・・。
このくらいのサイズのテーブルなら、500万件くらいはいけるんじゃないですかねぇ。すっごい適当ですけど。
まあ、パソコンのディスク上で1GB以上のファイルを維持/管理することに抵抗がなければ、Accessとしては何万件レコードが入力されてもどうってことないです。
パフォーマンスとかも、遅くなったりとかそういうことはほとんど気にしするひつようないと思います。

それは、Accessが「レコード単位」で処理をするように考えられてるからです。

1件レコード追加している間とか、レコードの内容を書き換えてる間とか、左端にエンピツマークが出てるの、確認いただけますか?
ためしにもう1件追加してみてください。
入力は中途半端でも結構です。あるいは、今までに入力したレコードの、売上金額をちょっと変更するとか。
書き換えると、左端のねずみ色の部分にエンピツマークが出ると思います。

つまり、テーブルはびよんと開いてますけど、わたしが使ってるのはこの1レコードのみ。
仮に、他の人が他のパソコンから、何らかの形でこのテーブルを開こうとしたとき、特別な場合を除いて、他のレコードは自由に見たり書き換えたりすることができるんです。

また、今、上の図だと、0013のオジーさんのデータは入力が途中ですけど、この状態でテーブルを閉じたとしても、上のこの中途半端な入力状態が残ります。
テーブルの中のデータは、入力した瞬間にテーブルの中にもうインプットされますので、閉じるときの保存とか、そういうことを考える必要はないんですね。
これもレコード単位でデータを考えてるから。このテーブル全体が1単位ではないんです。


普段、テーブルが閉じてるときは、テーブルの中のレコードは、ばらばらになってます。っていっても、別に無理やりばらばらになってるわけじゃないんですけど・・・レコード単位で保存されると考えてください。すなわち、必ずしも、入力順にレコードが並んでるわけじゃない・・・。あ、でも、別に下のようにわざとらしく保存されてるわけじゃないですよ。あくまでもイメージです。

で、このばらばらのレコードが、こちらの思惑通りに整列するためには・・・基準となるフィールドが必要になるんです。
入力順にしたいのなら、入力した順番を何かしらの番号で残すとか。

そのテーブルの中でダブらない値・・・。それが「主キー」です。

で、社員番号というフィールドを主キーにしてると、同じ社員番号を持つ人はこのテーブルの中に複数存在できないし(基準になるフィールドですからね)テーブルが開いてきたときぴしっと整列もする。

厳密には並べ替えをするためだけに設定するもんじゃないんですけどね。
実際、レコードの並べ替えとかには「クエリー」というオブジェクトを用います。
なので、結局、そのテーブルの中に雑多に並んだデータ群を、何を基準にして捕らえたらいいのか、Accessに知らしめてやるもんだと考えてみてください。
実に内部的なもので、わたしたちには一見メリットがないように思えますけど、主キーのないテーブルほど、データベースの中で不安定なものはないんですよ。

だから、別にそのテーブルの中のデータがどういう順番でどういう風に処理されようが、ただデータ入力して突っ込んどくだけだから、とかいう場合は、主キーなんてうざったいだけかもしれません。主キーなどというものを定めることができないようなごった煮テーブルを作らなきゃならないことも、たまにはあります。
でも、テーブルっていうものは、中にはある一定の約束事に基づいた意味のあるデータが入ってくると思います。
「社員テーブル」だったら、社員の情報が入りますよね。
400人いたら400件。その中で、同じ社員番号を持つ社員が二人以上いたら、このテーブルの意味合い自体ヘンです。
「社員番号」を基準に、このテーブルは構成されるべきなんです。

それを見定めて、その値を主キーとして設定してやります。
それが、レコード単位で処理をするAccessの基本的なデータの考え方。ここまでわかっても、でもやっぱり主キーの意味がわからないや・・・という方もいらっしゃるかもしれません。あとは少しずつ体験の中で見出していってください。

でも、基本的には、テーブルにとって必要なことなんですよ・・・<主キーは、ね。


では、主キーの設定です。

繰り返しますが、主キーとは、そのテーブルの中で基準となる値を持つフィールドです。

具体的には、「そのテーブルの中で値がダブらないフィールド」です。

このテーブルの中には今、12件しか入力されてないですけど、これが、月日が流れてたくさんの社員がこのテーブルの中に集まってきたことを考えてください。
このテーブルの中の、値の最小単位って、なんでしょう。
「社員番号」じゃないですか?

まあ、「名前」でもいいんですけど、同姓同名の人が来たら、どうします?
「トミー・ショウ」っていう人が入社してきたら、同姓同名だから0008の社員番号を使ってもらいます?
同姓同名でも、社員番号は違いますよね。同じっていう会社、あります?ないですよね・・・。多分。

じゃあ、あとで作ってもらった「商品テーブル」はどうでしょう。
まだぜんぜんデータ入れてないんで、どういうデータが入ってきて、どのフィールドを基準に考えていけばいいのか・・・ちょっと考えてみてください。

つまり・・・テーブルを設計するとき、おのずと「主キー」となるべきフィールドは決まってるはずなんですね。
これを見極められるようになると、データベースなんてどうってことないですよ。
でも、これがイマイチわからず、いつも適当・・・となると、データベースというものそのものを使っていくのがちと苦しいかもしれないですね・・・。


では、主キーの設定をしましょう。どのフィールドがどうして主キーなのか、その辺わかっちゃえば、操作はたいしたことないですよ。
デザインビューに切り替えましょう。デザインビューへの切り替え操作は、もうオッケーですよね。切り替わりました?

「社員番号」のところにカーソルがあります?
その状態で、「主キー」ツールボタンをクリックします。何回かクリックしてみてください。

と・・・カギのマークみたいなのがついたり消えたりすると思うんですけど・・・。
ついてるときは、そのフィールドが主キーであるということ、消えたら、主キーの設定を取りやめたことになります。

これでおしまい。保存をして、閉じましょう。同じように「商品テーブル」の方も、主キーの設定してみてください。
どのフィールドが主キーか、は・・・みなさん、大丈夫ですよね。

繰り返しになりますけど、主キーになってるフィールドは、入力した値がダブってはいけません。
だから、どのテーブルでも必ずしも「社員番号」が主キーになる・・・ってわけじゃないです。
それは、テーブルの役割、テーブルの構造によって違ってくるはず。
このテーブルは、同じ社員番号を持つデータが2レコード以上入らないことがわかってるから、社員番号を主キーにしたんです。

主キーの設定したフィールドに、ダブったデータがあった場合、情け容赦ないエラーメッセージが出てきます。

・・・と、いう場合のために・・・ということで、「オートナンバー型」っていうデータ型があるにはあるんですけど・・・
わたしは個人的には、このデータ型、あんまり使いません。その辺は、また別の機会にお話できれば、と思います。


さて、テーブル作成の基礎は、こんな感じです。
だいたい、段取りと役割、イメージできました?
いっぺんに覚える必要はないですけど、テーブルってなんだっけ??ってことになると、先がきついんで・・・。
役割だけでも、言葉で説明できなくってもいいですから、なんとなくイメージできるように・・・ちょっと一息ついて整理整頓しておきましょう。

で、改めて、データベースウィンドウに戻ってまいりました。
テーブル、相変わらずふたつありますよね。

例えば、「商品テーブルはもういらないから消したい」という場合・・・。
基本的に要らないものは使わなければいいので、無理に削除することはないんですけど、どうしても消したい場合は、消したいオブジェクトをクリックして選んだ後、キーボードのDeleteキー押してください。
あ、データベースウィンドウの上のほうに、おもいっきし「×」っていうツールボタンがありますね。これをクリックしてもいいです。

と、いちおう確認メッセージが出てきます。[はい]の方をクリックすると、商品テーブルはこの世からなくなります。
間違った〜〜〜というときは・・・メニューバー[編集]→[元に戻す]で何とかなりますが、基本的に消えてしまうものだと考えてください。
まあ、使わないオブジェクト残しといても、別にどうってことないですよ。


さあ〜。テーブルだけではなんだか寂しいので、次は「フォーム」作りに挑戦してみますか!
がんばりましょう♪