宜しくお願いします。
テーブル構造をどのようにしようか悩んでいます。
顧客情報に関するテーブルですが。
フィールドは、
顧客ID
顧客名
顧客名フリガナ
顧客名略称
拠点名（工場名や事業名）
都道府県
所在地_市区町村番地
所在地_建物名等
電話番号
FAX番号
郵便番号
営業担当者
これに請求先情報と支払情報を加えたいのですが。
請求情報
請求先名
請求先郵便番号
請求先住所
請求先担当者
支払情報
支払形態 （振込 or 電子債権）
金融機関名
支店名
預金種類（普通 or 当座）
口座番号
口座名義
登録番号
問題は、顧客IDが同じ会社で複数あります。
例えば、A社のA工場とB工場など
（顧客IDは工場や事業所単位で取ります。）
その場合、同じ会社なので、請求先情報と支払情報が同じになります。
なので、顧客テーブルにそのまま請求先情報・支払情報のフィールドを作成すると、
同じ会社の複数のレコード間で同じ請求先情報・支払情報のレコードができてしまいます。
請求先情報テーブルや支払情報テーブルを作成して、顧客テーブルとIDで紐づければと思いましたが、
顧客テーブルに登録の際、請求先情報のIDを検索して入力というのも、どうかと思いました。
ユーザー側としてはすんなり請求先情報を入力したいかなと思い。
ご意見をよろしくお願いいたします。
専門学校などで基礎を勉強するのはどうでしょう？
回答の前に確認ですが、
請求書の発行は、会社単位でまとめてするのですか。
それとも工場や事業所単位で発行するのですか。
hatena様
請求書の発行は会社単位でまとめる会社もあれば、
工場・事業所で発行する会社もあります。
これに関しては、「オートルックアップクエリ」という機能を使えば、顧客IDと紐づいた請求先情報、支払情報を参照して出力することが可能です。
「Access オートルックアップクエリ」でWEB検索すると解説ページが見つかるのでそれで研究してみてください。
hatena様
オートルックアップクエリを調べてみました。
顧客IDは連番数字なので、どの顧客が何番かは検索（検索フォーム等で）しないとわかりません。
ざっとオートルックアップクエリをネットで見てみた感じの感想ですが、よく研究してみます。
すみません。
「請求先情報テーブルや支払情報テーブルを作成して、顧客テーブルとIDで紐づければと思いましたが」
というのは、請求先情報テーブル、支払情報テーブルのフィールドにそれぞれ請求先情報ID、支払情報IDを主キーとして設け、
顧客テーブルにも請求先情報ID、支払情報IDを設け、リレーションで紐づけるという意味です。
ユーザーは請求先情報、支払情報を入力する際、請求先情報IDが分からないので、検索しないといけなくなるかと思います。という意味でした。
上記の点は了解しました。
もうひとつ確認したいのですが、請求先情報テーブルと支払情報テーブルというように２つに分けるのはどういう理由でしょうか。請求先（会社）と支払情報は一対一の関係ならば分けずに一つにまとめたほうがいいでしょう。
一つの会社に対して支払先が複数ある（一対多の関係）ならば分ける必要はありますが。
一対一の関係ならば請求先情報と支払情報をまとめたテーブルを作成してこのテーブルの主キーを顧客テーブルに外部キーとして持たせて、クエリでリンクさせればオートルックアップ機能が働くので検索せずとも自動で表示させることは可能です。
hatena様
請求先情報テーブルと支払情報テーブルは分ける必要はありませんでした。1つにします。
作成中の画面をアップします。
画面上下スクロールで合計2枚です。
オートルックアップ機能をやってみます。
会社単位でまとめる場合もあるのなら、
会社と工場・事業所は一対多の関係になるので、データベース設計の基本としては、
一側から先に入力してから多側を入力するというのが基本になります。
会社マスターの方に会社情報、支払情報データを持たせます。
私がマスター登録フォームを作成するなら、メインサブフォーム形式にして、
メインフォームに会社マスター、サブフォームに工場・事業所テーブルを配置するという設計にしますね。
hatena様
ありがとうございます。
その場合の設計は
メインフォームの元テーブルのフィールドは
会社ID
会社名
住所
など
サブフォームの元テーブルのフィールドは
事業所ID
会社ID
事業所名
住所
など
会社IDで紐づけ、事業所IDを主キーにする感じですか？
売上が工場・事業所なので、
売上入力の際は、売上先顧客のフィールドとしては、事業所IDとするのでしょうか？
ただ、工場・事業所がなく本社のみの会社もあります。
もうひとつ面倒なことがありまして、
支払いを、本社がする場合と各工場・事業所がする場合があります。
なので、支払情報が会社マスターにだけでなく、工場・事業所マスタにも必要となります。
これに対するひとつの解決法としては、下記のような設計にします。
メインテーブルには会社名、代表者名、支払先情報などの共通データを格納（会社マスター）
本社と各工場・事業所データはサブテーブルに格納する(本社・支社マスター)
このテーブルには種別フィールドを追加して、そこで本社か支社か区別できるようにする
これは、ルックアップ機能で参照するようにすればいいでしょう。
上記の投稿は私のものです。
外出先からログインせずに投稿したので名前なしになりました。
hatena様
メインテーブルに会社のデータと支払情報のデータを格納し、
サブテーブルに本社・支社区分と住所のデータを格納するような感じの設計になるということでしょうか。
支払に関しては、本社が支払う場合と工場が支払う場合とでは口座が違うので、メインには格納できないかと。
かといってサブに支払情報を持たせると、
ある会社によっては複数ある工場が同じ支払情報を持っているので、同じ支払情報のデータが重複してテーブル内に格納されます。
話が食い違っていたらすみません。
そういうことなら、両者の関係は一対多の関係になりますので、口座情報は別テーブルにすればいいでしょう。
一例をあげると下記のようなテーブル構成になります。
会社マスター
※会社ID
会社名
代表者名
・・・
本社・支社マスター
※本社・支社ID
会社ID
支払口座ID
本社・支社区分
本社・支社名
住所
・・・
支払口座情報
※支払口座ID
金融機関名
支店名
預金種類（普通 or 当座）
口座番号
口座名義
・・・・
リレーションシップ設定
会社マスターﾎ.会社ID → 本社・支社マスター.会社ID
支払口座情報.支払口座ID → 本社・支社マスター.支払口座ID