- ベストアンサー
ACCESSのフィールドに複数の情報を載せたいときは？
初めてACCESSでデータベースを構築しています。お教えください。 例えば「Aさんがカキを1つ買いました。」という伝票のデータベースは構築できました。お聞きしたいのは「Bさんはカキを1つ、と同時にクリも1つ買いました」という同時に「２品目」を買った場合の時の事です。 「２品目」というフィールドを作るのが良いのか、レコードを新しくした方が良いのか、それともそれ以外の方法（「1品目」に複数入力できる←これが出来れば一番良いんですが…）があるのかお教えいただきたいと思います。 よろしくお願いします。
- みんなの回答 （7）
- 専門家の回答
質問者が選んだベストアンサー
いわゆる請求明細という問題だと思います。これを簡単に解決する方法は請求マスタを作成し、明細テーブルを作り、主キーか何かで関連付けする方法です。明細項目数の上限が決まっているなら、1つのテーブルに明細を作成してもかまいませんが、明細がいくつになるか不明という状況なら、明細テーブルを別に持った方が拡張性に優れていると思われます。
その他の回答 (6)
- imogasi
- ベストアンサー率27% (4737/17069)
データデース設計の、大切な、しかし絶対正しいというのはない事項だと思いますが。私の経験から ＞２品目」というフィールドを作る 最悪 カキとクリの変化に対応しづらい。カキ・クリなど数の突出的増加分に対応しづらい。 取引数などは、捉えやすい。 ＞レコードを新しくした方が良いのか レコード間の処理はVBAなど使える人は良いが、クエリSQLなどでは、前後の両レコードの関係いとして捉えるのは、難しい。 カキ・クリなど数の突出的増加分に対応できる。 取引数は、レコード数でなく、別途カウント必要。 ＞フィールドを分ける方法（当然限度があるので、増やしても、オーバー時に困るが） 第２のお勧め。 フィールド間の横の関係で抽出はクエリ・SQLでやさしい。 結局、自分の対象業務の検索の多いパターンに便利なように設計すべきでしょう。精緻なプログラムを組める人はどうでもなりますが、主にそのシステムのメンテを扱うひとの技量も影響します。
- hitokotonusi
- ベストアンサー率52% (571/1086)
多分、お持ちのACCESSにはNorth Windデータベースがサンプルでついていると思いますので、それを一度いじって見ることをお薦めします。このデータベースの受注フォームがおそらくおやりになりたいことなのではないかと・・・・・
どうも、今一つ、質問内容が理解できません。 そこで、どうしたら質問者の質問が成立するのかについて考えてみました。 まず、リレーショナルデータベースの設計ではないことは明らかなようです。 そうすると、 [ヘッダー部] ID 長整数型 伝票日付 日付型 伝票番号 長整数型 [明細部] 顧客名 文字列型 商品名 文字列型 数量 整数型 という設計が想定されます。 [ヘッダー部] ID 長整数型 伝票日付 日付型 顧客名 文字列型 伝票番号 長整数型 [明細部] 商品名１ 文字列型 数量１ 整数型 商品名２ 文字列型 数量２ 整数型 ・・・・ 商品名７ 文字列型 数量７ 整数型 という設計ですと、質問自体が成立しません。 売上伝票、請求伝票は、顧客単位発行するので[顧客名]はヘッダー情報に一つあればいい訳です。 [商品名]、[数量]は、１個も２個も発生するので、通常、明細行を７行程度必要とするでしょう。 ********************************************************************************** ここまでの設計が出来たら、次のステップは、主表=ヘッダー部、従表=名細部という表の分割だと思います。 ＊質問者が現行のテーブル設計を示されると、問題点が明確になりそうですが...
- adaypajimy
- ベストアンサー率20% (201/964)
３品目の時はあるのでしょうか？今現在作成しているのは「明細テーブル」だと思いますが… 下記の方がおっしゃるように、レコードに毎に記述するべきです。例えば同じ注文があった際にNo2さんのテーブルのままだと同じ注文が幾つもあって分からなくなる可能性があります。明細番号というフィールドを加えて、１回の注文として明細テーブルの各レコードをまとめる必要があります。 こうしておいて、同じ明細番号で選択したレコードを伝票に並べて書き出すことができれば、Ｘ品目の品をＸ個、購入されても対応できます。 そして更にこのテーブルを管理する、明細番号によって顧客名や商品名に関するテーブルをつけて、整合性をとりやすくします。 でも、こうなるとデータベースを細部から全体を構築しているので、正攻法ではない気がします。正規化や構築法をどうすべきかは、こういう場ではやはり字数が足りないと思います。データベースは奥が深いです。機会があったら勉強してみてください。私も勉強の身です。まちがっていたらすみません。参考↓
お礼
アドバイスいただきありがとうございました。参考のURL見させていただきました。おっしゃるとおりデータベースは奥が深いというのを実感させられました。
- mshr1962
- ベストアンサー率39% (7417/18945)
例でのテーブルのフィールド（最小の場合）は「購入者」「商品」「個数」ですよね。 後で購入者、商品ごとの集計があるなら別のレコードがいいのではないですか？ 入力時の問題なら、サブフォームを作って購入者単位に複数行の入力を行うようにすればいいかと思います。
お礼
アドバイスいただきありがとうございました。仰せのとおり「サブフォーム」も何とかでき、無事形にすることが出来ました。ありがとうございました。
テーブルの構造ですか？ 通常は２品目というフィールドを追加することはしません。 例えば、品数などのフィールドを設けます。 例 ・購入日時 ・名前 ・品数 ・品名 のようにし、 2005/1/11 Ａさん １ カキ 2005/1/11 Ａさん ２ クリ とすることで、何個でも購入可能なテーブルになります。
お礼
ご回答いただきありがとうございました。また、御礼が遅くなり申し訳ありませんでした。ファイルメーカーPROは使ったことがあり、そこでは、「繰り返し入力」というものが出来ましたが、ACCESSにはないようですので、ご回答のとおり作ってみました。なんとかなったと思います。ありがとうございました。
お礼
ご回答いただきありがとうございます。急な出張等でお礼が遅くなり申し訳ありませんでした。ご回答に従い、なんとか満足いくものにたどり着くことが出来ました。ありがとうございました。