<HOME  <お願い事項  <Access2002 TOP   <Access97 TOP   <サイト内検索
 MS-Access2000超入門部屋--料理レシピ集を作る
  1 → 2 → 3



では今日は「料理レシピ集」を作りましょう。
え?そんなデータベース必要ない?
いいえ、きっと必要です。いいから。必要でなくても何かと練習になりますから。

えーと、どういうのを作るかというと・・・。
まず、料理名の一覧が出てきて、どれかひとつ選ぶと、必要な材料と料理の手順と1人前のカロリーが表示される・・・。
と、こんな感じではどうでしょう。
まあ、なんか別のデータベースに利用できる操作方法とか出てくるかもしんないから、挑戦してみてちょ。

じゃ、ここから自由行動です。

・・・それじゃだめなのか。んじゃ行くぜ!ぬかるんじゃねぇぜ!




この手のデータベース作りでもっとも重要なポイントは「テーブルの設計」です。
いきなりテーブル作り始めないで、まずはいろいろ考えてみましょう。みなさんはテーブルの全体像を頭の中でイメージしてみてください。

まず、↓料理の名前のフィールドが必要ですよね。

で、後で「検索」できるようにしたいなぁなんて思ってますので、このテーブル全体で「各料理に異なる番号」をつけたいと思います。いわゆる主キーですね。みなさん、「主キーって何で必要なの?」とか、そんなこと思ってないですよね???

で、その料理の材料と分量を入力するフィールドが必要ですね。えーと、

・・・。こんな感じ?

分量は、「g」とか「個」とか、単位まで入れたいんで、あえてテキスト型にしてみました。
とりあえず足し算したり掛け算したりする必要ないかなと思ったんですけど、どうでしょうね。材料を4倍にするとか4分の1にするとか、そういう必要性も出て競うでしょうかねえ。まあ、おいおい考えるとしよう。

手順が3段階あるので、[手順1][手順2][手順3]と3つフィールド作って・・・。

こんな感じかしら。
そんで、2件めの料理を入力してみるとすると・・・。

あ・・・。
サメうどんは材料が4種類いるんですけど、入力できないじゃん。
こ、こんな感じかな↓・・・。

うーん、こういう考え方でもできないことはないと思いますけど、こういうテーブルがよいのなら、Excelみたいな表計算ソフトの方が絶対楽ですよ。
Accessのような、「リレーショナルデータベース」という考え方を持ったデータベースを使うなら、「料理名」のテーブルと「材料」のテーブルと「手順」のテーブル、3つに分けて作りましょうよ。

Access以外のデータベースでも同じことですが、「横方向に情報が伸びちぢみするテーブル」というのはあんまし作らないです。作れないというのと意味違いますよ。データベースでは「縦方向に伸び縮みする」ように作るのがベストなんです。その方がね、データベースとしての真価を発揮できるんですよ。
今回の場合、「材料」は、料理によって4種類だったり2種類だったりするわけですよね。15種類くらい使う料理もあるかもしれない。こういう情報は横に並べないで縦につむように考えていくといいでしょう。

たとえばこんな感じ。↑
テーブルだけ見てると、なんだかよけいややっこしそうですけれど、こうやって作ることによってとても合理的で間違いの少ないデータベース作りを実現することができるんですよ。

ピンクで囲った部分が、ひとつの料理の材料ですよね。これ、必ずこの順番で出てきてほしいですよねぇ。
たとえばレポート作ったりフォーム作ったりしたとき、必ずしも「入力した順番」にレコードが出力されてくるとは、限らないんです。データベースって言うのは、表のイメージでデータを捉えますけど、一枚の大きな表があるわけじゃないんですよ。だからね。「こういう順番に並んで出てきてもらいたいんだが」という指示ができるようなフィールドを設けておくんです。

たとえばこんな感じかな・・・。↑

特に他のテーブルとかかわりを持たない、このテーブルの中だけのフィールドなんで、オートナンバー型とか使っちゃってもいいかもしれないですね。
オートナンバー型にしとこうかな・・・。うーん、どうしよう。まあいいや、あとで決めましょうかね。

で、ここでもう一工夫・・・。

