ACCESS テーブル作成にアドバイスください

質問

初めてACCESSに取り組んでいる超初心者です。2007使用ですが、勤務先で使えるよう、2003形式で保存するつもりです。
社内での物品請求、払い出しのような業務で使おうと思っているプログラムで、最終目的は、個人別注文(請求？）伝票の印刷と物品数量の集計（フロア毎）です。注文伝票は前回分として印刷し、次回注文時に必要に応じて訂正して利用してもらうことを考えています。
次のような感じの伝票です。

３F　　　山田太郎　　　　　請求種別A
１）　商品A　　　　　1個
　　　商品B　　　　　2個
　　　商品C　　　　　1個
　　　　　　　　定型文1
２）　商品A　　　　　3個
　　　商品D　　　　　3個
　　　　　　　　定型文2
３）・・・

・1人の注文伝票の中に注文番号が複数（多くて20くらいまで）、注文番号１つにつき商品が複数と定型文が1つ。
・1枚の伝票の中で、商品、定型文は重複して使用される。
・注文番号は全体の通し番号でなく、1枚の伝票のなかで必ず１から順につくようにしたい。
・注文番号のふりなおし（並べ替え）と商品の並び順も変更できるようにしたい。
・直近の請求内容が分かればよいので履歴はとらず、変更をしていければよい。（あまり難しいことはできないので）

書籍にある注文関係データベースの例を参考にして、社員テーブル、商品テーブル、注文テーブル、注文詳細テーブルを作ってみたのですが、注文関連のテーブルをどのようにすればよいかよく分かりません。現在とりあえず作ってみたのが
注文テーブル：注文書番号(オート）、社員ID、請求種別
注文詳細テーブル：注文詳細番号(オート）、注文書番号、商品ID、数量、定型文ID、注文番号(並べ替え用）
です。（注文書番号にリレーションシップ設定）
これだと結局同じデータ(定型文など）を何度も入力しないといけない気が・・・
長文ですみません。アドバイスよろしくおねがいします。

回答No.2

CHRONOS_0 · ベストアンサー

>特定個人の前回注文データを呼び出し、回ってきた注文票と同じになるように修正を加え
以前のレコードを新規レコードにコピーし、変更点だけ書き換えます
こうすれば新しいレコードが登録されます
以前のレコードを書き換えたのではそのレコードが消えてしまいます

>実務で必要な番号で、
ということが管理に使っているということでは?

>1番は1番と書いた袋に入れて渡す。薬は毎回ほぼ同じだが、時々変更がある。
>毎回1から続き番号がふられていて、順番や番号は勝手に変えられない。
グループとして管理するという感じかな

だったらテーブルは3重の階層構造より2層にしておいてグループを指定してやるというほうが簡単みたいですね

[伝票見出し](伝票番号、顧客ID、請求種別）
[伝票詳細](伝票番号、注文番号、商品、数量）
[注文番号マスタ](注文番号、・・)

お礼

＞[伝票見出し](伝票番号、顧客ID、請求種別）
＞[伝票詳細](伝票番号、注文番号、商品、数量）
＞[注文番号マスタ](注文番号、・・)

この場合、[伝票見出し]では伝票番号が、[伝票詳細]では注文番号が主キーになりますよね？とすると、[注文番号マスタ]に入るフィールドは注文番号、グループ番号（実際にレポート時に表示したい番号）と、定型文ID・・・でよいのでしょうか？

3層の場合は次のように想像したのですが・・・
[伝票見出し]伝票番号(主キー）、顧客ID、請求種別
[伝票中見出し]伝票番号、注文番号(主キー）、グループ番号(注文番号として表示したい番号を手動入力）、定型文ID
[伝票詳細]注文番号、伝票詳細番号(主キー）、商品ID、数量

回答No.3

CHRONOS_0

3層の場合はそれでいいです

ただし2層にする場合は
>番号ごとにひとまとめにして渡します
ということですから
注文番号は複数レコードで同じものがでてくるはずですから主キーにはなれません

もうひとつ中身が分からないので詳細の主キーまで考えられないのですが
同じ注文番号で同じ商品が無いのなら
伝票番号、注文番号、商品の3つで主キーにするか
詳細行ナンバーのようなものを導入し
伝票番号と行ナンバーの2つで主キーにします

お礼

詳細行フィールドを導入するのがいいように思います。
まずは2層で作ってみます。
まだまだ先は長そうなので再度質問することがあるかもしれませんが、そのときはよろしくお願いします。何度もありがとうございました。

回答No.1

CHRONOS_0

構想の中で問題は
>・直近の請求内容が分かればよいので履歴はとらず、変更をしていければよい。
データベースではこのような考え方をしません。（この考え方はExcelのような表計算のものですね）
発生したデータを次々と溜め込んでいきます
(何時の注文というようなことは重要な情報として残す必要があるのでは)

アップされた情報の中でよく分からないのが注文番号ですねこれはどういう理由で分けているのでしょう
分ける必要性があるのだとテーブルは
注文大見出し、注文中見出し、注文詳細の3段階の親子関係になりますね

>・注文番号のふりなおし（並べ替え）と商品の並び順も変更できるようにしたい
注文番号は管理に使用しているのじゃないのですかだったら途中で変更したりしたら混乱しますよ
ただのお飾りならテーブル設計にも影響してきます

>と商品の並び順も変更できるようにしたい
データベースではレコードの順番には意味がありません
逆に並べたい順番があるのならそのためのフィールドが必要です

お礼

回答ありがとうございます。やっぱりわかりにくいですよね。
現状を言いますと、例のような手書きの伝票が週1回まわってきます。注文伝票の枚数が多い上内容は毎回ほぼ変わらないので、物品を予め用意しておいて、最終チェックをして渡しています。業務自体は注文票さえ回ってくればできるのですが、手書きゆえの書き間違い等で確認に時間をとられています。注文内容を予め前回通りにプリントアウトして渡しておけば、次回は部分的に加筆訂正するだけでよいのでお互い楽になると思いました。やりたい作業としては、特定個人の前回注文データを呼び出し、回ってきた注文票と同じになるように修正を加えて登録、次回用に印刷という感じでしょうか。履歴は現段階では利用していないので、直近のデータを修正でも良いかと思ったのですが、履歴をとっておくに越したことはないという感じです。
注文番号は、管理というよりは実務で必要な番号で、（番号ごとにひとまとめにして渡します）レポートの段階で入れば良いです。並べ替え用のフィールドということになるでしょうか。
薬の処方箋が一番近いかもしれません。
１）薬品A　　1個
　　薬品B　　1個　　1日1回朝　とか。
で薬を番号(飲み方）ごとにまとめ、1番は1番と書いた袋に入れて渡す。薬は毎回ほぼ同じだが、時々変更がある。毎回1から続き番号がふられていて、順番や番号は勝手に変えられない。
具体的にこんな内容のテーブルを作るといいんじゃないかというのがありましたら教えてくださるとうれしいです。