Essay集:AccessClub


[HOME]
4.テーブルの考え方

2000/1/27
テーブルの作成は、簡単なようで難しいですね。

皆さんも何気なしに「あ、この項目もいるな…」てな感じで、フィールドを作成しているんじゃないですか?
私の経験から、最初に作ったアプリ(らしきもの)は、後で見るとテーブルで失敗しているのが多いですね。拡張性に乏しいとか、満足なフォームやレポートが作れないとか、このような場合はテーブルに問題がある場合が多いです。心当たりありませんか?

問題があるのは、「フィールド」の決め方じゃないでしょうか。
例えば、一例を挙げると、スーパーマーケットでレジ毎の日々の売上金額のデータベース化を考えます。その日の最後に入力すると考えて下さい。テーブル名は「tbl_売上」とでもしましょうか。フィールドには「ID」のオートナンバーと「日付」、次に「レジavとして、別テーブル「tbl_レジ」とリレーションを結ぶやり方と、「レジ1」、「レジ2」…というようにレジのフィールドをどんどん作成し、リレーションと縁がない方法とがあります。

これらには、それぞれ問題点があるんですよ。

前者の「リレーションを利用する方法」ですが、当然これらはメインとサブの関係ですから、レジb入力し金額を打ち込んでいきます。
例えば、売上のないレジがあったとします。
この場合でも、"0"という金額を入力する必要があるんですよ。でないと、入力漏れなのかどうか判別できなくなります。フォームやレポートでも、そのレジだけデータが飛んでしまうことになります。
よって、売上が無いということは稼動していなかった、つまりレジ担当者がいない訳ですから、管理者は必ずデータ入力を行わなければなりません。

次に、後者の「リレーションを利用する方法」、つまり「レジ1」、「レジ2」…とフィールドを設けるやり方ですが、レジ担当者別に入力させるとすれば、その都度全レジのフィールドが効果を持ちますから、膨大なテーブル容量が必要となります。
また、項目が散らばっているので集計クエリを多用せねばなりません。管理者がまとめて入力する場合は問題ないですが、管理者宛ての「入力一覧表」なるものが別途必要になりますね。

このように、テーブルのフィールドを決めるときでさえいろいろな選択があり、その後の構成に影響を及ぼします。それとチェックボックスがありますね。性別とか要不要の区別とかにお使いだと思いますが、データベースの対象が広がっていくと、いろいろと不都合が出てくる場合があります。

例えば、アンケートや市場調査の場合、何も記入していない場合だとか、"どちらでもいい"との回答があった場合です。慌てますよ。こんな時は、テキストボックスでコンボ入力した方がいいです。


格言 :  テーブルやフィールドの採り方でデータベースの構成が決まる!
格言 :  安易にチェックボックスを使うな!


BACK

Microsoft Access Club


- Genesis -