単位なんですけど、「g」とか「玉」とか単位を書き添えたいけど、分量を4倍したりとか計算もさせたい、しかも材料によって単位はまちまち、なんて時は、こんな方法はどうでしょう。[単位]ってフィールド設けるんです。[分量]と組み合わせれば、「150g」って表示させることできそうじゃないですか?


料理の手順の方も同じようなイメージですね。

これなら、こみ入った料理も簡単な料理も入力できそうでしょ?
こういうテーブルどうしの結びつきを「1対多の結びつき」って言いますね。

[料理テーブル]の1レコード(たとえば番号が00000001のレコード)に対して、[手順テーブル]に手順が4レコードあります。だから1対多(4)。
[料理テーブル]と[材料テーブル]の結びつき方もおんなじ考え方ですよね。
んでもって、こういうテーブル同士の結びつきをきちんと考えてやることを「リレーションシップ」というのです。

こういう場合、[料理テーブル]は[番号](料理名でもいいんですけど、漢字とかひらがなよりは半角英数字で統一した方がコンピュータにとってありがたいと思いますよ)を基準に結びつきます。[料理テーブル]に00000001が2件入ってしまったら、[手順テーブル]の00000001の4件は、いったいどっちの料理の手順なのか、わからなくなってしまいますよね。
データベースとかAccessとかそういうこと抜きにして、人間として、[料理テーブル]に00000001が2件以上存在するのはおかしい、と、思いません?

こういう状態に陥らないよう、[料理テーブル]の[番号]にダブったデータが入ってこないようにします。
といっても、気をつけて入力するとか、そういうことではありません。「ダブらないよ」って、[料理テーブル]と約束をしてください。破ったらハリセンボンです。
といっても口約束では困ります。信用できません。

そこで、[料理テーブル]の[番号]を主キーにするのです。

主キーにすることで、[料理テーブル]に対して「[番号]ダブって入力したりしないからね」って保証できたことになるでしょう?
こういうのはですね。結果的にダブらなければいい、ってもんじゃないんです。主キーとはそういう意味合いも含んでいるんですよ。
ただ闇雲に主キーの設定をしたりリレーションシップの設定をするんじゃいけませんよ。机上の学問として捉えず、データの中身と業務内容を照らし合わせながら理解を深めていってくださいね。
学問として理解できる人はそれにこしたことはないですが、主キーにしてもリレーションシップにしても、結局は「データを効率よく管理するため」のものですので、ただややこしくなるだけならいっそのことない方がいい。そうならないように理解をしていってください。


ここでもうひとつ、認識を深めておいていただきたいのが、AccessのテーブルとExcelのワークシートはぜんぜん違うものである、っていうことです。
[ナンバー]とか[手順]って、1,2,3,4・・・って続き番号が入るようなフィールド作りましたよね。といっても、続き番号が入るように考えて入力する、っていうことですけど・・・なので、当然ですけれど、1レコード削除したとしても、都合よく書き換わってくれるもんじゃありません。

ここでひとつ、認識を深めておいていただきたいのが、AccessのテーブルとExcelのワークシートはぜんぜん違うものである、っていうことです。
[ナンバー]とか[手順]って、1,2,3,4・・・って続き番号が入るようなフィールド作りましたよね。当然ですけれど、1レコード削除したとしても、都合よく書き換わってくれるもんじゃありません。↓

Excelのように、1枚の表があるわけじゃないんで、必ずしも↑こんなふうにいつもレコードがくっついているわけじゃないんです。
だから、「前のレコード削除したから、[手順]が3から2に書き換わってもらいたい」なんて考え方や機能は、データベースにはありません。「行番号」みたいな、表示上の番号を持ちたいときもたまにありますけど、基本的にデータベースというものはレコード単位で物事を考えますから、欠番が出たからといってテーブル全体で通し番号を振りなおすなんて考え方はしないです。
Excelのオートフィル機能みたいなのをデータベースに望まないでくださいね。ああいう操作をしたいならExcel使った方がいいでしょう。


では、作り始めましょうか。


料理テーブル↑


材料テーブル↑


手順テーブル↑

テーブルの構造はこんな感じでいかがでしょう。

それぞれのテーブルを結びつけるのは[番号]というフィールドです。まあ、フィールド名は何でもいいですよ。ただしデータの型は統一してくださいね。
つまり、[料理テーブル]の[番号]はテキスト型なのに[材料テーブル]の[番号]は数値型、なんてことにならないように、ってことです。